AZIdentity

In a previous post we discussed now even after a user had been granted Network Contributor rights within the Load Balancers blade, they were still getting Access Denied.  The challenge for these Access Denied errors is that they don't really tell you what you don't have access to that is generating the error.  In this post we will discuss a method to determine the cause of these errors.

The primary tool that we will use is called Fiddler.  You can download Fiddler here, once installed you will need to go ahead and setup Fiddler to decrypt HTTPS traffic as well.  To do that you need to ensure Capture HTTPS Connects and Decrypt HTTPS traffic is enable.  Then export the Fiddler cert and import it on your machine, and restart Fiddler.

Now start Fiddler and ensure that it is capturing traffic:

Now reproduce the issue until you see the Access Denied message again

Go back into Fiddler and tell it to stop capturing traffic (File/uncheck Capture Traffic). 

At this point we are ready to start analyzing the traffic.  The quickest way to find the errors is to look for the entries that have the Key symbol next to them, like this:

Next you view the data in the right hand panes in RAW mode.  The top window is the request from the client and the bottom is the answer:

So we can clearly see here that we are trying to enumerate the VM public IP address by opening the Inbound NAT rule properties, but this user does not have rights to the VM network interfaces.

We are working at exposing these kinds of errors through the Portal, but until that time this is a good method to see the true nature of the error. 

Hope this helps!

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.