ADFS 2.0 to 4.0 Migration
Scenario
Active Directory Federation Services (ADFS) is one of those nice services that goes in easily, works without fuss and is soon forgotten in the upgrade cycle that is the curse of those who must maintain the server estate for an organisation.
So, it was no surprise that the ever reliable ADFS server for this particular organisation was still running on a Windows 2008R2 – version 2.0 of ADFS - and that this had only come to light following an examination of the results of a recent penetration test. The question, however, was what was involved in migrating the ADFS implementation to ADFS 4.0 running on Windows 2016 servers? More importantly, could this migration be done with the bare minimum of service interruption. It would have been preferable to just create a new federation service but it was felt by the organisation that this would involve too much reliance on the efficiency and enthusiasm of both internal external parties (and therefore cost).
As it turned out, this was a straightforward job that simply involved building new Windows 2016 servers and transferring the certificates and configuration to the new setup. The current deployment is shown in the following diagram:
As load balancers were being used for both the internal and external ADFS services, the new servers were introduced as new nodes with the plan being to keep the old servers temporarily to provide a rollback position and thus have only one potentially destructive change – the NAT firewall rule that presents the ADFS proxy servers to the outside world. As this was a relatively large organisation, this relatively simple migration acquired extra logistical (and financial) challenges as the servers, load balancers and firewalls were managed by separate teams. In this scenario, the firewalls were managed by an external company that were somewhat reluctant to make any changes out of hours or, at least, were unwilling to do so without charging a substantial amount of money so it was decided to leave the external firewall alone and do the change at the load balancers instead. The internal firewall rule changes to allow TCP 443 traffic between the new ADFS proxy servers and the new ADFS internal servers (via their respective load balancer IP addresses) could be done during the day and in advance to avoid additional cost.
Load balancer configuration changes
ADFS is a simple service to load balance but configuration methods vary substantially depending on the model of load balancer used. In this scenario, F5 BIGIP units were in place so the new ADFS servers, once built, were added as new nodes to the same pool as the existing ADFS servers but were marked as down initially. When ready to make things live, the old ADFS servers were marked down and the new ADFS servers were marked up. Besides avoiding the need to make an out of hours firewall change, it also saved some time as there was no need to make any DNS changes and there froe no need to wait for server or client DNS cache timeouts before testing could commence. This approach was used on both the internal and DMZ load balancers.
Migration Process Overview
- Build and deploy 2 new internal ADFS servers
- Build and deploy 2 new ADFS proxy servers
- Change load balancer configuration to point to the new ADFS servers
- Test it all still works
Build and deploy 2 new internal ADFS servers
Certificate
Export the service communications certificate from the existing ADFS primary server. Note that this certificate should have, and will have if you have been using ADFS with a load balancer, an exportable key. Note that the certificate specifications have changed slightly in ADFS 4.0 but the certificate on the existing installation was, in this case, perfectly adequate for federated authentication. The certificate and its key should, of course, be treated as a security item. This certificate should be imported into the new, Windows 2016, ADFS servers.
Other prerequisites
The installation media for Windows 2016. This contains the PowerShell scripts that will be used to export and then import the configuration. The scripts are in the \support\adfs folder and are called export-federationconfiguration.ps1 and import-federationconfiguration.ps1. You will also need the login details for the ADFS service account from the existing ADFS installation.
Export the configuration
On the existing ADFS primary server, mount the Windows 2016 installation media and run the export-federationconfiguration.ps1 script. Copy the exported configuration file to the new W2016 server that will be your new ADFS primary server
Set up the SQL server
The SQL database used by ADFS is not large and therefore it seemed excessive to use a local SQL installation so an instance was set up on another SQL server. Even though the ADFS database was originally on a SQL 2008R2 installation, it was possible to use SQL 2016 for the new ADFS database and successfully import the configuration.
Setting up the new primary server
First, import the service communication certificate from the existing server. Then, on your new W2016 server, install the Active Directory Federation Services role and configure it. It is important to select the option to Create the first federation server in a federation farm and select the imported service communications certificate. Then the details for the existing ADFS service account were entered and the new ADFS instance on the SQL 2016 server were selected.
Once this part of the installation is completed, the ADFS installation will be operational but will not have the configuration from the existing ADFS installation. To do that, mount the Windows 2016 installation media and run the import-federationconfiguration.ps1 script and use the configuration file previously that you copied to the new server.
Open up the ADFS console and check that all the token decrypting and token signing certificates are now present under the Certificates node and that the relying party trust and claims provider trusts from the old ADFS setup are present. As you still have the old ADFS servers, double check that everything matches.
Build and Deploy 2 New ADFS Proxy servers
This did not present much of a problem. The certificate exported from the old ADFS primary server was copied to each of the new Windows 2016 ADFS proxy servers and imported. The Remote Access role and the Web Application role service have to be installed. When you configure the Web Application role service, you will be prompted for the name of the federation service and the certificate from the existing installation that was previously imported. This process is repeated for the other ADFS proxy server. Note that TCP 443 needs to be open between the new ADFS proxy servers and the new ADFS internal servers
One point to note is DNS resolution for the federation service name for the ADFS proxy servers should resolve to the IP address of the internal load balancer for the internal ADFS servers. Many firewalls, such as the Cisco ASA, can do some form of DNS rewriting and replace the public IP address for fs.mycompany.com, in this example, with the internal address of the server (or load balancer) when there is a static NAT in place so that internal clients can connect to the service. In this scenario, that would mean that the ADFS proxy servers would resolve the name fs.mycompany.com back to itself rather than the internal load balancer IP address for the internal ADFS servers and connections would therefore fail. The simplest solution is often the best and an entry was added to the local host file on each of the ADFS proxy server to resolve the name fs.mycompany.com to the internal load balancer IP address.
Checklist
- On the new ADFS proxy servers, ping the Federation service name – fs.mycompany.com in this example – and verify that it resolves to the internal federation service load balancer IP address
- On the ADFS proxy server, verify the Web Application Proxy functionality (green ticks)
- On the internal ADFS servers, use the ADFS console to verify that you can see the ADFS configuration data (certificates, relying party trusts etc.
Change the load balancer configuration.
The nodes for the old ADFS servers were marked down and the nodes for the new ADFS servers were marked up. It was then possible to start testing safe in the knowledge that the old ADFS servers could be made live quickly.
Final testing
You should now be able to test federated authentication and the authentication page should be displayed when accessed from both internal and external client computers.
Notes
ADFS 4.0 has many more features than ADFS 2.0 (such as Azure integration) but it has some prerequisites such as Windows 2016 domain controllers to give full functionality. Therefore, you ADFS installation will report itself as version 3.0 until you install Windows 2016 domain controllers.