I have Windows and Forms Based Authentication enabled for my Web Application.

All three web.configs (Central Admin, Security Token Service and Application) are correctly configured to use a custom membership and role provider.

In Central Admin, I can use the People Picker to find SQL (i.e FBA) users using my custom provider and set these as admin for the Web Application.

When I log into the web application using either a Windows or Forms user, the behaviour is the same for both, I can use the application but I cannot find other FBA users or roles using the people picker.

In debug my custom provider is hit both when finding users with the people picker in the central admin and when logging into the web application with a FBA user.

When I use the people picker in the web application the custom provider is never hit. This makes me think it must be a configuration issue?

I have very thoroughly checked the web.configs to ensure the correct entries are in all three for the providers and in both the central admin and web applications for the PeoplePickerWilcards configuration.

I have searched extensively here and elsewhere and followed all configuration suggestions I can find to no avail.

I have a web application working with the default ASP.NET membership provider and using this the people picker works. Alas I can't see any difference in configuration.

3 Answers 3


Sounds like maybe you didn't configure the People Picker Wildcards in the web.config file? (I'll delete my answer if this turns out to not be the case as FBA is VERY finicky about how its configured and it could be a million different things!)


  <clear />
  <add key="AspNetSqlMembershipProvider" value="%" />
  <add key="fbaMembers" value="%" />
  • I have exactly the same configuration for PeoplePickerWildcards in the web.config for the SharePoint Web Application as I do for in the web.config for the Central Admin site where people picker is finding users from my custom provider. As I said I have very thoroughly checked configuration for both the providers. I'll update here if/when I eventually find the problem. Commented Mar 13, 2012 at 7:53
  • As you will see I found the problem and have posted the answer. Interestingly it seems the PeoplePickerWildcards configuration has absolutely no effect on the web application at all. I can completely delete the section from the web.config and the picker still works and still finds results correctly for partial searches. This doesn't appear to be the case for the central admin site though where the configuration is required. Why am I not surprised! Commented Mar 13, 2012 at 14:29

The problem is that the login process whereby the user is authenticated and gains access to the application uses a different account to access the SQL database to the process which fills the people picker. This explains why I was, with the same configuration, able to login with a user that I then could not find with the people picker. Specifically the picker is using the NT AUTHORITY\IUSR account whereas, presumably, the authentication process is using the service account I configured in the central admin when creating the web application. Giving this account access to the database resolved the problem.

What I don't understand is why this isn't the case using the standard membership provider. I can only assume that in creating the database using aspnet_regsql the access is configured differently though I could see no difference when looking at the two in management studio.

Finally a note on why I didn't see this earlier. It would appear that there is some sort of caching of membership provider responses as with debug enabled the custom provider code only seemed to be hit the first time after performing an iisreset.

  • what kind of access? I have a similar problem and giving nt authority\iusr datareader access didn't help
    – Matt
    Commented Jan 8, 2013 at 16:56
  • This was some time ago, however it would appear that giving the IUSR account read/write permissions on the membership database resolved the issue for me. If you have the exact same issue (ie. FBA works everywhere except the people picker in the SharePoint application) perhaps your IIS configuration is set to use a different account? Commented Jan 9, 2013 at 8:30
  • 2
    how would I find out which account the people picker is using?
    – Matt
    Commented Jan 9, 2013 at 16:20
  • As it was the IUSR account for me perhaps the anonymous account in IIS? One way to check if this is actually your issue would be to run SQL Profiler on the database server and see what is happening, I expect that is how I debugged it. If your not working with a public facing application then you could open up your membership database to basically everyone just to test if that fixes the issue and then at least you would know you were looking in the right place. Commented Jan 9, 2013 at 19:56

Make sure that your applicationName parameter is set correctly in the provider config. I think this might need to have a value of "/" by default, but it depends on how you configured Sharepoint.

<membership userIsOnlineTimeWindow="20" defaultProvider="EfMembershipProvider">
    <clear />        
    <add name="EfMembershipProvider" type="Company.Namespace.EfMembershipProvider,MyDLL" connectionStringName="ApplicationServices" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" applicationName="/MyApplication" />
  • I'm using a custom provider which is written specifically for this application and hence I don't have ApplicationName fields in my database schema and am not using the application name property to filter results when accessing the database and therefore am not even reading this value from the configuration. I think this is the only use of this property? I tried with it hard coded to '/' anyway but no change. I didn't expect it to make any difference as it works everywhere else except the people picker on a site collection but worth a try anyway. Commented Mar 13, 2012 at 8:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.