On Prem Fileshare Access With Azure Joined Device, Windows Hello For Business and Cloud Trust

Question

On Prem Fileshare Access With Azure Joined Device, Windows Hello For Business and Cloud Trust

Philipp Naether 5

Hello,

I have a Azure AD joined device with cloud trust and therefor Windows Hello for Business enabled.
I am trying to access a on prem fileshare. When logged in via PIN, authentication does not work - I get prompt to enter the PIN all the time. If I log into the machine with password, authentication to the on prem resources work.

Looking into the KRB5 traffic with wireshark, I get a KRB error "kdc_err_client_name_mismatch" back from the DC when using PIN. Unfortunately, I don't really know what to do with this error.

COUMET Charles 51 Reputation points

2024-08-21T12:31:10.2433333+00:00

Hello @Philipp Naether , did you find a solution for your problem ? I got the same
Philipp Naether 5 Reputation points

2024-08-21T13:51:07.9+00:00

Hi @COUMET Charles , no, unfortunately I did not get any further on this issue. I have a pending support request at our licensing partner but did not receive any answer yet.

2 answers

Your answer

COUMET Charles 51 Reputation points

2024-08-21T12:31:10.2433333+00:00

Hello @Philipp Naether , did you find a solution for your problem ? I got the same
Philipp Naether 5 Reputation points

2024-08-21T13:51:07.9+00:00

Hi @COUMET Charles , no, unfortunately I did not get any further on this issue. I have a pending support request at our licensing partner but did not receive any answer yet.

Answer 1

William Nieto 545

It seems you’re encountering an issue with Windows Hello for Business on your Azure AD-joined device. Let’s troubleshoot this step by step:

Windows Hello for Business known deployment issues

Check Domain Trust Relationship: Ensure that there is a proper trust relationship established between the on-premises Active Directory (AD) and Azure AD.

Verify Hybrid AD Join Settings: Confirm that your device is correctly configured for hybrid AD join. This involves connecting to both on-premises AD and Azure AD.

Update Azure AD Connect: Make sure you’re running the latest version of Azure AD Connect. Keeping it up to date can resolve compatibility issues.

Check Certificate Configuration: Verify that the certificates used for Windows Hello for Business are correctly configured. Ensure that the device has the necessary certificates.

Review Windows Hello for Business Policy: Check the Windows Hello for Business policy settings to ensure they align with your requirements.

Check Event Viewer Logs: Examine the Event Viewer logs for any relevant errors or warnings related to Windows Hello for Business.

Restart Devices and Services: Sometimes a simple restart can resolve issues. Restart your device and relevant services (such as Azure AD Connect).

Regarding the KRB error “kdc_err_client_name_mismatch”:

Check DNS Configuration: Ensure that your device’s DNS configuration is correct. It should be able to resolve both the on-premises domain and Azure AD domain names.

Verify SPN (Service Principal Name) Configuration: Confirm that the SPNs associated with your device are correctly set up. SPNs are used for Kerberos authentication.

By following these steps, you should be able to identify and resolve the issue with accessing on-premises file shares using Windows Hello for Business.

If this answer solves your issue, please vote for it so other community members know that this is a quality answer.

Philipp Naether 5 Reputation points

2024-06-04T15:59:26.0966667+00:00
Hi William,

thanks for your input.

Check Domain Trust Relationship:

I assume there is no problem in the domain trust because on-prem AD and Azure AD are the same domain anyway.

Verify Hybrid AD Join Settings:

We are not using Hybrid AD Join.

Update Azure AD Connect:

We are running the latest version 2.3.8.0.

Check Certificate Configuration:

As far as I can say we do not use key or certificate trust. We want to use Kerberos cloud trust.

Review Windows Hello for Business Policy:

Policy settings on the device are set locally. For example "Use cloud trust for on prem authentication" policy.

Check Event Viewer Logs:

No errors when trying to access the share/get the SPN kerberos ticket. Checking Event Viewer > Applications and Service Logs\Microsoft\Windows\User Device Registration\Admin Log everything looks good.

Restart Devices and Services:

Multiple restarts were performed over time.

Check DNS Configuration:

Checking DNS via nltest /dsgetdc:my.domain.de results in correct resolution of the domain and DC.

Verify SPN (Service Principal Name) Configuration:

SPNs are set up correctly imho. Because when using password instead of PIN access and kerberos auth works fine.

Following the wireshark trace trying to get a ticket from the cifs-SPN using "klist get" authenticated with PIN:

DC receives AS-REQ message from client

DC answers with KDC_ERR_CLIENT_NAME_MISMATCH

checking the content of the TCP AS-REQ package with PIN auth is different in this parts:

padata 3 items:

PA-DATA pA-PK-AS-REQ

PA-DATA pA-PK-OCSP-RESPONSE

PA-DATA pA-PAC-REQUEST

req-body, etype: 8 items

ENCTYPE: eTYPE-DES-EDE3-CBC

ENCTYPE: eTYPE-RC2-CBC

ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96

ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96

ENCTYPE: eTYPE-DES-CBC-MD5

ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5

ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56

ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP

content from the AS-REQ package with Password:

padata: 2 items

PA-DATA pA-ENC-TIMESTAMP

PA-DATA pA-PAC-REQUEST

req-body 6 items

ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)

ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)

ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD (-133)

ENCTYPE: eTYPE-ARCFOUR-MD4 (-128)

ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56 (24)

ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)

So there is a difference in the used encryption. Could it be, the DC does not know what to do with the PIN encrypted message? How can this be further validated?

To make it clear what works and what not:

I am booting the Entra joined device.

I am logging in with my UPN and WHfB PIN.

The device has line of sight to the DC via Zero Trust Network Access.

The device received the krbtgt/KERBEROS.MICROSOFTONLINE.COM TGT.

Running "klist get krbtgt/MY.DOMAIN.DE" receives the TGT of the on-prem KDC.

Running "klist get cifs/fileserver.MY.DOMAIN.DE" results in LSA-error: 0x8009033d and klist-error 0xc00002f9/-1073741063 and the KDC_ERR_CLIENT_NAME_MISMATCH appears in the network trace.

I am locking the device via WIN+L.

I am logging in again, but this time using password method.

Running "klist get cifs/fileserver.MY.DOMAIN.DE" again now receives the Kerberos ticket for the fileserver.

I am able to access the fileshare without any prompt.

Answer 2

Philipp Naether 5

@COUMET Charles
I found what the issue was. The user object I was testing with was member of Builtin/Administrators and Users/Domain-Administrators. Stupid mistake by me...
I removed the user from the groups and reset its attribute "adminCount" to not-set, did a full sync with ADConnect and voila, on-prem SSO with PIN login now works. Admin accounts are prevented from changes from the cloud, but the Cloud needs to write back the KeyCredentialLink attribute. I assume this mismatch caused the "kdc_err_client_name_mismatch" in the network trace.

COUMET Charles 51 Reputation points

2024-10-02T08:16:35.8233333+00:00

Hello Philipp,

Thank you for your message. I found a solution yesterday. In my case, the problem was caused by the presence of an RODC in the infrastructure. After shutting it down, the issue was resolved. I'm not sure why exactly, but it works! :)
Philipp Naether 5 Reputation points

2024-10-02T10:16:55.29+00:00

@COUMET Charles

If you had the same KDC error in the Kerberos network stack, then it is probably a similar issue regarding the user attribute not being written back to the AD due to presence of a read only DC.

Share via

On Prem Fileshare Access With Azure Joined Device, Windows Hello For Business and Cloud Trust

2 answers

Your answer