This blog will hopefully show you why sometimes configuring devices for Azure ad Hybrid is not always the best choice. Also, I will show you how you could map drive letters with Intune instead of PowerShell
I will divide this blog into 6 parts.
1. Azure Ad Hybrid?
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 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 KFMto 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.
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 azure ad hybrid. We advised the customer to skip the hybrid part, why you might ask?
2. How the SSO to your Onpremise AD works
Summing it up: When using Azure Ad Connect you can still access your on-premise file shares from an Azure Ad joined device without credential prompts.
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
Let’s see what happens when a user signs in to his/her Azure AD joined Windows 10 device:
Azure Ad will send the name of the on-premise domain back to the device among with the PRT. 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 open an unc path from the file server, Windows would request authentication (Kerberos). The domain information and the user’s credentials (hash) are sent to the Domain controller which is detected at logon to verify 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 check it yourself, open a CMD before trying to connect to the on-premise file server and list those Kerberos tickets
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.
I guess this picture below just explains it
Sometimes you can even use Windows Hello and still have SSO. So you need to try SSO first without Windows Hello, if it’s working enable it and test again. You could end up with some notification, asking for credentials.
But beware 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.
3. 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
-They already had a Remote desktop cluster. So, for now, we could publish the legacy app as a remote app
-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 or migrate them to a cloud printer Solution.
-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)
4. Drive Letter Mappings
But how are we going to map some old-fashioned drive letters without 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.
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 of and logging on again, the drive mappings popped up and where ready for use.
5. UPDATES 07-05-2020
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. 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
6. 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 like 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
If you don’t block PowerShell, it’s a lot easier of course. Just create a PowerSHell script which 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 servername and sharename to the value you have seen in the registry key
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 onpremise domain even when using windows hello.
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.
It’s great to see you can also map drive letters without the need for PowerShell. I guess there are no reasons left to block Powershell for end users.
It’s no discussion the data will need to be migrated soon, but Rome was not built in one day.