Part 9 – Windows Server 2012 R2 AD FS – Federated Web SSO

This is Part 9 and the final part of a multi-part series on how to deploy a complete end-to-end Federated Web SSO solution using Windows Server 2012 R2's AD FS role and the Web Application Proxy. In this part I configure SharePoint 2013 to accept claims, I will create a test user in CONTOSO and FABRIKAM, and I will test the federated Web SSO process from both directions.

In case you missed it:

Here is Part 1 – Overview

Here is Part 2 – Installing AD DS, AD CS, and DNS Records

Here is Part 3 – Installing SQL Database Services

Here is Part 4a – Installing CONTOSO's SharePoint Services

Here is Part 4b – Installing FABRIKAM's SharePoint Services

Here is Part 5a – Installing CONTOSO's AD FS Services

Here is Part 5b – Installing FABRIKAM's AD FS Services

Here is Part 6a – Installing CONTOSO's Web Application Proxies

Here is Part 6b – Installing FABRIKAM's Web Application Proxies

Here is Part 7 – Installing External DNS and Workstations

Here is Part 8 – Creating the circle of trust

Topology

The following topology highlights in yellow the servers and workstations that will be used in this post. If you wish to see the full topology click here

Configure CONTOSO's SharePoint Server

At this point SharePoint is configured to accept claims from a Trusted Identity Token issuer, in this case that is the AD FS servers, however the web applications within SharePoint need to be configured to use the new trusted identity token issuer as their authentication provider. For this lab we only have one web application, the following steps will configure it to accept claims.

1. Log into CONTOSO's SharePoint server
2. Open SharePoint's Central Administration web page
3. Click Application Management > Manage Web Applications
4. You should have a single web application similar to the one shown in the following figure.
   
5. Highlight the web application and click Authentication Providers > Default
   
6. Scroll down to where it says Trusted Identity Provider, you should have an identity provider called ADFS similar to the following image.Click the "Trusted Identity Provider" checkbox > ADFS
7. Uncheck Enable Windows Authentication
8. Scroll to the bottom and click Save
9. Repeat these steps for FABRIKAM's SharePoint server and web application.

The SharePoint web application is now configured to accept claims or more specifically a single claim; email addresses. Since we do not have Exchange in the lab environment, we will next have to go configure an email address for the test users or else we will be unable to authenticate to SharePoint.

Configure Test Accounts

• CONTOSO
  • Log into the CONTOSO domain controller and add administrator@contoso.com to the email field for the Administrator account
  • Create a new user called John Doe with an email address of jdoe@contoso.com
• FABRIKAM
  • Log into the FABRIKAM domain controller and add administrator@fabrikam.com to the email field for the Administrator account
  • Create a new user called Sarah Doe with an email address of sdoe@fabrikam.com

Test INTERNAL AD FS

1. Log into CONTOSO's workstation CONT-WK01 as the administrator.
2. Open IE and go to https://www.contoso.com
3. You should see the web page similar to the following figure
4. Click Sign In in the upper right corner.
5. You should now be presented with an AD FS home realm discovery page which asks you which organization's credentials you would like to use to authenticate to the portal as shown in the following figure
6. Click CONTOSO Users.
7. You should now be successfully signed into the CONTOSO portal using your email claim as evidenced by the email address in the upper right corner; shown in the following figure.
8. Repeat this test with FABRIKAM. Make sure that you have provisioned an email address for the Administrator account in the FABRIKAM forest and click FABRIKAM users at the FABRIKAM AD FS home realm discovery page. After logging into a FABRIKAM workstation and going to https://www.fabrikam.com > Sign In you should be presented with a successful login as shown in the following figure.

If you made it this far then congratulations are in order, you now have two organizations with AD FS and SharePoint fully configured. One thing I should point out before proceeding is that if you look at the images above you will notice that IE is in Private mode. I always use Private mode when testing AD FS because cookies are being set all over the place. If you use IE in normal mode closing and re-opening the browser will not delete the cookies, so if you recently made a change and want to test it, some of the cookies from the previous session may give you false positives or negatives. By testing in Private mode, you can be certain that closing and re-opening the browser will clear all of the previous settings. To open IE in private mode I press Windows+R and type iexplore -private

Test FEDERATED AD FS

Now it is finally time to test federated AD FS end-to-end. This is where a CONTOSO or FABRIKAM user logs into their local domain and can sign into the other organization's web portal using the federated trust.

1.  Log into the CONTOSO workstation
2. Open IE and go to https://www.fabrikam.com
   
3. Click Sign In
   
4. Select CONTOSO Users
   
5. Select CONTOSO Users again
   
6. You should now be signed into FABRIKAM's portal using CONTOSO's credentials as shown in the following figure.
   

The last test is to repeat these steps to test from the opposite direction. Don't forget you also have a completely external workstation called EX-WK-01 which you an use to test non-domain joined users. The only difference in the sign in experience will be that when you select CONTOSO Users or FABRIKAM Users you will be presented with the following login dialogue box since the AD FS server cannot obtain your domain credentials from your workstation. This prompt is the Web Application Proxy's Forms Based Authentication page which can be customized as needed. See here for more information.

BONUS

