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 "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -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.

 -Antonio