Question

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.

Was it helpful?

Solution 2

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.

OTHER TIPS

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!)

http://msdn.microsoft.com/en-us/library/bb975136.aspx

<PeoplePickerWildcards>
  <clear />
  <add key="AspNetSqlMembershipProvider" value="%" />
  <add key="fbaMembers" value="%" />
</PeoplePickerWildcards>

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">
  <providers>
    <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" />
  </providers>
</membership>
Licensed under: CC-BY-SA with attribution
Not affiliated with sharepoint.stackexchange
scroll top