Everything is working as planned right? But how good would you rate the user experience at this point? More importantly how good would your users rate their user experience during the sign in process? Most Intranet users would not want to have to click Sign In then have to select CONTOSO or FABRIKAM Users just to sign into their own Intranet portal. Also, most users would not want to have to select their organization twice when logging into the federated organization's portal. The fix for both of these scenarios is to tell the AD FS server to use the Active Directory provider for Intranet users. This will eliminate the sign-in prompt that user's were getting from the Intranet AD FS server's home realm discovery process and make the login process more intuitive for Intranet users.

1. Log into CONTOSO's or FABRIKAM's server
2. Open an elevated PowerShell window and type the following command: Set-AdfsProperties -IntranetUseLocalClaimsProvider $true
   
3. Repeat these steps for the other organization's AD FS server
   
4. Log into CONT-WK01 > Open IE > go to https://www.contoso.com
   
5. Click Sign In
   
6. You will now be signed in without first being prompted to select CONTOSO Users or FABRIKAM Users
   
7. Next type https://www.fabrikam.com and click Sign In and select CONTOSO Users
   
8. You will now be signed in without having to select CONTOSO Users again
   

 Wrap-Up

At long last this series is complete. If you follow every step in the series you will have a complete end-to-end lab environment where you can test almost every possible AD FS scenario, and hopefully you have a better understanding of how federated AD FS works as well as how to configure the WAP and AD FS services to be highly available. Along the way I also provided tips and advice that I have accumulated after deploying and troubleshooting AD FS deployments for multiple customers. Speaking of troubleshooting see the following section for a few more troubleshooting tips in case your environment does not work as desired.

I am not a SharePoint expert but I am aware that People Picker's behavior within SharePoint changes after enabling AD FS, and some other changes happen behind the scenes as well. Ensure you fully understand the impact of those changes to SharePoint and how to mitigate them prior to making changes to a production SharePoint environment.

Troubleshooting

• You are unable to sign into the local SharePoint server using AD FS
  • Verify that SharePoint trusts the AD FS server's token signing certificate: SharePoint Management Shell > Get-SPTrustedRootAuthority
  • Verify that your Trusted Token Identity Issuer is property configured: SharePoint Management Shell > Get-SPTrustedIdentityTokenIssuer . What you are looking for here is that the Provider URI is correct, that the Default Provider Realm matches the AD FS server's provider realm, and that the signing certificate is in fact the certificate that is being used by the AD FS server. Also verify that the claim type is email address and that the Email Address is the identity claim
  • Verify that the account you are using has an email address. Log into the domain controller and enter the following commands from PowerShell: Get-ADUser Administrator -Properties * | fl name,mail if the mail attribute is empty, then the account will not work
  • Verify that your web application is configured with your AD FS Authentication Provider: SharePoint Management Shell > Get-SPWebApplication | %{Get-SPAuthenticationProvider -WebApplication $_.DisplayName -Zone "Default"} The display name and LoginProviderName should be ADFS
    
  • Verify that the AD FS SharePoint Relying Party trust is properly configured. Log into the AD FS Server > Elevated PowerShell > Get-AdfsRelyingPartyTrust -Name "SharePoint 2013". Make sure that Active Directory is configured as an IssuanceTransformRule and that is is configured to send Email Address claims.  Also make sure the Identifier value is the same as the Provider Realm within SharePoint's SPTrustedIdentityTokenIssuer configuration. Make sure that the WSFedEndpoint is the proper URL and ends in /_trust (i.e. https://www.contoso.com/_trust)
    
  • Make sure that DNS works everywhere. DNS problems will quickly break everything, make sure that the AD FS server can resolve the SharePoint address, vice versa, and that the desktop client can resolve the AD FS URL and the SharePoint URL. Make sure that the AD FS url resolves to the AD FS server not the WAP
    
• You are unable to sign into the remote SharePoint Server using AD FS
  • Before attempting to sign into a remote organization, make certain that AD FS is working internally, also make certain that AD FS is working internally for the remote organization.
    
  • If this is a lab environment, verify that certificate revocation checking works, or that is is disabled on both sides for both the relying party trusts and claims provider trusts and for both the signing and encrypting certificates (Get-AdfsRelyingPartyTrust / Get-AdfsClaimsProviderTrust)
    
  • Verify that both organizations can resolve their federation metadata and SharePoint URLs in DNS for the other organization
    
  • Ensure that the user account that is being used to test has an email address
    
  • Verify that the proper claims provider and relying party trusts are in place to send and accept the claims
    
  • Verify that the claims provider trust is configured to receive the email address as a claim and verify that the relying party trust is configured to send the email address as a claim
    
  • Verify that claim filtering, if configured is properly configured on both sides.
    
  • Verify that each organization resolves to the WAP's IP address in the other organization for federation services, not the AD FS servers
    
• You are unable to sign into the SharePoint server from a non-domain joined workstation
  • Verify that you can resolve both the federation metadata URL as well as the SharePoint portal using DNS
    
  • Verify that the workstation's DNS resolves to the WAP server's IP address not the AD FS server's
    
  • Verify that the workstation trusts the CA that signed the AD FS and SharePoint server's certificates