When clicking on FBA User Management I am getting the following error:
A Membership Provider has not been configured correctly. Check the web.config setttings for this web application.
I have already created database and the web.config has a provider in that was previously created, is there somthing I have missed?
Have you configured authentication in your SharePoint web application to use your membership provider entry? (Step 4 from http://donalconlon.wordpress.com/2010/02/23/configuring-forms-base-authentication-for-sharepoint-2010-using-iis7/)
Can you successfully log into SharePoint using Forms Based Authentication? (You should be able to do this even without the FBA Pack)
I am seeing the same error message, and I can log in using SharePoint FBA...
though, I am using AD LDS to store user credentials.
Do you have any ideas about what I can look for?
So you're not using the SQLMembershipProvider? This should work as long as all of the membership provider methods are implemented.
Another potential issue is that it is possible to login using FBA even if it's not completely configured properly. Only the SecurityTokenServiceApplication needs to be configured to login, but the but the web.config for the actual site needs to be configured for the FBA Pack to function. This is discussed here: http://sharepoint2010fba.codeplex.com/discussions/256360. I'd probably check the site in IIS and make sure that you see the membership and role provider that you use under 'Providers'. Also temporarily set them as the default providers and make sure that you can browse them using the IIS interface. Also make sure that they are selected and typed in correctly under 'Authentication Providers' in SharePoint.
I greatly appreciate that you take the time to respond to people like me.
I did have everything set up and working using SQL, but the guys who are responsible for security told me I could not use SQL and had to use AD LDS (aka ADAM). I tried, a little, to change their minds, but didn't want to waste a lot of time arguing over that.
So... I looked a the link you provided, and one major difference about my situation is that I did not extend the web app. I'm using both Windows authentication and FBA in the default zone.
I've spent a lot of time looking at various instructions regarding the setup of AD LDS and SharePoint 2010 FBA. It seems they all vary a bit. But, I was finally able to access my FBA user (the only one I've created in AD LDS so far), from a people picker in Central Admin. So, I am thinking and hoping that since the web.config for Central Admin seems to be setup properly that the one for the web app is also.
Could it be that FBA User Management is expecting fields in the user's record which are not defined in my AD LDS setup? Or, perhaps the fields are there, but empty, and that's a problem?
Also, I am not using a Role Provider for FBA since I don't need roles/groups for my situation; therefore, I have not added anything to the web.config files for Roles. (Anything that was there already, when SharePoint created the original web.config files, is still there.)
Could this be a problem? - even though I am not enabling Roles in "Manage Forms Based Authentication Configuration".
(I keep finding new information which is possibly relevant to this issue, so I'm editing this post from time-to-time.)
If I try to add my one user (from AD LDS) to a SharePoint group for permissions for my site collection, this FBA user is not found by the people picker. So, perhaps there is still something not quite right with the web.config for the associated web app.
You should definitely be able to find the users and add them to a group in your site collection, so I think there's still some configuration you have to do there. Missing the Role Provider should be ok, just the Role Manager won't work.
I'm not familiar with AD LDS, so unfortunately i'm not going to be much help with that. The FBA Pack wasn't tested against it, so I can't tell you if it will work or not. As long as the provider implements all the methods the SQLMembershipProvider does (and implements them the same way), it should work fine. So get it working properly with the group membership first, and then test it with the FBA Pack parts. You may want to set up the SQLMembershipProvider for testing, to make sure it works properly with that, and then move it to AD LDS.
If the FBA Pack doesn't work with AD LDS, then unfortunately some programming will probably be required. Probably the best way to deal with the problems is identifying the membership provider methods that work differently than the SQLMembershipProvider (or don't work at all). And then inherit from the AD LDS provider, and provide your own implementation of those methods.
Or maybe save yourself some time and just try and convince them again to use the SQL Membership provider. It is very easy to use and manage, and it's used by lots of sites out there (probably the majority of internet .NET solutions).
I checked all the methods provided by LdapMembershipProvider vs SqlMembershipProvider, and the only mismatch I can find is that the SQL version provides a GeneratePassword method, but the LDAP version does not. BUT, for all the LdapMembershipProvider methods, there is this statement: "This member is reserved for internal use and is not intended to be used directly from your code."
Could that be a problem?
Even if it is, though, I will have to solve my SharePoint group membership problem first.
All the methods will be there, but they're not necessarily implemented (or if they are implemented, they might work slightly different than the SQLMembershipProvider). That's the problem with built in SharePoint provider - a lot of the methods return a not implemented exception.
I have now solved my SharePoint group membership problem....
I had to add the security group used for the Application Pool for my web app to the Readers and Users Roles in my AD LDS instance.
So, I have a little more functionality now, but it does seem that some of the membership provider methods for LdapMembershipProvider are not cooperating with the code you have written.
I'm not likely to take on the task of providing the needed methods, so I am probably going to attempt (once again) to talk those who are responsible for security of our sites to allow me to use the SQL Membership Provider.
I have figured out why the functionality was limited when using LdapMembershipProvider and AD LDS.
The connection to the AD LDS instance must be a secure connection (SSL) in order to successfully complete any operation which includes the user's password (that is, creating or updating the password for a user).
In the process of attempting to create such a connection, which involved creating a certificate, etc., I damaged the virtual machine I was working on, and had to rebuild it.
So far, I have not gone back to re-attempt this. I am still hoping to convince "the powers that be" that the use of SQL to store user credentials is not a security risk.
I believe that it IS possible to use the LdapMembershipProvider with the SharePoint2010fba pack, but it's complicated (at least for me).
If you try again and are still having troubles, maybe try the ActiveDirectoryMembershipProvider instead of the LdapMembershipProvider:
But yeah, probably the easiest solution is to convince the "powers that be" to use the SQLMembershipProvider instead.
I think I am getting very close to making the SharePoint2010FBA pack work with LDAPMembershipProvider and AD LDS.
I am now seeing this error when attempting to create a new account:
The method or operation is not implemented.
...
Microsoft.Office.Server.Security.LdapMembershipProvider.get_MinRequiredPasswordLength()
I don't see that this method is implemented for the SQL nor AD providers either.
MinRequiredPasswordLength is a property of the class, but as far as I can tell, there is no get_MinRequiredPasswordLength() method to access that property.
Should I create one?
Hi,
I'm getting the same error. I want to use the User Mgmt. page to add forms auth. users. My providers show up when I look in IIS and my app. pool account is DBO on the SQL aspnetdb database. Is there any other way I can tell what's wrong/why this message is being shown?
Thanks.
- Ed.
If you are using the SQL aspnetdb, then you should be using the SQLMembershipProvider which has everything implemented. So you shouldn't be getting this error. Check your configuration against this link:
and please provide some more details if you continue to have the problem.
djklord:
Unfortunately what it's saying is that although the MinRequiredPasswordLength exists, it hasn't been implemented in this membership provider. The proper way to fix this would be to inherit from the LDAPMembershipProvider and implement any properties or methods that haven't been implemented. Alternatively, for a quick fix, you can modify the FBA Pack to work around the unimplemented function (but this would make it difficult for you to upgrade to newer versions, unless we merge your changes in).
Have you tried the ActiveDirectoryMembershipProvider to see if it implements the unimplemented methods/properties?
If I have time, I will try ActiveDirectoryMembershipProvider today.
It's a shame that these providers are released by MS - unfinished. It would be nice if they would at least explicity explain which parts are not fully implemented.
djklord
How did you get on with the ActiveDirectoryMembershipProvider? Have you had to implement any of the methods that Microsoft has not got around to finisihing. I am keen to do something similar in order to provide password self service foe my users. If you need someone to help you with the testing/ coding please let me know.
Regards
Daniel
Hello Daniel,
I have put my efforts to get ActiveDirectoryMembershipProvider working on hold, and am still hoping to be allowed to use the SQLMembershipProvider.
Here is what I wrote to my supervisor about my current situation with the AD provider:
Hi Djklord.
Yes, I do sense your frustration. Thanks for the heads up. I currently don't have any other solution for allowing my users to managed their passwords without having to consider a 3rd party application. So it looks like I will be going down the same path. Regarding point 3, I had couple of thoughts 1) have your deployed your dll to the gac rather than going down the trusted proxy sandbox solution. 2) I previously set up User profile sync service on my (personal) server farm running on my laptop. I know I had to set up specific user permissions to do this - I can be more specific once I log on later. I wonder if you could run the code that is giving you grief with elevated permissions / impersonating a user with the appropriate access permissions.
Ok time to go home. BTW, If there is any code you are willing to share that would be good.
Hello again, Daniel,
(BTW, the 'd' in "djklord" stands for "Dan" = my name.)
I am deploying my solution (.wsp file) to the GAC, so the .dll is going there.
I'm not going to even think about your point #2 unless I am told that I definitely cannot use the SQLMembershipProvider and have to pick this up again.
Also, I don't believe I have any code to share which would be helpful to you.
BUT, if you do get the ADMembershipProvider working with SharePoint2010FBA Pack, I would appreciate hearing details about how you managed to make it work.