Deploying ADFS 3.0 for SharePoint 2013 in a perimeter network

Many organizations that intend to deploy a public facing on-premises SharePoint farm will want to do so in a perimeter network. Perimeter networks often have no more than a one-way trust with the private employee internal network. This walk through is one approach of how you can setup authentication using ADFS 3.0 for SharePoint 2013 in order to leverage a better sign-in experience for clients.

Once this process is complete, you will also be able to take the next step by implementing and leveraging then new Web Application Proxy feature in Windows 2012r2 as well if you choose to.

The first item to tackle is deploying an ADFS server into the perimeter network in a way that it will still be able to authenticate internal users on the private LAN when there is only a one-way trust in place. DMZ trusts LAN, but LAN does not trust DMZ. This is a common scenario.

Building a new ADFS server in DMZ using LAN service account

First, be sure that your one way trust is a forest trust and not an external trust. If it is an external trust remove it and recreate the trust using forest trust as the option. The reason for this is that if you want UPN suffixes for your internal staff login (user@domain.com), UPN suffix routing is required and only available with forest trusts.

We use UPN suffixes for all our clients in the DMZ AD so that usernames match email addresses. It makes it easier. For staff in the internal domain, the name is different than our public one so we have a UPN that matches our username@publicdomainname.com instead of internaldomain\user.

Build a new Windows 2012 R2 server in your DMZ, assign it a static IP (ADFSDMZ01.yourDMZ_AD.com)

The ADFS server will use URL ‘https://ADFS.publicdomain.com’ for the ADFS service once configured.

Create a static DNS A record in your internal LAN for the ADFS service URL to point to the DMZ IP.

In the LAN (internaldomain.com) create a service account to be used for the Perimeter ADFS server (internaldomain\adfsdmzsvcupnadfsdmz@publicdomainname.com)

Set an SPN HOST record for this service account that points to the ADFS service URL. Do not copy/paste this command as setspn will throw ‘unknown parameter’. You need to type this out yourself.

Setspn –A HOST/adfs.publicdomain.com internaldomain\adfsdmzsvc

On the newly installed ADFS server, install the ADFS 3.0 role and any prerequisites. Then, run Windows update. Do not ‘configure’ ADFS yet.

Open the MMC for certificates on local machine and import a certificate to use for the ADFS service URL. I used a wildcard certificate for habaneroconsulting.com for this–thinking of web application proxy later–otherwise it needs to match the ADFS URL FQDN.

In your perimeter firewall ensure the IP from your ADFS server has LDAP access to your LAN LDAP server (your DCs). Ensure there is 443 access to this server from your LAN and a public IP NATed to it (or routed through a WAP or what have you).

On the ADFS server add the internal domain service account to the local administrators group.

Add this service account as well–temporarily–as a domain admin in the LAN domain. You can and should remove this one after you complete the ADFS configuration wizard, but it is needed to make ADFS OU configuration changes. Otherwise, you will have to manually make the configuration changes prior to running the ADFS config wizard. It lasts only for a few minutes, so I took the easy route.

Login to the ADFS service as the internaldomain service account and run the ADFS configuration wizard. When prompted, enter the credentials of a DMZ domain admin. If you used a wildcard certificate, be sure to put the proper FQDN name in for the service URL as it will just mimic the wildcard certificate unless otherwise.

You will get an SPN error at the completion. Ignore this. We already set the SPN manually.

You can remove the ADFSDMZSVC account from domain admins group once this is complete, but leave it on the local admin group until you finish configuring claims and rely settings in ADFS.

Configure Relying trusts for SharePoint 2013 on ADFS 3.0 server

Open the ADFS management console, expand Trust relationships, r-click Relying Party trusts and choose add relying party trust.

Click start, then select the third option: ‘Enter data about relying party manually' and click next.

Enter a descriptive name (I chose TEAMSQA relying trust for the name).

Select first option AD FS profile and click next.

Do not specify an encryption certificate, just click next.

Check the first box ‘Enable support for WS-Federation Passive protocol’.

In the relaying party URL enter the FQDN of your SharePoint site, including HTTPS and adding /_trust/ to the end.  For example:

https://portal.publicdomainanme.com/_trust/

On the next page, add a Relying party trust identifier. You will need this for your SharePoint configuration. Use the format urn:something:somethingelse

For example I chose urn:sharepoint:teamsqa  The syntax of urn:xx:xx is important. What you enter is not important.

On the next page, do not bother with multi-factor. Just click next, again.

Select ‘permit all users to access this relying party’ and click next, next and finish. Leave ‘launch claim rule’ checked.

Claim rule editor will launch.

On theIssuance Transform Rules tab, click Add Rule.

On the Select Rule Template page, select Send LDAP Attributes as Claims. Click Next.

On the Configure Rule page, type the name of the claim rule in the Claim rule name field.

From the Attribute Store drop-down list, select Active Directory.

In the Mapping of LDAP attributes to outgoing claim types section, under LDAP Attribute, select E-Mail-Addresses.

