I was recently asked to consult on a project that was looking at the integration of Workday with Azure AD for Single Sign On. One of the requirements for the project, is that staff number be used as the NameID value for authentication.
This got me thinking as the staff number wasn’t represented in Azure AD at all at this point, and in order to use it, we will need to get it to Azure AD.
These days, this is fairly easy to achieve by using the “Directory Extensions” option in Azure AD Connect. Directory Extensions allows us to synchronise additional attributes from the on-premises environment to Azure AD.
Launch the AADC configuration utility and select “Customize synchronisation options”
aadc_config_p1
Enter your Azure AD global administrator credentials to connect to Azure AD.
aadc_config_p2
Once authenticated to Azure AD, click next through the options until we get to “Optional Features” and select “Directory extension attribute sync”
aadc_config_p3
There are two additional attributes that I want to make use of in Azure AD, employeeID and employeeNumber. As such, I have selected these attributes from the list.
aadc_config_p4
Completing the wizard will configure AAD Connect to sync the requested attributes to Azure AD. A full synchronisation is required post configuration and can be launched either from the configuration wizard itself, or from powershell using the following cmdlet.
Start-ADSyncSyncCycle -PolicyType initial
Once the sync was complete, I went to validate that my new attributes were visible in Azure AD. They weren’t!
After some digging, I found that my attributes had in fact synced successfully, they just weren’t in the location I wanted them to be. My attributes had synced as follows:
Source AD                                                                    Azure AD
employeeNumber                                                         extension_tenantGUID_employeeNumber
employeeID                                                                    extension_tenantGUID_employeeID
 
So… This wasn’t exactly what I was looking for, but at least the theory works in practice.
Fortunately, this problem is also easy to fix. We can configure AAD Connect to synchronise to a different target attribute using the synchronisation rules editor.
When we configured Directory extensions above, a new rule was created in the synchronisation rules editor for “User Directory Extension”. If we edit this rule, we can see the source and target attributes as they are currently configured, and we are able to make changes to these rules.
Before making any changes, follow the received prompt guiding you not to change the existing rule, but instead clone the current rule and then edit the clone. The original rule will be disabled during the cloning process.
As seen below, I have now configured the employeeNumber and employeeID attributes to sync to extensionattribute5 and 6 respectively.
aadc_config_p6
A full synchronisation is required before the above changes will take effect. We are now in a position to configure Single Sign On settings in Azure AD, using extensionAttribute5 as the NameID value.
I hope this helps some of you out there.
Cheers,
Shane.

Category:
Office 365
Tags:
, ,

Join the conversation! 0 Comments

  1. Hi, you said that ‘after some digging’ you found the attributes in Azure AD. Where did you find them? I’m trying to sync targetAddress and have done all the above steps but for the life of me I can’t see if it has synced or not and don’t even know where to look. Thanks

    Reply
    • Hi Nathan, You will need Azure Powershell to find them, but the attribute name you have synced will be prefixed by extension_tenantGUID_ where tenantguid is your tenant id.
      The below PowerShell cmdlet should work
      Get-AzureADUser -ObjectId “YourUPN” | Select -ExpandProperty ExtensionProperty

      Reply
  2. hi,
    You can use the below command to get all properties:
    Get-AzureADUser -ObjectId “YourUPN” | Select-Object *

    Reply
  3. Do you know if there is a way to protect these attributes in Azure AD? They seem to be readable by all users through powershell/graph API where some attributes may be confidential (such as employee id).

    Reply

Leave a Reply