Some organisations may still have ADFS v2 or ADFS v2.1 running in their environment, and haven’t yet moved to ADFS v3. In this blog, we will discuss how can you move away from ADFS v2 or ADFS v2.1 and migrate or upgrade to ADFS 2016.
In previous posts, Part 1 and Part 2 we have covered the migration of ADFS v3.0 to ADFS 2016. I have received some messages on LinkedIn to cover the migration process from ADFS v2 to ADFS 2016 as there currently isn’t much information about this.
As you may have noticed from the previous posts, upgrading to ADFS 2016 couldn’t be any easier. In ADFS v2 however, the process is as simple, albeit differently than upgrading from ADFS v2 or ADFS v2.1 to ADFS v3.
Before we begin however, this post assumes you already have a running ADFS v2 or ADFS v2.1 environment. This blog post will not go into a step-by-step installation of ADFSv2/ADFSv2.1, and will only cover the migration or upgrade to ADFS 2016.
This blog post assumes you already have a running Windows Server 2016 with the ADFS 2016 role installed, if not, please follow the procedures outlined in part 2.
Prior to commencing the upgrade, there are few tasks you need to perform.
- Take a note of your ADFS Server Display Name
- Take a note of your Federation Service Name
- Take note of your federation Service Identifier
- Export the service communication certificate (if you don’t already have a copy of it)
- Install/Import the service communication certificate onto ADFS 2016 server
- There is no need to make your ADFS 2016 server as primary, since this should have been a new installation. You can’t add to an ADFS v2/ADFS v2.1 farm anyway.
- There is no need to raise the farm behavior level, since this is not a farm member like we did when migrating from ADFS v3 to ADFS 2016.
- However, you will still need to upgrade the schema as outlined in part 2.
Before you begin, you will need to download the following PowerShell script found here.
Those scripts can also be found in the support\adfs location in the Windows Server 2016 installation file. Those scripts are provided by Microsoft and not Kloud.
The two main functions, are the export and import federation configuration.
Firstly, we will need to export the federation configuration by running the “export-federationconfiguration.ps1”.
Here are the current relying party trust I have in the ADFS v2.1.
The “Claims Provider Trust” is Active Directory, this toll will be exported and imported.
1- Navigate to the folder you have just downloaded:
[code language=”PowerShell”].\export-federationconfiguration.ps1 -path "c:\users\username\desktop\exported adfs configuration"[/code]
Once successful, you will see the same results in the above picture.
Open your folder, and you should see the extracted configuration in .xml files.
2- Head over your ADFS 2016 Server and copy/paste both the folder in which you have extracted your federation configuration, and the one you downloaded that includes the scripts.
Then open PowerShell and run:
[code language=”PowerShell”].\import-federationconfiguration.ps1 -path "c:\users\username\desktop\exported adfs configuration"[/code]
When successful, you will see a similar message as above.
And now when you open the ADFS management you should see the same relying party trust as you had in ADFS v2/ADFS v2.1.
Basically, by now you have completed the move from ADFSv2/ADFSv2.1 to ADFS 2016.
Notice how the token-signing and token-decrypting certificates are the same. The screenshots below are only of the token-signing certificates only, for the purpose of this blog.
You can also check the certificates through PowerShell:
Last thing, make sure that service account that was running the Active Direction Federation Services in ADFS v2/ADFS v2.1 is the same one running in ADFS 2016.
Notice the message in the exported results:
Ensure that the destination farm has the farm name ‘adfs.iknowtech.com.au’ and uses service account ‘IKNOWTECH\svc-adfs’.
If this is not setup, then head over your services and select the account that you were originally using to run the ADFS service.
In addition, make sure that the service account has read-only access to the certificate private key.
This is a very straight forward process, all that you need to be sure of is to have the right components in place, service certificate installed, service account setup, etc.
After you have complete the steps, follow the steps here to configure your Web Application Proxy. Although this covers a migration, but it also helps you in configuring a new deployment.
I hope you’ve found this informative. Should you have any question or feedback please leave a comment below.