ADFS Rapid Restore Tool, backup and restore your ADFS farm easily in seconds…

Posted on by

SAML authentication with Microsoft Azure / O365 hybrid cloud environments – or even Google or AWS, via ADFS services is something that must be taken very seriously. Few months ago, Microsoft released the ADFS Rapid Restore Tool which is – it seems to me, somewhat passed unnoticed. So it’s time to talk about it because this tool is really useful to export and rebuild an ADFS farm for recovery or even to create / rebuild an existing exported ADFS farm in another environment.

In short, this tool is much more than just an export / import tool because it also allows you to reconfigure an existing ADFS farm. For example, with this tool, it is very easy to switch from the default WID database to a SQL Server instance, if required.

  • So, first, to discover this powerful Microsoft tool, download it from Microsoft Connect.
  • Second, once installed, use the new Windows PowerShell cmdlets – Backup-ADFS and Restore-ADFS.

Note that the ADFS Rapid Restore Tool is features complete and supports the following capabilities:

  • Supports ADFS running on Windows Server 2012 R2 and 2016. Note that it does not support ADFS 2.0 or ADFS running on Windows Server 2012.
  • Supports both SQL Server and WID databases configurations of ADFS.
  • Supports both self-generated token signing certificates (that is the default configuration in ADFS) and custom token signing certificates. In the case of custom token signing certificates, the tool will attempt to export these as well if it exportable. Note that if certificates are not exportable, then you have to install these on the target machine prior to the restore process.
  • Supports export and restore of SSL certificates if the certificate is exportable. Otherwise, you will have to install these on the target machine prior to the restore process.
  • Supports storage of the exported backup in a networked folder or better still offers support to store in Azure storage.
  • All exported backups are strongly encrypted using the password provided.
  • Backups can be done on-demand or can be integrated within a scheduled task on the machine.
  • Any custom attribute stores, additional authentication providers (for MFA) or local claims provider trusts (new ADFS feature running on Windows Server 2016) are also backed up and restored.
  • All page customizations are backed up and restored.

To backup your ADFS farm, use the command listed below with the following switches:

  • BackupDKM – Backs up the Active Directory DKM container that contains the AD FS keys in the default configuration (automatically generated token signing and decrypting certificates).
  • –StorageType – The type of storage:“FileSystem”-stores backup it in a folder locally or in the network.“Azure”-stores backup in the Azure Storage Container (Azure Storage Credentials should be passed to the cmdlet). The storage credentials contains the account name and key,a container name must also be passed in,if the container doesn’t exist, it is created during the backup.
  • EncryptionPassword – The password that is going to be used to encrypt all the backed up files before storing it
  • AzureConnectionCredentials – The account name and key for the Azure storage account
  • AzureStorageContainer – The storage container where the backup will be stored in Azure
  • StoragePath – The location the backups will be stored in
  • ServiceAccountCredential – specifies the service account being used for the ADFS Service running currently. This parameter is only needed if the user would like to backup the DKM and is not domain admin.
  • BackupComment <string[]> – An informational string about the backup that will be displayed during the restore, similar to the concept of Hyper-V checkpoint naming. The default is an empty string

Backup-ADFS -StorageType “FileSystem” -StoragePath “C:\Install\ADFS_BACKUP\” -EncryptionPassword “Passw0rd_2016!” BackupComment “ADFS_Farm_O365_WS2016” -BackupDKM

In the same way, the restore process is also very easy to achieve with the following switches:

StorageType – same as for backup (“FileSystem” and “Azure”)

  • DecryptionPassword – The password that was used to encrypt all the backed up files
  • AzureConnectionCredentials – The account name and key for the Azure storage account
  • AzureStorageContainer – The storage container where the backup will be stored in Azure
  • StoragePath – The location the backups will be stored in
  • ADFSName < string > – The name of the federation that was backed up and is going to be restored.
  • ServiceAccountCredential < pscredential > – specifies the service account that will be used for the new ADFS Service being restored
  • GroupServiceAccountIdentifier – The GMSA that the user wants to use for the new ADFS Service being restored. By default, if neither is provided then the backed up account name is used if it was GMSA, else the user is prompted to put in a service account
  • DBConnectionString – If the user would like to use a different DB for the restore, then they should pass the SQL Connection String or type in WID for WID.
  • Force – Skip the prompts that the tool might have once the backup is chosen
  • RestoreDKM – Restore the DKM Container to the AD, should be set if going to a new AD and the DKM was backed up initially.

Note that you must specify the database engine type used with the ADFS farm by using the -DBConnectionString parameter as follow:

  • To restore your ADFS farm when using WID Database or SQL Server, use respectively the following paramters:

Restore-ADFS -StorageType “FileSystem” -StoragePath “C:\Install\ADFS_BACKUP” -DecryptionPassword “Passw0rd_2016!” -RestoreDKM -DBConnectionString “WID” 

Restore-ADFS -StorageType “FileSystem” -StoragePath “C:\Install\ADFS_BACKUP” -DecryptionPassword “Passw0rd_2016!” -RestoreDKM -DBConnectionString “Data Source=SQLServer\SQLINSTANCE; Integrated Security=True”

During the restore process, note that the ADFS Rapid Restore Tool proposes to the administrator to specify which backup to restore  – based on date and time.

As you can see, at this point, it’s almost done because after the restore operation, the ADFS service is not yet operational and running!

The final step consists to read the Post Restore instructions .TXT file before to start the ADFS service to add – if necessary,  additional software or DLLs on the ADFS folder to support additional MFA providers or attribute stores.

In summary, with the Office 365 success, it is sure that the most important point to migrate successfully to the Hybrid Cloud model consists to offer to users a rich logon experience based on SSO – Single Sign On, via ADFS services.

Unfortunately, an ADFS solution requires multiples ADFS / WAP servers to ensure security and high availability. With the ADFS Rapid Restore tool, administrators have the ability to export the configuration of a single AD FS server to be able to deploy a new AD FS server quickly in the event of a server failure or a misconfiguration.

This approach can be useful for small and medium costomers that do not have the ability to deploy n ADFS servers.. In addition, the ADFS Rapid Restore tool can be used to duplicate an existing ADFS server into a test environment.

Enjoy,