This blog will hopefully show you why sometimes configuring devices for Hybrid Azure Ad Join (HAADJ) is not always the best choice. I will show you all the information you need to make a good choice!
Also, I will show you how you could map drive letters with Intune instead of PowerShell. Don’t forget to read the conclusion!
I will divide this blog into 8 parts.
1. Do you need HAADJ?
This week we were visiting a new customer with still some on-premise software and a lot of 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… go hybrid!!
Of course, you can configure your devices to use an Autopilot white-glove Hybrid Azure Ad join but what if you don’t want the cons of this kind of deployment? I guess the main disadvantage of using hybrid is you still need a line of sight to our on-premise domain controller (sometimes) and you are still stuck with some old group policy objects who can really mess up your Intune settings.
For example, DisablePersonalDirchange will cause Onedrive KFM to stop working.
Not forgetting the fact, you must deal with all kinds of forgotten settings that were configured by someone else who is probably long gone? Of course, it’s best practice to configure the MDM wins over GP setting to make sure your Intune policies would win when you have a hybrid setup but beware it only works with conflicting policies.
Please beware! I need to warn you when you want to use the MDMWinsoverGPO setting: This setting is not universal and it only applies to the settings from the PolicyCSP and even then there are exceptions. Please don’t use it, please prevent conflicts by creating 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 were talking for some time, we knew in which phase of transforming to the modern workplace, the company was. 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.
Luckily the customer already decided to implement Azure Ad Connect to sync their identities to Microsoft 365. After your identities are synced to Microsoft 365 you will need to migrate your devices. (DBF –> Devices Before Files)
As said before, there are some disadvantages when you choose to implement 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 legacy app as a remote app. 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
-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
-We don’t have any problems with existing or broken GPO’s
-We can ditch the old AV and start using Microsoft Defender for endpoints.
-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) which 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 Onpremise AD works
Like I mentioned in the last part of section 2, you can get an SSO to your onpremise file server, even while 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-premise 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
When we installed Azure Ad Connect, it will make sure the on-premise local active directory user’s password hash is the same as your Azure Ad user. Windows also knows about the domain name, because it also has been synced with Azure Ad 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, Azure Ad will send the name of the on-premise domain 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 using Netbios broadcasts and DNS.
So when you are mounting a drive letter or trying to connect to an unc path on a file server, Windows would request authentication (Kerberos).
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 Domain controller which was detected at logon and 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-premise 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 the SSO is working configure the Hello requirements and configure Hello to test the SSO again.
Beware, when you have enabled Windows hello without the IIS configuration you could end up with some notifications, asking for credentials.
And also beware of the fact, you could also end up getting some weird errors when you are trying to create an ODBC connection.
You have got 2 options here:
*1 Disable WH4B and only login with your password
*2: Some additional configuration 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.
4: What about stuff that don’t work with AADJ?
Now we have seen we could still get SSO to our on premise legacy fileservers when our device 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 when 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
For now, the Local Administrator Password Solution (LAPS) is only available when using an on-premise 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!
Intune/Azure AD folks,— Ru Campbell (@rucam365) July 24, 2021
What are the legitimate cases where hybrid Azure AD join is *needed* instead of Azure AD join.
Excluding things such as time constraints on planning for GPO migration etc. I'm talking hard tech limitations.
cc: @martin_schmidli @dean_ellerby @ooms_rudy
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-premise active directory to a database. All of your users and computers are organized in it.
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!
There are some old school legacy applications that still use LDAP to lookup information and guess what either, this isn’t going to work.
5. Drive Letter Mappings
Back to the SSO, how are we going to mount drive letters to our on premise file servers when we not yet migrated the data to sharepoint?
Are we going to map some old-fashioned drive letters with the use of PowerShell? I guess everyone has deployed Adminless and Applocker and of course you made sure your Applocker policy will block PowerShell for the regular users. What to do now?
In some older blogs I showed you the possibility to ingest some ADMX templates to configure some additional settings, so why not doing the same for the drive mappings?
The only thing you will need is the drive mapping ADMX file which you will find here:
First, we need to configure the CSP for the admx
OMA-URI: ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/DriveMapping/Policy/DriveMappingAdmx Data Type: String Value: content of the drivemapping.admx file
And of course, a separate CSP for the drive mappings and itself
OMA-URI: ./user/Vendor/MSFT/Policy/Config/DriveMapping~Policy~DriveMapping/Drive_H Data Type: String Value: <enabled/> <data id="Drive_H_RemotePath" value="\\fileserver\fileshare"/>
While waiting for the custom-made policy to apply, look at the registry to check if you already can find the ADMX policy.
As shown above, the admx drive mapping admx is installed without any problems and within a few minutes, the drive mapping itself started showing up.
After logging off and logging on again, the drive mappings popped up and were ready for use.
6. Solving the Red Cross and Disconnection Warnings
Okay , we have our drive mappings, but what about the disconnection warnings and the red crosses? Let’s fix it.
Please make sure you also add this CSP to make sure you don’t get any reconnection warning
OMA URI: ./user/Vendor/MSFT/Policy/Config/DriveMapping~Policy~DriveMapping/ReconnectNetworkDrivesWarning
And to be 100% sure create and deploy a PowerShell script to the devices with this content
New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\NetworkProvider -Name RestoreConnection -PropertyType DWord -Value 0 -Force
2. Solving the Red Cross/Disconnection issue
Sometimes you could end up with this red cross error. It looks like you can’t open the drive letter.
To solve this issue, you need to make sure the Network Drive ProviderFlags is set to 1. You will need to configure this key because the Registry Key ProviderFlags controls the recovery of network shares they use Server Message Block (SMB) version 1 when they are stored in the registry.
REG ADD “HKCU\Network\P” /v “ProviderFlags” /t REG_DWORD /d “1” /f
(change the P to one of the drive letters you are experiencing the issue with)
7. Making the Drive Letter Names more Beautiful
Totally forgot to mention this part. Looking at the drive label names… it doesn’t really look that nice does it?
If you want to specify a nice name to it, we need to open the registry first and browse to:
You will notice, all of your Drive Letters show up here.
I decided to export them first
I opened the export reg file and add the _LabelFromReg with a nice name to each Mountpoint.
When you are blocking PowerShell you can deploy this reg file to your device by using this trick, you could even create proactive remediation to be sure the drive letters are always having a nice description.
If you don’t block PowerShell, it’s a lot easier of course. Just create a PowerShell script that is deployed to the user context
reg add “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\##servername#sharename” /f /v “_LabelFromReg” /t REG_SZ /d “NewLabel”
You will need to change the server name and share name to the value you have seen in the registry key
8. Sharepoint Drive Mapping
I did some tests if it would also work when you want to map a drive letter for a SharePoint site, but unfortunately, it doesn’t (yet?) map the drive letters with the web protocol. Next week a new deep-dive I guess
And here it is!
If you have the possibility to 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-premise domain? With an Azure Ad Join you can get SSO to your on-premise domain even when using Windows Hello.
And with that, the user could still access data on the file server on-premise. 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 is the default!
It’s great to see you can also map drive letters without the need for PowerShell. It’s no discussion the data will need to be migrated soon, but Rome was not built in one day.