Forum Discussion
Azure AD Join (Entra Join) vs Hybrid Azure AD Join vs Azure AD Registration (Workplace Join)
I still find it hard to understand the differences between Azure AD Join (Entra Join) vs Hybrid Azure AD Join vs Azure AD Registration (Workplace Join).
I know Azure AD Registration (Workplace Join) is supposed to be nest for Personal devices (BYOD) but if you have security as an important part of your business why would you want to allow this? You could end up with a billion random machines in your Entra. What's the benefit of this?
Also, if I have a Hybrid environment and I have booth cloud and on prem apps that do auth via both on prem (for on prem apps linked to AD) and Entra for cloud do I need to be Hybrid Azure AD Joined to support on prem an cloud? Or will a person working from a Azure AD Joined machine still be able to access on prem resources like file servers and any app that uses AD groups for auth, access provisioning etc?
2 Replies
As far as I know, you can't really prevent someone from registering their device in Entra but you can control what data they can use. A device registration happens automatically, when a user adds their work account under work & school in the windows settings. That in it self isn't a theat because you can still control what data the user can access on which device using conditional access. Just ensure that the users can't enroll their private devices in Intune through automatic enrollment, that will cause you real headaches down the line.
If you're still tied to your local active directory I don't recommend going for Entra ID Join only. Using Hybrid Join is the way to go in this scenario. With hybrid join, users login to their device using their AD Identity but they still have their work & school account linked and can use SSO both on-prem and in M365.
If you have any further questions let me know :)
Entra ID registered allows SSO > less sign-ins > less interruptions.
You have a set of granular options for fine-tuning access to certain services. With Conditional Access you can specify under which conditions, from which location / IP ranges, users can access these services, and if for example some services can only be signed-in to from a device that is marked as compliant. Requiring the device to be marked as compliant, also requires the device to be enrolled in Intune. In Intune you could decide not to allow personally owned devices, requiring the device to be Entra joined. Then there's settings in Entra ID where you can decide under which circumstances a device can be joined. There's a lot of possibilities to design this. Depends on your needs and infrastructure.
That's authentication. For authorization you have tools like Entra ID Governance. For data leakage BYOD concerns there's MAM for Windows.
For on-premise resources that require authentication with AD, you would need an account in AD to sign-in to it of course. And designing a solution for this is also highly dependent on your environment and each on-premise resource. There's federation with ADFS (no EOL announced but not recommendable), Cloud Kerberos Trust with Windows Hello for Business or FIDO2 and of course SSO which requires line of sight network wise and user's attributes synced via Entra Connect or Cloud Sync: https://learn.microsoft.com/en-us/entra/identity/devices/device-sso-to-on-premises-resources
For "a billion random machines in your Entra" you have the option to set the max amount of devices each user can register. Generally speaking you have IT putting security policies in place and thinking ahead as much as possible for risks and then you have free roaming users who want to work but not wait on IT for each mouse click. Every sensitive file can end up anywhere if you think about it long enough. But with modern features for monitoring, alerts, rules, automations etc. and tools like sensitivity labels you have a wide variety to minimize the burden on IT staff and at the same time making your environment maybe even more secure than it was before.
