Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
SOLVED

Dynamic groups filter based on custom extension not working

Copper Contributor

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!

2 Replies
best response confirmed by rtenklooster (Copper Contributor)
Solution

@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:

 

LainRobertson_0-1668264739833.png

 

 

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

Lain,
Thank you so much for your comprehensive answer!
While it's not the answer I was hoping for, I know I have to look for an alternative.

I have searched extensively for similar questions and have not really been able to find one. Although the link to the Azure AD connect documentation describes some limitations for working with multi value items, there is no mention of this in the dynamic groups documentation. https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/groups-dynamic-membership

Thanks again!
Regards, Richard
1 best response

Accepted Solutions
best response confirmed by rtenklooster (Copper Contributor)
Solution

@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:

 

LainRobertson_0-1668264739833.png

 

 

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

View solution in original post