Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2012-09-14) Claims Based Authorizations For Sharepoint Through ADFS (Part 1)

Posted by Jorge on 2012-09-14

I have been wanting to create this post for quite a long time. Reason for that is that when I started to learn about working with ADFS v2.0 I tried this by leveraging federated webSSO against a Sharepoint 2010 Web Application/Site. For me at that time, it was not easy and finding information on the internet on how to achieve this was also not easy. Lots of blog posts provided information, but were at some point lacking important steps or information. Because of that I want to post an end-to-end blog post and save somebody else from the exact same painful experience if you are trying to learn about ADFS v2.0 with for example Sharepoint 2010 as a Relying Party Claims Based Application. So here goes and have fun! Oh, by the way, I’m far from a Sharepoint 2010 specialist! Smile So, if you have comments about that, feel free to use the comments section to say whatever you want to say. Oh, heck I don’t care. Whatever you want to comment on, go ahead and do so so that everybody is able to learn from it!

This explanation assumes everything is installed on one box! If stuff is separated on different boxes, then some of the scripts may need to be changed accordingly. With the information I’m already giving you, that’s therefore something for you to figure out!

So, stay tuned as I will post this in different parts for the next few days! Have fun!

One thing that really surprised me, and you will hit it like me if you do not know about it, is that Sharepoint 2010 (SP2010) does not leverage the certificate stores in Windows. For whatever reason it has its own “Trusted Root CA Store”. Because of that, when a user presents a security token from the ADFS STS and signing by its own token signing certificate, SP2010 will wine about not trusting the token signing certificate from ADFS, although the corresponding root CA certificate indeed is in the Trusted Root Certificate Authorities on the Windows Server. So, to make SP2010 stop wining about this, you must import the root CA certificate into SP2010 own trusted root CA store.

So, first I will export the trusted root CA from Trusted Root Certificate Authorities on the Windows Server and write that to a file. Then I will read the certificate file and import it into SP2010 and of course check the trusted root CA actually is there. By the way, do not forget to change the paths and the name of your trusted root CA!

You can use the following PowerShell commands, but first make sure to start the Sharepoint Management Shell:

# Export The Trusted Root CA Certificate From The Windows Trusted Root Certificate Authorities Store $rootCACert = dir cert:\LocalMachine\CA | where {$_.Subject -eq "CN=MY-ROOT-PKI, DC=ADCORP, DC=LAB"} $rootCACert $rootCABytesCER = $rootCACert[0].export("Cert") # Write The Trusted Root CA Certificate To A File [system.IO.file]::WriteAllBytes("D:\_DEMO\SP2010\RFSRWDC1.ADCORP.LAB_MY-ROOT-PKI.CER", $rootCABytesCER) # Import The Trusted Root CA Certificate Into Sharepoint 2010 $rootCACertSP2010 = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("D:\_DEMO\SP2010\RFSRWDC1.ADCORP.LAB_MY-ROOT-PKI.CER") $trustedRootCAuth = New-SPTrustedRootAuthority -Name "Trusted Root CA Certificate - PKI-ROOT-ADCORP" -Certificate $rootCACertSP2010 Get-SPTrustedRootAuthority | Select DisplayName

The output of that all can be seen in the picture below.


Figure 1: Importing The Trusted Root CA Certificate Into Sharepoint 2010

Now I’m going to export the Token Signing Certificate used by ADFS v2.0 so that it is recognized by SP2010 as the Token Signing Certificate of the STS trusted by SP2010. SP2010 will be made aware of this certificate when creating the authentication provider within SP2010 later on.

# Export The ADFS Token Signing Certificate From The Computer's Personal Store $ADFSTokenSigningCert = dir cert:\LocalMachine\My | where {$_.FriendlyName -eq "Token Signing Cert For ADFS-STS"} $ADFSTokenSigningCert $ADFSTokenSigningBytesCER = $ADFSTokenSigningCert.export("Cert") [system.IO.file]::WriteAllBytes("D:\_DEMO\SP2010\FS.ADCORP.LAB.STS.TOKEN.SIGNING.CER", $ADFSTokenSigningBytesCER) $ADFSTokenSigningCertSP2010 = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("D:\_DEMO\SP2010\FS.ADCORP.LAB.STS.TOKEN.SIGNING.CER")

The output of that all can be seen in the picture below.


Figure 2: Exporting The Token Signing Certificate Used By ADFS From The Personal Certificate Store Of The Computer

If you have paid close attention you have noticed that the token signing certificate is from an internal PKI environment and therefore not self-signing. BUT… what if the token signing certificate indeed is self-signed and you are leveraging ADFS automatic certificate rollover? In that case you will not be able to export the self-signed certificate as it is not stored in the personal store of the computer, but rather in the ADFS Configuration database. I have not found a way to export that certificate from the database, BUT… there is a way to export it though! As you may remember, all certificates used by ADFS are listed in the federation metadata of the federation service! Therefore if you target the federation service you can get the token signing certificate used by ADFS. This applies to whatever certificate type you used (external PKI, internal PKI, self-signed). Something to be aware is that you need to target the correct section in the federation metadata and the certificate information is stored in Base64 format. So you have to decode that to bytes and save to a file. See the PowerShell below to see how to do that!

# Load The ADFS Snap-in And Get The Current Directory Add-PSSnapin Microsoft.Adfs.Powershell $CurrentDir = (Get-Location).Path # Get The ADFS Federation Metadata URL $ADFSFederationMetadataURL = (Get-ADFSEndpoint | ?{$_.Protocol -eq "Federation Metadata"}).FullUrl.ToString() # Get The ADFS Federation Service Name/FQDN $ADFSServiceName = (Get-ADFSProperties | Select HostName).HostName # Define The File Name That Will Store The Federation Metadata $ADFSFederationMetadataXMLFile = "$CurrentDir\$ADFSServiceName_FederationMetadata.xml" # Download The Federation Metadata From The Specified URL And Save In The Defined XML File $WebClient = New-Object System.Net.WebClient $WebClient.DownloadFile($ADFSFederationMetadataURL, $ADFSFederationMetadataXMLFile) # Get The Content From The XML File $ADFSFederationMetadataXMLFileContent = [xml](Get-Content -Path $ADFSFederationMetadataXMLFile) # Get The Base64 Encoded Version Of The Token Signing Certificate $ADFSTokenSigningCertBase64 = ($ADFSFederationMetadataXMLFileContent.EntityDescriptor.RoleDescriptor | ?{$_.type -eq "fed:SecurityTokenServiceType"}).KeyDescriptor.KeyInfo.X509Data.X509Certificate # Convert The Base64 Format Into Bytes Format $ADFSTokenSigningCertBytes = [System.Convert]::FromBase64String($ADFSTokenSigningCertBase64) # Write The Bytes To A Certificate File [system.IO.file]::WriteAllBytes("$CurrentDir\$ADFSServiceName.STS.TOKEN.SIGNING.CER", $ADFSTokenSigningCertBytes)

The output of that all can be seen in the picture below.


Figure 3: Exporting The Token Signing Certificate Used By ADFS From The Federation Metadata

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 2)




* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!



############### Jorge’s Quest For Knowledge #############

######### ########



2 Responses to “(2012-09-14) Claims Based Authorizations For Sharepoint Through ADFS (Part 1)”

  1. […] Server Core (2) « (2012-09-14) Claims Based Authorizations For Sharepoint Through ADFS (Part 1) […]

  2. […] If you are looking for good source of step-by-step configuration for ADFS and SharePoint you can also visit Jorge’s blog where he provides good description of ADFS side of infrastructure (start with Part 1 and there is 8 more). […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: