Azure AD Connect is Microsoft’s latest tool to support your latest hybrid identity scenarios and synchronize object information from an on-premises Windows Server Active Directory environment to Azure Active Directory. One of its components is Azure AD Sync, responsible for the synchronization itself.
Azure AD Connect became generally available on June 24, 2015. Azure AD Sync became generally available on September 16, 2015.
Using Express Settings, Azure AD Sync creates service accounts with minimal privileges but with non-expiring passwords on the Windows Server running Azure AD Sync, and in both the on-premises Windows Server Active Directory and the Azure Active Directory tenant:
This account is configured as a local account on the Windows Server running Azure AD Sync to run the Microsoft Azure AD Sync service and scheduled task for DirectorySyncClientCmd.exe. It has Allow log on locally, Log on as a batch job and Log on as a service user rights assigned on the server in the local security policy.
This account is configured with the user role in the tenant’s Azure Active Directory.
This account is configured as a member of the Domain Users group in the on-premises Active Directory environment your Azure AD Sync installation is a member of. It has additional delegated rights, depending on the password write-back settings.
The common theme with these service accounts is they all feature a 12-byte ID.
When using Custom Settings, the Domain account is not automatically created.
At a customer last week, they have an Azure AD Connect implementation per datacenter site, resulting in six Azure AD Sync instances (of which five are in Staging Mode, obviously). All these installations feature their own service accounts. In this situation, the customer found the relationship between the service accounts and the hostname, fully qualified domain name, IP-address or MAC-address unclear.
In fact, the ID in Azure AD Sync’s service accounts does not have a relationship with any of these items. The ID represents the first 12 bytes of the universally unique identifier (UUID) used by Azure AD Sync.
The full Installation Identifier can be found in the Registry of the Windows Server installation on which Azure AD Sync is installed. The value is stored in the InstallationIdentifier key under HKLM\SOFTWARE\Microsoft\MSOLCoExistence\:
The full value for InstallationIdentifier reveals that is a version 4 UUID. Wikipedia provides the following information on these types of IDs:
Version 4 UUIDs use a scheme relying only on random numbers. This algorithm sets the version number (4 bits) as well as two reserved bits. All other bits (the remaining 122 bits) are set using a random or pseudorandom data source. Version 4 UUIDs have the form
xis any hexadecimal digit and
yis one of
The IDs for Azure AD Sync’s service accounts are the first 12 bytes of the randomly generated version 4 UUID used by Azure AD Sync.
When you feel your organization needs service accounts tied to hostnames, fully qualified domain names, IP-addresses or MAC-addresses, you might want to create service accounts of your own choosing on the Windows Server running Azure AD Sync, and in both the on-premises Windows Server Active Directory and the Azure Active Directory tenant, instead.
Ten things you should know about Azure AD Connect and Azure AD Sync
Five Things you should know about using DirSync with Password Sync
Azure Active Directory Synchronization: An Introduction, Part 1
Azure Active Directory Synchronization: An Introduction, Part 2
Azure Active Directory Synchronization: Filtering, Part 1
Azure Active Directory Synchronization: Filtering, Part 2
Azure Active Directory Synchronization: Object Matching