Configuring Claims Based Authentication for SharePoint with AD FS 2.0

 I have posted a more up to date version of this post.  I have found that a couple of steps in this process were left out of the writeup, so I created a new posting from start to finish.  While you may still find what you are looking for in this post, I strongly encourage you to read the new one if you are having issues getting claims set up.

 https://shannonbray.wordpress.com/2010/10/02/claims-based-authentication-made-simple/.

———————————————————————————————————————————–

  In this session, we will now move onto configuring Claims Based Authentication for our internal farm. If you are unsure where to start in the process, please refer back to one of the previous posts:

• SharePoint 2010 Machine Configurations
• Laptop Configurations
• Configuring Windows Server 2008 for Virtualization
• Configuring RRAS for Windows Server 2008 R2
• Building Your SharePoint 2010 Infrastructure
• Creating Your Web Application
• Configuring Kerberos

  Before we dive into the step by step process, let’s first examine what happens during a “claim” authentication. This will be very useful, should you need to debug your environment to find out what piece isn’t working the way you expect.

1. Client, web browser or Office 2010, makes a resource request to SharePoint
2. SharePoint responds and tells the client that it is unauthenticated and passes a url to the client so that the client knows where to go to get authenticated.
3. The client then requests authentication from the Identity Provider Security Token Server (IP-STS)  AD, SAML, etc
4. IP-STS returns a security token (Windows NT token, Forms, SAML etc.) to the client.
5. Client passes the newly acquired security token back to SharePoint.
6. SharePoint decides if it trusts the issuer of the token, if it does, performs Claims augmentation and gets claim info, in the form of a new token.
7. Client then passes new token to SharePoint, SharePoint then converts the augmented claim into a SPUser and grants access.

                                – SPC307, SharePoint Conference Oct. 2009

I would also recommend looking at Spence’s claims presentation available here. Now that we have a basic understanding of the steps, let’s put them in place. You will also need to download the latest version of AD FS 2.0. At the time of this article, there are versions for Windows Server 2008 and Windows Server 2008 R2. I will be using the R2 version in the following steps.

Once you have it downloaded, run the setup file and step through the wizard.

For the ‘Server Role’, I chose ‘Federation server’. This is because this environment or lab will not be incorporating any firewalls and simulating a perimeter network.

From here, we are now ready to configure the federation server. Click on the link ‘AD FS 2.0 Federation Server Configuration Wizard’ and follow along with the screenshots below:

Once we complete the wizard, we will enter into the Internet Information Services (IIS) Manager. Click on the server name in the left hand pane (ie. MCM-ADFS). You will now click on ‘Create Self-Signed Certificate’. This will launch a wizard that creates a certificate that we will use to establish communications between our ADFS and our SharePoint server. In this example, I name my certificate ‘adfs.mcm.lab.internal’.

 
 

  If you have been following along through the entire series, you would have created a ‘Certificates’ folder on the SharePoint server. We will now need to create one on the AD FS server. I created mine directly on C.

Now that we have a location to save the new certificate to, export it to the newly created folder. You will need to enter a password. For this example, I used ‘pass@word1’.

You will now import your certificate into your ‘Trusted Root Certification Authorities’. You can get here by typing ‘MMC’ into the search box and adding ‘Certificates’ as a snap-in.

 
 

Once this certificate is in place, I hit the previous button and then next. This will populate the ‘Federation Service Name’ details as indicated below.

Open up your domain controller and create a new user. For this demo, I created ‘mcmADFSService’.

We can then add the new user in the next step of our wizard: Specify a Service Account.

 
 

Click through the remainder of the Wizard.

As you complete the wizard, you may get an error in the ‘Configure service settings’. This notify you to create a SPN for the ADFS service account.

We are now ready to add a trusted relying party. Click on the link and follow along with the screenshots.

 
 

We will be creating my own relying party, so select “Enter data about the relying party manually”. I have included screen shots of the steps I took below.

Meanwhile, back on the SharePoint Server … When you create or transform a web application to support claims based authentication, it creates a folder called ‘_trusts’. We will make reference to this location in the next step.

  Back to the AD FS server …

By default, you will see https://www.mcm.lab.interal/_trust/. Note the ‘/’ at the end!!!!! We will remove this and add ‘urn:MCM-SPS:adfs’.

 
 

 
 

Once this wizard completes, we will create a new Claim Rule.

 
 

 
 

We will be using the email from AD as the information that goes into our “Claims Augmentation” token. You can select any number of properties, but for the sake of this demo, we will just select email. You will be able to follow the rules wizard diagrams below.

 
 

The bulk of our work is now done. Navigate through the nodes and examine the different pieces of data.

 
 

  We will now select the ‘Token-Signing’ certificate and import it. Notice from the diagram below that the CA Root certificate is not yet trusted.

 
 

Once you complete the import, you should have a clean looking certificate. Click on the ‘Details’ tab and export this certificate to the certificate folder on the C drive.

 
 

You will need to copy this certificate over to your SharePoint server and place it into the certificate folder on the C drive. We will have a couple of PowerShell commands that are dependent on the location of this file. On the SharePoint server, open up the SharePoint 2010 Management Shell.

 
 

 

Add the ADFS Token Signing Certificate Root Authority To SharePoint’s List of Root Authorities

Here we add the root certificate used in ADFS token signing to SharePoint’s list of trusted root certificate authorities.

Open the SharePoint Management Shell to run the PowerShell commands. If you modified any of the demo, you will need to pay special attention to the variables used here. $signinurl will send the request from SharePoint to the ADFS server.

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

You will need also add the certificate to the SharePoint Trusted Root Authority. You will be able to do this will the following PowerShell cmdlet:

• New-SPTrustedRootAuthority “MCM Lab ADFS Token Signing Trusted Root Authority” -Certificate $cert

 

Once you complete the PowerShell scripts, you will be able to modify the Authentication of the web application to use ‘MCM ADFSv2’. Make sure that you make this change of the ‘Intranet’ zone and not your ‘Default’ zone.

When you navigate to your site, you should be prompted to select your authentication type.

We will expand on this in the next article and create an external farm that will access this site through an AD FS trust.