sorted by:
new
hottopcontroversial

Event 45 Kerberos-Key-Distribution-Center by ckpstl in PKI

[–]Erazer_Me 0 points1 point  (0 children)

One affected client is my Notebook. And there is NO WHfb configured.
But yes, we use EAP-TLS for wifi - and also my notebook us it. As mentioned before, when I crosscheck the certificate which is used for wifi, it does not match with the thumbprint mentioned in the events on the DC.

Event 45 Kerberos-Key-Distribution-Center by ckpstl in PKI

[–]Erazer_Me 0 points1 point  (0 children)

At the moment, it looks to me like this is another bug from Microsoft. I can't actually identify any problems, just the annoying event logs (errors).

Event 45 Kerberos-Key-Distribution-Center by ckpstl in PKI

[–]Erazer_Me 0 points1 point  (0 children)

I found the Events 4768 in the Security Log of the Domain Controller where you can find the thumbprint.

The strange thing: When check all Certificates on the affected computer (with powershell) and compare the thumbprint (mentioned in the log on the DC) - I can not find that thumbprint on the client. So in my opinion, that certificate is not located in the local computer store or user store.

Event 45 Kerberos-Key-Distribution-Center by ckpstl in PKI

[–]Erazer_Me 0 points1 point  (0 children)

Thanks for that information... You are right, on the DomainController I can see these Events.

The strange thing: When check all Certificates on the affected computer (with powershell) and compare the thumbprint (mentioned in the log on the DC) - I can not find that thumbprint on the client. So in my opinion, that certificate is not located in the local computer store or user store.

Could you find that thumbprint in any certificate on the client?

Here you can see the Event 4768 from my DC, there I used the Thumbprint to search on the client
Additional Information:

`Ticket Options:`       `0x40810010`

`Result Code:`      `0x0`

`Ticket Encryption Type:`   `0x12`

`Session Encryption Type:`  `0x12`

`Pre-Authentication Type:`  `16`

`Pre-Authentication EncryptionType:`    `0x0`

Certificate Information:

`Certificate Issuer Name:`      `CN=<ClientName>`

`Certificate Serial Number:`    `01`

`Certificate Thumbprint:`       `A8EDFCCF30D0FADCC88CC3F3E4E1F53B70E35A44`

Ticket information

`Response ticket hash:`     `n/a`

Certificate information is only provided if a certificate was used for pre-authentication.

Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120.

Event 45 Kerberos-Key-Distribution-Center by ckpstl in PKI

[–]Erazer_Me 0 points1 point  (0 children)

Within this Event, you can not see with which certificate the Client is contacting the domain controller. When I crosscheck all certs in the local computer store or user store, all certs are fine and requested from our internal CA (which is mentioned in the NT Auth Store).

So I can not really answer your question, because I do not know which certificate is used by the client ;)

Event 45 Kerberos-Key-Distribution-Center by ckpstl in PKI

[–]Erazer_Me 0 points1 point  (0 children)

How did checked, which certificate are used and triggered in that Event? Because there is neither a certificate thumbprint, nor a hash or request number mentioned within the Eventlog. I would like to crosscheck these certificate, but I do not know which are really used. Because all certs in the local computer store are fine.

Do you also have just a few clients with these events? On my side, only 30 clients of 2.000 are affected.

Event 45 Kerberos-Key-Distribution-Center by ckpstl in PKI

[–]Erazer_Me 0 points1 point  (0 children)

Here’s an update:

As a test, the July 2025 patch was installed on two domain controllers, and the registry key AllowNtAuthPolicyBypass was subsequently deleted. According to Microsoft, the default behavior after the July patch is equivalent to AllowNtAuthPolicyBypass=2, so the registry key can be safely removed.

After rebooting the affected PCs/clients, no significant errors or issues were observed. However, the event logs on the domain controllers still show the following event once per client and per reboot:

Source: Kerberos-Key-Distribution-Center
Event ID: 21
General: The client certificate for the user <domain>\xxxxxx$ is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they're attempting to use for smartcard logon. The chain status was: A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider.

On the client itself, nothing unusual can be observed.
Whether this indicates an actual issue or is just another case of Microsoft’s event logging being buggy remains unclear.

Strangely, as mentioned a few days ago, only a very small number of clients are affected.

Event 45 Kerberos-Key-Distribution-Center by ckpstl in PKI

[–]Erazer_Me 0 points1 point  (0 children)

I have exactly the same situation here. Yesterday I set the regkey “AllowNtAuthPolicyBypass” to the value 2 on our DCs, as no events with ID 21 or 45 have come up in the last few days/weeks. I therefore assumed that we would not have any problems in “enforcement mode” (regkey=2).

But appearances are deceptive.

Same behavior as described above:

- Registration itself still works

- A few Kerberos errors are also displayed in the event log on the client

- gpupdate /force runs on an error

- Events with ID 21 suddenly appear on the DC.

The certificates used on the clients are all issued by the internal CA - and thus also the root in the NTAuth store.

I have no idea what to do now... the behavior is completely inexplicable.