Part 6a: Windows Server 2012 R2 AD FS - Federated Web SSO
This is Part 6a 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 will deploy CONTOSO's highly available Web Application Proxies.
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
Topology
The following topology highlights in yellow the four servers that will be built for parts 6a and 6b and where they fit into the overall topology. If you wish to see the full topology click here
Deploy CONTOSO's First Web Application Proxy (WAP) Server
This section will deploy CONTOSO's first Web Application Proxy server.
Deploy a Windows Server 2012 R2 workgroup server and configure the IP addess, subnet mask, hostname, and DNS servers. For the purposes of this series the information will be as follows:
- Hostname: CONT-WAP01
- IP Address: 192.168.30.8
- Subnet Mask: 255.255.255.0
- DNS Servers: 192.168.30.2
Join the contoso.com domain
After rebooting, log into the server using CONTOSO domain credentials (i.e. CONTOSO\Administrator)
Add the WAP role to the server by typing the following command from an elevated PowerShell window:
- Add-WindowsFeature -Name Web-Application-Proxy -IncludeManagementTools
Request a certificate for the WAP
- From the Start Menu type MMC > File > Add/Remove Snapin > Certificates > Add > Computer Account
- Click Next > Finish > OK
- Expand Certificates > Right Click Personal > All Tasks > Request New Certificate
- Click Next, ensure Active Directory Enrollment Policy is highlighted > Next
- Select Web Server then click the More Information is required link
- For the subject name select Common Name then type sts.contoso.com and click Add
- Click the General tab and enter sts.contoso.com for the Friendly name and Description
- Click the Private Key tab
- Select Key Options > Make private key exportable then click OK > Enroll
Get the certificate thumbprint of the WAP's certificate by typing the following commands:
- dir cert:localmachine/my
Copy the cert thumbprint to Notepad or the clipboard then type the following command to connect the Web Application Proxy to the ADFS server:
- Install-WebApplicationProxy -CertificateThumbprint <thumbprint> -FederationServiceName sts.contoso.com
Enter a username and password with administrative rights on the Federation Service servers then click OK.
You should get a success message that the deployment succeeded as shown in the following Figure.
Before proceeding I recommend that you edit your hosts file on a server other than CONT-WAP01 to point sts.contoso.com to the IP address of CONT-WAP01 then verify that you are able to view the federation metadata by going to the following URL: https://sts.contoso.com/federationmetadata/2007-06/federationmetadata.xml. This will ensure the WAP is properly publishing the metadata before proceeding.
Deploy CONTOSO's Second Web Application Proxy (WAP) Server
This section will deploy CONTOSO's Second Web Application Proxy server to support a highly available configuration.
- Deploy a Windows Server 2012 R2 workgroup server and configure the IP addess, subnet mask, hostname, and DNS servers. For the purposes of this series the information will be as follows:
- Hostname: CONT-WAP02
- IP Address: 192.168.30.9
- Subnet Mask: 255.255.255.0
- DNS Servers: 192.168.30.2
- Join the contoso.com domain
- After rebooting, log into the server using CONTOSO domain credentials (i.e. CONTOSO\Administrator)
- Add the WAP role to the server by typing the following command from an elevated PowerShell window:
- Add-WindowsFeature -Name Web-Application-Proxy -IncludeManagementTools
- Export the public and private key of the certificate that was requested for CONT-WAP01 and import the certificate to CONT-WAP02's personal computer store.
- Get the certificate thumbprint of the WAP's certificate by typing the following commands:
- dir cert:localmachine/my
- Copy the cert thumbprint to Notepad or the clipboard then type the following command to connect the Web Application Proxy to the ADFS server:
- Install-WebApplicationProxy -CertificateThumbprint <thumbprint> -FederationServiceName sts.contoso.com
- Enter a username and password with administrative rights on the Federation Service servers then click OK.
- You should get a success message that the deployment succeeded as shown in the following Figure.
- Before proceeding I recommend that you edit your hosts file on a server other than the CONT-WAP02 to point sts.contoso.com to the IP address of CONT-WAP02 then verify that you are able to view the federation metadata by going to the following URL: https://sts.contoso.com/federationmetadata/2007-06/federationmetadata.xml. This will ensure the WAP is properly publishing the metadata before proceeding.
Install Windows NLB (OPTIONAL)
The following steps will make the WAP deployment a highly available service. Typically in a production environment, a 3rd party load balancer is used to provide this functionality. If you choose to skip the deployment of Windows NLB or a 3rd party load balancer ensure to change the external sts.contoso.com DNS A record IP address to point to either CONT-WAP01 or CONT-WAP02.
Deploy NLB to CONT-WAP01
- Log into CONT-WAP01 and open an elevated PowerShell window
- Type the following commands to add NLB to CONT-WAP01 and to configure the port rules
- Add-WindowsFeature NLB,RSAT-NLB -IncludeManagementTools
- New-NlbCluster -Hostname CONT-WAP01 -Interface "Ethernet" -ClusterName WAPNLB -ClusterPrimaryIP 192.168.30.10 -SubnetMask 255.255.255.0 -OperationMode Multicast. Note: if you are unsure of the Inteface name or this command fails type Get-NetAdapter | fl name to get the interface name
- Get-NlbClusterPortRule | Remove-NlbClusterPortRule -Force
- Add-NlbClusterPortRule -StartPort 443 -EndPort 443 -IP 192.168.30.10 -Protocol Tcp -Affinity Single -Interface "Ethernet"
- Add-NlbClusterPortRule -StartPort 49443 -EndPort 49443 -IP 192.168.30.10 -Protocol Tcp -Affinity Single -Interface "Ethernet"
- Verify that the cluster is operational by typing the following command: Get-NlbCluster
Deploy NLB to CONT-WAP02
- Log into CONT-WAP02 and open an elevated PowerShell window
- Type the following commands to add NLB to CONT-WAP02
- Add-WindowsFeature NLB,RSAT-NLB -IncludeManagementTools
- Add-NlbClusterNode -NewNodeName CONT-WAP02 -NewNodeInterface "Ethernet" -Hostname CONT-WAP01 -Interface "Ethernet"
- Verify that the cluster is fully converged by typing the following command: Get-NlbCluster
Verify NLB and AD FS Federation Metadata
Verify NLB is fully configured by going to the start screen > type network load balancing manager then press enter. NLB should show that it is fully converged.
Verify AD FS by editing the hosts file of one of the servers to point sts.contoso.com to the NLB virtual IP address then by typing the following URL into a browser window: https://sts.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml. The federation metadata should display.
If you chose to deploy NLB or a 3rd party loadbalancer, ensure both nodes work as intended before proceeding by drainstopping one of the nodes (Powershell: Stop-NlbClusterNode -Drain -Hostname CONT-WAP01 or CONT-WAP02). A common problem I have seen when dealing with clustering is that only one node works so users get intermittent errors that can be hard to troubleshoot since traffic occasionally hits the non-working node.
If your environment is virtual and your hypervisor host is Hyper-V and the NLB VIP is unreachable outside of the NLB cluster's VLAN or you encounter intermittent connectivity problems to the VIP then try enabling MAC spoofing for the VM as explained here. If your hypervisor is VMware, you may need a static mapped mac address entry to resolve the issue.
Wrap-Up
You now have two forests one named contoso.com and one named fabrikam.com along with the DNS records, certificate services, database services, CONTOSO's and FABRIKAM's SharePoint Foundation 2013 services, and CONTOSO's and FABRIKAM's Windows Server 2012 R2 AD FS services, and CONTOSO's Web Application Proxy services.. In the upcoming parts FABRIKAM's Web Application Proxies will be deployed and configured to support federated web SSO, a bi-directional AD FS trust will be established, external DNS will be configured, and different login scenarios will be tested.
Troubleshooting
- If the WAP's federation metadata does not display, ensure the WAP's service is started: Get-Service appproxy* | fl name,status
- If the WAP fails to connect to the ADFS servers, verify that the WAP can properly resolve the service name of the ADFS service running on the ADFS servers (i.e. sts.contoso.com)
- If the WAP is in a workgroup, ensure the WAP trusts the CA that signed the ADFS Service's Service Communications certificate.
Comments
- Anonymous
February 16, 2015
Overview
The purpose of this series is to walk you through step-by-step from start to finish setting - Anonymous
February 16, 2015
Thanks - Anonymous
May 14, 2015
Any update on the remaining parts of this lab?? Part 6b...etc. - Anonymous
September 15, 2015
Will this be continued? - Anonymous
October 06, 2015
Hi,
Nice Article
I have successfully deployed ADFS and Web Application Proxy
However, now I want to use the same ADFS Server for another application
I added another Relying Party using metadata file, however, am facing some confusion regarding Publishing it via Web Application Proxy
I would like to know the exact meaning and difference between the External URL and the Backend URL
The first Relying Party I setup was published to the same Public URL to which the ADFS Server was setup, example :https://abc01.contoso.com
It used a SSL certificate issued to "https://abc01.contoso.com"
My ADFS Federation Service name is also "abc01.contoso.com"
Hence, the Public Certificate I used while publishing is the same as the SSL/Service Communication Certificate setup in my ADFS
Since, Web Application Proxy does not support nesting of URLs, I am unable to Publish my second Relying Party to another path of the same Public URL, example :https://abc01.contoso.com/second/ is not accepted
Will creating a new sub domain for the second Relying Party and publishing it to the new sub domain work ? example :https://second.contoso.com
In this case is my Backend URL supposed to be set as the ADFS Service Name URL "https://abc01.contoso.com" OR can it also be set as the new sub domain I create "https://second.contoso.com"
Will using "https://second.contoso.com" and a different certificate(issued tohttps://second.contoso.com) during publishing still let users authenticate via ADFS even though ADFS is configured for the first URL "abc01.contoso.com"
Thanks and Regards,
Jack - Anonymous
October 26, 2015
This is Part 6b of a multi-part series on how to deploy a complete end-to-end Federated Web SSO solution - Anonymous
October 27, 2015
This is Part 7 of a multi-part series on how to deploy a complete end-to-end Federated Web SSO solution - Anonymous
October 28, 2015
This is Part 8 of a multi-part series on how to deploy a complete end-to-end Federated Web SSO solution - Anonymous
October 28, 2015
This is Part 9 of a multi-part series on how to deploy a complete end-to-end Federated Web SSO solution