Connecting SharePoint 2016/2019 and ADFS Server (Part 3)

Previously, I described what needs to be done on the ADFS Server to successfully authenticate SharePoint Server. In this article, I will describe the process of configuring SharePoint Server.

Establishing Trust

To successfully establish a trust between our ADFS Server and SharePoint Server, we must import the certificate that ADFS uses to sign authentication tokens to our SharePoint Server. If we use certificates from a public certificate authority, we usually don’t need to import the root certificate. If it is a self-signed certificate, however, we also need to import the root certificate.

The following is a certificate importing script:

$adfsLogon="https://sts.kompas-xnet.si/adfs/ls/"
$signCertPath="C:\Users\sp13_farm_admin\Desktop\Certi\ADFS-TokenSigning.cer"
$rootCertPath="c:\temp\rootCert.cer"
$webAppName="adfslogin"


$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($rootCertPath)
New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root

$signingCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($signCertPath)

Mapping Claims

When mapping claims, we need to take into account the configuration of our ADFS Server. It is important to check which claims the ADFS Server is going to send and specify them in our configuration. The only way to do this is, of course, with using PowerShell:

# Claim type mapping
$roleClaim = New-SPClaimTypeMapping "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming

$EmailClaim = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName "Email Address" –SameAsIncoming

$upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN" -SameAsIncoming

Creating a New Trusted Token Issuer

For SharePoint to know that it can use another authentication method, we need to register the ADFS login. The script we will use is in many ways related to the previous commands we used:

$defaultRealm = "urn:sharepoint:$webAppName"
$signinurl = $adfsLogon
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS30" `
                    -Description "ADFS 3.0 Federated Server" `
                    -Realm $defaultRealm `
                    -ImportTrustCertificate $signingCert `
                    -ClaimsMappings $roleClaim, $EmailClaim, $upnClaimMap `
                    -SignInUrl $signinurl `
                    -IdentifierClaim $upnClaimMap.InputClaimType

When we run the command for creating a new trusted identity token issuer, we can also check the new configuration in PowerShell:

Get-SPTrustedIdentityTokenIssuer

Get-SPTrustedTokenIssuer returns the configuration of our authentication provider. We can see which claims will be used to identify a user. In our case, these are UPN, Role and Email Address.

On the screenshot we can see that we haven’t registered any ProviderRealms, which means that we don’t have any registered Web-Apps, that could use ADFS for authentication. In this case, every Web-Application that has ADFS authentication turned on presents itself as urn:sharepoint:adfslogin. If we would like to have more precise control over our Web-Applications, we can register each one of them separately. But be sure to create and configure appropriate rules on the ADFS Server.

Registering a Web-Application

To successfully register a web application, we need to run a few lines of PowerShell code. We must specify the address of our web application and how the web application will identify on the ADFS Server.

#Add URL and REALM to token issuer
$tp = Get-SPTrustedIdentityTokenIssuer –Identity "ADFS30"
$uri = new-object System.Uri("https://adfslogin.kompas-xnet.si")
$tp.ProviderRealms.Add($uri, "urn:sharepoint:adfslogin")
$tp.Update()

After running this command, we can run one of the previous commands again:

Get-SPTrustedIdentityTokenIssuer

This time, the result is as follows:

Configuring the Authentication Provider

In the central administration, we can now turn on the ADFS authentication for our web application.

First, we select the web application and click »Authentication Providers« on the ribbon.

In this case, the web application contains only the default zone. I will tell you more about what this means and what kind of restriction it represents in a future article. We select »Default« and turn on »Trusted Identity Provider« and »ADFS30«.

Click OK to confirm.

Testing if it Works

Because authentication is possible in two different ways, we are given the option to authenticate with the Windows System or with our ADFS30.

If we pick ADFS30, SharePoint redirects us to the ADFS Server, where we can enter our credentials and authenticate. If we take a look at the URL, to which we were redirected, we will notice that realm is also defined as a parameter: »wtrealm=urn%3asharepoint%3aadfslogin«.

We have successfully authenticated to SharePoint using our ADFS Server. Sadly, this is not everything we must configure in order to make everything work and make it user-friendly. We still need to fix the search settings and the people picker. So read the next article!