In the last couple of posts I covered the use of admin consent to grant permissions for an application to access more than simply data related to the signed in user:
Admin Consent for Permissions in Azure Active Directory
Making your Azure Active Directory application Multi-tenanted
In my initial post talking about admin consent I added the “Read directory data” to the set of permissions that the application would request. This permission, along with a number of other permissions for the Windows Azure Active Directory resource, have a green tick in the “Requires Admin” column.
It’s all to easy for developers, when setting up the permissions for an application to not think through what enabling permissions for an application does. When you enable permissions for an application, by ticking the box alongside the permission in the Azure AD application configuration (see previous) image, you are essentially saying that the application will be able to perform those actions after the user has signed in and provided consent – this is true regardless of what role the user belongs to within the organisation (the application can perform the same actions whether a receptionist or the CEO of an organisation is signed in).
The division between permissions that require admin consent, versus those that do not, usually are based on whether the permission is for an action that only administrators should be able to do, versus those that any user should be able to do. For example in the case of Windows Azure Active Directory all users should be able to sign in and read their profile, read the basic profile of all users in the directory and access the directory as the signed-in user – all of these do not require admin consent as they are either actions that pertain to the signed in user, or they are actions that all users should be able to perform. The last permission does permits more access control as elements within the directory can be secured so users/roles/groups can access them; if the user is accessing the directory as themselves, they’ll only be able to access objects that they have permissions on.
When I checked the box alongside the “Read directory data” permission, I was essentially saying that all users (assuming a global administrator had performed the admin consent) would be able to read all data in their organisation’s directory (see https://msdn.microsoft.com/en-us/library/azure/ad/graph/howto/azure-ad-graph-api-permission-scopes):
In order words, once someone has signed into the application, the access token granted to the application can be used to retrieve all directory data – ummm that’s starting to sound pretty scary. No imagine if I granted “Read and write directory data” permissions to the application. Now the access token can read and write directory data. Put this into the context of hackers who use social engineering to access low level employees, you can imagine it wouldn’t be hard for them to access this application in order to access employee information.
The moral of this post is DO NOT enable REQUIRES ADMIN permissions to any native application (unless you’re 100% sure you know what the implications are) – it’s way to easy to intercept access tokens and act on behalf of the user.