Forum Discussion

rtenklooster's avatar
rtenklooster
Copper Contributor
Nov 10, 2022

Dynamic groups filter based on custom extension not working

Hi, I'm having some issues with Azure-AD dynamic Groups.

Our AAD is synced with our local AD. When I query a user in the Graph API I can see the following attribute listed:

 

"extension_6d7943a8c26d4ce980cef807cd2aefc1_title": "Consultant",
"extension_6d7943a8c26d4ce980cef807cd2aefc1_afdelingMV": "#Collection(String)",
    "extension_6d7943a8c26d4ce980cef807cd2aefc1_afdelingMV": [
        "Department_a"
    ]

 

My goal is to create a dynamic group with users from "Department_a" but not with the _title "Consultant". So to start, I created this Dynamic rule.

 

(user.extension_6d7943a8c26d4ce980cef807cd2aefc1_afdelingMV -contains "Department_a") and (user.extension_6d7943a8c26d4ce980cef807cd2aefc1_title -ne "Consultant")

 

I used the -contains operator because the data type is a collection (string) according to the Graph API 

Using the query listed, the group remains empty, so that's not working.

I tried removing the title filter, so only add all Department_a members, still no members, so the issue appears to be caused bij the afdelingMV filter.

I tried a lot of variations, using the (_ in "Department_a") and -equals "Department_a", all without luck.

It would be great if someone can help me and tel me what i'm doing wrong!

Azure Active Directory (AAD)
  • LainRobertson's avatar
    LainRobertson
    Nov 12, 2022

    rtenklooster 

     

    You're not doing anything wrong: the Portal, Azure AD and Graph have never been at parity with each other and what you're experiencing is a "by-design" issue.

     

    Multi-valued attributes have synchronised via AAD Connect properly for some years now, however, the Portal cannot consume them despite allowing them to be listed.

     

    When it comes to directory extensions (reference article below discusses all types), AAD Connect faithfully replicates the multivalued structure to Azure AD (Graph is not involved in this.) However, Graph - until quite recently would not honour multi-valued directory extensions outside core attributes such as proxyAddresses.

     

     

    Historically, that meant while you could filter on multi-valued attributes (with some - but not all - PowerShell modules), those values weren't surfaced in the JSON response from Graph, which brings us to the Portal.

     

    I suspect (but don't know for sure) the Portal is actually consuming from Graph rather than the underlying directory which would go some way to why it has not been able to cope with multi-valued directory extension attributes in the past. But now, I think it's just not keeping in-step with Graph developments, since the latter now properly presents such attributes in the JSON response (as you've already noted.)

     

    To some extent, this disparity between AD, AAD, Graph and the Portal is captured in the "disclaimer" from the Azure AD Connect page:

     

     

     

    So, until the Portal (and other things: notably the Microsoft Identity Manger Graph connector for B2B, which is a big sore point for me) gets in-step with Graph, you cannot do what you wish to do leveraging AAD Connect-registered multi-valued attributes.

     

    Cheers,

    Lain

  • LainRobertson's avatar
    LainRobertson
    Silver Contributor
    Nov 12, 2022

    rtenklooster 

     

    You're not doing anything wrong: the Portal, Azure AD and Graph have never been at parity with each other and what you're experiencing is a "by-design" issue.

     

    Multi-valued attributes have synchronised via AAD Connect properly for some years now, however, the Portal cannot consume them despite allowing them to be listed.

     

    When it comes to directory extensions (reference article below discusses all types), AAD Connect faithfully replicates the multivalued structure to Azure AD (Graph is not involved in this.) However, Graph - until quite recently would not honour multi-valued directory extensions outside core attributes such as proxyAddresses.

     

     

    Historically, that meant while you could filter on multi-valued attributes (with some - but not all - PowerShell modules), those values weren't surfaced in the JSON response from Graph, which brings us to the Portal.

     

    I suspect (but don't know for sure) the Portal is actually consuming from Graph rather than the underlying directory which would go some way to why it has not been able to cope with multi-valued directory extension attributes in the past. But now, I think it's just not keeping in-step with Graph developments, since the latter now properly presents such attributes in the JSON response (as you've already noted.)

     

    To some extent, this disparity between AD, AAD, Graph and the Portal is captured in the "disclaimer" from the Azure AD Connect page:

     

     

     

    So, until the Portal (and other things: notably the Microsoft Identity Manger Graph connector for B2B, which is a big sore point for me) gets in-step with Graph, you cannot do what you wish to do leveraging AAD Connect-registered multi-valued attributes.

     

    Cheers,

    Lain

Resources