If you would like to read the other parts in this article series please go to:
In part 3 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, I explained what identity federation against the new Office 365 is. In addition, we configured the two ADFS servers in a Windows Network Load Balancing (WNLB) cluster in order to load balance incoming authentication sessions.
In this part 4, we will continue where we left off in part 3. That is, we will install and configure Active Directory Federation Service (ADFS) 2.1 on the two ADFS servers on the internal network. After we have configured the servers, we will verify they work as expected.
Since all client authentication against ADFS occurs via SSL, we need to import a server authentication certificate on each ADFS server. Because all clients should trust this certificate, it is recommended to import a certificate from a third party certificate provider. Although we use a wildcard certificate in this article series, a single name SSL certificate is sufficient. If you use a single name certificate, the FQDN included should match the FQDN we configured in the previous article (in this example sts.clouduser.dk).
To import the certificate, first install the Windows Server 2012 “Web Server (IIS)” role. You can do this just like you installed the Network Load Balancing component earlier on. That is by opening the Server Manager > click “Manage” > Add Roles and Features and then tick the Web Server (IIS) role in the wizard.
Figure 1: Selecting the Web Server (IIS) role
To import the server authentication certificate, open the IIS Manager, and select the web server object followed by opening “Server Certificates” in the middle pane.
Figure 2: Launching the IIS Manager
Figure 3: Selecting Server Certificates in IIS Manager
Under Server Certificates, click ”Import” in the action pane as shown in Figure 4.
Figure 4: Clicking “Import” under Server certificates in the IIS Manager
Point to the certificate you wish to import and then specify the password, then click ”OK”.
Figure 5: Pointing to the certificate we wish to import
As can be seen in Figure 6, the certificate has now been imported to IIS.
Figure 6: Certificate has been imported
Next step is to bind the certificate to the “Default Web Site”. To do so, expand ”Sites” then select the ”Default Web Site” and click on the ”Bindings” link in the ”Action Pane”.
Figure 7: Clicking “Bindings” under Sites in IIS Manager
Under ”Site Bindings” click ”Add”. In ”Add Site Bindings”, select ”HTTPS” in the ”Type” drop-down box and then point at the imported certificate under ”SSL certificate”.
Figure 8: Adding a new site binding for HTTPS
Click ”OK” twice.
Repeat the above steps on the secondary ADFS server.
With the two ADFS servers configured in a WNLB cluster and the required certificate imported, it is time to get the Windows Server 2012 Active Directory Federation service (AD FS) role installed and configured on both servers.
With Windows Server 2008 R2 based servers, we had to use the separate ADFS 2.0 RTW package, that could be downloaded here. However, with Windows Server 2012 we use the native ADFS role (ADFS 2.1).
To install the ADFS role, open the “Server Manager” and click “Add Roles and Features” launch “AdfsSetup.exe” and then accept the license agreement.
Figure 9: Installing the ADFS 2.role
When the ADFS role has been installed, click “Run the AD FS Management snap-in” in order to perform the rest of the post-deployment configuration.
Figure 10: Launching the ADFS Management console
With the ADFS Management console opened, click “ AD FS Federation Server Configuration Wizard”.
Figure 11: Launching the AD FS Federation Server Configuration wizard
On the “Welcome” page, we need to specify which to configure. Since these are the two internal ADFS servers we wish to configure a “Federation service” so select that and click “Next”.
Figure 12: Selecting “Federation Server” in the ADFS Setup wizard
On the “Select Deployment Type” page, select “New federation server farm”.
Figure 13: ADFS Deployment Type page
Now we need to specify the federation service name which in this case is “sts.clouduser.dk”. Well, actually based on the common name in the certificate the wizard will do this automatically, but since we use a wildcard certificate in this article series, the wizard cannot determine the name meaning we need to specify it manually.
Figure 14: Wizard cannot determine the federation service name as a wildcard certificate is used
Replace the “*” with “sts” in the federation service name and click “Next”.
Figure 15: Replacing “*” with “sts” in the federation service name
On the next page, we need to specify the service account that should be used for the federation server farm. This account must be the one that is used on all federation servers in the respective farm.
The service account specified should just be an Active Directory user account with “domain user” permissions.
Make sure the account is created with the following set: “User cannot change password” and “Password never expires”.
Figure 16: Creating a service account for the federation server farm
When the account has been created enter the username and password and click “Next”.
Figure 17: Specifying the username and password for the federation server farm service account
On the appearing page, we can see a list of the settings that will be configured for AD FS 2.0 (Figure 18).
Figure 18: Settings that will be configured for ADFS
When the wizard has configured each component with success, click “Close” to exit the wizard.
Figure 19: Each component has been configured with success
As we can see in the AD FS console, we need to add a trusted relying party in order to manage SSO for our Office 365 users. We will actually do this using PowerShell, but first we want to add the other ADFS server to the federation server farm.
Figure 20: AD FS Console
So switch to the other ADFS server and install the ADFS role and then launch the ADFS Federation Server Configuration wizard.
On the “Welcome to the AD FS Federation Server Configuration Wizard”, select “Add a federation server to an existing Federation Service” and click “Next”.
Figure 21: Adding the server to an existing federation service
On the “Specify the Primary Federation Server and Service Account” page, enter the “adfs1.clouduser.dk” (or whatever the server FQDN name is for the primary ADFS server in your environment) and then enter the credentials for the federation server farm service account followed by clicking “Next”.
Figure 22: Specifying the FQDN of the federation server farm as well the service account credentials
Make sure the server certificate is selected and the correct federation service FQDN is configured and then click “Next”.
Once again we’re now ready to apply the settings, so click “Next”.
Figure 24: Ready to apply settings
On the configuration results page, click “Close” when all components have been configured successfully.
Figure 25: Configuration results
You will now see in the AD FS Management console that this server is not the primary federation server in the farm and that you must perform configuration changes on the primary ADFS server.
Figure 26: AD FS Management console on the second federation server
We have now configured the federation server farm.
With the federation server farm configured, let’s check that it behaves as expected. First let’s try to see if we can reach the XML with the service description document. To do so, open a browser on a client located in the same AD forest as the ADFS server and enter (replace the ADFS server FQDN with the one in your environment):
If things work as expected, you should see something similar to Figure 27.
Figure 27: Accessing the XML service description document via a browser from an internal client using ADFS server FQDN
Repeat this step but point to the other ADFS server.
Lastly, try to access the XML service description document using the federation service FQDN (in this case sts.clouduser.dk).
Figure 28: Accessing the XML service description document via a browser from an internal client using federation service FQDN
Also, open the AD FS Admin log and look for event 100. If you see event 100, it means that the federation service was able to communicate with the federation service.
Figure 29: Event 100 in the ADFS Admin log
This concludes part 4 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to the new Office 365 (Exchange Online).
If you would like to read the other parts in this article series please go to:
Microsoft has rebranded various products in its Office 365 lineup as Microsoft 365. Here is…
In this second article in our series, we will work on the Ansible Automation Engine…
Microsoft Build 2020 included several announcements aimed at developers and the IT community. Here are…
Using Azure Active Directory Identity Protection will boost your security. This step-by-step guide shows you…