SharePoint Adventures : ADFS Setup – Part 2

In Part 1, we looked at getting ADFS actually installed, for Part 2, we will see what we need to do to get it working with SharePoint 2010. Being that I focus on Reporting Services, the end goal here is to see how it work with Reporting Services. However, RS will be for another post.

To get this working with SharePoint, there are a few things that we need to do.

Token-Signing Certificate

The ADFS 2.0 Service has what is called a token signing certificate.

Step 1 - Install to local Trusted Root

The first thing we want to do with this cert is to install it into the trusted root for the computer. This cert happens to be auto generated. You could also change the cert to be generated from the Certificate Server, but I'm not going to do that for this example. To install it into the trusted root, we can right click and view the certificate.

Click on "Install Certificate…". Go through the wizard and choose to "Place all certificates in the following store". We then want to be sure we select "Show physical stores" and select "Trusted Root Certification Authorities\Local Computer". This will ensure that the certificate goes into the Local Computer Trusted Root as opposed to the User's Trusted Root which would be problematic.

If we look at the Trusted Root for the local computer, we should see the certificate now.

Step 2 - Export the Token Signing Cert

We want to export the Certificate so that we can import it into SharePoint and the Trusted Root of the SharePoint machine. I just put these certs into a Certificate folder on the C drive. To Export, just right click on the cert, go to Tasks and choose Export.

We won't be able to export the private key, so we can just go with DER Encoded binary X.509.

Step 3 - Grab the Web Cert for ADFS as well

While we are here, lets grab the ADFS Web Certificate as well, as we will need that. This certificate happens to be in the Personal store.

We can just do the same thing that we did with the Token Signing Certificate.

Step 4 - Install the Certs into the SharePoint Box Trusted Root

We will want to install both Certificates into the Trusted Root for the SharePoint box. Within MMC, add the Certificates Snap-In for the local computer. Go to "Trusted Root Certification Authorities" and then right click on Certificates. Go to "All Tasks" and then "Import…".

After you have imported both Certificates, you should see them listed.

SharePoint Trusted Provider

Now that the certs are in place, we can setup the SharePoint Trusted Provider. This is done through PowerShell. Here is the script:

$certPath = “C:\Certificates\TokenSigningCert.cer”
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“$certPath”)
$map1 = New-SPClaimTypeMapping “https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming
$realm = “urn:” + $env:ComputerName + “:adfs”
$signinurl = “https://dsdcontosodc.dsdcontoso.local/adfs/ls/”
$ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS20Server” -Description “ADFS 2.0 Federated Server” -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType

Lets break this down.

$certPath = “C:\Certificates\TokenSigningCert.cer”
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“$certPath”)

This gets the cert that we exported, and sticks it into the $cert variable.

$map1 = New-SPClaimTypeMapping “https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming

This sets up our Claim mapping that we will use to identify users. Basically off of the Email address. We will have to set this up on the ADFS side as well a little later.

$realm = “urn:” + $env:ComputerName + “:adfs”
$signinurl = “https://dsdcontosodc.dsdcontoso.local/adfs/ls/”

The first item here identifies the Realm that we will use for the ADFS communication. This is also defined on the ADFS side as well. It is important that you keep these the same on the SharePoint side and the ADFS side. It doesn't have to be call this, but it needs to match what you will later define on the ADFS side. The second item is the URL to ADFS itself. In my case, it is on my domain controller, but this may be different in your case. It is important that the URL you use matches the Certificate in place with regards to whether you use the machine name or FQDN. They need to match.

$ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS20Server” -Description “ADFS 2.0 Federated Server” -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType

The last command is what pulls all of this together and creates the Trusted Provider within SharePoint. To run the above PowerShell script, make sure you use the "SharePoint 2010 Management Shell" and that you run it as Administrator.

After that is done, we then want to add the Token Signing Cert to SharePoint's Trusted Root with the following command which will use the same $cert that we defined.

New-SPTrustedRootAuthority “Contoso ADFS Token Signing Trusted Root Authority” -Certificate $cert

ADFS Web Cert

