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.

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.

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.

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.

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.

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.

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.

You need to define the Root Auth first and then create a new site where the ‘_trust’ folder is automatically created. At-least that’s what is happening for me.
Although I still can’t go beyond the “Server Error in ‘/’ Application” error message. Any help?

I noticed one more thing, for me “-ImportTrustCertificate $cert” didn’t work, I had to “-ImportTrustCertificate C:\Contoso.cer” and likewise for “-Certificate $cert” to “-Certificate C:\Contoso.cer”

It sounds like you might not have the correct permissions on the SharePoint databases. Check out this post for more info. If this doesn’t get you past it, shoot me an email at sbray@go-planet.com and I will see if I can help you find the issue.

Thank you Shannon, for your quick response.
That was infact the permission issue. Now I have anothe error. That is:

When I browse the sharepoint site; it brings the “Sign In” Page. I selected the provider and it redirects to https://server/adfs/ls error is:
There is a problem accessing the site. …. and Reference number d9eaf33a-0287-4ea5-b05dcbdaf461.

This reference number keeps changing.
What could be the problem, I could not see any log that gives me clue.

I followed the stteps to authenticate user from ADFS 2.0 with SharePoint 2010 web Application .

I got this problem not able to find the couse of it. I have given read permission to serviceaccount and App pool acount. still I get this error. Any suggestion is appreciated.

Server Error in ‘/_trust’ Application.
——————————————————————————–

The trusted login provider did not supply a token accepted by this farm.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.ServiceModel.FaultException: The trusted login provider did not supply a token accepted by this farm.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Awesome! got my guy logged in. I had to jump through a small hoop where I needed to specify an EncryptedSecurityTokenHandler certificate in the SharePoint Web.Config, not a big deal, but I wonder why I was so unlucky.

I set everything up and I get all the way to the last step, a Windows auth prompt, after I select one of my domains from the ADFS Home Realm discovery page’s dropdown. However, no matter what credentials I enter the windows auth box keeps popping up for credentials. All the users have email addresses in AD. I tested and did a dual-auth provider and added windows NTLM as an auth option in SharePoint. If that is selected the current user can get into the site. Can’t via ADFS. I believe ADFS is setup correctly because I have another ASP.NET web application that is setup as a relying party on the same server and that works just fine.

Have you seen this behavior before? Any suggestions? I see nothing that jumps out in any logs in either server.

I need more information on the actual issue. Feel free to email me at sbray@go-planet.com and I will help how I can. There is a more recent post that may offer a solution for you that goes into the steps in more detail.

Hi Shannon. We are currently investigating adfs 2.0 for SharePoint 2013. In my lab I have everything configured and working, but I’m wondering if there is a way to just have ADFS pass through your session credentials along to SharePoint rather than having to hit the log on page?

It seems like this would be a simple and wanted feature. Having the logon page really removes the user from a seamless interaction that you get with just NTLM authentication.