(154) Microsoft Intune - Windows Hello for Business (WhfB) Kerberos Issue

Had this ongoing issue a few months ago with a customer when both devices have the 'Cloud Kerberos Trust' and 'Trusted Certificates' which allowed PIN to be setup on enrolment but failed when trying to access on-premises file share with "Cannot connect to domain credential" when using face recognition or PIN.

Logs that were gathered throughout the whole process:

Entra joined:

Windows Hello for Business provisioning will be launched.
Device is AAD joined ( AADJ or DJ++ ): Yes
User has logged on with AAD credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: No
Machine is governed by none policy.
Cloud trust for on premise auth policy is enabled: Yes
User account has Cloud TGT: Not Tested

Entra Hybrid joined:

Windows Hello for Business provisioning will be launched.
Device is AAD joined ( AADJ or DJ++ ): Yes
User has logged on with AAD credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: No
Machine is governed by none policy.
Cloud trust for on premise auth policy is enabled: Yes
User account has Cloud TGT: Yes

SMBclient security event, a lot of events with id 31001 were listed.

Log Name: Microsoft-Windows-SmbClient/Security
Source: Microsoft-Windows-SMBClient
Event ID: 31001
Task Category: None
Level: Error
Keywords: (128)
User: SYSTEM
Description:
Smb2DiagReasonISC.
Error: The system cannot contact a domain controller to service the authentication request. Please try again later.
Security status: 0xC0000388
User name:
Logon ID: 0x85472

After further digging, by running: nltest /dsgetdc:domain.local, which showed as expected.

DC: \\DC.domain.local
Address: \\10.XX.XX.XX
Dom Guid: Xd4cdbbX-1e00-495X-XXXX-0225587246eX
Dom Name: domain.local
Forest Name: domainlocal
Dc Site Name: SITENAME
Our Site Name: SITENAME
Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9 DS_10 KEYLIST
The command completed successfully

By running klist cloud_debug, I was provided with the output which looks normal

Current LogonId is 0:0x11ed51
Cloud Kerberos Debug info:
Cloud Kerberos enabled by policy: 0
AS_REP callback received: 1
AS_REP callback used: 1
Cloud Referral TGT present in cache: 0
SPN oracle configured: 0
KDC proxy present in cache: 0
Public Key Credential Present: 0
Password-derived Keys Present: 1
Plaintext Password Present: 0
AS_REP Credential Type: 0
Cloud Primary (Hybrid logon) TGT available: 1

After discovery, that the AES256 key type must be enabled in order to use it.

According to the documentation, this configuration needs to be set on the Domain Controller. The following change was updated in Active Directory (AD) for the following user, even after the making this change it was inconsistent.

Solution

Microsoft have described what this Kerberos negative caching is, where the default caching time is 10 minutes. By waiting for 10 minutes or executed KLIST PURGE_BIND in an evaluated command prompt, I would be able to connect to the on-premises file share with Windows Hello for Business (WfHB) PIN.

To ensure FarKdctimeout is set to cache timeout in 1 minute instead of 10 minutes, create the following win32 app:

Install.ps1 

if((Test-Path -LiteralPath "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters") -ne $true) { New-Item "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" -force -ea SilentlyContinue };
New-ItemProperty -LiteralPath 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters' -Name 'CloudKerberosTicketRetrievalEnabled' -Value 1 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters' -Name 'FarKdcTimeout' -Value 1 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters' -Name 'MaxPacketSize' -Value 1 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters' -Name 'MaxTokenSize' -Value 65535 -PropertyType DWord -Force -ea SilentlyContinue;

Detect.ps1

$Path = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters"
$Name = "FarKdcTimeout"
$Type = "DWORD"
$Value = "1"

Try {
$Registry = Get-ItemProperty -Path $Path -Name $Name -ErrorAction Stop | Select-Object -ExpandProperty $Name
If ($Registry -eq $Value){
Write-Output "Detected"
Exit 0
}

Exit 1
}

Catch {

After the win32 app has been deployed successfully, it will apply the following on the device.

After the win32 app has been successfully installed on the device, a test of accessing the on-premises file shares with Whfb PIN worked. By ensuring this worked for further Entra joined or Hybrid Entra joined devices, a wipe was performed on both devices and confirmed access to on-premises file shares using WhfB PINs.