ADFS 2.0 Configuration with SharePoint 2010 / 2013

Prior to starting the installation please verify the following:

• Windows Certificate Services is installed
• ADFS 2.0 Prerequisites are in place

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

Installation

There are a variety of ways to install and configure ADFS 2.0 that can be referenced on theTechNet 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”

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

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

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

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

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

• 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

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

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

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

• Select the “AD FS 2.0 profile” radio button

• 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

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

• 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 >”

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

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

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

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

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

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

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

• 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.

• 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.

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

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

• 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
   • https://logon.2008r2.local/adfs/services/trust/mex
2. Access the Federation Metadata endpoint
   • https://logon.2008r2.local/FederationMetadata/2007-06/federationmetadata.xml

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

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 with.  In this example I’ve placed a copy of the “ADFSSign.cer” file in the D:\Software\Microsoft\ADFS\Certs directory:

• 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.

1 2 3 4 5 6 7

$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 ccount" –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”)

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

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

• 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:

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”

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

• 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.

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

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

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

Ref: http://sharepointobservations.wordpress.com/2013/08/19/sharepoint-2013-how-to-install-and-configure-adfs-2-0/

http://blogs.technet.com/b/speschka/archive/2010/07/30/configuring-sharepoint-2010-and-adfs-v2-end-to-end.aspx