AD FS SharePoint Configuration

Prerequisites

SharePoint SAML support

SAML 2.0 is not supported by SharePoint 2013 or 2016, which support SAML 1.0/1.1 only. See the Does SharePoint 2016 support SAML 2.0 Microsoft TechNet article for more information.

AD FS settings

Configure the relying party in AD FS, which consists of the following elements:

• URL or endpoint: The endpoint must follow the WS-Federation Passive protocol.

• Relying party trust identifier: This can be in the format urn:<instancename>:<env>, which will be used later in the SharePoint configuration.

• Claim rules: These rules may vary depending on customer requirements and environments. Generally, UPN and email are two common attributes that are passed in the claims.

• Token-signing certificate: There are two ways to extract the token-signing certificate:

  • Extract the certificate from the federation metadata: From the federation metadata URL, copy the data located between <X509Data><X509Certificate> </X509Certificate></X509Data> and paste it in a text editor, then save the file with the .cer extension. (Example: ADFSToken.certo SharePoint Server.)

  • Export the certificate from the AD FS management console: Choose Services > Certificates > Token-Signing, then save the certificate as a DER encoded binary (.cer) and copy it to SharePoint Server.

SharePoint configuration

To configure AD FS, run the PowerShell snippet below on SharePoint Server:

#Import the ADFS Token to SharePoint Trust
$cert = "c:\adfstoken.cer" 
$adfscert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($Cert)
New-SPTrustedRootAuthority -Name "ADFS Token Signing Cert" -Certificate $adfscert
#Once the above step is complete, You must see the certificate in Central Administration > Security > Manage Trust > “ADFS Token Signing Cert”
#The realm is the same value you have used in ADFS setting for Relying Party Trust Identifier. The below is an example
$realm="urn:adfshoozin:prod"
#In the example below, Email and UPN claims have been used. The ClaimType can be provided by ADFS administrator or can be extracted from Claim Rules
$emailClaim = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -sameasincoming
$upnclaim = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN" –SameAsIncoming
#ADFS sign in URL shall be provided by ADFS administrator
$signinURL="https://adfs.mycompany.com/adfs/ls/"
$issuer = New-SPTrustedIdentityTokenIssuer -name "ADFS Token Issuer" -Description "ADFS Identity Provider" -Realm $realm -ImportTrustCertificate $adfscert -signInURL $signinURL -ClaimsMappings $emailClaim,$upnclaim -IdentifierClaim $emailClaim.InputClaimType
#In the above code snippet for configuring Trusted Identity Provider, IdentifierClaim is set to use Email i.e., Email is being used as a unique identifier that represents a specific user. This may vary depending on the customer requirement/environment.

Once these steps have been successfully completed, go to the SharePoint Central Administration menu and click Application Management. Then, under Web Applications, choose Manage web applications and select the hoozin Web Application that requires AD FS configuration.

Click Authentication Providers and choose Default, then set the following options:

1. Uncheck Enable Windows Authentication.

2. Uncheck Enable Forms Based Authentication (FBA).

3. Check Trusted Identity Provider, then check ADFS Token Issuer. (Note that

   ADFS Token Issuer is the name specified when creating the Trusted Identity Provider.)

Save and close, then perform an iisreset.

Hoozin configuration

Hoozin AD LDS needs to be synchronized with the Enterprise accounts. These accounts can be synchronized from the following sources:

• Active Directory

• CSV

• SharePoint List

• XML

Follow the instructions in the Active Directory User Synchronization section. In the directory synchronization settings Mapping tab, the source attribute of the userPrincipalName destination is the Identifier Claim. In this AD FS–SharePoint configuration, the Identifier Claim is set to email, and the source and destination configuration is as follows:

Source	Destination
mail	userPrincipalName

In some cases, the mail attribute is the same as userPrincipalName in Enterprise AD, so the source and destination can be set as userPrincipalName.

Troubleshooting

• Internet Explorer: Use Fiddler. See the AD FS 2.0: How to Use Fiddler Web Debugger to Analyze a WS-Federation Passive Sign-In Microsoft TechNet article.

• Chrome: Use the SAML-tracer extension.

• Firefox: Use the SAML-tracer add-on.

AD FS token renewal

You must have an AD FS token extracted and copied to SharePoint Server. Extract the token-signing certificate using one of the methods in the AD FS settings section above, then run the following SharePoint PowerShell commands to renew the certificate:

#Select the appropriate Token Signing Certificate from List
Get-SPTrustedRootAuthority | FL –Property Name

#Remove the Old Signing Certificate, Ex: ADFS Token Signing Certificate”
Remove-SPTrustedRootAuthority "ADFS Token Signing Certificate"

#Update the New certificate
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\NewADFSToken.cer")
$trust = Get-SPTrustedIdentityTokenIssuer -Identity "ADFS Token Issuer"
$trust.SigningCertificate = $cert
$trust.Update()
New-SPTrustedRootAuthority -Name "ADFS Token Signing Certificate" -Certificate $cert

#Restart the web application
Iisreset

Identity claim information

To get identity claim information, run the following SharePoint PowerShell commands:

$spidtkn = Get-SPTrustedIdentityTokenIssuer
$spidtkn.IdentityClaimTypeInformation
#Refer DisplayName attribute to know the IdentityClaim