Azure AD – Viewing Active Directory Domain Services’ synchronized attributes in Azure AD

This blog was originally posted to – https://devonblog.com/security/azure-ad/ 

Not every field or property in Azure AD that is synchronized from on premises AD DS (Active Directory Domain Services) is directly visible in the Azure Portal. So how do we establish that the field (employeeid) we desire to synchronize from AD DS to Azure AD is actually present in Azure AD?

We present two ways below to find out whether the employee id attribute from on premises AD DS is synchronized with Azure AD. The below examples show how to view employee id in Azure AD, however the same technique could be used for any other customer field in AD DS or an extension attribute in AD DS that is synchronized with Azure AD.

Azure AD Connect Synchronization Service Manager UI

Open “Azure AD Connect’s Synchronization Rules Editor”, and the outbound rule that is responsible for synchronizing employeeid or any other attribute from the on premise AD DS (Active Directory Domain Services) to Azure AD.

Look at the Transformation section of the Outbound rule that is responsible for synchronizing on premises AD DS data to Azure AD. This step however only shows the attributes of AD DS and against what attributes they are ‘supposed to be synchronized’ in Azure AD.

However, when looked at the “Azure AD Connect Synchronization Service Manager UI”, we could actually see the fields (employeeid) and their values that were synchronized with Azure AD from on premise AD DS.

Using Microsoft’s Graph API Explorer

Navigate to https://developer.microsoft.com/en-us/graph/graph-explorer and sign in with the organization’s Azure Global Admin account to view the actual synchronized data.

On a slighter note, if including an employee id (or any other information from Azure AD) in the JWT token appears as many steps, then we could also call the Graph API (https://graph.microsoft.com/beta/users/MiriamG@M365x214355.onmicrosoft.com) with an email address and read the employee id as a JSON response. But that is just a workaround, what we actually want is to have employee id as one of the claims in the JWT token itself, so we do not need to query somebody else again to obtain the employee id.

Or if the on premised AD DS values are synchronized as extension attributes, then they would have a new name in the Azure AD (with a guid added to their name) as shown in the picture below.