Introduction

Microsoft does not yet provide fine-grain access controls for Azure Active Directory. This is in stark contrast with Active Directory Domain Services, which shipped in 2000 with Windows Server 2000, where you can restrict access down to the individual attribute on an object.

Microsoft has been investing heavily in improving the role-based access controls (RBAC) infrastructure underlying Azure Active Directory, but to date, the features provided have primarily focused on reducing the number of people in the global admins role–a role which can do just about anything in your Azure AD tenant.

If you want to limit access to the data in Azure AD, you have only a few options:

1. Don’t put it in Azure AD. We exercise this option with course groups and other groups whose membership is considered confidential. This is in stark contrast with our Active Directory, where the fine-grain access controls available allow us to include course groups.
2. Obscure data in Azure AD. With this solution, we change the real data to avoid undesired consequences of that data being generally available.
3. Only allow a limited number of users & apps to have read permissions to anything. This option puts you in the role of gatekeeper for any scenario which requires read access to objects in your Azure AD, i.e. it introduces a huge amount of friction, which can only lead to less interest and use of Azure AD based technologies. This includes owners of Azure subscriptions, 3rd party applications trying to do low-risk OAuth activities, and IT professionals trying to get their job done. Many folks with perfectly good business intentions who run into the problems this creates will give up.

Discussion

It’s worth noting that there are a couple special purpose solutions that Microsoft has created, e.g. by default guest users can only see their own account and nothing else in your Azure AD tenant. This special purpose solution suggests that Microsoft has the capability to implement fine-grain access control solutions but hasn’t yet prioritized the ability for customers to craft custom solutions which meet their own purposes.

Solution #1 – don’t put data in Azure AD

Solution #1 is not really a solution–it’s a dodge. If you avoid putting data in Azure AD, you aren’t getting the value Azure AD might provide.

Everyone loses with this solution–there is no value–just avoiding the bad outcomes associated with data being exposed.

Solution #2 – obscure data in Azure AD

With this solution, we change the real data to avoid undesired consequences of that data being generally available. The scenarios where this type of solution are most appropriate are not unique to Azure AD–they usually involve obscuring the data at the source system, and informing those who consume that data with ways to decode that presented information. An example might be a person’s name, where a person at risk has a different name presented than their actual name.

This type of solution generally is best when implemented at the source system and the affected parties have consented to the solution–not in or at the boundary of Azure AD. When implemented on a per-system basis like only in Azure AD, you set up a paradigm where one system has false data but others do not. This paradigm will create support overhead and disincentive to use that system.

This solution is only valuable for specific, limited use cases, not for generally solving Azure AD access control limitations.

Solution #3 – Conditional Access generally prevents read access via undocumented option

Solution #3 is predicated on limiting access to the user interfaces that can be used to query Azure AD information. By blocking the UIs, you block access to the data. You probably already saw the problem–what if a new UI shows up? This solution is predicated on rocky ground which assumes Microsoft won’t introduce something new–which in this constantly changing environment is absolutely not a safe bet.

You implement solution #3 by implementing a Conditional Access policy that prevents issuing access tokens (OAuth) to the Azure Management application in your tenant. Microsoft has never documented what the Azure Management application actually represents. So by implementing this policy you are taking an unknown risk that essentially says:

• I’m able to determine all the impacts myself
• Microsoft won’t change what this means on me
• I will identify all the valid business reasons for a user/application to have access beyond themselves and manually manage exceptions to this policy
• The chilling effect this policy will have is an acceptable cost

To dig a bit deeper on this, based on other customer reports it is believed that Azure Management includes the following:

• Azure Portal (portal.azure.com)
• Office Portal (portal.office.com)
• Azure AD Graph API
• Microsoft Graph API
• PowerShell modules which interact with Azure AD, including but not limited to:
  • MSOnline
  • AzureAD

Whether there are additional affected interfaces is unknown.

The most widely used of these interfaces is the Azure Portal. A customer would have to identify all subscriptions in their tenant, and for each subscription, identify the owners or other role holders which might need to access the Azure Portal, and have some acceptance process to allow them to be excluded from the Conditional Access policy which blocked access to Azure Management.

Similar mitigation steps would be needed for the other capabilities included in Azure Management. Of the others, the hardest to address would be 3rd party applications with OAuth permissions. These applications operate on a consent basis–if a user grants consent, they are allowed to read designated information about the user. The Conditional Access policy would block such 3rd party applications from retrieving that data, unless they were excluded. Depending on how this was approached, this has the potential to recreate a gatekeeper situation for Azure AD applications. At the University of Washington, we spent several years in contention over a gatekeeper approach to Azure AD applications, and reverting the progress made is undesirable.

A problem with this approach is that it won’t necessarily entirely lock down access to the data you’ve put in Azure AD. Some of Microsoft’s applications (which they sometimes call 1st party applications) have been granted broad read access to a variety of data in your Azure AD. For example, Exchange Online can read a lot of Azure AD based data. To really be effective, you’d also need to analyze every one of these Microsoft applications for whether it exposed data and then mitigate those issues, if you can. In some cases, you may find that you can’t mitigate the behavior of an application which Microsoft controls other than to stop using that application. If the application were Exchange Online, not many organizations would seriously consider stopping use of Exchange Online.

The initial effort of implementing solution #3, without also analyzing and mitigating all 1st party Microsoft applications, is estimated at 200 hours. Ongoing maintenance is estimated at 2h/week. Additionally analyzing 1st party Microsoft applications is likely to add at least 600 hours to the effort.

Summary

While you could implement a Conditional Access policy, the consequences of doing so are broad and would require significant effort to implement in a well-planned manner. There are chilling effects and other unknown costs. For these reasons, unless the need is very significant, this solution is not recommended.