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.
 SharePoint 2013 and ADFS 2.0 Installation Guide
 Lab Environment
 Install Windows Certificate Authority
 ADFS Prerequisites
 How to Install and Configure ADFS 2.0
 Configure User Profile Service for ADFS 2.0
 Configure Search to Crawl Web Applications Using Claims and ADFS 2.0
 Configure People Picker to resolve ADFS Identities
 Adding Host Name Site Collections to Existing Web Application Configured to use ADFS 2.0
 Validate Configuration with “Claims Viewer Web Part”
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 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”
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
o https://logon.2008r2.local/adfs/services/trust/mex
2. Access the Federation Metadata endpoint
o 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 $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("D:\
2 Software\Microsoft\ADFS\Certs\ADFSSign.cer")
3 $map1 = New-SPClaimTypeMapping
4 "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -
5 IncomingClaimTypeDisplayName "Role" –SameAsIncoming
6 $map2 = New-SPClaimTypeMapping
7 "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.

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.
 
Pasted from <http://sharepointobservations.wordpress.com/2013/08/19/sharepoint-2013-how-to-install-and-configure-adfs-2-
0/>