OVERVIEW
Target audience: Lan Administrators and ITS Server Admins
This document gives guidance on when to join devices to Azure Active Directory (Azure AD) and when not to, and the potential implications of Azure AD joining. The guidelines apply to all users, including Lan Administrators and ITS Server Admins. Please note that regular users are no longer allowed to join devices to Azure AD.
Adhering to these guidelines will help maintain a secure and efficient computing environment at McGill. By understanding when to join devices to Azure AD and the potential consequences, users and sys admins can make informed decisions that promote the best interests of both individuals and the organization.
In this article:
When to join devices to Azure AD
Join devices to Azure AD when there is:
- AutoPilot deployment: Azure AD joining is a requirement for Autopilot even for Autopilot Hybrid Azure AD join. The end user going through the autopilot process requires permissions to Azure AD join the device. ICS is currently in the early stages of testing Autopilot Hybrid Azure AD.
- A specific use case: For Lan Admins and ITS staff, there may be unique situations where Azure AD joining is appropriate, but these instances are rare and should be evaluated on a case-by-case basis.
When NOT to join devices to Azure AD
In general, regular users should not join their devices to Azure AD, as it transforms their machines into McGill-managed devices and may lead to unintended consequences.
Potential issues with Azure AD joined devices
- Group Policies cannot be targeted or applied to Azure AD object.
- No Computer Object in Active directory and therefore cannot be part of AD groups.
- SCCM client will not be installed automatically.
- Sharing of BitLocker keys: BitLocker device encryption is turned on by default on devices that support Modern Standby. After joining Azure AD when you sign in, the clear key is removed, and a recovery key is uploaded to Azure AD (This also for users who turned on BitLocker on their own). Losing access to your McGill account will also result in losing access to your BitLocker key, which can be disastrous.
- Stale device objects: If a device fails to synchronize regularly, its device object may become stale, leading to the device being locked out of network resources and potentially causing other complications. A device’s primary refresh token (PTR) is continuously renewed if the user uses their device and has internet access. However, the PRT token is only valid for 14 days.
- Device limit: Each account is limited to 20 devices. Migrating devices to other accounts is feasible but requires assistance from CIA. Please note that this process is not a standard procedure and while not overly complex, it may require some time to process. As such, it is recommended to plan device joining accordingly to avoid the need for device migrations. We do not promote device migrations as a regular practice.
Best practices for users and system administrators
- Avoid joining devices to Azure AD unless necessary, as it may lead to unintended consequences and potential issues.
- Remember that only Lan Administrators and ITS Server Admins can join devices to Azure AD.
- Consult with an ITS staff member before considering joining a device to Azure AD to ensure it aligns with McGill's policies and use cases.