Some time ago, I had a conversation with my girlfriend (also a Microsoft Consultant) about how to manage secure access for external admins. Probably not your average dinner talk at home.She explained that new customers would create an admin account for her, but she often couldn’t sign in afterwards. The cause was always conditional access policies requiring her to work from a compliant device. But obviously, she could not do so as she was working from her own device, which her own company manages.Most of the time, the customer would simply exclude her from conditional access policies, and she could do her job afterwards. But clearly, the customer needed to prepare for external admins properly or be more concerned about the situation.Today, we’ll compare three options for providing access for these external admins: regular user accounts, guest accounts, or through GDAP.We’ll compare them by looking at them from three perspectives: least-privilege access to permissions, the user experience, and our main problem today, device compliance.Today’s post will cover the following sections:

• Option 1: User accounts
  • Permissions
  • User experience
  • Device compliance
• Option 2: Guest accounts
  • Permissions
  • User experience
  • Device compliance
• Option 3: GDAP
  • Permissions
  • User experience
  • Device compliance
• Conclusion

Option 1: User accounts

For our first option, we will discuss providing access to the environment through regular user accounts.This option is the most commonly used way of providing access to external users, and for good reason! By creating and managing the account from our own tenant, we can treat it as any other internal admin user. More importantly, we have all the tools available to provide and manage access securely through everything that Microsoft offers.

Permissions

So, in terms of permissions, we will not be restricted in any way when dealing with external admins using regular user accounts. We can assign them a least-privileged Microsoft Entra or Azure role or create and assign a custom one.If we want to go further, we must assign some Entra ID P2 licenses to our admins. We’ll have access to Privileged Identity Management, Access Packages, and Access Reviews. By implementing these products, we can provide just-in-time and just-enough access, require justifications or approvals for privileged roles, regularly evaluate and expire permissions, audit history, and more!

User experience

When talking about the user experience, we can be short as well.The Microsoft Cloud platform is mainly built for regular user accounts, so users can easily navigate and reach everything they need.One thing to remember is that external consultants or (MSP) support engineers are or could be working for more than one customer. As a result, they’ll need a separate account for each customer. This situation could be seen as user productivity loss as they would have to sign in to a different account each time. I think it’s not too much to ask, but some see it as unpleasant.

Device compliance

Now, back to our main challenge. In our high-security (zero trust) environments, we will not trust external admins to work from an unmanaged, non-compliant, potentially unsafe device.So, our challenge lies in the fact that these external admins will almost always work with devices already managed by their company. And since devices cannot be managed by two tenants or two MDM providers at once, what can be our next step?As I mentioned earlier, I’ve seen many companies struggle with this, and almost always, they will exclude the user account in Conditional Access and forget about it.A while ago, I wrote two blogs on how you can manage conditional access policy exclusions by using either PIM for Groups or Access Reviews. They are pretty unusual methods, but they are worth a read if you go this route.Another thing I’ve seen companies do is ask for an IP address they can exclude. By doing this, the external admin can work physically or remotely (with a VPN) from their company’s office location.This is arguably better than simply excluding the accounts, but we still cannot ensure they work from a managed and compliant device. So, what’s left then? Giving them a (second) device is not always an option here, as these consultants or support engineers shouldn’t have to juggle multiple laptops to be able to work for their customers.If the budget allows, offering them a Windows 365 Cloud PC to sign in to could work, or else any other virtualized option managed by Microsoft Intune and secured by Microsoft Defender could work! You can even consider having them work from your virtualized Privileged Access Workstation (PAW), which is already the most secure way to handle privileged access.If you’re not convinced option one is right for you, keep reading; this was never going to be a simple choice!

Option 2: Guest accounts

For our second option, we will discuss providing access to the environment through guest accounts.Providing external admins with guest accounts can seem logical, as they are, theoretically, guests to your tenant. We also won’t have to create the account ourselves, as we can simply invite them.

Permissions

There is no real difference between granting permissions to regular users or guest accounts. So, just as with option one, we can provide access through Microsoft Entra and Azure roles or even create and assign custom roles.We can also implement Privileged Identity Management, Access Packages, or Access Reviews for guest accounts. Our external admins can easily activate or request their permissions through Privileged Identity Management, just as any other admin user.

User experience

The user experience for guest admin users is slightly different, though. They will not need a separate account for each customer, as they can use a single (their own) user account.To navigate, they can switch directories from the portal settings in the Microsoft Azure management portal like this.After switching, they can use the Azure portal to view and manage any Azure subscription they can access. The Microsoft Intune and Entra admin centers are accessed the same way because these are also accessible from Microsoft Azure.But let’s try navigating to other Microsoft 365 (non-azure) admin portals, and we will quickly encounter a problem.Typing in any of the URLs such as “admin.microsoft.com”, “exchange.microsoft.com”, or “security.microsoft.com” will redirect the guest admin user straight back to their home tenant.But I will show you a simple trick to to reach our destination here. We can replace the tenant ID in the URL to match our destination tenant, or you can simply copy and paste your tenant ID behind this URL: “https://security.microsoft.com/homepage?tid=“.By doing this, we can reach our destination (host) tenant. Sadly, this trick only works for the Microsoft Defender admin center, as doing this for any of the other Microsoft 365 (non-azure) admin centers will present us with an error or just plainly redirect us back to the home tenant.Please let me know if anyone knows a similar trick to reach any other admin center! But for this reason, this option will be a no-go for any external consultant or Managed Service Provider (MSP) that needs access to a Microsoft 365 admin portal.

Device compliance

