SharePoint 2013 Configure Web Application for ADFS

Overview

This is part 6 in our SharePoint 2013 ADFS 3.0 Installation and Configuration series of articles.  In this article we will go over configuring the SharePoint web application to use ADFS as one of its authentication providers.

• SharePoint 2013 and ADFS 3.0 Installation Guide
• Part 1: Lab Environment
• Part 2: Install Windows Certificate Authority
• Part 3: ADFS Prerequisites
• Part 4: How to Install and Configure ADFS 3.0
• Part 5: Configure Relying Party in ADFS 3.0

• Part 6: Configure Web Application for ADFS

• Part 7: Configure User Profile Service for ADFS
• Part 8: Validate Configuration with “Claims Viewer Web Part”
• Supplemental 1: Configure People Picker to resolve ADFS Identities
• Supplemental 2: Adding Host Name Site Collections to Existing Web Application Configured to use ADFS
• Supplemental 3: Configure Automatic Sign-In with Mixed Authentication

Configure SharePoint Web Application

In the final steps for this post, we’ll configure the “SharePoint Lab – SPT” web application to use ADFS as a “Trusted Identity Provider“.  Make sure you have created your certificates from Part 4.

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 we’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.

$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:spt"
$signinurl = "https://adfs.splab.local/adfs/ls/"
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS" -Description "ADFS 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 “ADFS” 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 “SharePoint Lab – SPT” 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 “ADFS” 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 ADFS authentication providers.  If we were to browse the root site at https://spt.splab.local a “Sign In” page would be displayed asking which provider to use:

Test Authentication Provider

At this point we can’t select “ADFS” 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://spt.splab.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 “ADFS” option

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

 Conclusion

The “SharePoint Lab – SPT” web application has now been configured to use both the windows and adfs authentication providers.  In a follow up post we’ll cover how you might get rid of the “Sign In” page.

‹ SharePoint 2013 Configure Automatic Sign-In with Mixed Authentication

SharePoint 2013 ADFS 3.0 Configure Relying Party ›

Tagged with: ADFS, How To, Part 6, SharePoint 2013, Step-by-Step
Posted in ADFS, ADFS 3.0, SharePoint 2013, Windows Server 2012