I found, when going through this, that any certificate that SharePoint interacts with needs to reside within SharePoint's trusted root. Even if the cert is in the computer's trusted root, it also needs to be in SharePoint's trusted root. This was the cause of a big headache for me. So, when dealing with Certs, I made sure if I added it to the Machine's local Trusted Root that I also added it to SharePoint's Trusted Root.

$certPath = “C:\Certificates\ADFSWebCert.cer”
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“$certPath”)
New-SPTrustedRootAuthority “DSDContosoDC web server” -Certificate $cert

SharePoint should be good to go from an ADFS perspective at this point. We just need to finish up the ADFS portion.

ADFS Relying Party Trust

The Relying Party Trust is the ADFS setup to know that SharePoint will be coming into it. This allows the ADFS provider to trust the SharePoint requests coming in.

We can just right click on "Relying Party Trusts" within the ADFS 2.0 window and select "Add Relying Party Trust...". This will spawn yet another wizard. Within that wizard we want to select "Enter data about the relying party manually".

The Display name can be whatever you choose. I choose "SharePoint ADFS Provider". We then want to select "AD FS 2.0 profile" on the "Choose Profile" landing page. For the "Configure Certificate" landing page, we can skip that.

For the URL, we want to select "Enable support for the WS-Federation Passive protocol" and enter the SharePoint Trust URL. In my case, this is https://dsdcontososp:5556/_trust/. Two things to note. First, the HTTPS on the url. HTTPS is required for this to work. Also the ending / after trust. Don't forget the trailing slash. The Port 5556 is what I will set my SharePoint Site to be.

For the "Configure Identifiers" landing page, you will notes that the URL we entered for the URL landing page is listed here. We want to remove this and add the Identifier that we used in our PowerShell Script. It is important that these match! Outside of that, you can make it the URL if you want, they just have to be the same on this screen and in the PowerShell Script. NOTE: The identifier is case sensitive.

For the "Choose Issuance Authorization Rules" landing page, you can select "Permit all users to access this relying party". Then finish out the wizard. At then end, be sure to leave the Edit option selected as we do want to edit the trust.

Edit Claim Rules

On the Edit Claim rules window, we want to Add a Rule. For the Rule, we can choose "Send LDAP Attributes as Claims". Then hit Next.

We will setup the attributes as follows:

This will send across the Email Address, their Account Name and the groups that they belong to in Active Directory. Once that is done, we can hit Finish and then OK.  Note: The accounts in AD need to have an email address defined for this to work properly.

Setting up the SharePoint Site

I already have a Windows Claims site setup on Port 5555. To keep things a little separate, I will Extend this site to create a port that will be dedicated for ADFS.

This site will go on Port 5556 too match our Relying Party Trust in ADFS. It will make use of SSL, of which I already have a Certificate setup.

For the Authentication for this site, I will not choose Windows Authentication, but will select our newly created ADFS20Server provider that was made with the PowerShell script.

The URL for this site is not the FQDN in my case. The URL will really be based on what the Certificate you have, as they need to match. In my case, I created a cert just off of the machine name and not the FQDN.

Once all of that is done, click on OK and let SharePoint do it's thing. Once that is done there are a few other loose ends that I had to shore up.

First was disabling Anonymous access to the 5556 site within IIS. Not sure why it is enabled, but I turned it off. Another is making sure a user has access to the site. My Windows credential does not work and give me access when I come in on the ADFS side. I think this is due to the fact that my identify is different at that point and I'm being represented by my email address and not my SAM name. I didn't try switching it around to prove that point, but to get around it I did the following.

Within Central Admin, go to Application Management -> Site Collections -> Change Site Collection administrators

From here we can see that the ADFS20Server provider is available to search from. If I had tried this from my Windows Claims site, that provider wouldn't have been visible, which is why I can't just add users from that site.

Be sure to use the full email address and not just the account name. Once all of that is done, the site should come up with your ADFS Login displayed.

Hopefully this helps with setting up and configuring ADFS. This is not an exhaustive look at all of the features and capabilities, but should be helpful for at least getting your hands on the technology and playing around with it. This is what I had to go through to get a local repro up and running.

Adam W. Saxton | Microsoft SQL Server Escalation Services
https://twitter.com/awsaxton