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 "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


6 comments:

  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.

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

    ReplyDelete
  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

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

    ReplyDelete
  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

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

    ReplyDelete