To make labs easy to set up and manage, Azure Lab Services is designed with no requirement to register/join lab VMs to either Active Directory (AD) or Azure Active Directory (AAD, or now also called Entra Id). As a result, Azure Lab Services doesn’t currently offer built-in support to register/join lab VMs. There are some key advantages with this approach:
We recognize that you may have scenarios where you want to register/join lab VMs. For example, you may want to increase VM security by using tools such as Intune or group policies to control user activity. Support for AAD joining lab VMs is being considered for the upcoming product roadmap. In the meantime, we recommend that you don’t attempt to register/join lab VMs to either AD or AAD.
In the rest of the blog post, we explain the limitations with the current experience and why we don’t recommend that you register/join lab VMs. In a future blog post, we’ll also talk about other ways that you can increase VM security without having to register/join lab VMs.
Thanks,
Azure Lab Services team
-------------------------------------------------------------------------------------------------------------------
To provide clarity, let’s first define common AD/AAD configurations and the options with each one to register/join computers.
In a full-cloud AAD configuration, your organization uses AAD and AAD Domain Services to manage computers/users. AAD is a cloud-based, Microsoft managed directory service that typically only requires that a computer has access to the internet. This enables users to either AAD register or AAD join their computers directly to your AAD in the cloud.
Figure 1 Full-cloud AAD configuration
In a Hybrid AD/AAD configuration, a computer joins AD Domain Services and AAD directories to enable management features of both directory services. Your on-prem AD is connected to AAD using Azure AD Connect which syncs your on-prem AD users/computers to AAD. This configuration gives several options to join/register computers:
Figure 2 Hybrid AD/AAD configuration
Here’s a table that compares the capabilities that are enabled depending on the register/join option being used:
|
Capability |
AAD register |
AAD join |
Hybrid AAD join |
AD domain join |
1. |
Students can sign-in to their computer with their AD/AAD credentials |
No |
Yes |
Yes |
Yes |
2. |
Students have single sign-on (SSO) access to cloud resources |
Yes |
Yes |
Yes |
No |
3. |
Students have single sign-on (SSO) access to on-prem resources |
No |
Yes* |
Yes |
Yes |
4. |
IT admin can apply group policies |
No |
Yes |
Yes |
Yes |
5. |
IT admin can enroll lab VMs with Intune |
Yes |
Yes |
Yes |
No |
* Only applies to a Hybrid AD/AAD configuration
Next, let’s look at the limitations that currently exist with each of the register/join options. The following table provides a high-level comparison of the limitations across the different register/join types. For more detailed info, read the bullets further below.
|
Limitation |
AAD register |
AAD join |
Hybrid AAD join |
AD domain join |
1. |
Cleanup: AAD/AD device entries are orphaned at high rate |
X |
X |
X |
X |
2. |
Management: Management challenges due to non-unique VM names |
X |
X |
X |
X |
3. |
Join/register: Join/register process is complex for both students and IT |
X |
X |
X |
X |
4. |
Physical device requirements: The student’s physical device must also be AAD joined/registered and run Windows 10/11 |
|
X |
|
|
5. |
RDP connection: Students must change their RDP file to use AD/AAD account credentials |
|
X |
X |
X |
When lab VMs are registered/joined, device entries in AD/AAD tend to become orphaned (or stale) at a high rate due to the transient nature of labs and their VMs. Here are common scenarios where lab VMs become orphaned:
Orphaned device entries can grow at a high rate which adds management overhead for your IT department. For more information on the cleanup that is required, see the article How to: Manage stale devices in Azure AD.
IMPORTANT: A lab’s template VM shouldn’t be registered/joined to AD/AAD because this image is used to create the student VMs and can be exported to the Compute Gallery to create other labs.
By default, Azure Labs doesn’t uniquely name lab VMs. For example, if you enable the Create a template virtual machine option when you create the lab, the VMs will all be named like “lab000001”. Or, if you leave this option disabled so that no template VM is created, the VMs will be named uniquely within a lab, but not across labs. With non-unique names, it’s challenging to manage lab VMs in AD or AAD, especially at scale.
If you’re an IT department or teacher that is proficient with scripting, you might consider using PowerShell to give lab VMs a unique name. However, we don’t recommend this because of the complexity involved:
To AAD register or AAD join lab VMs, currently the best option is for students to self-register or self-join their lab VM using either Windows Settings or Edge. This involves several steps for students that may be too complicated and requires that their lab VM first be uniquely renamed (see bullet #2 above):
Figure 3 AAD register using Windows Settings
Or they can use Edge to sign-in which will AAD register their VM.
Figure 4 AAD register using Edge
Figure 5 AAD join using Windows Settings
IMPORTANT: AAD join is further complicated by physical device requirements that need to be met to successfully RDP to an AAD joined VM. See the next bullet #4 for more info.
To Hybrid AAD join or AD domain join lab VMs, your IT department typically must do this because it requires admin credentials to join the VMs to AD and direct access to AD to ensure devices are properly joined. It’s possible to Hybrid AAD join and AD domain join VMs using PowerShell; however, this is complicated by the following:
Things get more complicated for AAD register, AAD join, Hybrid AAD join, or AD domain join because the steps need to be repeated in the following scenarios:
To successfully sign-in and connect to an AAD joined lab VM, the physical device must adhere to the following requirements:
This means that students can’t use a Chromebook, Mac, or Linux device to connect to an AAD joined lab VM.
IMPORTANT: These physical device requirements only apply to VMs that are AAD joined. They do not apply to VMs that are AAD registered, Hybrid AAD joined, or AD domain joined.
One reason that IT departments and teachers want to join lab VMs, is to enable an SSO experience so that students can sign-in to their lab VM with their AD/AAD credentials and access on-prem and/or Microsoft 365 (M365) cloud resources such as OneDrive. However, students must know how to change the RDP connection file’s default account to sign-in with their AD/AAD credentials to a VM that is AAD joined, Hybrid AAD joined, or AD domain joined. These steps may add too much complexity and be error-prone for students.
After the student downloads the RDP connection file and opens the RDP client, they need to change from the default local account to their AD/ADD account (e.g., user@domain.com or AzureAD/user@domain.com). To avoid repeating this step each time the student logs in, they can also edit the RDP file to use their domain account by default and save the RDP file to their physical device.
IMPORTANT: These steps to change the default account in the RDP file are only needed when a lab VM is AAD joined, Hybrid AAD joined, or AD domain joined. AAD register does not support signing into the lab VM using their AD/AAD credentials.
Figure 6 Prompt to change default RDP account
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.