We have a lot of customers who use Windows Hello for Business Azure AD joined Key trust. But now that Windows Hello for Business cloud trust is available (preview), we expect to see a move towards Cloud Trust, maybe this could also be interesting for your setup?
Key trust is rather complicated because you need PKI infrastructure and the solution also rely on Azure AD connect synchronization, Cloud trust on the other hand is so much simpler.
And with devices only joined to Azure AD it gets even more complicated.
But let us have a look at why Cloud Trust is such a good idea.
In this example we use an Azure AD joined only Windows 10 device, with Windows Hello for Business configured for PIN login.
On a device not setup with Cloud Trust or Key Trust, we try to get access to a SMB share, where the user has access.
Because we have not setup Cloud Trust or Key Trust, we will be prompted for credentials.
If we try the same but this time from a client with Cloud Trust enabled, we will get instant access as desired.
Windows Hello for Business cloud trust will give us access to a simplified solution that will allow password less SSO using Windows Hello for Business. The solution also support migration from Key trust to cloud trust and uses Kerberos as part of the solution.
Cloud trust is, as already stated, so much easier to deploy because it does not require your own PKI infrastructure and does not rely on synchronization.
So let us test the setup needed.
Prerequisites
- Multi-factor Authentication
- Fully patched Windows 10 version 21H2 or fully patched Windows 11
- Fully patched Windows Server 2016 or later Domain Controllers
- Azure AD Kerberos PowerShell module
- Device management
You can find more information I the documentation Link
Azure AD Kerberos
We then need to setup a Kerberos server object in AD.
This is done with the following PowerShell commands (when executed from a domain joined device with domain administrator privileges).
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12Install-Module -Name AzureADHybridAuthenticationManagementSet-AzureADKerberosServer -Domain "yourdomain.local" -UserPrincipalName "admin@yourtenant..com"
This will create the following object in the Domain Controllers OU.
It will appear as a Read Only Domain Controller (RODC) object, but it is not associated with a physical server.
It will be used to generate TGTs for Active Directory.
You can find more information regarding this part in the following Link.
Configure Using Intune
Then we need to configure our clients, in this example we will create a policy enabling Windows Hello for Business (disabled by default in this tenant) and a policy for Cloud Trust itself.
Hello for Business will be enabled with the following configuration from the Settings catalog.
Cloud Trust can right now only be enabled using an OMA-URI setting, so let us create custom profile.
We will name it Cloud Trust in this example.
Select Add to enter the setting.
And then enter the following settings:
Name: “Windows Hello for Business cloud trust” you choose
OMA-URI: ./Device/Vendor/MSFT/PassportForWork/tenant ID/Policies/UseCloudTrustForOnPremAuth
Data type: Boolean
Value: True
Tenant ID must be replaced with the tenant ID for your Azure AD tenant
Deploy both profiles to the desired targets.
These settings can also be deployed using GPO 😊
User PIN setup
As soon as our policies are in place the user will be required to setup PIN.
Next step will be the MFA step – remember that this is a requirement.
After successfully MFA, the user can enter the desired PIN.
And we are all set.
Sign-in
Once PIN has been setup, we can use it for sign-in. But note that on Hybrid Azure AD joined devices, first use of the PIN requires line of sight to domain controller. But in this test the device is Azure AD joined only.
After sign-in we can access the share as we already seen (line of sight to server needed).
Log
We can see the status in Event viewer Applications and Services Logs – Microsoft – Windows – User Device Registration as shown here:
Testing on Hyper-V
If you test on Hyper-V, remember to not use an Enhanced session when entering PIN.
Key rotation
The Azure AD Kerberos Server encryption krbtgt keys should be rotated on a regular basis, and can be done with the following PowerShell command (when executed from a domain joined device with domain administrator privileges):
Set-AzureADKerberosServer -Domain "yourdomain.local" -UserPrincipalName "admin@yourtenant.com" -RotateServerKey
Azure AD Kerberos Server Object
We can view the Azure AD Kerberos Server by PowerShell using the following command:
Get-AzureADKerberosServer -Domain "yourdomain.local" -UserPrincipalName "admin@yourtenant.com"
And finally, we can remove it as well using the following PowerShell command:
Remove-AzureADKerberosServer -Domain "yourdomain.local" -UserPrincipalName "admin@yourtenant.com"
Happy testing 😊
