Entra join only is a journey – are you on it yet?

Entra join only is a journey – are you on it yet?

 , , , ,

If you think you need a domain joined device to access a file share after this blog, I did something wrong. For the past 2 years, I have been working with clients of all sizes and in all industries to take them on what I believe is the most important journey they can take right now: Entra-Join Only. This blog post won’t be that technical (think a L300), but I want to show you what I think are the most important issues you need to be aware of. But first, let me briefly summarize why this is so important.

Basics first

While I recommend refreshing your memory quickly, you can skip this part if you already know the basics of how things are synchronized between Active Directory (AD) and Entra ID (EID). This is a very simplified version thus I’m leaving out certain parts on purpose.

To understand why Microsoft Entra join only is much simpler, we first need to understand how we got here. Most companies already have some form of sync set up between AD and EID. However, it is crucial to understand that this (mostly) only applies to three object types: Users, Computers and Groups. Structures like organizational units are left behind, everything is organized in groups instead.

The user can then be used with Entra ID or Active Directory as the Identity Provider (IdP), depending on what type of authentication is required. Each has its advantages, and it’s important to note that I’m not suggesting in this article that you make your users cloud-only unless there is nothing on-premises that requires AD.

Using this authentication logic, what does that mean for a computer object? A computer object created on-premises is synchronized (or rather staged) as soon as it is within the scope of Entra Connect. This staged object is a prerequisite for the hybrid device join. The join is initiated on the client device and connects both objects using an anchor attribute. To make this happen, we have our first set of requirements. In total, this process takes at least 30 minutes or one Entra Connect synchronization cycle from the moment the object is “born”. Again, (device) authentication is possible in both worlds. However, device authentication with Entra has only a few use cases (just like Active Directory).

Why shouldn’t I use hybrid join?

Well, this is a trickier question than you might think and depends very much on your specific situation. I have had many discussions on this topic with all sorts of random people, (ex-) colleagues, customers, friends. But if you’re here, you’re already thinking about the relevance of hybrid join, so that’s an excellent start. Let’s look at what I find to be minor or major issues with most customers. Let’s start with the facts

  • Hybrid join has been around for as long as Windows 10 has been around – that’s almost 10 years now.
  • As of December 2023, Microsoft no longer recommends using hybrid join, and has a note on every article about it.
  • Over the past 10 years, hybrid join has never been “good”, it has provided additional technology to make authentication with Entra easier.
  • Hybrid join requires a labor intensive infrastructure (even a simple setup is a couple of systems) to work. Among other things, you need domain controllers, network components (such as DNS, DHCP, ideally AD integrated, plus firewalls and a VPN solution) and Entra Connect.
  • Using hybrid join also means that the device can handle CSPs from Intune and GPOs – a really bad mix and hard to troubleshoot.
  • Limits Autopilot features
  • Limits Windows features (see next chapter)
  • Inherently less secure, due to domain trust (well known lateral movement paths)
  • (Double workload of on-premises and Azure maintenance)1

And what do you actually gain by using hybrid join?

  • Device authentication against AD while getting additional user authentication for Entra.
  • Auto enroll devices into Autopilot (this is solvable through many other means).
  • Learning cloud technologies more slowly gives IT staff time to adapt.2
  • You don’t need to think further about your IT. You run it, like you’ve always done it.

However, it is a recommendation for now. We absolutely have other things to worry about. But at the core, this is what you gain by using hybrid join.

Entra-Join only?

Yes, Microsoft has been discouraging the use of hybrid join for almost a year now – in reality this has been the recommendation for way longer. It felt like a good step in the right direction in December 2023 when they officially added this note to all of the “Learn” pages related to this topic. However, I still find myself discussing this topic over and over again, and sometimes it feels like wading through a swamp. The most important thing to remember is that you only lose one thing from the last chapter, device authentication against AD. Let’s see what that means.

  • User authentication against AD and Entra is sustained (using WHfB + Cloud Kerberos Trust (CKT) gives you additional quality of life SSO too3)
  • Simplified enrollment – all you need is an internet connection (especially true for Autopilot)
  • More features available (like web sign-in and device preparation)
  • Some current and future (NDA!) features will only be available using Entra-Join

Yes, you heard right! AD and Entra authentication is possible! This means you can continue to open your file shares, printers, and other local applications just as you always have. It’s the same user experience as on a domain-joined device. Providing a single sign-in method with Windows Hello for Business and Kerberos trust in the cloud can greatly improve the experience, but it’s not a prerequisite.

Sounds good – what do I need to do?

As some MVPs sometimes so aptly points out, “You can’t modernize in a vacuum”. You can’t make this journey without involving more people than just yourself. Some challenges will be technical, others will require organizational change. Overall, there are eight core areas you need to address. These are in no particular order: Network, GPO, Certificates, Remote Support, Security, File Shares, Printers, and most importantly, Applications. Now, there will always be “special” cases (see next chapter), and there are topics I have left out – this blog is long enough as is.

When not to use Entra join

I won’t say there are no cases, that’d be a lie and everyone who tells you otherwise doesn’t have enough experience yet. However, you will want to apply the Pareto principle here. No, seriously, your first attempt at this should be to set up a device with Entra join and see how far you get. Now, what would limit you to use hybrid or even AD joined?

  • Air gapped – this should be fairly obvious. No internet, no Entra join. Stay AD only. Remember to apply the Pareto principle. To how many endpoints does this apply?
  • Legal requirements – I have not seen these yet, usually it’s because “someone higher up said so”. Remember, the fact that you remove the device from the domain doesn’t change where your data is, just how it’s accessed. Keep in mind that I’m not a lawyer – I can only speak from my experience thus far.
  • If device authentication can’t be easily dispelled. Now, the following are just some examples – you might have different limitations.
    • Network Access Control that requires an AD device object or a MAC-address. Usually fixed by implementing 802.1x for WiFi/Ethernet on a user level.
    • Network Policy Server that verifies your devices. Verify your users instead or even better yet, move away from a product, that Microsoft clearly has no interest in developing any further. (I’m also quite convinced that this KB5014754 will break NPS indefinitely).
    • Applications are a big factor, if they require device authentication. I’ve only ever seen this a handful of times, where the machine’s AD identity is required to activate a license that is bound to it. Usually in health care or manufacturing. Ask your vendor for a more modern approach.

Entra Join’s octagon

As I mentioned earlier, there are eight areas to take care of, hence the name. The following is a brief summary of what is involved and what you need to be aware of. Keep in mind that your company may have different requirements, that’s up to you. This is meant as a guide that can be applied to any company, not specific needs. All eight have one practical advice in common: test them on yourself with an Entra joined device – I highly recommend doing it using WHfB and Cloud Kerberos Trust!4

Network

While other topics may run concurrently after this one, this one belongs in the “prerequisite” category. About 80% of Entra Join troubleshooting is network related. Now, Microsoft does provide an official list, but as I found out the hard way, it is incomplete in more than one place.

  • Get your network team involved, regardless if you like them or not (truth be told, especially if you already think you have issues using other cloud services)
  • Run the script and present the merged file to the networking team so they know what they might have to fix. The blog also provides guidance on certain issues.
  • If you still can’t get things working, especially for your test client, make a fresh installation and try to set it up outside your corporate network.

Applications

This is the probably the most important topic. If you’re not equipped or staffed for this kind of maneuver I highly recommend getting external help. Here’s what you/they need to do:

  • Inventory your applications, this includes web applications.
  • Categorize your applications, starting with your LOB applications. These are usually <10, even in really large organizations.
  • Find out which ones require some form of authentication and which ones are used (Kerberos, SAML2, NTLM…).
  • Test your LOB applications, extend testing where necessary.

Group Policies aka GPOs

This may be shocking, but the Settings Catalog in Intune has you covered for the most part. It still surprises me that customers think Intune is what it was four (or more) years ago. You do need to take care of your GPPs, as there is no direct replacement for those. I am not going to rewrite what other people have already done. So please read James’ blog or jump ahead, toss what you have and use his Open Intune Baseline. You’re testing on a fresh device anyway – right?

File Shares

As mentioned earlier, these will keep working out of the box. Even if you don’t use WHFB+CKT, but a username and password5. So the only tricky bit is how you get the mapped network drives to the user. I won’t rehash the great posts below. However, I will note that I have a version of Rudy’s ADMX that doesn’t require the windows.admx import right here. Keep in mind that the best user experience is usually achieved by migrating to OneDrive for Business and SharePoint Online document libraries, although this varies greatly by use case.

Printers

This is almost the same solution as file sharing. Now that Microsoft has raised the limits on most Universal Print licenses so high that you can print until the rainforest dries up, you might want to take another look at it. It also works well with existing print solutions, print servers, and some new printers have direct support for it. Universal Print will also allow the (imho) best UX, because users can simply use the “add printer” function. Mind you, this is a topic completely outside of Intune or Entra. It makes distributing and installing printer drivers much easier though.

Certificates

Certificates have become so important that they’re literally used everywhere. You will want a solution for issuing user and/or computer certificates. Again, you can keep your current Public Key Infrastructure or – especially if you never had the need for an on-premises one – look at CloudPKI.

  • Use your current PKI and connect it to the cloud using SCEP or PKCS (the latter is highly recommended!).
  • CloudPKI does come at a cost, and at around $24 per year per user it’s not cheap. However, for that price you can set up the most secure PKI in 5 minutes you’ve ever had (including it running on a HSM!).

Remote Support

This is usually the topic that quickly divides endpoint administrators. Yes, you will need to relearn and expand your knowledge of certain things. Yes, you will need to prepare yourself for the features that may not work between a hybrid connected and an Entra connected device. Rather than delve into what works and what doesn’t, here are a few recommendations to think about first.

  • Use “new” tools. For example, Remote PowerShell using SSH to connect to servers. This is a general recommendation, by the way; you can use it right now. Even with Azure Arc enabled machines.
  • “But what about my servers,” I hear you say. Yes, they still require a different method because you really should not synchronize your local administrative users with Entra ID. There is also no “run as” for AD-only users. But RDP works as usual. So does any tool that allows you to remotely authenticate against the server.
  • Remote Help: Zero Trust means exactly what it says on the tin. You don’t trust, you verify. No unattended access until the user agrees (if you want something like that). Again, I realize there are exceptions like kiosk devices, but don’t just focus on your edge cases. Also, wouldn’t you rather have one tool for multiple operating systems like iOS and macOS?
  • Or, again, don’t do any of this. You’ll find that many of the current consoles will continue to work if you use the correct account and setup (Cloud Kerberos Trust, for example).
  • Make a list of the tools your helpdesk needs – I find this usually helps a lot to keep track. Below is an example to give you an idea. This simple example can of course be improved by adding columns for things like importance, possible replacement tools, cost. Then test accordingly.

Security

Security is a very broad term, and I chose it deliberately. I’m not going to talk about implementing Zero Trust (although Cloud Native does count as part of the Zero Trust workshop) or specific tools. Talk to your security team, this side of the octagon is another stern reminder to break down silos and communicate. Here are some talking points to start with.

  • Are there any security measures in place that would rely on a computer’s Active Directory object? Remember, certificates do not count, we can easily get those.
  • What standards are you following and why is(n’t) it CIS and why aren’t you using their Intune version yet? Please apply whatever framework you’re using accordingly. Many policies don’t make sense in Intune/Entra.
  • What other software do you use that might require an Active Directory infrastructure to work? Usually you should have some idea after evaluating the applications. I have found that sometimes the security department has additional “invisible” things that need to be addressed. Sometimes things are planned, that aren’t fully implemented yet.

Closing notes

You may have noticed that I left out certain topics and gave only a few examples outside of the most obvious. This blog is the essence of the cloud-native device journey, a starting point. It doesn’t and can’t cover the full range of changes that may be needed in your organization. For example: I haven’t talked about replacing OSD. Autopilot and ESP would do what you need (if done right), and you can also use it to enroll devices in other MDM solutions like WorkspaceONE, Ivanti Neurons, or the like. However, you, dear reader, may have a very valid use case for OSD. Another example would be compliance, because I can never know what ISO or other standard you need to comply with.
Please don’t take what I’ve said here as a bible – but do look into this asap. As always:

Think.
Research.
Plan.
Act.
And throughout all of it: Communicate

Footnotes

  1. This is not entirely true, hence the brackets. Yes, you have two systems now, but only one needs infrastructure maintenance. So it comes down to configuring both, which is less important than you think. How many times do you really need to configure a GPO? ↩︎
  2. I should add here that this is only relevant if the plan is to keep this knowledge in-house. More and more companies are moving from “infrastructure administrator” to “service administrator”. By their very nature, these are mostly standardized so that they can be operated by a managed service provider. ↩︎
  3. See footnote 5. ↩︎
  4. See footnote 5. ↩︎
  5. That’s because logging in with username and password allows authentication to any DC – using WHfB + CKT you get the same, but you’re also already authenticated against Entra ID, making it a one-stop shop for SSO. The assumption here is of course that you have an “All cloud apps must use multifactor authentication (MFA)” conditional access rule. Just using username and password, would lead to the PRT not having an MFA claim and that would mean the user has to authenticate at least once using an MFA method (this could be done in a browser, teams, any office tool or company portal). ↩︎