Nowadays, a “normal” ADFS infrastructure with high available ADFS servers and high available proxy servers in the DMZ is not future proof anymore. Especially, since most companies want to remove the dependency of on-premise servers to authenticate to cloud services. Therefore, I was tasked to create a plan to get rid of our on-premise ADFS infrastructure.
Getting rid of ADFS is just a part of what I want to achieve here as the end goal for me is to have one single portal from where our users can access all (web) applications with SAML SSO. First, this will be the default Office 365 portal and later on we might check a 3rd party solution like Workspace 365 to make it more user-friendly and provide us with some more options. While moving our applications from ADFS to Azure I also had to rethink how I wanted to authenticate our users to Office 365/Azure AD. I would say there are 2 logical ways to achieve this and those are briefly described below.
Azure AD Connect with password synchronization
This is a feature inside Azure AD Connect which will synchronize password hashes from the on-premise domain controllers to Azure AD. This SHA256 password hash cannot be decrypted according to Microsoft. Also, the password hashes are salted which means random data is added to the password hash to make it even more secure. A big benefit with password synchronization is that no additional software or infrastructure is required apart from Azure AD Connect (what you probably already have if you use ADFS). There will be no direct impact once the Azure AD Connect server fails but keep in mind that passwords normally sync every 2 minutes so this might become an issue quite fast when there is no sync between AD and Azure AD. For a detailed guide about how it works check this URL.
Azure AD Connect with Pass Through authentication (PTA)
With this type of authentication there will be no passwords or hashes synchronized to Azure AD from your on-premise infrastructure. How it works is that you install one or more PTA agents (for high availability) on your servers. When a user logs in to Office 365 it will talk with a PTA agent which will then checks your on-premise AD and authenticates you. This is fast and secure but once there is no connection to any of these PTA agents it will have direct impact as users will be unable to login to Office 365/Azure AD services instantly. For a detailed guide about how it works check this URL.
Our choice – password synchronization
For us based on these two options we chose to go with password synchronization. Especially now that Microsoft have created it more secure by adding 10-byte salting to the password hashes this is both easy and secure.
Here is how you configure it
Whatever option you choose, the first step would be to de-federate your domain(s) and users. If you’re running the Windows Azure AD module from a workstation other than your ADFS server, then you will need to enter the following command first:
Set-MsolADFSContext -Computer <your computername>. Don’t enter the FQDN, just the computer name itself.
When you’re ready to flip the switch, run the command:
Convert-MsolDomainToStandard -DomainName <example.com> -SkipUserConversion $false -passwordfile c:\password.txt
The “SkipUserConversion $false” tells Powershell to also convert your users from federated to standard while converting your domain. The password file is where the users’ temporary passwords will be saved. You won’t need the file if you’ll be syncing AD passwords over to Azure AD, but it’s required as part of the conversion process that these temporary passwords are issued. In other words, the file is there but it will be empty. If you do not use password synchronization, then the file will contain temporary passwords for every user that is converted. The domain conversion and user conversion will take some time (approximately a minute per 50 users). You will receive a message once complete. Close the Windows Azure AD module.
When the domain and users are de-federated you can run the Azure AD Connect wizard and either enable PTA or password synchronization.
The “Enable SSO” feature in Azure AD Connect makes it possible to log users in without needing to type in their password and often even the user name. Before turning this on in Azure AD Connect you would have to meet some prerequisites in order for this to work. For example you need a domain administrator account as there will be an AD user created in the background. Also you need to configure GPO’s and add 2 URL’s the user’s intranet zones. For a complete how to please see this guide.