RSS

Category Archives: Claims

SharePoint 2010 adding Relying Party trusts to Existing Provider

How shall I edit my existing provider to add more Relying trusts? I might create new web applications which needs claim auth from same provider.

Simple powershell commands to do this

$newtrust = Get-SPTrustedIdentityTokenIssuer -identity “Current Providername”

$uri = new-object System.Uri(“https://a.contoso.com”)

$newtrust.ProviderRealms.Add($uri, “urn:sharepoint:hh”)

$ap.Update()

 

Tags: , , , ,

SharePoint 2010 Claims: Migrating Windows users to Claims users on existing sharepoint site

would like to migrate all  existing web applications from Windows NTLM auth to Claims based authentication using WEB SSO.

We got the Claims provider setup and we tested the web single sign on test user and it is working fine. Now the biggest challenge is migrating the previous users and groups on the site collections to claims users. In sharepoint 2010 when a user or group is added the user or group is prefixed with some additional characters and stored in database. The additional prefix is to identify the user from which Auth provider he is logging in. This makes sense because we can have multiple different types of auth providers configured to sharepoint web application.

In my case for a WEB SSO claims provider the user was prefixed with i:0ǵ.t and group was prefixed with c:0!.s hence a test user and group would be like this

i:0ǵ.t|ProviderName|userloginID

c:0!.s|ProviderName|GroupName

In My case the Provider is Contoso

 Note: The SCRIPT snippet is AS IS. Please test the script in Test to validate. The author will not be responsible for any damages occurring because of this script and hence use at your own risk.

Solution:

Below is the powershell script which migrate the users

$rootSite = New-Object Microsoft.SharePoint.SPSite(“https://a.contoso.com”)

$spWebApp = $rootSite.WebApplication

foreach($site in $spWebApp.Sites)

{

Write-Host “$site”

$url = $site

# get all users in the site, this includes iwindows users

$users = get-spuser -web $url -Limit ALL

foreach($useriteration in $users)

{

$a=@()

$userlogin = $useriteration.UserLogin

# Skip if the user login contains “i:0ǵ.t” for claims users, and also skip your Farm account

if( $userlogin.StartsWith(“i:0ǵ.t”) -or $userlogin.Contains(“_share”) -or $userlogin.Contains(“system”) -or $userlogin.StartsWith(“NT”) -or $userlogin.StartsWith(“Built”) -or $userlogin.StartsWith(“c:0!.s”))

{

continue;

}

# get the user login name

$a = $userlogin.split(“\”)

$username = $a[1]

$us=$a[0]+”\”+$username

# perform the actual migration by getting the user and Move the user

$user = Get-SPUser -web “$url” -Identity “$us”

Move-SPUser -IgnoreSID -Confirm:$false -Identity $user -NewAlias “i:0ǵ.t|contoso|$username”

# Log

Write-Host “converted user kacstmp:$username to i:0ǵ.t|contoso|$username”

}

}

$site.Dispose()

$rootSite.Dispose()

For groups you need to use the below command

Get how group is currently stored by running the below command on the Content database of the site collection

select * from dbo.UserInfo where tp_DomainGroup = 1

Based on the format the current  prefix for windows groups substitute in the below command

$farm=Get-SPFarm

$farm.MigrateGroup(“c:0-.t|contoso\GroupName”,”c:0!.s|contoso|GroupName”)

 

Tags: , , , ,

SharePoint Claims based site very slow

SharePoint Claims based site very slow:

All the SharePoint web front end servers are in enclave network and there is no internet access.

Sharepoint web application has been configured to use claims based authentication.

The login to the site takes more than 2 mins.

What is going on here? Why this incredible wait time to successfully login to a sharepoint claims based site.

Below is what little bit debugging I have done to find the root cause and fix for this.

Took a fiddler trace:

If you notice much of the time is being spent at /_trust/ url of the site. This is nothing but the Sharepoint STS (Token service) to validate tokens and authorize users.

I enabled the CAPI2 logging to find out what’s going on

I find event ID 11: error

ChainElement

–           Certificate

[ fileRef]          F6586B7706BD3BE44CE6453AA6E82A020361A57A.cer

[ subjectName]           SharePoint Root Authority

–           EventAuxInfo

[ ProcessName]           w3wp.exe

–           CorrelationAuxInfo

[ TaskId]          {E4E89B82-25F7-4763-9088-E1B4661044A5}

[ SeqNumber] 19

–           Result  A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

So the Sharepoint security token service validates it own Sharepoint Root certificate that is installed OOB. This certificate will not be installed in “Trusted Root certificate Store”

I looked at the other event ID 53:

URL http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
[ scheme] http

 

EventAuxInfo
[ ProcessName] w3wp.exe

 

CorrelationAuxInfo
[ TaskId] {E4E89B82-25F7-4763-9088-E1B4661044A5}
[ SeqNumber] 17

 

Result This network connection does not exist.
[ value] 8CA

 

By this call it was evident that after the CRL validation failed the call is being made online to the Microsoft site to do the CRL validation.

It is good practice to validate to Certificates because their might be some certificates that have been revoked and needs to be validated for security reasons. But in this case even after the validation fails over the internet because the servers are in DMZ the user gets into the site.

One more thing I noticed was for every sharepoint authentication request there was a build chain happening for CRL validation.

Solution:

Note:The certificate needs to be installed on all the web fron tend servers in the Trusted Root certificate Store.

1. Obtain the “SharePoint Root Authority” certificate as a physical (.cer) file

a) Launch the SharePoint 2010 PowerShell window as Administrator

b) $rootCert = (Get-SPCertificateAuthority).RootCertificate

