Azure AD Sync has reached general availability a few months ago. This triggered me to write a post about Microsoft’s new directory synchronisation tool which will replace Dirsync in time.
Azure AD Sync and Azure AD Connect
When you are looking in to the ability to extend your on-premises Active Directory to Azure Active Directory, you will find out there are several tools available with its own functionalities. As we will do a deep dive into Azure AD Sync, I will first explain what the difference is compared to Azure AD Connect.
First of all, Azure AD Connect is not a synchronisation tool like Azure AD Sync or Dirsync but it is more like a wizard to install all required tooling to make synchronisation or Single Sign On to the on-premises environment possible. It should be noted there is a difference between these user authentication experiences.
Synchronisation + Password hash
In this case the user attributes are synchronised to Azure AD including the password hash of the principal (hash of the hash). When this option is being used, the Azure AD will become the identity provider and users will be authenticated against Azure AD.
SSO using ADFS
This option requires the use of an ADFS server and the synchronisation of the users attributes without the password hash. Azure AD does not require the password hash because it will direct the user to the “on-premises” ADFS server for authentication. In this case the Windows Server Active Directory will remain the Identity Provider.
At this moment the tool is still in preview and does include the “old” dirsync tool for synchronisation. I will go in to more detail about the Azure AD Connect tool in a new post when it becomes general available.
Azure AD Sync
As mentioned, Dirsync will be replaced by Azure AD Sync. Azure AD Sync will provide some extra functionalities compared to Dirsync:
- Active Directory and Exchange multi-forest environments can be extended now to the cloud.
- Control over which attributes are synchronized based on desired cloud services.
- Ability to set up the connection to AD with minimal Windows Server AD privileges.
- Preview AAD Premium password change and reset to AD on-premises.
The architecture of Azure AD Sync is still similar to both Dirsync and FIM:
Basically, you connect your data sources, in this case the AD forests, to AADSync by using a connector. Like FIM and dirsync, these connectors feed into a metaverse that contains a consolidated view of all the inbound identities. This view will be synced to Azure AD using AADSync.
To give some more insights in how to use Azure AD Sync, I will go over two test scenarios covering most of the new functionalities:
- Single forest synchronisation including password write-back
- Multi forest synchronisation including password write-back
Single forest synchronisation
Before we dive into the configuration details, I will give you an overview of this scenario and the prerequisites:
As we want to make use of all the Azure AD capabilities, we are syncing our local AD with Azure AD using Azure AD Sync. As shown in the drawing above the only prerequisites for this scenarios is a configured Active Directory Domain Controller and an Azure AD Premium tenant. At this moment the only attribute which can be written back to the local AD is the password of a user. This provides us the ability to make use of the Azure AD Self-Service Password reset capability and keep the passwords in both directories in sync.
To start configuring this scenario we have to download Azure AD Sync from the Microsoft website.
Start the Azure AD Sync executable on your Active Directory Domain Controller. Provide the required installation path, local AD credentials and Azure AD credentials to start the configuration. By the way, this Azure AD account needs to be an global admin in your tenant.
After setting up the connection, you are able to create some user mappings based on attributes. As we are just syncing a single forest to Azure AD, we can go with the default settings in “Matching across forest” property window.
The “Matching with Azure AD” option however gives us the ability to change the unique identifier (sourceAnchor attribute) of a user object which is being used for identity federation. Keep in mind this attribute may never change :).
The userPrincipalName attribute is the user’s login ID in Azure AD. The UPN or the e-mail address of user would be a perfect candidate here.
The default configuration is perfect for this test scenario. Let’s click Next to open up some more configuration options:
In a quick overview:
- Exchange hybrid deployment, select this option if you want migrate your existing exchange environment to Office 365 or if you want to keep your on-premises exchange in a hybrid scenario with Office 365.
- Password synchronisation, enable this option if you want to synchronize passwords of user accounts to Azure AD. In this case the hash of the hash of the password will be synced.
- Password write-back, this option is only available of you are using an Azure AD premium license. If you enable this option, you can change passwords of the user accounts within Azure AD. These change will be automatically synced to the on-premises AD.
- Azure AD app and attribute filtering, by enabling this option you can filter which attributes are synced for a specific application. This might be considerable, if you do not want to synchronize private information to every SaaS vendor application.
For my test scenario I am just enabling Password synchronisation and Password write-back.
And with these simple clicks you have just configured Azure AD sync. I just want to make one other recommendation before you start syncing!
Make sure you have configured a selection of the OU’s you want to sync. You can easily configure this in the Synchronisation Service Manager:
Open up the properties of your inbound connector which is pointing to your local Active Directory.
Go to Configure Directory Partitions and click the Containers… button.
After logging in you will be able to make a selection of what OU’s will be synced!
That’s it for part 1. Stay tuned for the next part, where I will configure Azure AD Sync in a Multi-Forest scenario..