Afraid of Windows 10 with Azure AD join? Try it out (part 2)

[Michael Niehaus]

First published on TechNet on Feb 21, 2018

In the part 1 blog , I talked about the mechanics of joining Windows 10 devices to Azure AD.  Now let’s shift focus and talk about the impact of doing it.  I already mentioned that Azure AD doesn’t provide management capabilities (those should be provided via Intune, System Center Configuration Manager, or other management tools).  But what about authentication with existing on-prem resources like web servers, file servers, etc.?  That’s the focus for this post.

Baseline:  AD-joined

Let’s start with the basics, things that you expect to “just work” because of Active Directory: users in AD, signed into devices joined to AD, accessing resources in AD.  Behind the scenes, Windows 10 talks to an AD domain controller to get a Kerberos TGT (ticket-granting ticket), which can then be used to access AD-joined resources.  No big surprise, these work just fine:

• Access a UNC path on an AD member server.
• Access a AD member web server configured for Windows integrated security
• Running Active Directory Users & Computers to administer all AD objects
• Running DHCP snap-in to administer an AD-joined DHCP server

So, let’s then look at another scenario:  Using the same AD-joined servers, let’s try using an Azure AD-joined device, where the user is signing into the device using an Azure AD account that has been synchronized with the AD domain.  What do you expect to happen in that case?  Before answering that question, let’s dig in a little deeper on what happens when you sign into an Azure AD-joined device.  Instead of talking to an AD domain controller, it talks to the Azure AD service, which provides a PRT (Primary Refresh Token), which can then be used to access Azure AD-protected resources.

Next Step:  Azure AD-joined

But what about AD-joined resources being access from an Azure AD-joined device?  The PRT doesn’t do any good in that case, because AD doesn’t know anything about it.  So to make this work, Windows 10 performs an extra step: When it sees that it is on a network with an available AD domain controller, it reaches out to that server to get a Kerberos TGT.  So now it has everything it needs to access both: a PRT for Azure AD, and a TGT for AD.

But how does this work? Through the magic of Azure AD Connect, Windows knows the AD domain name (synchronized from the on-prem AD into Azure AD) and can use that to look for an AD domain controller.  When it finds an AD domain controller, it can they get the TGT  needed to access AD-joined resources.  Let’s look at the results:

• Access a UNC path on an AD member server
• Works perfectly.


• Access a AD member web server configured for Windows integrated
  security
• Works perfectly.


• Running Active Directory Users & Computers to administer all AD
  objects
• You have to manually specify the domain that you want to connect to, as the MMC snap-in can’t use LDAP to figure that out itself.  Just use "Change domain” and then it will work perfectly.


• Running DHCP snap-in to administer an AD-joined DHCP server
• You may need to specify the DHCP server name or address (may work automatically if you used another AD-linked MMC snap-in first), but once you do it will work perfectly.

No surprises, you can successfully authenticate, although you might need to help some tools locate the AD domain you are trying to administer or the resource you are trying to access (if it’s located using AD).

Another Twist:  Windows Hello for Business

By default, devices joined to Azure AD will be enabled for Windows Hello for Business, which enables devices to sign on using a PIN or biometrics.  (You can turn it off via MDM policies, but you’re not doing your users any favors by doing so – avoiding passwords is a great thing.)  This works well when accessing only Azure AD resources, but does have some implications when accessing AD-joined resources.

For me, this was definitely a learning experience, pouring over the Windows Hello for Business documentation , including a detailed deployment guide .  I could probably write several blogs about that, but I’ll just provide the cliff notes here:

• You want to do a “hybrid” deployment of Windows Hello for Business.
• There are two choices for setting this up:
• Key trust , which requires at least one Windows Server 2016 DC, Certificate Services set up in the domain, Kerberos certificates on each DC, the trusted root cert deployed to each device using Intune, and an accessible certificate revocation list (CRL).
• Certificate trust , which needs the Windows Server 2016 schema, but works with older DCs.  But for this to work, you need to issue certificates to everyone, which requires NDES, more Intune configuration, deploying the trusted root cert, and having an accessible CRL.  (You’ve probably already done this work if you are using smart cards, so it might not be so bad).

Once you have either a key trust or certificate trust set up and properly configured (took me several days to get the CRL right), then all the above tests work just as they did without Hello for Business:

• Access a UNC path on an AD member server




• Works perfectly.


• Access a AD member web server configured for Windows integrated
  security




• Works perfectly.


• Running Active Directory Users & Computers to administer all AD
  objects




• You have to manually specify the domain that you want to connect to, as the
  MMC snap-in can’t use LDAP to figure that out itself.  Just use "Change
  domain” and then it will work perfectly.


• Running DHCP snap-in to administer an AD-joined DHCP server




• You may need to specify the DHCP server name or address (may work
  automatically if you used another AD-linked MMC snap-in first), but once you do
  it will work perfectly.

More Options Available

Also note that you might choose to leverage something like the Azure AD Application Proxy to access internal web apps.  With that, you can authenticate using Azure AD (including support for multi-factor authorization) and let Azure handle the internal authentication and redirection for you (no client-side VPN required).  And as announce last week, you can now configure these apps using PowerShell; see https://cloudblogs.microsoft.com/enterprisemobility/2018/02/15/faster-application-deployment-in... for more details.

Summary

For those afraid of joining devices to Azure AD because of the number of Active Directory-secured apps, services, shares, etc. that are being used in your environment, I think you’ll be presently surprised at how well it can work.  Obviously your results may vary (people always find creative ways to configure things, so there’s definitely a chance that some apps might not work, at least not without some reconfiguration), so you still want to do some testing on your own.  But it will likely work well enough for you to try it out yourself – take a few devices, maybe even your own primary device, and join it to Azure AD to see what happens.  (See part 1 for more details on that.)