c) $rootCert.Export(“Cert”) | Set-Content C:\SharePointRootAuthority.cer -Encoding byte

2. Import the “SharePoint Root Authority” certificate to the Trusted Root Certification store

a) Start > Run > MMC > Enter

b) File > Add/Remove Snap-in

c) Certificates > Add > Computer account > Next > Local computer > Finish > OK

d) Expand Certificates (Local Computer), expand Trusted Root Certification Authorities

e) Right-click Certificates > All tasks > Import

f) Next > Browse > navigate to and select C:\SharePointRootAuthority.cer > Open > Next > Next > Finish > OK

I had raised this issue with Microsoft and asked them to publish a KB on this issue. Finally we have one

http://support.microsoft.com/kb/2625048

Note: If you’re SharePoint servers are in enclave network and using claims based web application. you need to implement this steps otherwise you will face site slowness.

 
 

Tags: , , , , ,

SharePoint 2010 Web Application Using Claims Based Authentication: WEB SSO Federation between Shibboleth and ADFS, Users get “Access Denied” on sharepoint 2010 claims based web application

Issue: Users get “Access Denied” on SharePoint 2010 claims based web application. The users are not explicitly added to the site but they are added via Active Directory Security Groups

Role claims are not working.

 

How to get Role Claims from Active Directory Store Using ADFS claim rule language.

Background:

Most of the mid sized organizations and Universities around the world use open source federated Identity –based authentication and authorization infrastructure know as Shibboleth. Shibboleth uses the SAML (Security Assertion Markup Language Protocol 1.1 or higher) to exchange security information to achieve WEB Single Sign On (WEB SSO).

Sharepoint 2010 has its own inbuilt security token service application which can validate Claims token and authorize users. The SharePoint token service acts as relying party in other words it’s just a service provider for the tokens.

Sharepoint 2010 cannot directly integrate with Shibboleth. Sharepoint STS cannot validate token generated from shibboleth. Therefore we need another layer in between this two which will generate or transform tokens to be compliant with SharePoint STS. This is where the Microsoft Active Directory Federation Services comes in (ADFS 2.0). Like Shibboleth ADFS is Microsoft product which provides rich SSO features and able to issue and validate SAML tokens.

After I successfully integrated SharePoint 2010 with ADFS and Shibboleth users were still not able to access the site. So where was the problem? I have enabled the ADFS logging and found that the tokens are coming from Shibboleth. why SharePoint STS is unable to Authorize?

After a little bit of debugging I found the solution.

The cause was I am not getting the Role claim ( Group membership of the user) from Shibboleth. I was just getting the Unique Name Identifier which was the login Id of the user. What if groups are added to the claims based SharePoint site. The users who are part of this group will fail to authorize to the site because the claim did not had the group membership in it. Look how I solved this

Configuration:

SharePoint STS : Relying Party or Service Provider

ADFS 2.0: Service Provider or Relying Party

Shibboleth: Identity Provider or Claims Provider

Identity Store: Active Directory

Claim being used: Windows Account Name

Role: Role Claim

Solution:

At the Claims Provider Trust I am getting UniqueName Identifier claim from Shibboleth and doing a claim transformation to WindowsAccountName

At the relying Party trust I am passing the Windows Account Claim as it is.

I created custom rule which is second in the list of rules for each relying Party trust.

The rule is below

I used the Send Claims using Custom Rule template

 

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”%5D

 => issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/ws/2008/06/identity/claims/role”), query = “;tokenGroups;contoso\windowsaccountname”, param = c.Value);

 

In this rule I am taking the Input windows account name and Doing a query on Active Directory store to issue Role claims for contoso\windowsaccountname

 

Note: This requires a little bit knowledge on Understanding claim rules and claim rule language.

 

This solves my problem. First users get authenticated at shibboleth side and we get a valid SAML token for that user. We now use that token to get Role Claims at ADFS. Now I can add AD security groups to my Claims based site and authenticate the user using Role Claims

 
 

Tags: , , , , , , , , ,