Welcome to part three of a four-part series on configuring single sign-on for hybrid Office 365. In part one, we...
prepped the Active Directory forest for Active Directory Federation Services (AD FS). In part two, we detailed the steps required to configure a load-balanced Active Directory federation farm. We'll now examine how to set up federation proxy servers.
The Active Directory Federation Services 2.0 federation server resides in the extranet and acts as a proxy for client logons to a federation server located in the corporate network. The federation server proxy also facilitates the distribution of security tokens for remote clients attempting to access Office 365. For security purposes, these servers should not be joined to your Active Directory domain.
Configure DNS requirements
When deploying a federation proxy farm, the Federation Service name on the internal corporate network must match the Domain Name System (DNS) cluster name you'll use for the federation proxy servers. Because the federation proxy servers are set up in the perimeter network, they are not a member of the Active Directory domain. Therefore, do not use your corporate network DNS servers for name resolution.
The federation proxy servers in my lab environment (Kbomb) are configured to use the Google DNS server (184.108.40.206) on the Internet for DNS name resolution. This leads to the obvious question: "How will my federation proxy servers communicate with the federation farm on the corporate network if the public DNS servers for Kbomb.com.au resolve to the public IP address pointing to the federation proxy servers?"
The answer is to modify the host file on all federation proxy servers. Servers always check the host file before attempting DNS name resolution. This means the federation proxy servers will always resolve fs.Kbomb.com.au to the federation farm on the internal network, and hosts on the Internet will resolve fs.Kbomb.com.au to the public IP address pointing to the federation proxy servers.
To start, modify the hosts file located under C:\Windows\System32\drivers\etc\ on all federation proxy servers (Figure 1).
On your public DNS zone, you should also create a new Host A record for the federation proxy farm that is pointing to your public IP address. In my lab example, I've chosen to host the public DNS zone for Kbomb.com.au with a company known as Web in a Box (Figure 2).
Install Internet Information Services
Internet Information Services (IIS) 7.5 must be installed on all servers running the federation proxy servers. Add the role through Server Manager, then select the default IIS 7.5 feature set (Figure 3).
Install the digital certificate
You must now install the digital certificate, along with the associated private key that we created in part two (see link at top of this tip) on all federation proxy servers.
Because the federation proxy servers use the same DNS cluster name as the federation farm, we can use the same digital certificate.
Note: Make sure to install the entire certificate chain on the federation proxy servers; this includes all intermediate certificates.
Assign your digital certificate
The digital certificate must now be assigned to the Default Web Site on all federation proxy servers. Therefore, you must install it on the Default Web Site before you can use the AD FS 2.0 Federation Server Configuration Wizard.
Perform the following procedure on all federation proxy servers:
1. Right-click on Default Web Site, then click Edit Bindings.
2. Click Add. Then, in the Add Site Bindings dialog box, select the certificate you created earlier in the series and click OK.
Download Active Directory Federation Services
The next step is to download Active Directory Federation Services. In this hybrid Office 365 single sign-on series, we are using the following build: RTW\W2K8R2\amd64\AdfsSetup.exe.
Note: Make sure that .NET Framework 3.5 is installed on all servers that will be configured under your AD FS farm.
Install Active Directory Federation Services
The next step is to install AD FS on all of your federation proxy servers with the following procedure:
1. Locate the AdfsSetup.exe setup file and double-click it.
2. Click Next on the Welcome screen.
3. Read the terms in the License Agreement check box, then click Next to accept.
4. Select "Federation server proxy" and click Next.
5. At the end of the wizard, de-select Start the AD FS 2.0 Management snap-in when this wizard closes and click Finish.
Configure the federation server proxy role
Now that all of the servers in your federation server proxy farm are set up with the required certificates, and the AD FS 2.0 software is installed, you can configure the servers to become a federation server proxy using the AD FS 2.0 Federation Server Proxy Configuration Wizard.
Perform the following procedure on all federation server proxies.
1. After the AD FS proxy software installation is complete, click Start -> Administrative Tools -> AD FS 2.0 Federation Server Proxy Configuration Wizard. This will begin configuring the federation server proxies. When you come to the Welcome screen, click Next (Figure 4).
2. On the Specify Federation Service Name page, under Federation Service name, type the name of the Federation Service that this computer will act as the proxy for. Click Test Connection to test the Federation Service in your corporate network, then click Next (Figure 5).
3. When prompted, specify the credentials necessary to establish a trust between this federation server proxy and the Federation Service. By default, only the service account that the Federation Service uses, or a member of the local BUILTIN\Administrators group, can authorize a federation server proxy.
Note: Use the service account credentials specified in part two of this series (link available at the top of this tip).
4. Review the details on the Ready to Apply Settings page. If the settings look correct, click Next. This will begin configuring the computer with the proxy settings.
5. Now review the results on the Configuration Results page. When all the configuration steps are complete, click Close to exit the wizard.
Configure network load balancing
Now that our two servers are configured in our federation server proxy farm, we need to load balance incoming conections from the Internet to fs.Kbomb.com.au.
Note: Since this is a lab environment, incoming connections from the Internet are translated through Network Address Translation (NAT) to a private IP address. This means all IP addresses will appear to come from the same address, and Microsoft network load balancing is unable to load balance the connections.
Network load balancing adds value by providing automatic failover if a server were to fail. Cookie-based persistence can be configured when load balancing connections through NAT. However, this requires a more advanced load balancer, such as F5's BIG-IP.
Now perform the following procedure:
1. Add the Network Load Balancing feature from Server Manager on all servers within your farm (Figure 6).
2. On the first server in your federation proxy farm, open the Network Load Balancing manager and select New from the Cluster menu.
3. Under Host, enter "localhost" and click Connect. Make sure to select the network interface that is connected to your perimeter network.
Note: In my lab environment I use a flat subnet. In your production environment, make sure that you have a firewall separating the corporate network from the perimeter network.
4. Under Host Parameters, mark the the Priority as "1." Under Initiate host state, set the default state to "Started." Under Dedicated IP addresses, enter the IP address of the server's network adapter.
5. Click Add and enter in the cluster IP address. This IP address must resolve to the name matching the Federation Service fs.Kbomb.com.au. Click Next (Figure 7).
6. Microsoft network load balancing (NLB) has two primary ways of working: Multicast and Unicast. Multicast requries a single network interface on each server to partake in load balancing. Unicast requires two network interfaces on each server to partake in load balancing and is generally the perfered method for implementing NLB.
Now, under Cluster Parameters, select the cluster IP address we created earlier, then enter the Full Internet name of the cluster to match the Federation Service name. Next, set the cluster operation mode to Multicast (Figure 8).
7. You must now configure Microsoft NLB to listen on TCP 443 for incoming requests. Under Filtering mode, select "multiple hosts" and set the Affinity to "Single." Active Directory Federation Services is a stateful application and must maintain persistent connections from the same IP address.
8. Add the second host to the cluster by right-clicking the cluster. Select Add Host to Cluster.
9. Enter the Host as the next server in your federation server proxy farm and click Connect. Select your network interface, then click Next.
Note: You cannot specify the server by host name, as the perimeter servers are using Google's DNS server (220.127.116.11).
10. On the Host Parameters page, leave all options at their default values, then click Next.
11. On the Port Rules page, leave all options at their default, then click Next.
12. Both Hosts will not participate in the NLB cluster and accept requests sent to the 10.4.2.16 IP address (Figure 9).
13. After rebooting the AD FS proxy servers, I noticed that NLB was not able to communicate with the other cluster node. This is because NLB tries to use the host name instead of the IP addresses to establish communication (Figure 10).
To resolve this issue, add the hostname and IP address of all AD FS proxy servers to the host files on all nodes (Figure 11).
Note: I experienced an issue where I was unable to route to my NLB Multicast address over layer 3 through my Cisco router. I've documented the solution on my personal blog.
This concludes part three of this four-part series. In the fourth part, we examine the PowerShell commands necessary to federate Exchange 2010 with Office 365.