SharePoint 2013 How to Install and Configure ADFS 2.0

Introduction

This article is another in our series that will outline the procedures to install ADFS 2.0 on a Windows 2008 R2 domain controller.  In a production environment you typically wouldn’t co-locate the “Domain Controller” and the “ADFS” role on the same server, but for a lab environment this shouldn’t be an issue.

Prior to starting the installation please verify the following:

Once the steps above are complete you’ll need to download the ADFS 2.0 installation and place a copy on the Domain Controller:

image

Installation

There are a variety of ways to install and configure ADFS 2.0 that can be referenced on the TechNet AD FS 2.0 Step-by-Step and How To Guides, but in this scenario we’ll install a single federation server.

  1. Right click “AdfsSetup.exe” and “Run as administrator”
  2. Click “Next >” on the “Welcome to the AD FS 2.0 Setup Wizard” screen
  3. Accept the terms of the license and click “Next >”
  4. On the “Server Role” screen select the “Federation server” radio button and click “Next >” to continue
  5. Click “Next >” on the “Install Prerequisite Software” screen
  6. Leave the “Start the AD FS 2.0 Management snap-in when this wizard closes.” checkbox selected and click “Finish” to launch the post installation “AD FS 2.0 Federation Server Configuration Wizard”

image

Post Install Configuration

This step will consist of a handful of tasks ranging from creating a new Federation Service, importing the “logon.2008r2.local” certificate that we previously created, creating the farm, configuration database, default claim set and finally configuring the token decrypting and signing certificates in the AD FS 2.0 console.

AD FS 2.0 Federation Server Configuration Wizard

  • Click the “AD FS 2.0 Federation Server Configuration Wizard” link

image

  • Select the “Create a new Federation Service” radio button and click “Next >”

image

  • Select “New federation server farm” and click “Next >”

image

  • Select the SSL certification that was previously created.  In this example it was “logon.2008r2.local”

image

  • Specify the ADFS service account and password that was created during the prerequisite phase

image

  • Review the “Summary” screen and click “Next >”
  • Verify all the steps completed successfully and click “Close” to return to the AD FS 2.0 management console

image

Configure a Relying Party

Now that ADFS is setup we can configure the initial “Relying Party” to be used with our SharePoint web application “portal.2008r2.local”

  • Click the “Required: Add a trusted relying party” link in the “Overview” section of the AD FS 2.0 console

image

  • Click “Start” on the welcome screen
  • Select the “Enter data about the relying party manually” radio button and click “Next >”

image

  • Enter a value in the “Display name:” and optionally the “Notes:” fields

image

  • Select the “AD FS 2.0 profile” radio button

image

  • Click “Next >” on the “Configure Certificate” screen because it is not necessary to encrypt SAML tokens since HTTPS is a requirement for the SharePoint Web App to communicate with the ADFS STS
  • Select the “Enable support for the WS-Federation Passive protocol” checkbox and enter the URL for the relying party WS-Federation Passive protocol URL

image

  • Enter a relying party trust identifier and click the “Add” button

image

image

  • Select the “Permit all users to access this relying party” radio button
  • Review the configured settings and click “Next >”
  • Leave the “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes” and click “Close”

Add Claims Rule

In this step a claim rule will be created that maps email address and role attributes from Active Directory.

  • Click “Add Rule…”
  • Select the “Send LDAP Attributes as Claims” entry from the dropdown box and click “Next >”

image

  • Enter a “Claim rule name:”, select and “Attribute store:” and configure the attribute mapping

image

  • The relying party is now configured and will be used in subsequent steps when configuring a “Trusted Authentication Provider” in SharePoint

image

Configure ADFS Certificates

In this step we need to configure ADFS to use the “Token-decrypting” and “Token-signing” certificates that were created previously.  Once configured, the “Token-signing” certificate needs to be exported and a copy placed on the SharePoint server to be imported in a subsequent step.

  • Navigate to the “Certificates” folder in the AD FS 2.0 console
  • Enter the following commands to disable certificate rollover

image

  • In the right hand pane click the “Add Token-Signing Certificate…” action

image

  • Select the appropriate certificate from the list of installed certificates.  These were created in a previous step.

