Field Notes: Azure AD Connect – Migrating from AD FS to Password Hash Synchronization

Active Directory, Identity 3 Minutes

This is a continuation of a series on Azure AD Connect. I started off this Azure AD Connect series by going through the express installation path, where the password hash synchronization (PHS) sign-in option is selected by default. This was followed by the custom installation path where I selected pass-through authentication (PTA) as a user sign-in option. The third blog post on user sign-in was configuring federation with Active Directory Federation Service (AD FS). Links to these are provided in the summary section below.

Here, I go through migrating from AD FS to PHS. You may want to do this to reduce complexity and server footprint in your environment.

Before we begin

I am running the latest version of Azure AD Connect that I downloaded from http://aka.ms/aadconnect. At a minimum, version 1.1.819.0 is required to successfully complete the migration using the process we are going to cover. See Azure AD Connect: Version release history to keep track of the versions that have been released, and to understand what the changes are in the latest version.

Federation is currently enabled for one domain. PHS is also enabled and the required permissions for the on-premises directory are already in place as per Azure AD Connect: Accounts and permissions (Replicate Directory Changes | Replicate Directory Changes All).

We’ll be using Azure AD Connect to perform the migration as federation was configured using it. One of the ways that can be used to confirm that AD FS was setup through Azure AD Connect is to open the federation configuration task under manage federation.

Information such as the federation service name, service account, certificate details would be shown here. Be sure to have documented your setup and have a valid backup before you proceed in your environment.

Migrating using Azure AD Connect

The swing itself is pretty straightforward. All we do is launch Azure AD Connect and select configure. At the additional tasks page, we select change user sign-in and click next to proceed.

We then connect Azure AD as normal by providing a Global Admin user name and password. Under user sign-in, we select password hash synchronization. We also need to confirm (by checking the box) that our intention is to convert from federated to managed authentication. Enable single sign-on is turned on by default, and we’ll leave tick-box checked.

Azure AD domains that are currently federated will be converted to managed and user passwords will be synchronized with Azure AD. This process may take a few hours and cause login failures.

Clicking next takes us to the enable single sign-on page, where we are required to enter a domain administrator account to configure the on-premises directory for use with SSO.

If everything goes well, the cross next to the enter credentials button will change to a green icon with a check mark. The next button will also be enabled. There is a problem in our case: an error occurred while locating computer account.

This is also highlighted in the trace file (C:\ProgramData\AADConnect\trace-*.txt).

Our workaround for now is to delete the AZUREADSSOACC computer account in AD DS that was created by a previous installation. I’ll cover this case in detail in a future post.

That’s it! The conversion happens once we go through the single sign-on page. Another look at Azure AD and voila, federation is now disabled, and seamless single sign-on is enabled for idrockstar.co.za.

A quick test performed by accessing http://aka.ms/myapps reveals that we are no longer redirected to AD FS, but authentication takes place in Azure AD.

Summary

We have just quickly gone through the process of migrating sign-on in Azure AD from federation with AD FS to PHS. Be sure to check the deployment considerations if you plan to perform the migration in your environment.

Related posts

Till next time…

Author

Published