If you are still considering this option, let’s go to our main challenge: dealing with external admins working from unmanaged, non-compliant, and potentially unsafe devices. For this, we’ll need to look at the cross-tenant access settings accessible from the external identities section in the Microsoft Entra admin center.From there, we can add organizations for cross-tenant access and configure specific trust settings. In short, this means we can manage how we can collaborate with external organizations and how they can collaborate with you.At the cross-tenant access settings, there is a section called trust settings. Configuring these trust settings can let you trust multi-factor authentication and device claims from external organizations. Your conditional access policies can then accept these claims, and you can require these external admin users to be working from a managed and compliant device before being able to access your tenant.This is a great feature that deserves more attention. Please be aware, though, that you don’t actually know what these claims are based on. The compliant device claim could be from a device without BitLocker or a device with real-time protection disabled. We simply don’t know what the compliance policy settings look like in external tenants.If option one or two hasn’t convinced you yet, keep reading because option three may be a better fit.

Option 3: GDAP

For our third option, we will discuss providing access to the environment through GDAP.Microsoft Partners have been managing their customers through something called Delegated Administration Privileges (DAP) for many years. They would receive these permissions after establishing a reseller relationship with a customer, usually when delivering services or selling licenses.These DAP relationships essentially came with (free) global administrator permissions for the Microsoft Partner, which many customers (or partners) wouldn’t even notice.Something changed as Microsoft saw increasing attacks targeting Cloud Service Providers (see Nobelium). As a result, Microsoft started to improve partner security, which is how GDAP was born. Now, partners are slowly being forced to transition to the new Granular Delegated Administration Privileges (GDAP) model. 

Permissions

In this blog, we will not fully deep dive into the new GDAP model. But what is important to know for now is that it provides partners with a way of managing multiple customer tenants with least-privileged access.Sadly, only the (default) Microsoft Entra roles are available to request at the moment. Partners cannot access Microsoft Azure roles, custom roles, or admin portal-specific permissions.Because of the limited roles and permissions available, from my experience, this results in over or under-privileged access rather quickly, especially when dealing with IT support staff. But let’s not get grumpy here; the new GDAP is far superior and way more secure than the old DAP relationships. If anyone is interested, let me know, and I’ll write a blog post on how you can securely implement GDAP for your customers.Ok, now back to the perspective of a tenant owner. Can we implement Privileged Identity Management for these GDAP users? No, you can’t. After you have given away permissions to a Microsoft partner, they can use them however they feel like.However, the Microsoft Partner themself can implement PIM for their customers. They can create and add a security group to the GDAP relationship and assign specific roles to members of this security group.Next, the Microsoft Partner can use PIM for Groups to provide just-in-time, time-bound, and just-enough access to these security groups. So, it’s definitely possible to use PIM here. Still, I think most high-security organizations will want to use their own implementation of PIM, which sadly is impossible.

User experience

Regarding the user experience with GDAP, you should know that the external admins can sign in and manage your tenant from their own identity. They can even access multiple customer tenants from their single pane of glass called Microsoft 365 Lighthouse, which can help them stay productive.Besides using Microsoft 365 Lighthouse, these external admins can also fully sign in to your tenant and do so from their own identity. They can switch tenants from the Microsoft Partner Center but can also do so from most of the Microsoft 365 admin centers.Sadly, this results in a situation where you, as the customer, cannot manage these accounts from your own (customer) tenant. They will sign in with an anonymous UPN, and audit logs will show the display name as “COMPANY NAME” Technician.Because we can not manage any external (GDAP) admin users, we can not target them with tools or policies or include them as a member of a security group. This is also why your own implementation of Privileged Identity Management won’t work here, and as you can imagine, it results in many other limitations.

Device compliance

Now back to our main question. Can we require GDAP users to work from devices that are managed and compliant?Yes! GDAP users are a type of guest user, so you can use the cross-tenant trust settings exactly the same as we discussed earlier with option two. Just make sure that your conditional access policies include “service provider users”.From a Microsoft Partner perspective, we can also require our engineers to work from managed and compliant devices before they can access customer tenants. We can achieve this by configuring a conditional access policy and tagging the security group in the role settings with a configurable authentication context.I still don’t think a high-security organization should accept so many uncontrollable external variables, but they’re an acceptable risk for some. However, if you are a Microsoft Partner, this is probably something you will want to use. But please do so securely using PIM for Groups and require compliant devices with authentication contexts.

Conclusion

Looking back on the available options, they are all viable, but none are perfect, as they all have advantages and disadvantages. Let’s re-cap them, and I will give my opinion on each of them.If you’re a high-security organization, you should consider option one, providing access through regular user accounts. You’ll have all the security tools available to you and can manage and audit the users in your tenant. The real challenge here is being able to require external admins to work from compliant devices. But it’s definitely worth the effort if you have the resources to do it.Option two, providing access through guest accounts, can be viable if you configure the cross-tenant trust settings. However, it requires us to place trust in external compliance policies. Comparable to option one, though, this is probably the easiest to configure and provides a decent user experience. Sadly, guest admins cannot access most of the Microsoft 365 admin centers, which makes this option useless for many scenarios. Then, finally, option three, providing access through GDAP, is the go-to option for any Microsoft Partner delivering MSP services. Managing your customers from a single identity and centralized portal with Microsoft 365 Lighthouse is what makes this option unique. However, as I mentioned, the current limitations and available roles are unacceptable for many high-security organizations.If you found this blog informative or have any questions, please tell me in the comment section.

This post is part of the unmanaged devices blog series; find more posts here. View previous part: How to disable personal device enrollments in Microsoft Intune View next part: Quick Guide: How to enable device trust for guest users

Three methods to manage secure access for external admins