There has been growing trend to get rid of ADFS among many organizations. Reasons vary, there are still scenarios where ADFS is extremely good such as single sing-on with 3th party applications.

When considering to replace O365 relaying party trust and ADFS alternative solutions are:

  • Pass-through authentication (PTA) with Seamless SSO
  • Password Hash Sync (PHS) with Seamless SSO
  • Both above without Seamless SSO

Take into account that there are scenarios where PTA or PHS with SSO might have issues:

  • PTA doesn’t support detection of leaked credentials
  • Azure AD Domain Services needs PHS to work, so if using only PTA AAD DS is not supported
  • PTA is not integrated with AAD Connect Health

The Environment

This specific environment doesn’t have strict security policy requirements and authentication can performed on the cloud (PHS with SSO selected). From user experience PHS & SSO and PTA with SSO are very near each others even the authentication process varies. 

In this particular case migration is performed once for all users. At Ignite conference Microsoft announced staged authentication migration option which would provide alternative approach for migration. I just couldn’t find any documentation about it, here is link to session Youtube video.

If you search guidance migrating ADFS to PTA & SSO here you go. My environment contains ADFS farm installation with two ADFS servers, two WAP servers and AAD Connect version 1.882.00.

Pre-Requirements

Azure AD Connect ADDS connector account needs following permissions to on-premises AD to be able to synchronize password hashes.

  • Replicate Directory Changes
  • Replicate Directory Changes All

How to set these permissions – check my earlier blog post, or run these assuming that you have regularly updated your AAD Connect.

  • Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountName “<aadc service account” -ADConnectorAccountDomain <domainname>

Validate current user sign-in settings from Azure AD

Verify AAD Connect settings, in my environment PHS is already enabled and necessary permissions configured earlier.

Validate any setting that might have been customized to your Federation design and deployment documentation, specifically the highlighted (PreferredAuthenticationProtocol, SupportsMFA, PromptLoginBehavior), in the event that you need to roll back:

Considerations

  • Depending of the number of users, Password Hash Sync operation can take from minutes to several hours. Referring to Microsoft guidance in 20k users environment operation takes approximately 1 hour.
  • Validate ADFS usage carefully before implementation
    • Is ADFS used for other applications?
    • Is it customized?
    • Are you using legacy authentication block via ADFS?
    • 3th party MFA providers integrated to ADFS?
    • Access Control Policies in use?
    • InsideCorporateNetwork claim used?

For all of these scenarios there is a workaround available which I do not cover ins this post, more information from Microsoft migration whitepaper.

Plan Migration Method (from Microsoft whitepaper)

Depending how ADFS has been originally configured there are two methods available for migration.

  1. Using Azure AD Connect. If AD FS was originally configured using Azure AD Connect, then the change to Password Hash Sync as the user sign-in method must be performed through the AzureAD Connect wizard. When using Azure AD Connect, it runs the Set-MsolDomainAuthentication cmdlet for you automatically when you change the user sign-in method, and hence you have no control over it un-federating all of the verified federated domains in your Azure AD tenant.
    Note: At this time, you cannot avoid un-federating all domains in your tenant when you change the user sign-in to Password Hash Synchronization when AAD Connect was originally used to configure AD FS for you.
  2. Using Azure AD Connect with PowerShell. This method may be used only when AD FS was not originally configured with Azure AD Connect. You still need to change the user sign-in method via the Azure AD Connect wizard, but the core difference is that it will not automatically run the Set-MsolDomainAuthentication cmdlet for you as it has no awareness of your AD FS farm, and hence you have full control over which domains are converted and which order.

Before going forward this is the point where you need to confirm that ADFS documentation is up to date and backups are taken (and working). 

ADFS backup can be taken with ADFS Rapid Restore tool. At minimum export “Microsoft Office 365 Identity Platform” relaying party trust settings.

Implementation

  1. Enable Password Hash Sync
  2. Enable Seamless Sign On
  3. Change sign-in method to PHS and Seamless SSO

Enable PHS

As seen below, it’s already configured. If deployment is needed in your environment run AAD Connect wizard and enable PHS. Remember to grant permissions to AADC ADDS Connector account before configuring AAD Connect.

Validate PHS has completed successfully

Couple options here:

  • Use Event Viewer and application logs
  • Use Azure AD Connect wizard troubleshooting task

Prepare for Seamless SSO

To your devices to use Seamless SSO, you need to add an Azure AD URL to the users’ Intranet zone settings by using Group Policy in Active Directory. Add these URL’s to Local Intranet zone (value in GPO = 1)

Change Sign-in method to PHS and Enable Seamless SSO

Connect to Azure AD
User sign-in, default setting if you haven’t use AADC for user sign-in configuration. If AADC had been used for configuring user sign-in to earlier selection (Federation with ADFS, PTA etc) will be selected
Select Password Hash Syncronization and Enable single sign-on will be automatically selected
Enter credentials for on-premises domain. 
Configuration is ready
Seamless single sign-on is now configured and seen from portal. In case you are wondering I have PTA configured from another on-premises domain to this tenant. Nothing related to this case.
Set domain from federated to managed domain. After setting this ADFS will be no longer used for authentication.
Verify change from Azure AD Connect blade in portal

Test Authentication with PHS

Now, after configuration change I’m landing to Azure AD login page instead of ADFS because my tenant is configured to use Password Hash sync.

To test PHS functionality and avoid Seamless SSO I opened browser In-Private mode and navigated to O365 login page (portal.office.com) with my test user and are able to login with my UPN and password to the portal. Everything works as expected.

Test Authentication with Seamless SSO

From Internal network open IE and navigate to portal.office.com where credentials are asked. Save persistent token to get smooth authentication experience at future.

Take in to account that portal.office.com doesn’t support currently domain hint and therefore UPN is needed.

If using services that supports domain hint SSO works as expected, examples:

And also if an application sends sign-in requests to Azure AD’s tenanted endpoints instead of common endpoints, link to reference.

Summary

Password Hash Sync with Seamless SSO provides smooth user experience and is good alternative approach when choosing cloud authentication model. As said, ADFS has still its place if it’s used heavily for SSO to 3th party applications.