Attribute naming in Active Directory, Office 365 and Exchange Online is pure anarchy!
You might think it was designed by people on different planets or that higher powers within Microsoft decided that consistency sucks.
Here’s the fact: In many cases you need to deal with multiple names for the same attribute depending on where and how you access it. Read this article to fully understand what’s going on!
One Attribute – Multiple Incarnations
If you have implemented Office 365 in your organization you’re most likely managing something like this:
You have an on-premises Active Directory which is the main authority of your objects and attributes.
The objects and attributes are synced from your on-premises Active Directory to Office 365 using Azure AD Connect. This synchronization involves two steps:
- Attributes are synced from Active Directory into the Azure AD Connect Metaverse
- Attributes are synced from the Azure AD Connect Metaverse to Office 365
(in some cases synchronization is happening in reverse order but we’ll skip those special cases).
This synchronization model means that user objects and attributes exist in three incarnations:
- The original object lives in Active Directory
- One replica exists in the Azure AD Connect Metaverse
- Another replica exists in Azure AD
Let’s have a closer look at where the anarchy sets in.
Attribute Anarchy – Step One
Attributes are mapped between the Active Directory and the Azure AD Connect Metaverse according to certain rules. These rules are accessible via the Synchronization Rules Editor:
Select a rule and edit it to view how attributes are mapped (do NOT make or save any changes!).
Below are some sample mappings from one of the inbound synchronization rules (inbound is seen from the Metaverse, i.e. inbound from Active Directory to the Azure AD Connect Metaverse)
In the screenshot above you’ll notice two interesting examples of attribute transformations:
- The second bit in the userAccountControl attribute (which designates if an account is disabled or not) is transformed into an independant attribute named accountEnabled in the Metaverse
- The sAMAccountName attribute is renamed to accountName in the Metaverse
So, already during the transition from your on-premises Active Directory to the Azure AD Connect Metaverse some of the attributes are undergoing significant changes.
Attribute Anarchy – Step Two
If we switch to outbound rules in the Synchronization Rules Editor we can see similar things going on during the synchronization from the Metaverse to Office 365:
In this example we notice that the Metaverse attribute mailNickname (which uses the same name as in Active Directory) is renamed to alias when synchronized to Office 365.
The takeaway is:
- Some attributes change their name during the transition from Active Directory to the Azure AD Connect Metaverse
- Some attributes change their name during the transition from the Azure AD Connect Metaverse to Office 365
Attribute Anarchy – Step Three
As if the renaming of attribute names between Active Directory and Office 365 isn’t enough, Microsoft designed various script management interfaces into the data that each have a unique take on attribute naming.
The three most common Office 365 script management interfaces are:
- Azure Active Directory Module for Windows PowerShell (aka MSOL or MSOnline)
- Azure AD PowerShell for Graph
- Exchange Online
(Read this article for details on how to connect with and use these different modules)
All three modules are able to access various user object attributes in the Azure Active Directory of Office 365 but they don’t always agree on the attribute naming. One example of this is seen below:
If you use the Azure AD PowerShell for Graph interface the attribute named physicalDeliveryOfficeName does not change it’s name. However, if you use the MSOnline module or the Exchange Online module the user attribute physicalDeliveryOfficeName is referred to as Office.
Other attributes, like Alias are also affected as seen above (referred to as MailNickName using the Azure AD PowerShell for Graph interface).
Anarchy in the AD – Summary
As illustrated above:
- An Active Directory user object attribute may change it’s name when it’s replicated from AD to the Azure AD Connect Metaverse
- An Active Directory user object attribute may change it’s name when it’s replicated from the Metaverse to Office 365
- An Azure AD user object attribute may be referred to by different names depending on which script interface you’re using to manage Office 365