Under Outgoing Claim Type, select E-Mail Address.

Under LDAP Attribute, select User-Principal-Name.

Under Outgoing Claim Type, select UPN.

Click Finish, and then click OK.

Export the token signing certificate.

In ADFS management console expand service and click on the certificates folder.

While you are here, select the token signing and token decrypting certificates one at a time. View the certificate, then install the certificate in the local machine store of trusted root authorities. Windows 2012r2 does not trust its own self signed certificates by default.

Now view the Token signing certificate, click the details tab, and select copy to file.

The export wizard starts. Click Next, select the default of DER X.509 and click Next.

Save it wherever you want. I saved it as c:\installs\adfs.cer

Configuring the SharePoint server

Logon to the SharePoint server with administrative rights.

Copy this over the certificate you exports to your SharePoint server somewhere.

Install the certificate into the local machine certificate store for Trusted Root Authorities.

You need to do this because it was a self-signed certificate from the ADFS server, and this server will not trust it otherwise. If you have multiple Token signing certificates, or the parent certificate is different (not self-issued) then you will also need to export the parent certificate from the ADFS token signing certificate.

This is not the case if you followed these steps, but in you are jumping into an already deployed ADFS server, this may be the case. If so, go to the certificate path tab on the token signing certificate, select each certificate listed there in the chain, and view then export each.  Again – this is not the case in this walk through.

Open PowerShell with elevated privileges.

Create a variable for your certificate by running this command:

$cert = New-Object
System.Security.Cryptography.X509Certificates.X509Certificate2("")

You will need to run SharePoint commands now, so import the admin shell by running:

Add-PSSnapin Microsoft.SharePoint.Powershell

Create the new Trusted Root Authority in SharePoint:

New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert

If you had a parent certificate to the root (in the above note) then you would want to create another variable for that certificate, and add it to SharePoint as well, just change the description name to something else such as parent :

New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $

Define all of your Claim type mappings that you may use (email address, UPNs, Roles, SIDs) by setting up these four variables:

=$emailClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN" -SameAsIncoming
$roleClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming
$sidClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid" -IncomingClaimTypeDisplayName "SID" –SameAsIncoming

Create the new Authentication Provider.

Setup the Relying party identifier variable.

$realm = “urn:whateveryouused:whateveryouusedhere”

For example I used urn:sharepoint:teamsqa as that is what I specified in ADFS as the identifier.

Setup the URL that SharePoint will direct Sign-in to.

$signInURL = "[https://%3cYourADFSServerName%3e/adfs/ls]https:///adfs/ls"

For example https://adfs.publicdomainname.com/adfs/ls

Put it all together for SharePoint.

$ap = New-SPTrustedIdentityTokenIssuer -Name “a Provider Name” -Description “a Provider Description” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $emailClaimMap,$upnClaimMap,$roleClaimMap,$sidClaimMap -SignInUrl $signInURL -IdentifierClaim $emailClaimmap.InputClaimType

ProviderName can be anything you want – just make it friendly and descriptive (I used “ADFS Login”).

Now you can login to Central Admin on your Farm, go to Manage web applications under Application management, highlight your main portal site (or whatever site you want this to be used on), and click Authentication providers (NOTE: NEEDS to be an SSL URL).

Click the zone (Default usually) that you want to configure.

Under Edit Authentication page in the Claims Authentication Types section, select Trusted Identity provider and then click the SAML provider you created.

Set the login URL.

Users will now be given the option to sign in using either of the authentication providers you have selected.

You will likely want to remove this step and have all login efforts go directly to ADFS instead.

To do so scroll down a little further, to the Sign in Page URL section, and select Custom Sign In Page, then enter the value 

/_trust/default.aspx

Hit Save and wait.

Now, there are a couple of additional housekeeping tasks you may want to take care of after setting this all up.

One issue is related to relying token timeout and intermittent ADFS authentication issues.

If this is still an issue when you implement SAML then check out this article.

The essence of this article is that to resolve the authentication loop between ADFS and SharePoint, you need to adjust the Token lifetime on the ADFS token, and reduce the Token cache lifespan on SharePoint.

On ADFS: from PowerShell run:

 
Set-ADFSRelyingPartyTrust -TargetName "Your Relying trust’s display name" -TokenLifetime 5

On SharePoint: from PowerShell run:

 
$sts = Get-SPSecurityTokenServiceConfig
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)
$sts.Update()
Iisreset

The other issue is related to people picker providing multiple results to queries – one for each claim type map you added. If this issue still exists by the time you have used this article, then check out this site.

Stories say it best.

Are you ready to make your workplace awesome? We're keen to hear what you have in mind.

Interested in learning more about the work we do?

Explore our culture and transformation services.

Our commitment to reconciliation

Learn how Habanero is responding to the Truth and Reconciliation Calls to Action as a settler-owned company operating on Indigenous territories across what is now called Canada.

Read about our commitment