image

  • In the “Token-signing” section two certificates will be listed.  Highlight the new entry, “CN=signing.2008r2.local” and click “Set as Primary”

image

  • Click the “Add Token-Decrypting Certificate…” entry

image

  • Select the appropriate certificate from the list of installed certificates to function as the decrypting certificate.  You can use the token-signing, but I choose to create individual certificates for each function.

image

  • Highlight the “CN=decrypting.2008r2.local” entry in the “Token-decrypting” section and click the “Set as Primary” action
  • The new certificates should be set as primary in each section.  Optionally you could delete the secondary certificates which are self signed certificates created during the ADFS installation.

image

Export Token Signing Certificate

The Token-signing certificate needs to be exported and a copy placed on the SharePoint server that will be used to run the PowerShell commands to configure the “Trusted Identity Provider”.  In this example I’ll copy it to the web front end server “SP-WFE-1”.

  • Navigate to the “Certificates” folder in the AD FS 2.0 console
  • Highlight the primary token-signing certificate “CN=signing.2008r2.local” and click on the “View Certificate…” entry in the “Actions” pane

image

  • Click the “Details” tab
  • Click the “Copy to File…” button

image

  • Select the “No, do not export the private key” option and click “Next >”
  • Select the “DER encoded binary X.509 (.CER)” radio button and click “Next >”
  • Click the “Browse…” button and navigate to a location on the local file system to save a copy of the export certificate.
  • Click “Finish” to complete the action
  • Copy the file to the SharePoint web front end server to be used in a later step

Test ADFS Connectivity

Now that ADFS has been configured we can verify the health of ADFS prior to configuring a “Trusted Identity Provider”.

  1. Access the WS-Metadata Exchange Endpoint
  2. Access the Federation Metadata endpoint

In both examples an XML result should be returned which validates the endpoints are functioning correctly:

image

Configure SharePoint Web Application

In the final steps for this post, we’ll configure the “Portal” web application to use ADFS 2.0 as a “Trusted Identity Provider”.

Create Trusted Identity Provider

  • Verify location of token signing certificate.  This location will need to be recorded in the PowerShell script to provision the “Trusted Identity Token Issuer” and should be located on one of the SharePoint servers in the farm we are working withIn this example I’ve placed a copy of the “ADFSSign.cer” file in the D:\Software\Microsoft\ADFS\Certs directory:

image

  • Now that the certificate is in place we’ll need to execute the following PowerShell script on the SharePoint server (SP-WFE-1 in our example).  The script will setup the Trusted Identity Token Issuer, 2 claim type mappings, sign-in URL, realm, import the token signing certificate and set the name and description.

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("D:\Software\Microsoft\ADFS\Certs\ADFSSign.cer")
$map1 = New-SPClaimTypeMapping "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming
$map2 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName "Email Address" –SameAsIncoming

$realm = "urn:sharepoint:portal"
$signinurl = "https://logon.2008r2.local/adfs/ls/"
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS20" -Description "ADFS 2.0 Federated Server" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1, $map2 -SignInUrl $signinurl -IdentifierClaim $map2.InputClaimType
  • To validate the script ran successfully the “Get-SPTrustedTokenIssuer” cmdlet can be executed to verify the results.  There are 5 key pieces of information to validate:
    1. ProviderUri  (SharePoint will send authentication requests to this Uri)
    2. ProviderRealms  (SharePoint will send the URN to ADFS which in turn will use the realm value to match it up with the appropriate relying party entry)
    3. ClaimTypeInfomation  (This verifies the two claim mappings that we created during the script execution and should match up with what is configured in the ADFS relying party entry)
    4. Signing Certificate  (Verify the “Token-Signing” certificate is listed here)
    5. Name  (The name entry will be listed in the Web Application as an option under the “Trusted Authentication Providers”)

image

Configure Web Application Authentication Provider

Now that the “ADFS20” Trusted Authentication Provider has been provisioned we can configure the Web Application to use it.

  • Logon to the Central Administration site
  • Click on the “Manage web applications” link under the “Web Applications” section
  • Highlight the “Portal” web application and click on the “Authentication Providers” in the ribbon

