Back to all blogs

Upgrading your Microsoft Active Directory Federated Services 2.0 (ADFS 2.0) to Celestix A Series

As our internal systems and services age in our infrastructure, it becomes necessary and imperative to update and migrate these systems and services to newer, current supported platforms, and to take advantage of new features and capabilities that come with an upgrade.

ADFS 3.0  with Windows Server 2012 R2® provides numerous updates to the ADFS experience, including support for modern authentication protocols and publishing web applications.  Combined with Celestix’s administration and reporting services, ADFS is simpler to deploy, simpler to operate, and simpler to support.

Celestix’s A Series combines Microsoft’s ADFS 3.0 services with our management and reporting interface, and provides for quick and easy integration with Office365®.

Migration Path for ADFS 3.0 and Celestix’s A Series

The migration from 2.0 to 3.0 is fairly simple, performed as a side by side migration, with a simple DNS cutover at the end.  The high level steps are as follows:

  1. Document the ADFS Service Account credentials and the Service FQDN
  2. Export the service certificate (and any other public rooted certificates, such as the token signing cert) from the legacy ADFS farm.
  3. Export the current configuration from the legacy farm
  4. Install and configure the ADFS role on A Series
  5. Import the configuration from the legacy farm
  6. Install WAP roles on the designated servers
  7. Perform testing to ensure that authentication is working
  8. Change the DNS and load balancer configurations as necessary to point to the new farm

Step 1:

In order to successfully migrate, you will need to current ADFS Service Account username and password, and the service name.  The service account name and service name will be displayed during the configuration export process as well.

Step 2:

Export the service certificate (SSL certificate) using the Certificates MMC snap-in.  If the other certificates (Token-decrypting and Token-signing) are publicly issued, then those need to be exported as well.  If they are self-signed, then no action needs to be taken.

Step 3:

The Windows Server 2012 R2 media contains the necessary scripts to import and export the ADFS configuration.  These scripts are located under supportadfs in the installation media.  Running this script is a simple process:

  1. Open a PowerShell session on the legacy ADFS server.
  2. Run the Export-FederationConfiguration.ps1 –Path “$export_path” (where $export_path is where you want to store the exported configs).

Note:  The export process will also list the service account name, and the federation service name.

Step 4:

Install and configure the ADFS role on the A Series appliance, or using the native Microsoft tools.  The following items must be the same as the legacy ADFS farm:

  • Service Account and password
  • Service Name (FQDN)
  • Publicly procured certificates from the legacy farm

Step 5:

Now, the configuration can be imported using the import script provided on the installation media at supportadfs:

  1. Open a PowerShell session on the new A Series appliance.
  2. Run the Import-FederationConfiguration.ps1 –Path “$export_path” (where $export_path is where stored the exported configs from Step 3).

At this point, you should have a functional ADFS 3.0 farm setup, and the configuration exported from the legacy farm, and imported to the new farm.  To test, open IE and enter the following address:  https://localhost/adfs/ls/IdpInitiatedSignon.aspx.  This will bring up the new logon page, and you can test authentication.

Step 6:

The use of the Web Application Proxy/ADFS Proxy with Celestix’s E Series appliance is optional, but recommended for security purposes for your external users.  The installation of the WAP role is located under Remote Access, and joining the WAP to the ADFS 3.0 farm is a straightforward process.  You will need to import the service certificate into the WAP server prior to the configuration of this role.  In addition, you will need to edit the local HOSTS file so that the WAP will resolve the federation service name to the new ADFS 3.0 farm, instead of the legacy farm.

Step 7:

Once you have configured the WAP, and performed the necessary firewall and load balancer changes, you can now test the claim rules from the inside and outside.  Be aware that since the DNS records are pointing to the legacy farm, you will need to use HOSTS entries to direct your testing clients to the new ADFS 3.0 farm (set the federation service name).

Step 8:

Once you have tested successfully, you can cutover all traffic to the new farm by changing the internal and external DNS record for both the federation service name to point to the correct A and E Series appliances.

 As you can see, migration from a previous ADFS farm (either ADFS 2.0 or 2.1) is a straightforward process, and combined with Celestix’s solutions, will increase your visibility and ease management of your ADFS farm.

For more information on Celestix A Series Solution, please call 510.668.0700 or email sales@celestix.com or read more here.

more blogs