locked
AADConnect not replicating msExchExtensionCustomAttribute1 despite reporting success in Sync Manager. RRS feed

  • Question

  • Hi folks,

    Firstly, there doesn't seem to be a perfect forum for this question around AADSync/Connect, in which case if you have a better recommendation, I'm happy to re-post of have this post moved by a moderator.

    Now, to the issue at hand.

    I have a requirement to use the on-premise Active Directory attributes beginning with msExchExtensionCustomAttribute within Azure AD. The goal is to make use of these multi-valued attributes within dynamic unified (or Office 365, if you will) groups for dynamic licencing.

    To this end I have:

    1. Ran the AAD Connect wizard and enabled the synchronisation of extended attributes;
    2. As part of this process, selected the five on-prem msExchangeExtensionCustomAttribute attributes for inclusion;
    3. Verified that the inbound on-prem Active Directory connector is successfully bringing the values into the connector space and subsequently the metaverse (flowed into two metaverse attributes: msExtensionCustomAttribute1 and extension_msExtensionCustomAttribute1);
    4. Verified that the metaverse attributes are being flowed out to the Azure AD connector space, and in principle, the Azure AD tenant (based on the Export cycle including the attribute update).

    All of this has supposedly happened without error, yet when I check with the various PowerShell commandlets from the various module (seriously, this commandlet spread needs to be fixed - what's going on with your strategy?), it appears that nothing has actually flowed.

    Now, there's two flows going on here from the AADSync metaverse (listed first) to the Azure AD connector space (listed second):

    1. [msExchExtensionCustomAttribute1 - 5] -> [msExchExtensionCustomAttribute1 - 5];
    2. [extension_msExtensionCustomAttribute1 - 5] -> [extension_<guid>_msExchExtensionCustomAttribute1]

    Now, I don't care about the first flow as I can't use this attribute in Azure AD anyway. I have to focus on the second flow as the dynamic membership rule builder is limited to leveraging attributes imported from the enterprise applications (as distinct from the full spectrum of Azure AD attributes).

    With this in mind, I've checked two user accounts that supposedly have had their msExchExtensionCustomAttribute values flowed through to Azure AD using the Get-AzureADUserExtension, however, I do not see anything beyond the vanilla extension details you get as shown in the below example:

    Get-AzureADUserExtension -ObjectId [someUserGuid];
    
    Key                                   Value
    ---                                   -----
    odata.metadata                        https://graph.windows.net/[tenantGuid]/$metadata#directoryObjects/@Element
    odata.type                            Microsoft.DirectoryServices.User
    createdDateTime                       25/08/2014 7:23:57 AM
    employeeId
    onPremisesDistinguishedName           CN=Lain Robertson,OU=[some OU paths],DC=robertsonpayne,DC=com
    thumbnailPhoto@odata.mediaEditLink    directoryObjects/[someUserGuid]/Microsoft.DirectoryServices.User/thumbnailPhoto
    thumbnailPhoto@odata.mediaContentType image/Jpeg
    userIdentities                        []

    It feels like the there's some sort of missing link between the Azure AD objects (users, groups, etc) and the enterprise application that provides these attributes.

    That said, I can't reconcile that feeling with the fact that within the dynamic rule builder in the Azure AD portal, I am able to see the enterprise app registration and subsequently the "extension_<guid>_msExchExtensionCustomAttributes" and use them in the rule.

    If anyone's seen this issue before, I'd love to hear how to resolve it as I'm out of ideas for the time being.

    Cheers,
    Lain


    • Edited by Lain Robertson Tuesday, February 4, 2020 3:42 AM Fixing typos.
    Tuesday, February 4, 2020 1:53 AM

Answers

  • Having lodged a premier support call for this issue, the abridged version is that Graph is the under-delivering component, yet again - and for a very superficial reason, too.

    The multi-valued data does indeed make it from AAD Connect into Azure AD and can even be queried. The following is an example using the AzureADPreview PowerShell module but it can be just as readily tested using the $filter query parameter in Azure Graph Explorer.

    Get-AzureADUser -Filter "extension_<someGuid>_msExchExtensionCustomAttribute1 eq 'loc=foo'"

    The custom multi-value data is indeed in Azure AD and Graph already makes use of it in queries. In the above example, you will get back a list of the matching users as expected. The missing component is at the presentation layer where custom multi-valued attributes still are not surfaced in the JSON response. Quite remarkable, really.

    This is noted here, however, the phrasing sets the context that it's AAD Connect that has the limitation on reading multi-valued attributes. Graph isn't mentioned at all, so you could be forgiven for overlooking the real culprit (i.e. Graph).

    Anyhow, just another area in which Graph limits feature parity with most other data repositories - directory services included.

    Cheers,
    Lain

    • Marked as answer by Lain Robertson Tuesday, February 11, 2020 2:00 PM
    Tuesday, February 11, 2020 2:00 PM