Wrong signature when fallback from Kerberos to NTLM

Question

Hi,

We’ve encountered an issue with one of our hosts acting as a server (Windows 10 22H2, OS Build 19045.4291). During the last session setup response, the signature sent by the server fails validation, as the value appears to be incorrect.

I’ve thoroughly verified the key calculation based on the NTLMSSP_CHALLENGE response and the signature calculation using the packet details. Both calculations seem accurate on our end.

This issue arises when our client attempts to connect to the host using Kerberos authentication, and the host responds with KRB5KRB_AP_ERR_SKEW. Instead of continuing with Kerberos, we fall back to NTLMSSP. We suspect that the signature contains invalid data because the server might not expect the client to switch to NTLM mid-authentication.

We need your assistance in diagnosing the problem. Are we missing any steps in the signature calculation, or could there be a server-side bug in this scenario?

Additionally, if we bypass the client validation step for the last session setup response, the server rejects the subsequent Tree Connect request with an STATUS_INVALID_PARAMETER error. It’s worth noting that the server’s clock is 10 minutes ahead.

I attached a screenshot that shortly demonstrate the issue since it is not possible to attach a full capture file. If needed, let me know how to attach it.

Thank you for your help.

Answer 1

Hi Aviv,

Thanks again for your question. After further investigation of [MS-KILE], I've discovered that the specified scenario does not align with the prescribed protocol. For the given scenario, refer to the following statement in [MS-KILE] section 3.2.5.8 AP Exchange:

"When the client receives a KRB_AP_ERR_SKEW error ([RFC4120] section 3.2.3) with a KERB-ERROR DATA structure (section 2.2.2) in the e-data field of the KRB-ERROR message ([RFC4120] section 5.9.1), the client retries the AP-REQ using the time in the KRB-ERROR message to create the authenticator."

As described, a fallback scenario after KRB_AP_ERR_SKEW to NTLM should not occur without disconnecting and renegotiating for NTLM. The server will exhibit unknown behavior after the client reattempts the session setup with NTLM.

Please let me know if you have additional questions.

Regards,
Kristian S
Microsoft Open Specs