Azure Communication Services: Microsoft Entra ID group role assignments are not applying to traditional users within the group.

Question

Hello, we have created a custom role with ACS permissions below.

permissions": [{

    "actions": [

        "Microsoft.Communication/CommunicationServices/Read",

        "Microsoft.Communication/EmailServices/read",

        "Microsoft.Communication/EmailServices/write",

        "Microsoft.Communication/EmailServices/Domains/read",

        "Microsoft.Communication/EmailServices/Domains/SenderUsernames/read",

        "Microsoft.Communication/EmailServices/Domains/SuppressionLists/read",

        "Microsoft.Communication/EmailServices/Domains/SuppressionLists/SuppressionListAddresses/read",

        "Microsoft.Communication/Operations/read",

        "Microsoft.Communication/CommunicationServices/Write",

        "Microsoft.Communication/RegisteredSubscriptions/read"

    ],

We conducted two tests: one by assigning the role directly to a traditional user and another by assigning it to a Microsoft Entra ID group. The traditional user was able to access ACS without issues. However, when the same user was added as a member of the Entra ID group, the test failed.

Before adding the user to the group, we removed the custom role assignment, ensuring that only the group had the role.

I came across a Q&A discussing a similar issue, where a managed identity wasn’t granted access when assigned through a group. The suggested solution was to assign the role directly to the managed identity, as group-based assignments only work with traditional user accounts and service principals.

https://learn.microsoft.com/en-us/answers/questions/2143376/using-managed-identities-with-azure-communication 

Given this information, I assume it should work with our configuration since the only member of the group is a traditional account.

Is this a bug?

Answer 1

Hi NOC,

In addition to Venkata Jagadeep response,

Group-based role assignments are not fully supported for ACS resources. This means that assigning roles to a Microsoft Entra ID group does not effectively grant the intended permissions to its members within ACS.

This limitation is highlighted in a Microsoft Q&A post, which states that while assigning a role to a group grants permissions to users and service principals directly within that group, managed identities are not treated as traditional user or service principal objects within Entra ID groups in the context of role-based access control (RBAC). Therefore, the recommended approach is to assign the necessary roles directly to the individual users or managed identities to ensure proper access. 

Additionally, discussions within the Azure community have noted similar challenges. Managing permissions via Privileged Identity Management (PIM) groups is standard practice; however, ACS doesn't recognize group-based role assignments, leading to access issues. Assigning roles directly to users resolved the problem, but this approach is not ideal for access management. 

To ensure that users have the appropriate access to ACS resources, it's advisable to assign roles directly to individual user accounts or managed identities rather than relying on group-based assignments.

• Keypoint from the link shared by you that helped me to find a way, Please refer-

A potential workaround is to continue assigning roles directly to the managed identities, as you mentioned. However, if you need to manage dynamic group memberships, you might consider using Azure Automation or Azure Functions to automate the role assignments. This way, you can maintain the dynamic nature of your groups while ensuring that the necessary roles are assigned directly to the managed identities.

https://learn.microsoft.com/en-us/azure/communication-services/how-tos/managed-identity?tabs=portal%2Cdotnet 

If you have any further assistant, do let me know.