Connecting SharePoint 2016/2019 and ADFS Server
ADFS + WAPSharepoint
Frank -
4:03 PM

Introduction

Many corporations are making the decision to open up their SharePoint Server to the outside world, to mobile users or for external collaboration with their partners. Because of security (and other) reasons, you don’t want to expose your SharePoint Server to the internet. So for the purposes of authentication, we can use an ADFS Server. In this case, an ADFS Server can also be used for multifactor authentication and connect it to other identity management systems.

Environment schema and authentication process

In order to enable authentication via an ADFS Server, the schema gets a bit more complex than if we only use SharePoint Server’s Active Directory authentication.

In our test environment, we have a classic SharePoint Server with a SQL Server for databases and one ADFS Server and a domain server for user authentication. Please note that the SharePoint web app should use the SSL protocol to access websites.

In our case, the authentication process is as follows:

  • A user wants to open https://adfslogin.kompas-xnet.si in his browser.
  • SharePoint receives a request to open a page. If we have multiple authentication models, the user can select the appropriate one. In our case, this is ADFS and when selected, it redirects the user to the ADFS Server.
  • The ADFS Server receives the authentication request. The URL also contains the “Realm” and the URL of the web application for identifying the request.
  • ADFS authenticates the user on the domain server.
    The ADFS Server creates a token.
  • The ADFS Server sends the token with data to the user.
  • The user sends the token to the SharePoint Server, which then authorizes the user.

Certificates

The ADFS Server uses multiple certificates. Depending on your ADFS settings, you must export different types of certificates and then import them to your SharePoint Server. The trust between SharePoint and ADFS Server is established through certificates. These can be domain certificates, issued by your local CA, or you can buy certificates from different vendors. If you wish to enable access to your SharePoint to users, who do not use your domain computers, you need to purchase a certificate.

In our case, we are going to use a certificate purchased at StartSSL www.startssl.com

In the screenshot, we can see that we are using a certificate with a common name of sts.kompas-xnet.si as our token signing certificate. This certificate must be exported and transferred to the SharePoint Server. When exporting the certificate, be careful to export it in the correct form. Make sure it does not contain a private key.

The end result of the exporting process is a file with the .cer extension. Read more about this topic in my second article.

In my previous article, I described an authentication method, where an ADFS Server is responsible for authenticating users. I also described which certificates are needed and how to properly export a certificate, so you can import it to you SharePoint Server.

ADFS Server Settings

When configuring the trust between your SharePoint Server and ADFS Server, the process is split into two parts:

  1. Establishing the trust by exchanging certificates.
  2. Establishing the relying party trust.

I will describe the process of establishing a trust between SharePoint Server and ADFS Server in a future article.

Relying Party Trust

The ADFS Server is responsible for authenticating users. SharePoint is an application that relies on ADFS to make sure that users are appropriately authenticated. Besides SharePoint, ADFS must also know that the incoming request is coming from a trustworthy application/website. This is established with a relying party trust.

If we want to add a new partner, we right click on the Relying Party Trust folder and select the Add Relying Party Trust option. In the wizard that opens up, we fill in the required information that ADFS uses to make sure the request is coming from a SharePoint Server and from the underlying application.

SELECT DATA SOURCE

In the second part of the wizard, we need to select our data source that relies on the ADFS Server. Because in our case, the data source is SharePoint, the option we need to select is “Enter data about the relying party manually”. By clicking the next button, we move to the next step.

SPECIFY DISPLAY NAME

In this step, we enter a unique, descriptive name, so we will recognize the name of our data source in the future.

CHOOSE PROFILE

In this step, we select the ADFS profile and move on to the next step.

CONFIGURE CERTIFICATE

In this step, we don’t need to perform any actions, so we can just press next.

CONFIGURE URL

In this step we need to configure two things:

  1. Select the “Enable support for the WS Federation passive protocol” option.
  2. Into the “Relying party WS Federation Passive protocol URL” field, we need to enter the URL of the web application, which will use ADFS for authentication. Next to the URL, we need to add “/_trust/“.

In our case, the URL is as follows: https://adfslogin.kompas-xnet.si/_trust/

CONFIGURE IDENTIFIERS

In this step we need to add a new entry. The entry must uniquely identify the web application which will connect to the ADFS Server. We must specify the same identifier on the SharePoint Server, but more on that in a future article.

CONFIGURE MULTI-FACTOR AUTHENTICATION

In this step, we don’t need to specify anything.

