Let's talk about Azure AD Conditional Access for a second.
Its deceiving, like rob you in the night after you thought you were friends deceiving. I say this for two reasons.
1. In the rules for Conditional Access there is an option that is labeled 'domain joined'. This is misleading. What this is really checking against is if the device is registered within Azure AD and domain joined. If the device is domain joined but not registered then it won't honor the conditional access controls. Registration can happen automatically for domain joined devices once some configuration is done on prem (more on that later).
2. Conditional Access only supports applications that use modern auth. This wouldn't be so big a deal if when you enabled Conditional Access it disabled legacy authentication methods. It doesn't. What this means is all your fancy layered rules can be defeated by someone in China firing up Outlook 2010 and using a compromised account. Don't believe me? Take a look here.
Microsoft's suggested fix is to stand up ADFS and use claims rules to block legacy auth....not much of a fix in my opinion.
I want to circle back around to point number 1 and talk about how to do automatic registration of domain joined devices.
Its not my style to just rehash all the steps in another article unless I had some sort of gotcha moment during it. The steps to enabling this feature can be found here
What I do want to touch on is some scenarios I had thought about when doing this. First some background info on how the registration works. Windows 10 devices have the logic to join Azure AD baked into the OS. You configure your SCP point and configure ADFS if you have it and you're off to the races.
A little caveat that I found out is that my devices would not sync unless I was also syncing their Computer Account Object. I believe this is due to Windows 10 machines not being tied to a user account when they sync (more on that later). I did some testing and what I saw when I stopped syncing the Computer Objects was that it also removed my registered devices out of Azure AD. That is gotcha #1
Windows 7 devices are a little different. They require a small MSI package to be ran to force a registration since they do not have the baked in logic. What I found when testing these guys is that they are tied to a user, whatever user's login triggers the join gets the device put in their name. This means that only users that are being synced into Azure AD can register. Gotcha #2. If a non synced user tries it will fail silently.
What is interesting though is that if a synced users stops syncing or gets removed from Azure AD the device will remain and not be associated to any user, like the Windows 10 devices.
So huge wall of text. Here's a picture of my devices and the output of dsregcmd /status on a successfully joined Windows 10 machine to make it all better.
See ya later!
(Disclaimer: I work for Microsoft in the Azure AD team.)ReplyDelete
I believe you may be mistaken in #1.
During device registration (with Azure AD) of a domain-joined device, two important things are recorded in Azure AD (on the Device object):
1) The fact that the device is domain-joined (in DeviceTrustType attribute).
2) The public key of the certificate which is generated and placed on the device.
During sign-in, in order to enforce a "require domain-joined" control in a conditional access policy, Azure AD first authenticates the device (via the certificate), then looks up the DeviceTrustType attribute of the now-authenticated Device object.
So, device registration is required, yes, but "require domain-joined" really *is* checking if the device is domain-joined to the on-premises AD. (You can do device registration of other devices, like an iPhone or an Android, and it will *not* be considered "domain-joined".)
For some reason my notifications for my post comments were turned off. Sorry for a late reply but thank you for the insight!Delete