14. February 2019
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!