CHOOSE ISSUANCE AUTHORIZATION RULES

In this step, it is very important that we select the “Permit all users to access this relying party” option.

READY TO ADD TRUST

In this step, we click next.

FINISH

Even though this step is the last one in the wizard, we are not finished yet. We have the option to “Edit the Claims Rules Dialog for this relying party trust when wizard closes”.

A window called “Edit Claims Rules” will show up, enabling us to change what type of data users will use to identify.

Edit Claims Rules

By clicking the Add rule button, a wizard starts up which we use to specify where will ADFS authenticate the user. For AD users, we need to select “Send LDAP Attributes as Claims” and in the next step we specify what are the attributes that describe a user.

“Configure Claims Rule” defines what the name of the rule will be, what type of “Attribute store” do we have, where we set “Active Directory” and configure the mapping of Outgoing and AD attributes.

In this step, we must always select at least two types of mapping. The first one usually uniquely describes the user. Most often this is the user’s email and Outgoing Claim E-mail Address. Due to the fact that some users may not have a valid e-mail address, you can also set the User Principal Name as the identifier.

The second option is the one that usually defines AD groups a user is a member of. Mapping must be set to “Outgoing Claim Type: Role”.

When everything is set up, we can save the rules and that is everything we need to configure on the ADFS Server.

In the next article, I will describe what needs to be configured on SharePoint in order to guarantee successful authentication with the ADFS Server.

 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!

In the previous articles about connecting SharePoint 2016/2019 and ADFS Server (part 1, part 2 and part 3) we mostly discussed the procedure for configuring the servers in order to successfully authenticate with them. In this article, I would like to highlight 2 problems that can arise when turning on the trusted identity provider authentication. They are:

  • People picker.
  • Search.

People Picker

In this case, the people picker is problematic because SharePoint cannot verify people with the help of ADFS and further with Active Directory. SharePoint uses claims rules to try and figure out what kind of object is trying to access it. In the screenshot you can clearly see that the people picker successfully recognizes an object, whatever we enter into the people field.

In the people picker, we can see thath SharePoint recognized 3 different entries:

  • UPN.
  • Role.
  • Email.

The number of entries we se here depends on the configuration of the TrustedTokenIssuer.

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

In the claims mappings we can see that SharePoint gets data about »role claim«, »UPN claim« and »Email claim«. If we select one of the entries in the picker, SharePoint treats it as a completely legit entry, even though such an entry/object does not exist.

Solution

Luckily, solving this problem is simple. We install an extra solution to the server. Codeplex’s website contains a lot of community solutions, including »LDAP/AD Claims Provider for SharePoint« (https://ldapcp.codeplex.com/). Installing this add-on to our server enables our TrustedIdentityTokenIssuer to recognize users from our Active Directory, even though authentication is still performed through ADFS.

After installing the WSP packet to the SharePoint Server, it is important to successfully register the claims provider with our TrustedIdentityTokenIssuer. Of course, we must do it in PowerShell.

$tp = Get-SPTrustedIdentityTokenIssuer –Identity "ADFS30"
$tp.ClaimProviderName="LDAPCP"
$tp.Update()

After configuring the TrustedTokenIssuer, entries in the people picker become different.

In this case we see that when we enter »Robi«, only entries that are successfully resolved in Active Directory are displayed. This add-in therefore solves the problem of displaying entries that are not part of Active Directory.

Search

In any type of SharePoint configuration, that does not use Windows authentication as the default zone, or that use multiple authentication methods, indexing can be problematic. Search doesn’t know how to properly authenticate to our SharePoint webpage. In this case we need to use some extra web application settings, namely, we need to “Extend”.

When we “extend” a web application, it is very important that “default” always stays with Windows authentication, while other instances can use other methods. This is because of the way that search works. If we don’t do this and index content, that is not on default AAM, problems can arise when using search.

In our case, I created a new instance of the web application, switched Windows authentication off and configured only “Trusted Identity Provider”.

When “Extending”, a new website is created in IIS, which points to the same content database. After that, we still need to change the “default” zone, which currently allows two methods of authentication. We are going to turn off “Trusted Identity Provider” and leave only “Windows
Authentication” turned on.

But let’s not forget about the ADFS Server configuration. The “Relying Party Trust” configuration contains the URL that the ADFS Server redirects us to after a successful authentication.

If the configuration was successful, we now have a fully functional SharePoint site, which uses SAML authentication. From here on out, you have a lot of options. You can use two-factor authentication or MFA.

Archives