This article is intended to provide some clarity for automation and the development team to understand fields in Active Directory (AD) and Azure Active Directory (AAD), how they relate to each other, the synchronization process between AD and AAD, and what fields are unique.
Synchronization
Azure AD Connect is an application installed to an on-prem server. It handles the synchronization process between AD and AAD.
Groups, users and computer objects are synchronized to AAD from AD by this tool. Computers in AD are represented as devices in AAD.
This is a bidirectional synchronization for some properties on each of these object types, but AD is the source of authority. Generally, it's safe to assume that properties on an AAD objects which were synchronized from AD are not writable in AAD.
Identity Fields
These are the important fields for users in relation to most scripting, development and automation purposes:
| AD Field | AAD Field | Synchronization | Immutable (cannot be changed) |
Unique | Notes |
| userPrincipalName | userPrincipalName | AD -> AAD | No | Yes | conventionally [email protected] Often abbreviated as UPN in documentation Conventionally (for Connor Group) we keep this value in sync with the "mail" field (primarySmtpAddress) Domain may be any domain added to AD and AAD. Most users have "connorgp.com" for their domain, but there are about a dozen valid domains for our systems (soldenservices.com, for example). All UPNs are automatically added as alias to Exchange Online recipient objects. |
| samAccountName | samAccountName | AD -> AAD | No | Yes | Conventionally matches the username part of the users userPrincipalName, but a match is not required. Limited to 15 characters. |
| AD -> AAD | No | Yes | The on-prem Exchange tooling should be used for keeping this field in sync with the primarySmtpAddress field. It shouldn't be edited directly in AD by administrators. Both the mail and primarySmtpAddress field are related to the list of strings in the proxyAddresses field, where the entry with "SMTP:...." becomes the primarySmtpAddress and thus the mail value. All over aliases in the proxyAddresses field will start with "smtp:..." or some other protocol identifier like "X500:..." or "SIP:...". In Exchange Online the primarySmtpAddress field is also available, but that field is not available through the AAD interfaces, only the Exchange Online tooling. |
||
| objectGUID | AD Only | Yes | Yes | GUID identifier for the object in AD | |
| objectSID | onPremisesSecurityIdentifier | AD -> AAD | No | Yes | This value is mostly static but can change if the user object is moved to a different container in the on-prem directory. |
| objectId or just "id" in some contexts | AAD only | Yes | Yes | GUID identifier for the object in AAD. | |
| mS-DS-ConsistencyGuid | ImmutableId or onPremisesImmutableId depending on the context |
AAD -> AD | Yes (written once by Azure AD Connect) | Yes | Hexidecimal field in AD String in AAD PowerShell: > $hexString = "D8 98 42 E5 60 73 4A 41 97 2A 49 5B 20 FE 43 68" > $base64 = [system.convert]::ToBase64String([byte[]] (-split (($hexstring -replace " ", "") -replace '..', '0x$& '))) > $base64 2JhC5WBzSkGXKklbIP5DaA== |
| displayName | displayName | AD -> AAD | No | No | The display name for a user (or any AD object). For users, it's generally a combination of "givenName" and "sn" (first name and last name) but does not necessarily match those values in any way. |
Attributes synchronized by Azure AD Connect - Microsoft Entra | Microsoft Learn
SID vs. GUID | Microsoft Learn
Cross-Tenant AAD Field Relationships
This is currently rather vague. The following seems true:
- The "mail" field (email address) is unique and must match.
- The userPrincipalName field in the "target" tenant will not match the UPN from the "home" tenant. It will be something like: <USERNAME PART OF THE EMAIL ADDRESS>_<HOME TENANT DOMAIN NAME>#EXT#@<TARGET TENANT MSOnline DOMAIN NAME>
How these accounts are associated between tenants when a user in a "home" tenant is invited to a "target" tenant is not known at this time.