image

  • Click the “Default” zone link
  • In the “Claims Authentication Types” section of the “Edit Authentication” screen, select the “Trusted Identity Provider” and “ADFS20” checkboxes.

image

  • Click “Save” to commit the changes (**this may take a minute or two**)

Now the web application is configured to use both the Claims/NTLM and ADFS20 authentication providers.  If we were to browse the root site at https://portal.2008r2.local a “Sign In” page would be displayed asking which provider to use:

image

Test Authentication Provider

At this point we can’t select “ADFS20” as an authentication option because no permissions have been set on the site using the email address identity or roles from ADFS. We need to logon to the site as a Site Collection Administrator and setup the permissions.

  • Navigate to https://portal.2008r2.local
  • At the “Sign In” page select the “Windows Authentication” option
  • Click the gear icon in the upper right hand corner of the page and select “Site Settings”

image

  • In the “Users and Permissions” section click the “Site collection administrators” link

image

  • When entering in the users to add to the group you’ll see 3 entries for each account.  Two of these are associated with ADFS (Role, Email-address) and the third one is the windows authentication account.  You won’t be able to tell them apart unless you hoover over the accounts, but add a user or role from the ADFS provider.  In a later post we’ll outline a method to have the people picker resolve the accounts in ADFS.

image

  • Click “OK”
  • Click the user name in the upper left hand corner and select the option to “Sign Out”

image

  • On the “Sign In” page select the “ADFS20” option

image

  • If successful you’ll be logged into the site using the email address claim attribute in ADSF.

image

Conclusion

The “Portal” web application has now been configured to use both the windows and adfs authentication providers.  In a follow up post we’ll cover how to get rid of the “Sign-In” page and the implications that may have on the user experience.

Tagged with: , , , ,
Posted in ADFS, SAML Claims, SharePoint 2013, SSL
11 comments on “SharePoint 2013 How to Install and Configure ADFS 2.0
  1. edward says:

    Hello Jasonth
    Great Tutorial, I am searching a guide to configure SSO SharePoint 2013 OnPremise with Office365 (Exchange OWA). I think so with your tutorial I can do it!

    If you have any advice, I will appreciate.

    Thanks
    Edward

  2. Khushi says:

    Where should the ADFS be install in prod environment?

    Thanks,
    Khushi

  3. Anonymous says:

    Excellent Article. Thanks for this step by step guide

  4. Indrajith says:

    Hello ,

    I have now completed integrating the ADFS with sharepoint 2013 succesfully. However post the configuration, when i log in to my Sharepoint website it displays the email id of the user on the top right corner instead of UPN. Any idea how can i change this to UPN ?

    Cheers,
    Indrajith

  5. Eric says:

    This was a fantastic article…

    I am having an issue where after authenticating to the ADFS site, the user gets redirected to /_login/default.aspx to select Windows or ADFS20 again. Do you have any tips?

    • M Aune says:

      Eric, I am getting the same login loop. ADFS authenticates the user, but SharePoint just send them back to /_login/default.aspx. Did you ever figure it out?

  6. Andrew Cottle says:

    Thank you for this wonderful step-by-step. Is there anyway to mold your steps to use certificate authentication, i.e. client user login receives a unique certificate that is used for authentication (not sure if this would be considered a claim or not) and all login dialogs are bypassed?

  7. Sarath says:

    Can you please place something for Windows 2012 or 2012R2 as well… pleaseeeee

    • jasonth says:

      Hello,

      Yes, we should definitely update this for Windows 2012/2012R2 and use ADFS 3.0. I’ll talk to the guys and see if they are up for the challenge of updating the ADFS series.

  8. NGAN says:

    Great… great.
    How am I to go for it when trying to use a federation trust, meaning external organization will get access in my Sharepoint Intranet with SSO

  9. pankaj says:

    I have configured ADFS and working without any issue for 1st web application, however for 2nd web app it is not working and getting redirected to 1st web app.
    Can you share steps to configure ADFS for 2nd web application, I am configuring this in my lab to confirm that we do not require to re-enter credential again for 2nd web app.

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

%d bloggers like this: