I’ve not put my hands on SharePoint for quite a long time since I involved in managing SharePoint team and a few start-up SharePoint-based products as an investor and advisor. This would make technical-focused skills in my brain be fired progressively.
Today I had to look at Form-based authentication (FBA) configuration issue that one of a great guy in my team was working on. You know dealing with authentication issues wouldn’t be sweet at all. Such things would unexpectedly come in a bad way it shouldn’t. We had a working FBA solution in our internal development server. With the same steps, the developer got in the staging server to edit machine.config file (%windir%Microsoft .NETFramework<version>config) with some changes on connection string because lots of articles telling him about machine.config file. After that, he went to Central Administration to create a new site collection. SharePoint threw the following error on your web.config of Central Administration web application.
In ULS log, I found the same thing:
“An exception occurred in Forms claim provider when calling SPClaimProvider.FillResolves():Default Membership Provider could not be found. (C:inetpubwwwrootwssVirtualDirectories28342web.config line 621).”
Investigated a little more in the Central Administration web.config at 621, I found nothing but default role and membership tags. Everything was checked carefully i.e. connection string, name of role and membership provider, membership database. The error got still thrown out addressing Central Administration web.config file after we created a new site collection.
I then clear added FBA parameters in machine.config then configured for each web.config respectively but still kept a copy of machine.config for investigation. Finally it worked like a charm. How did the error come?
I realized that two potential problems. The first one was that no membership provider in our machine.config had been specified default provider even the custom one. The latter was that someone deleted the generic default provider named “AspNetSqlMembershipProvider”. Combining with what machine.config was functioning, I then came to conclude that adding AspNetSqlMembershipProvider or specifying default provider (by adding defaultProvider) would be a walkaround. I tried to go back with machine.config with one change for default provider. Finally, it worked.
Firstly, I’m not really keen on making changes on machine.config file for FBA solution even it would be the fastest way to get things done. It contains settings you can set to globalize configuration to all web.config files in IIS. Specifically in SharePoint, if you add connection string, you don’t need to add it again in each web.config file of SecurityTokenServiceApplication, Central Administration and your (intranet) web application. Configuration is set in one place so you don’t have to have the same settings in two different web.config files. This sounds like a flexible approach, doesn’t this? In testing scenario, this way is acceptable. In complex extranet SharePoint scenario that has multiple authentication providers, utilizing machine.config isn’t recommended. Someone may overlap your configuration when he adds his own configuration.
Be careful with machine.config when working on SharePoint Form-based authentication!