The Claims Authentication Riddle - Part 3: First Level Support Conclusion

A short post to summarize the state of the matter revealed in my prior two posts (Part 1, Part 2) on the bizarre behaviours I've been encountering on behalf of my customer, Envision IT, with respect to SharePoint 2010 Claims Based Authentication. As indicated in my last post, we have initiated a support ticket with Microsoft to explore the issues we've seen (captured in a screencast that can be found in Part 2). This was sent to Premier Support, along with corresponding ULS logs: In the end, they had no explanation for what was causing the problems. 

So, I asked for an escalation to the next level which should be initiated some time today - I have no preconceived expectations here, but it would be nice to know why, precisely, FBA/CBA is such an untameable monster. In the interim, my customer opened a second support ticket to walk through setting up FBA on one of their integration servers that was acting ornery and not allowing the setting of permissions for Forms Based Users.

A bizarre (to me) outcome of this was the discovery that you don't need to add FBA users via User Policy in Central Administration for them to access a site collection. That's really, really, really interesting. Because just about every ounce of documentation that I've ever come across for setting up Claims requires this step to allow your FBA/Sql users into your web app. Even my first level of support indicated this as a required step. So what gives with that?

All this underscores a wide amount of confusion and lack of concise documentation from Microsoft on how to configure these environments successfully and repeatedly. Additionally, there is also the matter of IIS 7 integration when it comes to configuring the environments - effectively, you're better off modifying the web.config files for Central Admin, the Security Token Service and the target Web App manually rather than through IIS Manager. Part 4 should come later today or tomorrow.

Ongoing…