This is now the default recomendation for any environment where certificate issuance is not needed.
The process we are outlining below will be for full AAD joined devices, if you are utilizing HAAD (Hybrid join), you can deploy this method via group policy for step 2.
Do note that for HAAD there is an added check before provisioning to verify DC connectivity.
- Windows 10 21H2 or Windows 11
- MFA - Any provider
- Windows Server 2016 or later DC’s
- Configuring Azure AD Kerberos
a. Install required powershell module
b. Create the Kerberos object
c. Set Kerberos connection
- Configure Intune Policy
*NOTE – We will use configuration policies here so they are all in one spot, you may read documentation that WHB can be set under device enrollment and this is true, they achieve the same end result, but it puts the config in two different places.
a. Create a Windows Configuration Policy for Windows Hello for Business configuration.
b. Create a configuration profile for cloud trust setup
a. Target test group
b. Test devices via force sync from client
*NOTE - Intune tries to notify devices of policy updates within 5 minutes of publishing, but if there is a delay or issue for any reason it may mean you have to wait 24 hours for the device to check-in, this way we force that update on the client.
c. Verify status via logs
- From an elevated powershell prompt execute:
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
Accept the prompt for untrusted repository ‘PSGallery’ to complete installation.
- After installation we will create the kerberos object utilizing this command:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 # Specify the on-premises Active Directory domain. A new Azure AD # Kerberos Server object will be created in this Active Directory domain. $domain = "LostInCloud.com" # Enter a UPN of an Azure Active Directory global administrator $userPrincipalName = "administrator@LostInCloud.onmicrosoft.com" # 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
You will need to replace the values for $domain and $userPrincipalName with the correct details for your environment.
The above script is assuming that we are utilizing a form of modern auth. If you are not using modern auth refer to this Microsoft documentation for other example scripts.
We will define a user group to target for our example “WHFBCloudTrustUsers”. Both of the required policies will be assigned to this group.
- Begin by creating a new configuration profile Templates > Identity Protection. Give it a fitting name/description and continue.
- Lets move into defining our Hello config. Below is an example of what would be fitting for most environments. These settings are fairly straight forward, The option for Pin recovery should be discussed with your security team and additional config may be needed for other third-party MFA providers.
Something to note here is that enabling “certificates for on-prem resources” will disable cloud trust.
Now we will create another configuration profile this time choosing Templates > Custom. Fill in the name and description as needed and continue
- Create the OMA-URI:
Replace tenant ID with the one that correlates to your environement. This can be found easily at
- Set Data Type: Boolean and Value: True
- Once these policies are defined and assigned to our target group, we will do a force sync on a device to quickly retrieve the policies and test provisioning. A sign out and sign in on the test device should present the user with steps to configure biometrics if applicable, and configure a pin.
If we hop over into event viewer and navigate down to Applications and Services Logs\Microsoft\Windows > User Device Registration we should be presented with the status’s of the pre-req checks for the partial TGT before provisioning begins. This test has 3 states: Yes and No are self explanatory, Not tested is acceptable for devices that are AADJ only as this pre-req check is skipped for them as no line fo sight to the local DC is needed for signin.
We can also verify these checks using ‘dsregcmd /status’. Furthermore, if we execute ‘klist’ we should be able to verify our cached kerberosTGT tickets after provisioning is completed.
Thats all there is to it. Utilizing this method puts your environment in a good place to begin looking at FIDO implementation for the future!