Recently I was contacted by an attendee from the SharePoint 2010 Ignite training I delivered in January to help out his firm, Envision IT, with a baffling problem. His team was under a lot of pressure to deliver a SharePoint 2010 portal that would allow extranet access – Forms Based Authentication is a natural fit. So they thought.
My former attendee, Mike, explained the problem: “We’re getting strange 500 internal errors when we try to log-in and there’s nothing in any of the event logs on the server.”
Strange. When I arrived on-site, Mike and his boss Peter walked me through the issue. They set up a basic 2010 web app and site, and were leveraging IIS7’s .NET Users and Roles providers to store credentials in a SQL database. All that was running fine – here’s what they demonstrated:
Exhibit A: The FBA Form
Exhibit B: The Fail
Strange. I enabled ASP.NET tracing on the login default.aspx page and saw the following details of the exception that was being thrown:
Claims Authentication Tag(fsq7) Request for security token failed with exception:
System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustChannel.ReadResponse(Message response)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustChannel.Issue(RequestSecurityToken rst, RequestSecurityTokenResponse& rstr)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustChannel.Issue(RequestSecurityToken rst)
at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForContext(Uri context, Boolean bearerToken, SecurityToken onBehalfOf, SecurityToken actAs, SecurityToken delegateTo) 0.0353631536969084 0.018933
This began to suggest that something in the configuration was amiss. Mike scared up a clean 2010 VM for me to play with and we started from scratch to build a “vanilla” 2010 FBA site. We reproduced the issue, so it wasn’t any of the customizations or settings they had on their original dev box. I was beginning to think that given the error message, something with the Secure Token Service wasn’t working as advertised – this, of course, is an integral part of SharePoint 2010’s Claims Based Authentication system which FBA sites now use to authenticate/authorize.
I sent a ping to a colleague who suggested I have a look at a recent post by Bil Baer on Claims Based Identity in SharePoint 2010 – specifically the section around how the STS is configured. The solution: We needed to add entries for the Role and Membership providers to the STS web.config and add a User Policy to the SharePoint web application to allow FBA user access. Also missing was a corresponding entry for the Membership provider in the Central Admin web application’s web.config.
Once this was done, authentication worked like a charm – case closed!
