Access Denied Errors After Changing Authentication Provider Settings

Sometimes, we SharePointers take things for granted because we work with the platform on a daily basis and intuitively understand how things are supposed to function. Accidental site administrators, power users, and the poor folks in IT who’ve had SharePoint dumped in their lap through no fault of their own, can easily get frustrated by all the ins and outs when something they think should work just doesn’t.

Case in point. Some time back I implemented a small 2010 environment for a client. At the time, they chose to go with a mixture of NTLM and Claims authentication due to the nature of their workforce, many of whom were seasonal employees without AD accounts. So we did the FBA dance and they went on about their business. After using the portal for some time it became apparent that none of their FBA users were ever accessing SharePoint and the NTLM users were complaining loudly about the out of the box login page (which forces users to select their authentication type in an extended, multiple zone web app configuration). So they made what seemed to be a perfectly normal request – turn off Claims and revert to NTLM for all users.

In simple scenarios, this isn’t difficult – a little powershell to change the auth provider for the default zone and some web.config modifications to pull out all the role and membership settings (along with a couple of extra IISRESET operations ’cause you always forget about that pesky web.config in the SecurityToken directory and the people picker wildcard settings). This is not a good time to disconnect from the VPN and go catch up on all those CSI episodes you’ve missed because it’s right about then that all hell breaks loose – nobody can log into the portal anymore. It’s a big helping of accessdenied.aspx for everyone except the system account.

This is where the occasional site admins get frustrated. They can login as the farm account or system user but regular users are out in the cold. They spent a bunch of time adding all those people into SharePoint groups so they shouldn’t have to do all that again, right? Eh, not quite. If the web application was originally created in Claims mode it’s very likely that a bunch of user accounts were added from a membership database (usually an ASP.NET membership provider but it could be any other type of Claims-compliant provider). A quick glance into the site permission reveals the culprit – the system accounts are in a domain format (DOMAIN\Username) while the user accounts are in that oh-so-lovely Claims format (something like "i:0#.f|members|joesmith"). Even if they were domain accounts to begin with, you’ll still see them listed in claims format, such as "i:0#.w|domain\joesmith". In other words, your users don’t exist anymore as far as SharePoint is concerned because "domain\joesmith" is NOT the same person as "i:0#.w|domain\joesmith".

The fix is simple (if tedious) and is immediately apparent to any seasoned SharePoint admin – recreate group membership with the proper domain accounts after the claims provider has been changed. But that kind of thinking doesn’t come naturally to people who don’t eat, breathe and live SharePoint. To them, Joe Smith is Joe Smith and he certainly appeared as such when they selected his user account in the people picker. A bunch of mumbo-jumbo in front of the name (which sometimes isn’t apparent until you look at the user’s profile page) doesn’t mean anything to them. It’s easy enough to explain but that’s the point – we have to explain it. Just like the list = library conversation and the site collection/site/web relationship, these sort of things take a little extra mental processing to conceptualize – it’s not at all intuitive.

The moral of the story is obvious – validate changes before you implement them. But it’s also a cautionary tale on trying to think like a user and not like an expert. A few extra minutes spent explaining the wily ways of SharePoint can go a long way to empowering users to look after themselves. And that’s always a good thing (at least, I think it is, right?).