Hello, my name is Nate Harris and I am part of the Azure Identity Incubation team. My role on the team is to become a SME with Role Based Access Control (RBAC), and ensure that Support has all the tools and knowledge necessary to deliver top notch support to our customers. To that end I will be creating these types of Blogs posts as I come across issues that I am working in and find that there is a clear knowledge gap with our customers and/or the support organization. What follows is one such example:
Scenario: You are the Global Admin for your Azure subscription and have created an Azure AD Group called TestGroup02. This group will contain your networking team members who will manage your load balancers. You assign the Reader role to the group for the Resource Group that the load balancers are found within. At the Load Balancer resource you add the group to the Network Contributor role so that they can manage the Load Balancer resources. However when a user from that group logs in and attempts to manage the existing Inbound NAT rules, they are met with this error message:
With RBAC the permissions are compartmentalized to a Resource or Resources and flow from Parent to child. As we cannot, today, assign Deny permissions, RBAC permissions are therefore cumulative in nature. In this scenario it appears that the User should have permissions to modify a Child resource, in this case an Inbound NAT rule on the Load Balancer, but that is not the case. Let's walk through the configuration around this scenario.
Here is the Azure AD group and it's membership shown.
This group has been added as a Reader to the Resource Group to which the Load Balancer belongs
At the Load Balancer we have added this Group to the Network Contributor role. So you can see the Implicit role (Reader) and Explicit role (Network Contributor).
So what's the cause, you ask? Well a clue can be found within other Inbound NAT rules that the admins are able to view. When they look into one of these other NAT rules that the Admin created we see a key difference in the destination choices:
What the LoadBalancerAdmin group member is able to view:
And what the Subscription Admin is able to view:
We see that the LoadBalancerAdmin member sees fewer VMs than the Subscription Admin, which ultimately is key to solving our issue. While the LoadBalancerAdmin AD group is a Reader for the Resource Group with which the Load Balancer resides, it does not have at least Reader role rights outside of that Resource Group. So for Inbound NAT rules that have been created by the Subscription Admin that point to resources outside of that Resource Group, the LoadBalancerAdmin group member would only ever see Access Denied when attempting to open the properties of those rules.
Solution: Grant the User/Group at least Reader role rights to all other necessary resources.