One of the many announcements on the MS Ignite 2019 is the preview of the admin consent requests feature. Starting from this preview I’d like to explain the topic around strategies for staying in control over used cloud apps and fighting shadow IT.
Which problem is addressed by this new feature?
In the default configuration of an AAD every user is able to register applications and give consent for himself. Microsoft provides a good and comprehensive explanation for this default configuration. Despite this I observed that my clients have strong concerns and want more control.
So the configuration in many tenants is that the user is still able to register applications but is not able to give the consent to use the app. Hoping that with this configuration a user would rather turn to IT for consent by an admin than create an account in the app. This is an important goal for staying in control and fight shadow IT. Only known accounts can be managed by the IT and the given SSO options of these apps can be used to end the access for e.g. users leaving the company.
OK – how does this preview feature help me to solve this problem?
The main problem with the described configuration is the bad user experience. The user has to understand what the error means, open a ticket in the ITSM system and be willing to wait for the request. This is what admin consent requests is trying to cover. It provides an integrated workflow and streamlines the complete process to ask for consent by an admin.
From an admin perspective the workflow is also improved. The admin is getting an email with a justification from the user and a direct link to the consent configuration of the app.
Should I do more than just enabling this feature?
Admin consent requests will help you discover business needs, improve the request process and will end, hopefully, in less shadow IT. But it is only a useful small puzzle piece. If you’re serious about fighting shadow IT, you’ll need to look at a few more topics and establish processes for evaluating and integrating new apps.
The first topic is discovery and assesment of cloud apps. You can do a lot with just AAD P1 licenses (I will try to cover this topic in more detail in later posts):
- The Discovery section from Microsoft Cloud App Security (upload proxy logs or integrate with Microsoft Defender Advanced Threat Protection (MDATP).
- Set up Monitoring on Audit Logs (in Azure Monitor or other)
- The cloud app catalog from Microsoft Cloud App Security for assessment of apps.
When you are able to discover and assess used or needed cloud apps you can go on to improve or restrict the usage (I will try to cover this in a later blogpost, too).
The main goal should always be trying to integrate the apps in the AAD. This is already done by the here discussed OAuth2-Apps, SAML-Apps will need some configuration in order to work properly.
If you decide to restrict the usage of cloud apps there is no ‚one-fits-all-solution‘. Depending on the apps I’ve seen the following approaches to restrict access and gain more control:
- Licensing: The visibility or availability of most Office 365 apps is controlled through licensing.
- Enterprise App Settings: For all registered Enterprise Apps a global deactivation is possible. For the most Enterprise Apps the requirement for User Assignment and the Visibility is configurable.
- Tenant Restrictions: With tenant restrictions, organizations can specify the list of tenants that their users are permitted to access. Azure AD then only grants access to these permitted tenants.
- Conditional Access: Conditional Access is able to block access to unwanted apps with granular scoping.
- Filtering with Proxies: The „old school“ approach for filtering access to the internet with DMZ systems or using Cloud Based Secure Web Gateways like zScaler for filtering access to the internet.
Every approach has his own advantages and limitations so in practice you will often need a mix depending on your used apps and given architecture.
Useful links to the topic: