Follow me on Twitter @AntonioMaio2

Tuesday, September 4, 2012

Configuring Site Collection Admin in a SharePoint 2010 Claims Enabled Web App

The other day I was working with one of my claims enabled SharePoint 2010 web application and I was logged in as (what I thought) was a site collection admin.  But, I noticed that some of the features that I should have access to on the site settings page for the root site were not available - features like configuring SharePoint auditing and audit trimming. 

I double checked I was logged in as an administrative user account. -CHECK. 

I double checked that I was accessing the correct web application URL -CHECK.

I double checked that I was accessing the root web site settings page, and that I was in fact missing links that a site collection administrator should be able to access.  -CHECK

I logged into SharePoint Central Admin and double checked that my administrative user account was configured as the site collection admin.  My user account was set as the Primary Site Collection administrator. -CHECK.

So, what was the issue?  In an attempt to resolve the issue, I reviewed the SharePoint authentication configuration for my web app. 

For my claims enabled web application I was logging in through ADFS 2.0 (Active Directory Federation Services) as a trusted identity provider and retrieving a SAML token.  When configuring a SAML trusted identity provider you need to chose an "identifier claim" - that is 1 claim which uniquely identifies every user in the domain.  I often choose email address claim because an email address must be globally unique. You must configure ADFS2 to return the email address attribute when a user logs into.  As well, you must configure your SharePoint 2010 trusted identity provider with your chosen identifier claim when registering the provider through PowerShell - this powershell configuration often looks like this:

$map = New-SPClaimTypeMapping -IncomingClaimType "" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
# Define other variables... cert, realm, signinurl...
# Adds the STS to SharePoint
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS20 Provider" -Description "SharePoint secured by ADFS20" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl $signinurl -IdentifierClaim $map.InputClaimType
In the past, I have run into issues logging into SharePoint when configured as such if the email address attribute is no populated in AD (Active Directory).

So, I double checked that my administrator user account had a valid email address and it did.  -CHECK

I checked the Central Admin site collection administrator configuration again, and found that I had configured my Primary Site Collection admin with the AD username 'SPDEMO\administrator' which normally would work fine in a non-claims enabled web app.  So, I decided to try changing it to the identifier claim:  administrator@spdemo.titus.local.

I logged in again and found the same thing was happening.  I would navigate to the site settings page for the root site and would only see links that a site owner would see, and not links that a site collection admin should see.

So, I returned to the Central Admin site collection administrator configuration page reset my Primary Site Collection administrator to 'administrator' and set my Secondary Site Collection Administrator to the identifier claim: administrator@spdemo.titus.local.  As in the following:

Voila!  When I logged back into my claims enabled web application as the same user, I was now in fact a site collection administrator.  I could now navigate to the Site Settings page in my root site and I could see the links that should be available to a site collection admin:

So, it turns out that in a claims enabled web application a site collection administrator needs to have both their AD domain\username and their identifier claim set as the site collection administrator identity.



  1. Only if they (the site collection admin) logs into both zones, which isn't typical in a non-SharePoint Administrator role. Actually, even a SharePoint administrator has limited needs to log in to the zone used by application users. Other than testing purposes, and I would say use an account (test account or other) that doesn't have the privileges a typical admin account would on the server or SharePoint farm. Using administrative accounts can mask errors that less privileged users would see. Plus, using IDP logins when you are only doing admin work just introduces other variables that aren't necessary. When possible, only login to the Windows auth zone.

  2. This post provide me good information about how to enable web application in sharepoint 2010. US web app development

  3. Don't clone a website for mobile devices and say we're done. You must customize the mobile app in the context of users. Desktop computers to mobile conversion may be easy but there are lots more in it. You can get all things done in a mobile as you do those in your website. The likely scenario is to save time using the mobile app while you are standing in a queue and want to finish things with your brand. But you are probably not going to accomplish everything from your mobile phone while you are waiting. mobile phone tracker

  4. In an attempt to resolve the issue, I reviewed the SharePoint authentication configuration for my web app. web design tips

  5. Get the IIM edge in IFBS, New Delhi.Only B-School with faculty from India's premier B-Schools and an all IIM-A alumni management . Placement network across IITs and IIMs recorded highest avg.placement package in Delhi/NCR.

    Banking PGDM Institute in Delhi

  6. Going through something so fantastic has a retouching power for the heart and mind.
    landing page

  7. Hi admin.Great post.Thank you so much for sharing about Claims Audit Enabled Web App.Keep in blogging.. Warehouse Audit


  8. This is genuinely an awesome read for me. I have bookmarked it and I am anticipating perusing new articles. Keep doing awesome!
    Web Development


  9. This is genuinely an awesome read for me. I have bookmarked it and I am anticipating perusing new articles. Keep doing awesome!
    Web Development

  10. Thanks for sharing this valuable and interesting article with good content stuff.Keep in blogging. AP Vendor Helpdesk | Internal Audit | Fraud Dectection

  11. Often purchased themes are so rigid that even moving an element from one part of the page to another is impossible to do with this type of limited knowledge.

  12. I have been checking out a few of your stories and i can state pretty good stuff. I will definitely bookmark your blog.
    software development company in delhi

  13. I encourage you to read this text it is fun described ...
    mason soiza

  14. Remember, a good web application development firm will not only deliver an exact web application to automate your online business processing, but also get into online promotion for your website.skrajučių gamyba

  15. You absolutely can't turn out badly in view of composing with your crowd: what you need is to sincerely associate with your prospects,seo services company in gurgaon and do whatever it takes not to sustain an undeniably flighty mammoth that Google has transformed into.

  16. When it has to do with web design, it is necessary to consider creatively. Today, web design is connected with the accumulation of income of the company a significant concern in an easy way.web designer nuneaton