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 multiple parts.
- 1: Do you need HAADJ?
- 2: Why do you want to go Hybrid?.
- 3: How does SSO work for your good old file server?.
- 4: What about stuff that doesn’t work with AADJ?
- 5: Could we also map Drive letters to our file servers?
1. Do you need HAADJ?
This week we were visiting a new customer with still some on-premises 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 could 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 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 forgetting 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 were talking for some time, we knew in which phase of transforming into 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 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
- 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) 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 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
When we installed Azure Ad Connect, it will make sure the on-premises local active directory user’s password hash is the same as your Azure Ad user. Windows also know 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-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 are mounting a drive letter or trying to connect to an unc path on a file server, Windows would request 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 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 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!
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!
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. 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. Mapping some drive letters to our AADJ devices
Now we know we could benefit from the SSO, we still need to ask the question If we could map some Drive letters to our on-premises files shares. And the answer is: Yes, of course, we can!!! I removed these parts in this blog and created an additional separate blog for it. Go check it out here!
But please note when you want to mount some drive letters and make use of the SSO you got 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.
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-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 is the default and HAADJ is just pure evil!
P.S: A good friend of mine (Jasper Bernaers) also created a blog (sorry in dutch) to show you the options you have when adding devices into Azure AD.
If you are interested in some other blogs of mine, here you go!