In my continuing struggle to write about topics other than “why you should turn on MFA,” in this column, I wanted to take a deeper dive into the wise words of Microsoft’s Merill Fernando. Merill is a principal program manager on the identity team at Microsoft, and he had a great Twitter thread this past week about Azure AD applications and tenancy. It’s worth digging into a little more.
The “Tenant”
Let’s start with the idea of a tenant itself. We all casually use the word “tenant” when talking about our Azure AD or Office 365 environments. One way to think of a tenant is in the classical meaning of the world: someone who rents land or property for their own use. In that vein, we’re renting computing, storage, and processing services from Microsoft so that we can send each other Oreo emojis in Teams or whatever. But there’s an additional sense of the word that comes into play when we’re talking about Microsoft’s products: a tenant is also a logical boundary for authentication, authorization, and access control. That is, without special action on the part of the tenant admins, users in one tenant cannot see or access resources or data in another tenant. In this sense, “tenant” is a synonym for “on-premises Active Directory forest.”
For most of us, most of the time, it appears that we wouldn’t have much need to grant access between tenants. When we do need to give outside users some degree of access, Microsoft has a range of solutions, including Azure AD external identities of various kinds, shared channels in Teams, and so on. However, one thing many tenant admins don’t think about is how the apps we use gain access to data in our tenant. This is where the concept of application tenancy comes into play.
What “Tenancy” Means: Theory
In Azure AD, an application can be registered as a single-tenant app or as a multi-tenant app. I used the word “registered” on purpose. When you register an application in your Azure AD tenant by creating an app registration, you create a binding that delegates authentication for that specific application (represented by the URL you provide when you create the registration) to Azure AD. Part of the registration process requires you to specify whether the application is a single-tenant app or a multi-tenant app. Microsoft explains the distinction simply:
- Single-tenant apps are only available in their home tenant (where they were registered).
- Multi-tenant apps are available in their home tenant but also to other tenants.
This may not make much sense if you’re not familiar with app registrations and their use, especially because you probably didn’t manually create registrations for the apps you’re already using. That’s because it’s the application owner who has to decide what type the application should be.
What “Tenancy” Means: Practice
If you develop your own application for internal use, it should be registered in your tenant as a single-tenant application. That seems simple enough: you’re the owner, you want the app available to users in your tenant, and there you have it. This model is simple to deploy and understand. In particular, things like conditional access policies or Privileged Identity Management work the way you would expect since there’s only a single tenant involved.
Things start to get tricky when you want users in other tenants to be able to use your application. This might be because you are a software developer, or because you’ve developed a line of business applications for a company that has partners or subsidiaries in other tenants. In that case, you need to register your application as a multi-tenant application, and that’s when the fun begins. Microsoft makes this plain in their documentation: “All users and guests with a work or school account from Microsoft can use your application or API. This includes schools and businesses that use Microsoft 365.” You’ve already experienced this capability from the user side if you’ve signed up for any multi-tenant application, including Microsoft Graph Explorer: those applications let you sign in, at which point you’re required to consent to give them the requested permissions through the familiar Microsoft permissions-consent dialog.
One super important point: the app itself is required to implement a set of security checks to properly run as a multi-tenant application. If you just take an app meant for single-tenant use and register it as a multi-tenant app, then any user who can sign in can (basically; I’m oversimplifying a bit) take any action that the app allows, no matter what tenant they come from. That’s bad.
One of the biggest takeaways from Merrill’s article is this: if you’ve defined conditional access policies and applied them to your users, they don’t apply to users from other tenants who sign in to multi-tenant apps. For example, the location-based policy controls that I wrote about recently only work for your users. If you register a multi-tenant app in your contoso.com tenant, you’re dependent solely on the application itself to decide what rights, if any, to allow a fabrikam.com user to have—and a conditional access policy that says “don’t allow sign-ins from North Korean IP addresses” won’t even be evaluated for fabrikam.com users when they try to sign in.
What Apps Do You Have?
Merrill recommends using the Azure AD application gallery to install apps so that at least you know where they came from; the well-known Azure AD admin consent feature allows you to prevent users from granting permission to applications without admin approval. Both of these are useful steps, but what about applications that are already present?
The Azure AD portal shows you what applications you have registered, and there are various reporting and auditing tools available (some free, some paid) that will help you keep an eye on them. Alongside regularly reviewing the application registration list (ideally, with some automated help to review the Azure AD audit log for app registration changes), you can perform additional, and preferably regular, reviews of the permissions assigned to all of your registered applications.
But Seriously
In reality, many, if not most, Office 365 tenants will have non-Microsoft multi-tenant applications. Their mere existence isn’t a security threat; lots of user-focused tools have utility applications (such as the native mail and calendar applications on iOS or the popular Todoist service) that register in your tenant; many SaaS applications, including popular migration and backup tools, also register as multi-tenant applications. However, understanding what multi-tenant applications are, what they can do, and how to manage them is a key part of keeping your tenant and users safe.
Thank you very helpfull