Since we can use Kerberos on Azure AD Joined Devices to access onpremises resources without typing the password, there are no more good reasons to join the endpoints to the good old Domain. But to go for this pretty nice design, there is a need for an Enterprise CA with a proper CRL publishing, to issue some certificates for the onprem Domain Controllers. Without this certificates, there will be no Kerberos Tickets issued to the endpoints when they use Windows Hello for Business. This configuration of Windows Hello for Business, was called “Windows Hello for Business Hybrid Key Trust” (you can find many Blogs regarding this topic out there).
This worked pretty well, but there was an issue when people cconfigured WHfB during Autopilot, because there is an Azure AD Connect Sync to be waiting for, to get some Attributes on the User Account set, which then makes it possible to get the Kerberos Ticket.
To work around this, we mostly brand 2 Registry Keys during Autopilot in the Default User Registry (with PSADT usually), to hide the Windows Hello for Business Wizard without disabling it through Intune:
‘HKCU\SOFTWARE\Policies\Microsoft\PassportForWork’ -Name ‘Enabled’ -Value 1 -Type DWord
‘HKCU\SOFTWARE\Policies\Microsoft\PassportForWork’ -Name ‘DisablePostLogonProvisioning’ -Value 1 -Type DWord
Hello for Business Hybrid Cloud Trust
But now we have a very interesting announcement, called “Hello for Business Hybrid Cloud Trust” (currently in previw). This new WHfB Method, uses an onprem Computeraccount, created for exactly the same purpose, to get some Kerberos Tickets out to the devices. The two main advantages of this method, compared to the Hybrid Key Trust Model are:
- No more Enterprise CA Infrastructure needed
- Because of the used Kerberos Delegation, there is no need to wait for Azure AD Connect sync anymore
how cool is that???
How to configure
There are a few prerequisites needed to get this running, all documentd here, most important:
- a couple lines Powershell code to deploy Azure AD Kerberos
- an Intune CSP Setting
- Full patched Win10 / 11 and Server 2016 on Domain Controller
Installing Azure AD Kerberos
based on this article, you install the required PowerShell Modules, then run the configuration script with your required values on one of your onprem servers:
# First, ensure TLS 1.2 for PowerShell gallery access. [Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
# Install the Azure AD Kerberos PowerShell Module.
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = “intra.domain.com”
# Enter a UPN of an Azure Active Directory global administrator
$userPrincipalName = “admin@domain.ch”
# Enter a domain administrator username and password.
$domainCred = Get-Credential
# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Azure AD.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred
Result:
Intune Config
Next we have to deploy the required Intune Settings. In my Lab I will configure Hello for Business and the Cloud Trust policy only (on your tenant there will be probably some more settings for sure).
and then as a custom Windows Configuration Profile, the Hybrid Cloud Trust CSP with your Tenant ID in it:
./Device/Vendor/MSFT/PassportForWork/xxxxxxxx-yyyy-uuuu-zzzz-516107738775/Policies/UseCloudTrustForOnPremAuth (dont forget to replace the Tenant ID)
Summary
If all went well, you can now layback and watch your devices going through Autopilot, then directly to the Hello for Business Wizard and then finally using their first Kerberos Tickets to access Fileshares or other legacy stuff.
This is a game changer!
Dave Wenger 