I’ve been working on a frustrating problem with SharePoint 2010 RTM that I’m at a loss to explain. Initially, I thought it was me not having a thorough understanding of how to configure claims for forms-based auth. But now, after a few months of repeating the same steps over-and-over-and-over, I’m fairly confident that I do understand it – and I’ve successfully set up single web apps without issue (but which, in the end, display the same failings I describe below in time).
I’m now at the point where I keep doing the same thing expecting a different result – and we all know what that is the definition of. ;-)
As an aside – it is totally frustrating to see that documentation – and I mean SOLID !#$%^&* DOCUMENTATION from MSFT has been almost entirely lacking for configuring FBA using claims, and what does exist is pre-beta this, RC that and RTM the other. Completely unacceptable.
The Scenario:
What I’ve been seeing is a couple of weird behaviours. They all distill to authentication problems – either I can’t add users via the people picker, the dialog textbox or both, and those I do add may or may not get denied after being added via User Policy to the web app.
In an effort to clear this up, I created three identical web applications (Publishing template) on a virtual machine, each configured for claims based auth on the default zone: http://localhost, http://localhost:85, http://localhost90 . Each of these point to three different ASP.NET membership databases on a separate SQL 2008 box which were created using the aspnet_regsql wizard.
In IIS, I created connection strings and membership providers for each DB in the usual way – if you don’t know what the “usual way” is, there are a few blog posts that can help clarify what I mean. Essentially, there’s a Texas two-step hokey-pokey you need to do to add the providers for Users and Roles (groups) to ensure you get users from each ASP.NET membership DB.
After you do this for the target Web Application, you need to add corresponding entries in the web.configs for the Central Administration and Security Token Service web application.
In terms of process, I created and configured each web app sequentially – I wanted to see when and where things started to go sideways as web apps were added.
The Results:
The web app on port 80 was created and configured without issue – and I was able to get my test user, fbacchapman, to authenticate via the default login form without issue. I repeated the process for the web app on port 85.
Then, I added my final web app on port 90. Everything was going well until I tried logging-in with my test user, fbacchapman4. Access denied! The user has been added to the web app, everything is fine – he just can’t authenticate.
Then something really bizarre happened: I went back to my first web app on port 80 and tried logging in again with my fbacchapman user. Access denied!
Update: Failure x 3
Returning to the web applications today, I discovered that, for some inexplicable reason, all three now deny access to FBA users that should work! To show what I’m seeing, I’ve recorded a screencast that you can download here from my SkyDrive.
The Challenge to You, Gentle Reader: Repeat the Configuration – Prove or Disprove
I’d like to know if anyone else can replicate this configuration of three web apps configured for claims auth failing on the same box. For no outwardly explicable reason.