Checklist for moving from Hybrid Azure AD Join to Azure AD Join devices

Many organizations are moving to cloud native identity and device management. For good reason – it lets your users work from anywhere and reduces the need for maintaining on-prem infrastructure and resources. If you are planning your move away from Hybrid Azure AD Join, what do you need to prepare in your environment?

✅Group Policy Objects have been analyzed and migrated

Group Policy Analytics is an amazing feature that lets you see which settings from your GPOs can be migrated to native MDM settings. Although some settings may not be supported for migration, it’s worth reviewing these settings to see if they’re even applicable to Azure AD joined devices. For example, “Domain member: Require strong session key” won’t be required since our device is not domain joined.

One recommendation when migrating your policies is to use this chance as an opportunity to revisit your device configurations. Consider implementing the Security Baseline for Windows 10 and later and then using the Settings Catalog to layer on additional settings that were surfaced from Group Policy analytics and determined to be required.

✅Your applications are cloud based

If your apps have been added to the Azure AD app gallery, your users can SSO into them from their Azure AD joined devices without any extra work.

✅Your on-prem web apps have been added to your browser’s trusted sites

For on-prem web apps, you need to add them to your browser’s trusted sites list. For Edge, this can be done using the AuthServerAllowList policy, which you can configure through Microsoft Endpoint Manager. Adding the domains of your on-prem apps to the allow list enables Windows integrated authentication to work, which gives you an SSO experience for those on-prem apps. Long term – consider integrating these applications with Azure AD.

If you need to access these web apps off the corporate network, take a look at Azure AD App Proxy.

✅Devices accessing on-prem (non-web) apps have line of sight to the Domain Controller

There’s some magic (read: hard work) built into Azure AD Connect that allows Azure AD Joined devices to access on-prem apps. Azure AD joined devices have no idea about your on-prem AD environment because they aren’t joined to it. So instead, we use Azure AD Connect to give your AADJ devices information about your AD environment, which they can then automatically use to access those on-prem apps. The details are all listed here, but they key point is that when an AADJ device attempts to access a Kerberos/NTLM resource, the device knows to contact the DC (because of AAD Connect) to authenticate the user, and the DC knows to return the Kerberos TGT or NTLM token. This means all apps that are configured for Windows integrated authentication (which is Kerberos/NTLM) will work seamlessly with SSO. Users on these devices can access UNC paths on AD servers, network shares, AD web servers, and more. Note that if you’re using Hello for Business or FIDO2 keys there is some additional configuration required.

Just like with the on-prem web apps, we can use Azure AD App Proxy to provide secure access to these applications from anywhere, but we also need to integrate with Remote Desktop Gateway.

✅Printers are integrated with Universal Print

Universal Print is an easy to configure modern print solution that allows printers to communicate directly with Azure for print management. While there are a number of supported vendors, you can also install a connector to work with any printer, making it easy to integrate into any environment. And it gets rid of needing to management print drivers!

⚠️LAPS

Azure AD joined devices won’t work with LAPS (local admin password solution), so we need an alternative if you were using it previously. Added in Windows 20H2, the LocalUsersAndGroups CSP lets us control which individuals are local admins on a device. You can also use the Azure AD device administrator role to give certain users local admin permissions on all devices. Neither of these solutions are identical to LAPS, since they’re not rotating a local admin password on the device. But they do let us restrict who can be local admins, and when you combine these solutions with Standard User Autopilot profiles, you can be in complete control of the local admin permissions on your devices.

⚠️RADIUS authentication for Wi-Fi

Azure AD joined devices don’t natively support RADIUS auth for Wi-Fi because a RADIUS server requires a computer object in AD. But – Azure AD joined devices can absolutely use SCEP or PKCS certificates for Network authentication. So you could begin using NDES (with SCEP certs) for accessing your corporate network. Or if you are leveraging NPS for your RADIUS server with WPA2-Enterprise/802.1x, then you can deploy a PKCS Certificate profile via Intune that allows users to connect to Wi-Fi without needing to manually enter their credentials.

❌Machine authentication

Apps and resources that depend on Active Directory machine authentication don’t work because Azure AD joined devices don’t have a computer object in AD. In the earlier example, we talked about how AAD Connect can give your AADJ devices extra information about your AD environment to be able to access on-prem apps. This works because the users were synced from Active Directory to Azure AD – so when the AADJ device knows to try authenticating the user against AD, the user credentials are there in AD to authenticate against. But an Azure AD Joined device itself is never in AD, so machine authentication apps will not work.

Many applications no longer depending on this form of authentication – even if they’re not cloud aware, they’re using Windows Integrated Authentication to authenticate the user, which is the automatically supported method discussed earlier.

☁️Final Thoughts

This type of transformation requires a change in mindset, and for some organizations that may not currently be possible. You aren’t building a first-class cloud experience if all of your user data is on mapped drives, apps must be on internal servers, and all traffic needs to pass through your corporate network. If that sounds like your scenario, before you try implementing something like AADJ Autopilot you should look into modernizing the rest of your environment (with OneDrive, moving apps into Azure, split-tunneling traffic only when necessary).

For others, they may be cautious because of decades of experience and success with on-premises device management. But these days the process can be incredibly seamless – so I would encourage you to do a proof of concept and see for yourself! 🎯