Wednesday, September 24, 2008

Access Denied For Site Collection Admins

...But I Can't Add Anymore Privileges

I was left scratching my head the other day when asked to troubleshoot a Access Denied error from SharePoint. These are normally a dime a dozen, but what separated this one is that the given user was already a Site Collection administrator for that site collection. In fact he also has Full Control on the entire Web Application through Web Application Policy.Access Denied, but to Site Collection Administrators!

The Delinquent Pages

The pages we were getting locked out of were themselves a clue, they were all User Profile and My Site related in the Shared Service Provider. User Profile/My Site links that were yielding Access Denied.

They were actually all layout pages, their URLs were:

  • /_layouts/ProfMain.aspx (User profiles and properties)
  • /_layouts/PersonalSites.aspx (Profile services policies)
  • /_layouts/ManagePrivacyPolicy.aspx (My Site settings)

Once we got digging into these pages it became pretty obvious what the problem was. In each of these layout pages was an AdminCheck control which required the user to have the ManagePeople privilege.

<spswc:admincheck requiredright="ManagePeople" runat="server" />

If you look up the AdminCheck class you can find it in the MSDN, and discover that it is "reserved for internal use and not intended to be used in your code", so not a lot of great documentation there.

The rights that drive the AdminCheck control are from the Microsoft.SharePoint.Portal.Security.PortalRight enum, which are quite different than those that drive the more popular SPSecurityTrimmedControl. The SPSecurityTrimmedControl is set with rights from the Microsoft.SharePoint.SPBasePermissions enum. It's the SPBasePermissions that you find scattered throughout SPSites, SPWebs, SPLists, and SPItems.

The Shorter Story

As it turns out you add these privileges by using the Personalization services permissions link which is embarrassingly (for us) located in the same place as the layouts pages that were throwing the error. Using this page you can associate the appropriate Microsoft.SharePoint.Portal.Security.PortalRight rights that will allow a given user access to these pages. Simply head into the Personalization services permissions page and assign the appropriate privileges. We ended up adding the Manage User Profiles permission which gave us the appropriate rights and banished our angry Access Denied demons.

Personalizatin services permissions page.

Hope that helps someone. I guess the moral of the story here is that there are other permissions besides SPBasePermissions in play within SharePoint. So there, you've been warned.

Stumbling along,
Tyler

7 comments:

LCUAdmin said...

This is exactly the problem I am having, Except I get an error when I click on Personalization services permissions page.

Now What???!!!

Tyler Holmes said...

If Personalization Services is a layout page found in the 12 hive (c:\program files\common files\microsoft shared\web server extensions\12\template\layout) then I would investigate the .aspx file for that url and see if it has the AdminCheck control and which privilege it has.

If it does you either remove the control temporarily or go about adding that privilege to your account.

Best,
Tyler

Charles Chen said...

Just a note: This may also be due to SQL Server permissions.

Namely, the content database of the shared services site may not be allowing the domain account configured for the application pool to access the database.

If this is the case, you should see an error in event viewer from the source Windows SharePoint Services 3 with category Database.

You will need to first ensure that the domain account which the application pool is running under has the proper rights to the content DB for the site.

I took the lazy route and just assigned db_owner :P but you may wish to be more stringent. After you grant access to the database, you need to follow the steps in this blog post to grant the SharePoint level permissions.

Anonymous said...

thank you thank you!

Mimi Jo said...

Awesome! Thank you! This is the fastest I've ever solved a problem. Now I hope my original problem can be solved on the Profile pages...
Thanks again Tyler!

Andrew said...

@LCUAdmin - I ran into this after changing to forms authentication. The creds that had access to this stuff were no longer valid. I was able to move forward by changing it back to windows authentication, adding the forms auth cred that was going to work with forms auth, and then changing it back to forms auth and using that cred. Hope that makes sense, even if it is a year late.

Shehzad Sheikh said...

check out my experience about the similar problem

http://social.technet.microsoft.com/Forums/en/sharepointadmin/thread/a42bdafd-98f5-4c77-a6df-1b637cba3c1a