If you are using Forms Based Authentication and try to access Site Policies you may well find that you get an Access Denied response. If you do, this post will help you!
I’ve been meaning to post this for a while because I’m sure it may help somebody. As usual, it’s been pushed back and back until now I finally have some time. I also have another, workflow-related post on another problem which will follow shortly.
Problem Background
We have been working on a SharePoint solution which involves a large number of web applications, each of which is hosting an internet-facing site using SharePoint Publishing. Each of these web applications uses forms-based authentication (FBA) with the AD provider in order to provide a better user experience.
Why a large number of web application? The format of the required urls, and the number of urls per site led us down that path.
Why only FBA and not extend the web app to have one with FBA and one with windows auth? There are enough web applications already, and since we would almost never use the windows auth ones why load up the system?
One of the roles of these site is to allow end users to upload files. However, our customer wants the document library that is used for upload to automatically purge files after a given time.
No problem, site polices will do that…
The Problem Itself
Unfortunately, when you authenticate as the site collection administrator, or a member of the site owners group, or a farm admin, you can’t access the Site Policies administration pages within the site collection hosted in the web application that uses FBA.
We spent a while checking group memberships and trying different users, and we established that toggling between FBA and windows auth would make the problem go away. We then called in the Microsoft Support guys and continued to investigate. Those guys deserve a mountain of praise as they carefully replicated the fault and kept us firmly in the loop whilst working on the call.
Using Gary Lapointe’s stsadm extensions we were able to examine the rights granted to the admin user when the site used FBA. The gl-enumeffectivebaseperms command showed interesting results.
stsadm -o gl-enumeffectivebaseperms -url <url>
FullMask
stsadm -o gl-enumeffectivebaseperms -invert -url <url>
UseClientIntegration, FullMask
The first command tells me what rights I have. The second tells me what rights I don’t. Note the confusion!
It turns out that when using FBA, the rights are not correctly applied for full control. The Microsoft team provided a workaround, in that enabling Client Integration fixes the application of rights. You either do this using stsadm to reset the authentication provider:
stsadm -o authentication -rul <url> -type forms -membershipprovider <membership provider> -rolemanager <role manager> -enableclientintegration
Or through the central admin. We have lots of sites, so we do it through the stsadm route.
The Long-Term Solution
I have been informed by Microsoft Support that this has now been logged as a bug with SharePoint and that they are working on a fix. As soon as I know more, I will post again.