Azure AD V2 Apps vs. The Brick Wall a.k.a. admin consent!
Some month ago I was introduced to what Microsoft internally calls “The Brick Wall”. The end users are left with a prompt for admin consent enforced by the Microsoft Azure Federation Gateway and even if a Global Administrator (or Application Administrator) tried to approve the application the users will never get access to the application.
One example of this would be the Microsoft Tech Community site, where the users see the following information.
Need admin approval
MS Tech Comm needs permission to access resources in your organization that only an admin can grant. Please ask an admin to grant permission to this app before you can use it.
Have an admin account? Sign in with that account
“Message: AADSTS90094: The grant requires admin permission.”
The global administrator of your Azure AD tenant have tried to approve the application for corporate use several times, but the end users still cannot get past the admin consent page – hence the name “The Brick Wall”.
Blocking end-user application consent
This issue often appears when someone have decided to increased the Azure Active Directory security to better protect the cloud data that application are able to access. Microsoft have a switch in Azure AD that can prevent users from approving applications access to corporate data. This switch is off by default, but many companies have started turning it on to prevent malicious application from accessing company cloud data. During January 2018 known hacker Kevin Mitnick made a video available with a proof-of-concept on how a Microsoft Exchange Online mailbox could be encrypted. This resulted in a lot of media posting about this very known default cloud behavior. If you have not flipped the switch on in you Azure Active Directory tenant you should properly consider doing so. Just be aware of the issues that might follow with some users that might hit the brick wall for non-approved applications.
Why can’t the admin approve the application?
Most of the newer applications use Azure Active Directory v2.0 endpoint for authentication, these new Azure AD v2.0 endpoint applications rely on a new consent model under the support for OAuth 2.0 authorization protocol. This will require that the applications is provided with the required permissions or it keeps prompting for the permissions. For some reason this functionality is currently broken or have not yet been added to the Azure federation gateway (EvoSTS), which provides a easy way for approving access correctly.
You can read more here:
- Scopes, permissions, and consent in the Azure Active Directory v2.0 endpoint
- Azure Active Directory v2.0 and the OpenID Connect protocol
Providing the required permission consent for the application
Now that you understand the problem. How can you fix this issue? Microsoft currently does not provide a simple way for solving this issue. I know that they are working on making this a less painful experience, but I do not have anything that I can share at this time. For the time being, we will have to use the Azure AD Graph for resolving this directly.
Step 1. Find the Azure AD App registration within your Azure Active Directory.
Step 2. Open the website https://graphexplorer.azurewebsites.net/# and sign-in with a Global Administrator or Application Admin role from the Azure Active Directory tenant.
Copy the Object ID (Not the Application ID)
Step 3. Insert the ”Object ID” into the Graph request string below, which will get all the permissions grants for the application.
https://graph.windows.net/myorganization/oauth2PermissionGrants?api-version=1.6&$filter=clientId eq ‘7ea9778c-9678-4b5a-9f62-131833e97e99’
Search after the permission with the consentType “AllPrincipals”. It should be listed as the first app permission, if it does exist within the tenant. In case it does not exist continue with the guide or go to the section for updating exiting admin consent permissions.
Application admin consent permissions doesn’t exist
If the ”AllPrincipals” can’t be found in the query, we have to provision it within the tenant. In the case it does exists please go to Step 7 under “Existing application permissions?“.
Step 4. Copy one of the permissions grants from the list to notepad.
It should like this….
Step 5. Change the “consentType” from “Principal” to “AllPrincipals” and removed the “PrincipalId” that represent a specific user.
In the Azure AD Graph Explorer change from GET to POST and the URL should still be https://graph.windows.net/myorganization/oauth2PermissionGrants/.
Step 6. Paste the consent from note, change GET to POST and click “GO”.
This creates the new admin consent application permission in the Azure Active Directory tenant. “This created the service principal to all users instead of only allowing the Admins”.
Existing application permissions?
Step 7. If the application permission already exist in the Azure Active Directory and you need to add more permissions.
If the AllPrincipals consentType already exists instead of POST change it to PATCH and just patch the scope like this:
“scope”: ” openid email profile User.ReadBasic.All”
Step 8. Execute the patch request with the required permissions needed for the applications. You can check the permissions that was granted to the administrator. Check permissions here: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-scopes.
Step 9. Execute a GET request to verify the updated permissions:
Application Permissions provided for specific users.
Each of the application permissions with consent type “Principal” represent a grant of a permissions to one of the users in Azure Active Directory.
Some applications have multiple API’s defined that you will have to provide admin permission consent for each for them. You can distinguish the API’s by looking at the “resourceId” in the graph call.
Below you see an example of an application that requires several admin consent approvals.
Links with more information: