This blog will hopefully show you why configuring devices for Hybrid Azure Ad Join (HAADJ) is sometimes not the best choice. I will show you all the information you need to make a good choice!
I will also show you how to map drive letters with Intune instead of PowerShell. Remember to read the conclusion!
1. Do you need HAADJ?
Some months ago, we visited a new customer with some on-premises software and a lot of company data. They asked our opinion on what we thought would be the best way to transform into a modern workplace.
The first thing that probably will come to mind is to go hybrid!!
Of course, you could configure your devices to use an Autopilot white-glove Hybrid Azure Ad join, but what if you don’t want to know the cons of this kind of deployment? I guess the main disadvantage of using hybrid is you still need a line of sight to your on-premises domain controller when enrolling the devices with Autopilot. Besides that horror full line of sight issue, you are also still stuck with some old group policy objects who can really mess up your Intune settings.
For example, when DisablePersonalDirchange is configured, it will cause Onedrive Known Folder Move (KFM) to stop working.
Not to mention the fact that you must deal with all kinds of forgotten settings that were configured by someone else who is probably long gone. You could be tempted to configure the MDM wins over GPO setting. With this setting, you could make sure your Intune policies would win when you have a hybrid setup, but beware: It only works with conflicting policies.
Please beware! It’s NOT a best practice to configure this setting. Why? This setting is not universal and it only applies to the settings from the PolicyCSP. For example, when you have Applocker configured, the MDMWinwsoverGPO isn’t going to do anything because Applocker belongs to the ApplockerCSP. So please don’t use it. A better option would be to prevent conflicts by making sure the devices that don’t need those GPOs aren’t targeted in the first place. You could do so by using security groups, WMI filtering, etc.
And I guess the most important, choosing between Azure Ad Join (AADJ) or HAADJ is like choosing a philosophy on how you design your IT. Once you have chosen HAADJ it could be very difficult to change this strategy over time and move back to AADJ. So think before you act!
After we talked for some time, we knew the company was in the phase of transforming into the modern workplace. It was obvious it would take some time to move all the data to OneDrive/Sharepoint/Teams. When moving to MS365 cloud only, you will need to follow this simple rule.
*source: Migration paths to Microsoft 365: Devices before data?? – ITProMentor
Luckily the customer already decided to implement Azure Ad Connect/ Cloud Sync to sync their identities to Microsoft 365. After syncing your identities to Microsoft 365, you must migrate your devices. (DBF –> Devices Before Files)
As mentioned before, there are some disadvantages to implementing HAADJ. For this case, we advised the customer to skip the hybrid part, why you might ask? Let me tell you why.
2. Why do you want to go Hybrid?
Why would you create a more complex environment than is needed? Creating a fresh new start with no old existing issues is just great! Some examples from our point of view
- The Customer already had a Remote desktop cluster. So, for now, we could publish the leftover legacy apps as Remote apps. Other legacy apps could just be launched from the SMB share!
- All existing thin clients needed to be replaced
- Their own personal documents and desktop could be moved to Onedrive and we can use Known Folder Move
- We can install/push printers from Intune (that also just works with AADJ) or migrate them to a cloud printer Solution. Read this blog if you want to know more about this
https://call4cloud.nl/2021/07/what-about-printer-drivers
- We don’t have any problems with existing or broken GPOs. A lot of people want to pick up all of their old GPOs and move them to the cloud. In my opinion, that’s not the best practice. AADJ is not the same as your on-premises domain! Of course, when you still want to move them over to Intune be my guest!. Just export/import them and click on the wonderful “Migrate” button
- We can ditch the old AV and start using Microsoft Defender for endpoints and maybe use the Defender For Business addon as it is now included in Business Premium!
- Autopilot will work fantastic (normally 😉 ) when using it with AADJ!!! Of course, HAADJ also supports Autopilot but it’s more complex than using Autopilot with AADJ. Deploying a Hybrid Azure Ad Joined device with Autopilot could bite you in the ass because there are so many moving parts and time issues!
- We can use the Windows Update for Business instead of an old (not working) WSUS server.
- We can access the file shares (and web servers) that are not yet migrated to Sharepoint Online with SSO (of course we are going to migrate the existing data to SharePoint when all devices are ready)
3. How SSO to your On-premises AD works
As I mentioned in the last part of section 2, you can get an SSO to your on-premises file server, even while ONLY using AADJ. To fully understand how the SSO works, check out this Microsoft article first!
Summing it up: When using Azure Ad Connect (The most important requirement!) and your user is in the scope you can still access your on-premises file shares from an Azure Ad joined device even when the device is not domain-joined and of course, without credential prompts!
I guess this picture below totally explains it all
Installing Entra Connect will ensure the on-premises local active directory user’s password hash is the same as your Entra ID user. Windows also knows about the domain name because it has also been synced with Entra Connect. Even our RMM tool is showing it!
Let’s see what happens when a user signs in to his/her Azure AD joined Windows 10 device:
When a user logs in, Entra ID will send the name of the on-premises domain (OnPremisesDomainName) back to the device among the PRT (Primary Refresh Token).
With this knowledge, the device will try to find the domain controller for the domain by launching the DCLOCATOR process. This process uses Netbios broadcasts and DNS. So DNS is quite important?
So, when you mount a drive letter or try to connect to an unc path on a file server, Windows requests authentication (Kerberos) to get back a Kerberos ticket.
You can confirm this by opening your event log on your Domain Controller and filtering for 4768 (Kerberos Auth Ticket requested TGT) and 4769 (Kerberos Ticket Requested)
The domain information (which we got at the user logon) and the user’s credentials (hash) are sent to the Key Distribution Center (KDC), also known as your Domain controller. With this information, the KDC starts verifying the user. When the user is verified, you will get the Kerberos ticket-granting-ticket (TGT) or NTLM token depending on the protocol which is supported by the application/resource you are trying to access.
You can also check it out on the client itself! Open a CMD before trying to connect to the on-premises file server, and list those Kerberos tickets by using “Klist”
Now open a share from the file server and request the Kerberos tickets again. You will notice you don’t get prompted for your credentials and you will receive a Kerberos ticket.
You can even use Windows Hello and still have SSO. Please make sure SSO is working first without Windows Hello enabled. If it is, configure the Hello requirements and configure Hello to test the SSO again.
Beware: When you enable Windows Hello without the IIS configuration, you could receive notifications asking for credentials.
Beware that you could also end up getting some weird errors when you are trying to create an ODBC connection.
You have got three options here but option 3 is the option you need to use!
*1: Disable WH4B and only login with your password
*2: Some additional configurations in IIS:
It’s obvious I am not going to recommend option 1, you will need to make sure you have got a Windows 2016 DC and start configuring IIS.
3. Hybrid Cloud Trust
Just skip the first two options and just start configuring Hybrid Cloud Trust!!
Hybrid Cloud Trust Deployment (Windows Hello for Business) – Windows security | Microsoft Docs
4: What about stuff that doesn’t work with AADJ?
Now we have seen we could still get SSO to our on-premises legacy fileservers when our devices are AADJ instead of HAADJ, there is some stuff that isn’t working or not yet available for AADJ devices
Let’s sum some up!
1. Device Authentication
When going full cloud, you could end up having some issues.
One of them would be situations in which you will need to have device authentication implemented.
For example, an NPS for Radius and NPS won’t authenticate with pure Azure AD Devices.
When the device arrives at the CTRL ALT DEL Screen the device will fail to authenticate because it is trying to use the device certificate and the device’s identity to authenticate
with the NPS. Now, because the device is not present in the active directory, NPS can’t authenticate that device, and it will all fail.
Luckily, there is something like Securew2!
Cloud RADIUS – Powered by SecureW2
2. LAPS
For now, the Local Administrator Password Solution (LAPS) is only available when using an on-premises ad or HAADJ. But then again, there are many other solutions out there to get the same results.
Hopefully, Microsoft will read the Twitter vote from Ru Campbell and will start working on a cloud-based LAPS solution!
3. LDAP
First, some background information about LDAP: LDAP (Lightweight Directory Access Protocol) is an open and cross-platform protocol used for directory services authentication. You can compare your old on-premises Active Directory to a database. It organizes all of your users and computers.
The active directory uses protocols such as Kerberos and NTLM for authentication and LDAP to query and modify items in this “database”
So LDAP is designed to work with an Active Directory.. and guess what. Azure Ad isn’t that!
Some old-school legacy applications still use LDAP to look up information, and guess what? Either way, this isn’t going to work.
5. Mapping some drive letters to our AADJ devices
Now that we know we could benefit from the SSO, we still need to ask if we could map some Drive letters to our on-premises file shares. And the answer is yes, of course, we can!!! I removed these parts from this blog and created a separate blog for it. Go check it out here!
https://call4cloud.nl/2021/03/willy-wonka-and-the-drive-letter-factory
But please note when you want to mount some drive letters and want to use SSO to your on-premises file server, please beware that it uses DNS! So don’t use \\fileserver\datashare but the FQDN, so it looks like this \\filserver.contoso.local\datashare.
Conclusions:
If you can replace all existing devices instead of enrolling the existing domain-joined devices into Azure, is there still a need to join the new devices to your on-premises domain? With an Azure Ad Join, you can get SSO to your on-premises domain even when using Windows Hello.
And with that, the user could still access data on the file server on-premises. Do you know what else is cool? You can still use your old legacy apps that can run from the SMB share, and even your old-school printer server is accessible.
Please think twice before you go Azure Ad Hybrid. Isn’t a simple Azure ad-joined device not enough? I love to hear your thoughts. For me, AADJ/ Entra Joined is the default, and HAADJ is just pure evil!
Thanks for this Rudy, can we give the mapped drive a custom name as the AD GPO would call the Label?
This is the only thing I’m missing.
It’s a very good question.. I noticed I didn’t add that part in my blog… I will add it today.. For now you could take a look at
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
And use something like this: reg add “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\##servername#sharename” /f /v “_LabelFromReg” /t REG_SZ /d “NewLabel”
If you do not want to use Powershell you can also rename mapped drives easily with vbScript:
[code]
Set oShell = CreateObject(“Shell.Application”)
oShell.Namespace(“X:”).Self.Name = “Afdeling”
oShell.Namespace(“Y:”).Self.Name = “Groep”
oShell.Namespace(“Z:”).Self.Name = “Projecten”
[/code]
Best regards,
Dave van Lare
Thats also a one of the other good options we have
Hi Rudy, love your opinion regarding AADJ devices.
Me having struggle during user drive mount, because %UserName% variable isn’t resolved. Drive name in Explorer shows “%username%”. By selecting the drive, it tries to load for a long time and stops with error “Connection could not be reestablished”.
Can you reproduce this or help out?
Hi,
Thats indeed correct. We sort of solve it by mapping the root share before it. \\servername\personalfolders$
On each personal folder are of course ntfs permissions so no one else could access other folders. When you combine this with access based enumeration… They will only see their own folder..
Another possibility would be to create bat file which only maps this folder as a drive letter. Place this bat file in a folder and create a powershell script which copies this folder to a trusted location on the device and creates a shortcut to the all users startup folder. So you can be sure each time
the user logs in it will be executed.
You Say – ” Once you have chosen HAADJ it could be very difficult to change this strategy over time and move back to AADJ. So think before you act! ” – Why is this?
Also if someone has decided to move to the cloud (Running full AADJ devices and AAD Identities) but still has on prem apps (Quickbooks Desktop) that require them to use a SMB share – so you set up a workgroup SMB share as a temp fix, instead of building out a Domain and use Azure Connect would you recommend – 1) Make Server DC 2) Create user accounts 3)Install Azure connect 4) Sync those accounts up to existing AAD users 5) Follow this tutorial to map drives and enjoy the rest of my day?
Or just leave as is, Mapped network drives in a workgroup have proven to be a pain. But figured make it as simple as possible as everything else had moved to the cloud…..
Hi, when you want to migrate from haadj to aadj to remove your dc, you will need to migrate (reset) all your devices to enroll them into aadj. So that could be difficult if you have like 1000+ devices?it will cost you some time….. And why should you choose haadj if your plan is to fase out the dc later on? When your devices are already aadj it’s way more easier to ditch your dc, right?
And your second question: You can be right, I get your point/idea… it depends if you have a need for ntfs security or not.. but I still prefer to have a dc, so I can still have some base of security on the smb share instead of open to everyone :).. And with the guest Guest Access Disabled by Default in Windows 10 Fall Creators Update.. i would go for a dc 🙂
Anything wrong with a mixed scenario where you start out with HAADJ devices, then as devices age out and are due to be replaced, begin deploying them as AADJ. Due to certain departments needs for legacy applications I could see us moving most users to to AADJ but others may need to remain Domain joined for the foreseeable future.
Its totally not wrong if you “need” to start with haadj (if there are requirements to do so)
And later on ditching haadj when you have the option to go aadj… what kind of legacy apps are we talking about? Most of them are still accesible with sso from an aadj device
Found this great article from Johan’s recent deployment newsletter. Although please stop saying on premise! 🙁
Hahaha.. Thanx.. and you are totally right!.. I had that discussion some time ago but totally forgot to apply the on-premiseS to this article… Its updated now!
Hey Rudy
We’re currently at the point to decide whether to use HAADJ or AADJ only. My main concerns are
– NPS: Here you already mentioned the use of a cloud RADIUS
– Legacy Applications such as Dynamics NAV and some Document Management System
Regarding the latter: Users login to the Application with their AD credentials. Would this work on an AADJ device? Or the other way around: When would a legacy application prevent moving to AADJ only? You mention when the Application performs “LDAP” lookups but I don’t fully understand. Can’t it just look up the info on the DC’s through the VPN?