Home > Authentication, Configuration > Configuring Claims Based Authentication for SharePoint with AD FS 2.0

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.

 http://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:

  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.

About these ads
  1. Brad Thurber
    June 16, 2010 at 7:59 am | #1

    Regarding “When you create or transform a web application to support claims based authentication, it creates a folder called ‘_trusts’”

    I never could get SharePoint to create the ‘_trusts’ folder. I tried a new CBA web app with NTLM, a new CBA web app with Kerberos. Maybe I’m missing some other prerequisite.

    • June 16, 2010 at 10:06 am | #2

      Brad,

      I will look into exactly when this folder gets created and let you know.

      Shannon

      • October 6, 2010 at 10:57 am | #3

        This folder get’s created when you add ADFS to your web application as an authentication method.

  2. Hitesh Dhruna
    July 16, 2010 at 11:44 am | #4

    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”

    -Hitesh

  3. Hitesh Dhruna
    August 11, 2010 at 3:34 am | #5

    Got it resolved, I forgot to install Claims Agent on Sharepoint Server..ugh..

  4. kanta
    August 23, 2010 at 9:58 am | #6

    Thank you for the detail steps, when I am running this step “Add the ADFS Token Signing Certificate Root Authority To SharePoint’s List of Root Authorities”

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

    I get error:

    New-SpTrustedIdentityTokenIssuer : The farm is Unavailable

    Sharepoint server and AD FS 2 server are in same domain.

    Really appreciate for the comments

    Thanks

  5. kanta
    August 23, 2010 at 1:34 pm | #8

    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.

    Thanks

    • August 23, 2010 at 5:38 pm | #9

      Hello Kanta,

      Have you checked the ADFS logs or just the SharePoint logs?

      Shannon

  6. kanta
    August 24, 2010 at 8:32 am | #10

    Hello Shannon,
    I don’t see any error in ADFS or Sharepoint log?

    Kanta

  7. kanta
    September 16, 2010 at 12:58 pm | #11

    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.

    Stack Trace:

    [FaultException: The trusted login provider did not supply a token accepted by this farm.]
    Microsoft.IdentityModel.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, RequestSecurityTokenResponse& rstr) +328
    Microsoft.IdentityModel.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst) +36
    Microsoft.SharePoint.SPSecurityContext.SecurityTokenForContext(Uri context, Boolean bearerToken, SecurityToken onBehalfOf, SecurityToken actAs) +19063094
    Microsoft.SharePoint.SPSecurityContext.SecurityTokenForOnBehalfOfContext(Uri context, SecurityToken onBehalfOf) +54
    Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.OnSessionSecurityTokenCreated(SessionSecurityTokenCreatedEventArgs arguments) +357
    Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SetPrincipalAndWriteSessionToken(SessionSecurityToken sessionToken, Boolean isSession) +92
    Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request) +360
    Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args) +247
    System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80
    System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +171

    Thank you
    kanta

    • October 2, 2010 at 12:07 pm | #12

      I am going through these steps and re-doing this to make sure the steps are all there.

  8. SharePointDeveloper
    October 26, 2010 at 9:25 am | #13

    Great Work dude..

    Really informative….Keep up the good work.

    Thanks once again :)

  9. Jaya
    October 27, 2010 at 10:49 am | #14

    Hi Shannon,
    The link on Configuring Windows Server 2008 for Virtualization is not functional.
    I am getting an Page Not Found Error.

  10. Lukasz
    February 12, 2011 at 8:16 am | #16

    The signin page redirects me to https://myservername/adfs/ls
    I’m getting 404 on this url. Did I miss something?

  11. April 1, 2011 at 12:13 am | #18

    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.

  12. June 11, 2011 at 3:41 am | #19

    Hi Shannon,

    thanks for your post and the updates in the second post… I stepped into the same problems but I was able to solve it with both posts doing step by step.

    Thanks

  13. Steve
    May 30, 2012 at 7:58 pm | #20

    Great step by step, thanks!

    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.

    Thanks,
    Steve

  14. Wang, Changhai
    January 30, 2013 at 1:33 am | #21

    Hi Shannon,

    I finished all the steps in your documents. however, i cannot log in successfully, it seems like i need configure and to use CBA user, do you have any idea?

    • January 30, 2013 at 7:40 pm | #22

      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.

  15. whorn76
    July 25, 2013 at 7:22 am | #23

    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.

    Thanks.

  1. May 31, 2010 at 9:40 am | #1
  2. June 2, 2010 at 9:06 pm | #2
  3. June 2, 2010 at 9:54 pm | #3
  4. June 2, 2010 at 9:57 pm | #4
  5. June 2, 2010 at 10:28 pm | #5
  6. July 6, 2010 at 3:01 pm | #6
  7. September 8, 2010 at 2:29 pm | #7
  8. September 22, 2012 at 5:33 pm | #8
  9. September 24, 2012 at 8:00 am | #9

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 29 other followers

%d bloggers like this: