Strong security posture is critical as attacks increase in sophistication
Within the last few years, we’ve seen an escalation in supply chain attacks where an attack on a partner company (like Kaseya or Solarwinds) has a direct effect on customers. This translates to the tech industry as well – lately, Microsoft has seen a significant rise in the number of attacks targeting Microsoft partners with ‘Delegated Admin Permissions’ (DAP), as reported by the Microsoft Threat Intelligence Center.
By targeting Microsoft Partners, attackers have easy access to a large number of Microsoft 365 tenants. If you have a Microsoft 365 partner or purchase CSP licenses, chances are that partner will have global admin permissions over your tenant.
This article takes a deeper dive into DAP, honing in on the two major issues around DAP and how to identify active DAP permissions. But more importantly, this article will provide alternative solutions to help you work around DAP with your partner, that still provides them with the access they need while maintaining a strong security posture for your tenant(s.)
What are Delegated Admin Permissions?
Whether you rely on a consulting company to advise you on all things Microsoft 365, or you purchase licenses through a CSP partner, there is a good chance that partner has a Delegated Admin Permission link to your tenant. Delegated Admin Permissions (DAP) are provided to partners for ease of accessibility. By using DAP, they have access to the tenants of their customers without needing a dedicated account in each tenant.
This avoids the complexity of managing all these accounts for their different customers and sharing this with their engineers. Instead of logging in with an account from your tenant, they can use their own Azure AD credentials and log into the ‘Partner Center’ where they have a central overview of all customers. From there, it’s up to the partner themselves to provide each engineer with the correct permissions.
There are two different permission levels within DAP:
- Full administrator – comparable to a Global Administrator.
- Limited administrator – comparable to a Password Administrator role.
There are also two big issues with DAP:
- By providing Delegated Admin Permissions to a partner, you are essentially handing out a global admin role to all their users. Unfortunately, there’s no way to provide the partner with a restricted admin role, and you also have no way of knowing which users in the partners tenant receive the full administrator role. From my experience, I have noticed that most Managed Service Providers (MSPs) provide full administrator permissions to every engineer in the company – from helpdesk engineers to cloud architects.
- You have no way of securing the identities used by the partner as they don’t reside in your tenant. This means it’s impossible to require MFA or setup a password policy.
It’s important to note that a partner cannot add a DAP link without having a global admin consent to this. Sadly, these kinds of connections are often accepted by the partner itself or by an admin who isn’t 100% aware of what kind of access he is handing out.
Identifying active DAP permissions
The overview of the active DAP links is somewhat hidden away, and not integrated into reports or a secure score from Microsoft. In order to identify the current DAP permissions, navigate to the Microsoft Admin Center and select Settings, then select Partner Relationships – this provides an overview of all current partner relations. Within the Microsoft 365 ecosystem, there are many ways for a partner to add a link to a customer, and not all of them involve Delegated Admin Permissions. In order to identify which relationships have admin permissions, you’ll need to check the Roles column.
The screenshot below is taken from a tenant that uses a ‘Tier 2 CSP partner’. This means that partner is an indirect reseller (they don’t buy the licenses from Microsoft directly, but rather from a ‘Tier 1 CSP Partner’ or direct reseller). When you use a Tier 2 partner, both resellers will show up in the relationships overview (Figure 1):
How to handle partners and DAP permissions
If you’ve just discovered the DAP permissions within your tenant, your first instinct might be to immediately remove them. While this type of reaction is understandable, I would recommend you contact your partner first and double-check why they would need those kinds of permissions.
There are several reasons why a partner would create DAP connections:
- Using the Partner Center is the how their engineers access your tenant to provide support.
- They use the Partner Center to create reports or run automated scripts.
- Partners are graded by Microsoft on how many customers they manage. One of the ways for a partner to prove that connection is by enabling DAP. So, in some instances, setting up DAP is a way for them to attain a certain partnership level with Microsoft.
If they don’t provide support on a regular basis, chances are you can just remove the permissions entirely. But if that partner is your MSP and they actively use the DAP link, you could potentially remove their access to your tenant. If you find yourself in this scenario, you need to talk with your partner and agree upon an alternative solution to provide access.
As a customer, you always have the ability to revoke the permissions you’ve provided to a partner. This can be done by clicking on a particular connection and selecting Remove roles. By doing so, the partner relationship will remain but the permissions the partner has on your tenant will be removed.
It’s important to note that this will not remove the ability for the partner to buy licenses on your behalf. The only thing you are removing is the ability for the customer to access your tenant using the Partner Center, and their ability to create support cases in your name. I have seen instances where a partner will insist they need this level of permission to add licenses, but this simply isn’t the case.
If your partner actively uses DAP, you could investigate some alternatives, but it all depends on the partner. Microsoft recently started requiring a basic set of security controls for their partners, including Multifactor Authentication (MFA) for every account in the tenant. While I applaud this, I don’t feel like these controls alone are enough. Most modern-day attacks are going beyond Multifactor Authentication by using Steal-The-PRT or OAuth phishing attacks. Each organization should assess the security maturity level of their MSP and double-check if they can be trusted with permissions like these.
If the partner requires access to Azure only, Azure Lighthouse is an amazing solution that natively integrates with Privileged Identity Management and allows you to provide granular access to certain resource groups or subscriptions. If you’re working with Microsoft 365 workloads there’s a similar tool called Microsoft 365 Lighthouse, but it does require DAP so that really isn’t a solution to this particular problem.
An easy alternative would be to create a generic account for the partner and have them share that with all their engineers. But that’s too easy, and a bad idea in general because it convolutes auditing and makes enforcing MFA rather tricky.
The only real alternative is to create a dedicated administrator account for each individual engineer working for your MSP. While this might sound cumbersome, account creation is easily automated through Powershell or the Graph API and utilizing this method will improve your security posture tremendously.
Read More: Using a Certificate for Authentication with the Microsoft Graph SDK for PowerShell
Luckily, Microsoft is aware of these issues and is currently working on something called ‘Granular Delegated Admin Permissions’ (GDAP), which will allow a partner to request access to a tenant for a limited number of roles. From there, it’s up to the partner to decide which roles they require, and they would then send a request to the customer, and the customer can choose to accept or deny the role request. Microsoft also has plans to integrate GDAP with Privileged Identity Management and log all activities in the audit log.
So, while the future does look promising, this is something you need to act on right away as threats and attacks become more frequent and sophisticated. You should contact your Microsoft partner and confirm if any active Delegated Admin Permissions are being used. If so, you’ll want to work with them to secure access to your environment.
“It’s important to note that this will not remove the ability for the partner to buy licenses on your behalf. The only thing you are removing is the ability for the customer to access your tenant using the Partner Center, and their ability to create support cases in your name. I have seen instances where a partner will insist they need this level of permission to add licenses, but this simply isn’t the case.”
Thank you for clarifying this. I’ve found so much contradicting information on if it still lets them create licensing and this confirms things.
Guess you read this blog? 😉