Microsoft now supports External Identities for both Azure Virtual Desktop and Windows 365; great news! This new feature makes it easier to collaborate securely with external users such as partners or contractors. I hear you thinking, “I could already work with partners before, so what’s new?” The difference is that this brings a more secure, managed, and seamless identity strategy through Microsoft Entra. It’s a big step forward and one you’ll definitely want to take advantage of.
The first struggle
If you need to collaborate with others or give a partner access to your environment, the simplest solution is often to create a separate account within your tenant. Just add a new user, for example jon.doe@kempeneers.eu, assign the necessary license, and share the credentials with your partner. They’ll be able to connect right away, simple and effective and a method that’s often used in the field.
When you think about it, this approach doesn’t scale well. If your partner has several users who need access, for maintenance, for example, you’d have to create multiple accounts for each one of them. Now imagine having several partners. Each with multiple users that need access to your environment. That are a lot of different accounts to manage.
“Not a big deal, I need to create accounts for my own users as well.” That’s true, but for your own users you have onboarding and offboarding procedures, you know when they leave the company and when you need to disable their accounts. That’s a big challenge when working with external companies.
Let’s continue on that; imagine an employee leaves your partner’s organization. You have to rely on them to tell you so you can disable the account. That’s a manual step in your identity process, and a risky one for sure! These accounts often have elevated permissions to backend systems or tools, and without proper governance, you might not even know whether they’re still being used. In other words, you’ve just left the door open.
You might think about using shared accounts, but that’s a clear security risk and should always be avoided. The reality is simple: more users mean more individual accounts, and that can quickly become challenging to manage. Still, having dedicated accounts for each user is the right and most secure approach.
So how do you deal with this?
The right question to ask yourself now is: how do you handle this? You’ve realized that the best approach is to let externals user their own UPN instead of an account that you provide.
So here comes the next issue. Every tenant has a primary domain. That’s the part behind your username. In my case “kempeneers.eu”. A domain can only be reigstered to one tenant at a time. This means it’s not possible for me to add “contose.com” as an alternate domain if I’m not the owner. That basic security. This however means that I’m not able to create user accounts with a domain suffix that isn’t associated with my own tenant.
Connect with your partner
Microsoft has already thought this through. Microsoft Entra allows you to invite guest users directly by using their email address. The external user receives an invitation email, accepts it, and a guest account is automatically created in your tenant. This new user is of the Guest type and will have a UPN similar to:
jon.doe_contoso.com#EXT#@kempeneers.onmicrosoft.com.
This UPN references the user’s original email address and enables Entra to identify the user and redirect authentication requests to the correct tenant.
So this is what you need, the user is now able to authenticate with their own account to your tenant. If you require additional MFA, you can configure so. The big advantage now is, if a user get’s disable in the remote (external) tenant, access to resources in my tenant is automatically revoked as the account is no longer able to log-in. I can rely on the offboarding process of my partner to keep my own tenant secure.
The second problem
The concept of using Guest accounts isn’t new, it’s been part of Microsoft Entra for quite some time. It’s commonly used for collaboration, especially in Microsoft Teams channels. But until recently, it didn’t extend to many other resource types. With this latest update, Microsoft has enabled External Identities to access Azure Virtual Desktop and Windows 365 Cloud PCs. Previously, this wasn’t possible, external guest users couldn’t sign in to a managed desktop within your tenant. This than meant that you would resort to the old habit of creating named users in your own tenant and share the credentials with externals.
The third problem
As you’ve now probably noticed, Microsoft is building a solid foundation to make External Identities work seamlessly. But there is a third issue! Now that Windows 365 and Azure Virtual Desktop support external identities, how does an external user sign in to the Windows App with their own email address but still connect to my tenant?
As mentioned earlier, every domain is tied to a specific tenant. So, when a user from contoso.com signs in with jon.doe@contoso.com, they’re redirected to their own tenant, and their own resources will load after authentication.
But that’s not what I want! I want them to authenticate with their own email address and then be redirected to my tenant, where I’ve assigned them a brand-new, shiny, Cloud PC.
So how can the external user authenticate?
It’s a simple process, let me show you how an external Contoso user can authenticate to my Kempeneers.eu tenant.
Let’s sign in to “https://windows.cloud.microsoft“, Windows App for
Web to see how the sing-in flow works. The process for Web is identical to the Windows app.
Instead of entering your email, you first click sing-in options, this is a crucial step in authenticating to a third party tenant.
You’ll now see a new option called “Sign in to an organization”. This option alows you to define to which environment or tenant you want to signin to. It’s therefore crucial that your external contractor knows the domain name of your tenant.
Fill in the domain
I am now redirected to the kempeneers.eu tenant, allowing the partner to sign in with their own Contoso account. As they are already connected to my tenant, no additional redirection is needed anymore.
After authentication and providing MFA the external users now have access to the Cloud PC in my tenant. You can verify by opening the account switcher, you’ll see my tenant name in the upper corner, while the account is authenticated with the “contoso.com” domain. Great!
When connected to the Cloud PC you can now see that the Contoso user is signed in to the Cloud PC residing in my kempeneers.eu tenant.
When using the Windows App, once you authenticate to another company you will keep the ability to easily switch back and forth using the account switcher.
Limitations and requirements!
It’s all fun and games but there are some things you should know before deploying this into your environment.
- The AVD Session Host or Windows 365 Cloud PC needs to be Entra Joined, Hybrid is not supported
- SSO needs to be enabled for both AVD and Windows 365
- You can only provide access to external users, using Social Accounts or commercial Microsoft Azure (Entra) accounts. Azure Government for example is not supported.
- Currently only the Windows App for Windows and the Windows App for Web are supported platform where External Identities will work.
- Device configuration policies assigned to an external identity do not apply to the external user’s Cloud PC. To enforce these settings, assign the device configuration policies directly to the device instead.
- The Azure Virtual Desktop existing per-user access pricing lets you pay on behalf of external users, this is however only a supported model for (for example) ISVs who leverage AVD to provide access to their application. This should not be confused with External Identities.
Although the documentation states that social identity providers are supported, I wasn’t able to access the Cloud PC that was provisioned to my personal Outlook account. The provisioning process completed successfully, but when I tried to sign in through the Windows App for the web, I encountered the following error.
Licensing
One important thing to know when using a single identity across multiple tenants is licensing. Many people assume or hope that guest users don’t need a license as a guest user because they’re already licensed in their own tenant. Unfortunately, that’s not the case. While guest users can authenticate through their own Identity Provider, they still need to be licensed for the features they use. In other words, they must meet the same Windows 365 or Azure Virtual Desktop (AVD) license requirements as internal users. For Windows 365, the license must also be explicitly assigned to the guest account in your tenant, whether it’s group based licensing or user based licensing.
Entra’s automated collaboration mechanism
Fortunately, creating guest isn’t solely a manual process. There are several ways to automatically add guest users to your tenant. For example, if you’re part of a larger organization and need users from subsidiary companies to access your tenant, you can use MTO (Multi-Tenant Organization). Additionally, Microsoft offers multiple B2B collaboration options to simplify and automate guest user management.
Lets wrap up
By combining External Identities with Azure Virtual Desktop or Windows 365, organizations can now implement a better strategy that aligns with the best practice: “Only allow access to company data from managed devices.” In this case, the Cloud PC or session host serves as the managed endpoint. In my view, this is a major step forward in enabling secure and seamless collaboration. What do you think? Share your thoughts in the comments below.
Leave a Reply