Deliver us from Hybrid

Deliver us from Hybrid

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.

*Part 1: Do you need HAADJ?

*Part 2: Why do you want to go Hybrid?.

*Part 3: How does SSO works to your good old file server?.

*Part 4: What about stuff that doesn’t work with AADJ?

*Part 5: But what about the network Drive letters?

*Part 6: Solving the Red Cross and Disconnection Warnings

*Part 7: Changing the Drive Letter’s Label

*Part 8. Sharepoint Drive Mapping

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.

*source: Migration paths to Microsoft 365: Devices before data?? – ITProMentor

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!

Access on-premises resources from an Azure AD-joined device in Microsoft 365 Business – Microsoft 365 Business | Microsoft Docs

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.

https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base

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
like Securew2!

2. LAPS

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.

The LAPS: Reloaded / Revolutions

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-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:

Download the ADMX files!

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.

1: RestoreConnection

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

Value: <disabled/>

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

(UPDATE 15-06-2021)

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:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

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.

https://call4cloud.nl/2020/03/how-to-deploy-hkcu-changes-while-blocking-powershell/

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

Result:

 

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!

Conclusions:

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.

6 thoughts on “Deliver us from Hybrid

  1. 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.

    1. 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”

  2. 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?

    1. 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.

  3. 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…..

    1. 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 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  14  =  24