Windows Hello for Business Cloud Trust Kerberos Authentication Issue

-

There are many options available for deploying Windows Hello for Business, ensuring compatibility with various organizational infrastructures. For cloud-only organizations, the implementation is simple and works straight out of the box. However, for Hybrid based models, where most organizations operate, there are can be some additional configurations requirements. Out of the available trust types - Cloud Kerberos, Key or certificate, Cloud Kerberos is the easiest and also the Microsoft recommended trust type. It allows users to authenticate to Active Directory by requesting a TGT from Microsoft Entra ID, using Microsoft Entra Kerberos. This way the on-premises domain controllers remains responsible for Kerberos service tickets and authorization. Which brings me to the reason behind writing this blog post. I recently assisted a customer with an issue involving Windows Hello for Business authentication while accessing on-premises resources like file shares. The end user experience was something like the one below -


This happened when a user used a PIN or their biometrics to authenticate. If they provided their username and password or locked the screen and authenticated using their password, then the authentication would simply go through automatically without having to deal with any additional prompts. The devices are Entra ID joined and interestingly everything just worked in the past.

There can be a number of reasons behind this behavior. Here is how I went about troubleshooting this -

1. I ran the dsregcmd /status command to get a status of SSO and it seemed fine.


2. I then ran klist cloud_debug to check for the configuration for Cloud Primary Hybrid logon TGT and it was fine as well.


3. Next thing I checked was for event id 358 under Microsoft-Windows-User Device Registration/Admin to see if 'Cloud Trust for on premises auth policy' was showing enabled or not, and it did.


4. However, when I ran klist to check if there were any tickets issued, I didn't find any.


5. Even though the Cloud Trust for on prem was showing enabled, I went ahead and checked in Intune for the cloud authentication policy to cover all bases.


6. Since the configuration was still in a pilot phase, I thought I will check whether the accounts being used for testing were elevated or in a protected group in Active Directory or not. They were all standard accounts (Non administrative permissions) and were not in a protected group. This can be easily verified by looking at the adminCount security attribute. It should be showing as not set. 


This is because Domain administrators are automatically excluded from Cloud Kerberos trust.


7. The next thing I checked was for the presence and configuration of the krbtgt_AzureAD account. This is where things started to unravel. The account simply didn't exist anywhere in the domain. The krbtgt_AzureAD account is used to establish trust between an on-premises Active Directory and Azure AD, allowing users to access resources using their Azure AD credentials. So you can see why it will be super important if the account went missing. To validate further, I ran the following command to verify for the AzureADKerberos account and as expected, there were was an error -

$domain = $env:USERDNSDOMAIN
$userPrincipalName = "administrator@contoso.onmicrosoft.com"
$domainCred = Get-Credential
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred


The Fix..

It was clear by now that the Kerberos Server object and its configuration got messed up and needed to be re-created. Here are the commands that I ran to remove the existing object.

Remove-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

Once removed, I re-created it by running the following command -

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred


That's it. After some time (device can be rebooted as well to speed things up), tickets started to issue and on-premises resources were accessible again without any additional prompts using Windows Hello PIN and biometrics.


Hope my experience saves you some time. Thank you for reading! Until next time..

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){              ...
Read more

Fixing Tamper Protection Blob Error 65000 using Microsoft Intune

-
Image
I recently encountered an issue with enabling Tamper protection as part of the implementation of Defender for Endpoint in one of customer's tenant and considering how unusual the behavior was and how I didn't encounter this before, I decide to blog my experience. If you have been battling with the same issue, then this blog may just help you. There are multiple ways to enable Tamper protection as part of MDE. One can enable at a tenant level using Defender portal or do it using Intune. I normally choose the Intune, especially when dealing with endpoints to maintain uniformity with other Defender policies being managed by Intune. However, in this particular instance, the issue started cropping randomly on some endpoints where tamper protection would not enable and throw an error code 65000, as show below. Additionally, the status in Defender will report as Unknown instead of reporting Active or something else like EDR in block mode to suggest that Defender Antimalware is running...
Read more

Prevent users from running certain programs or applications on Windows endpoints using Intune

-
Image
  When it comes to blocking or preventing users from running an application on Windows devices, one normally uses App locker policy, Windows Defender Application Control and not so new but pretty useful method called Defender Vulnerability management within Microsoft 365 Defender Portal. A recent question on the Tech Community Microsoft forum prompted me to look for all possible alternatives. I started reminiscing over the legacy GPO policies and that is when I stumbled upon the policy  Don’t run specified Windows applications  located under User Administrative Templates - The policy setting does come with its own caveat - " This policy setting only prevents users from running programs that are started by the File Explorer process. It does not prevent users from running programs, such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting does not prevent them from st...
Read more