Deconstructing the KDC certificate processing functionality

發行項
02/02/2012

For a DC to be able to service smartcard logons the DC must have a valid and suitable certificate present in the personal store of the computer account.
This is typically autoenrolled for whenever a Windows CA server has been installed into the AD environment.

The KDC service on W2k8 R2 monitors the personal certificate store of the computer account it is running on and gets notified when changes occur.
At that point a KDC certificate selection process gets kicked off and the Kerberos Distribution Center service parses the contents of the store for any suitable certificates.

If the current DC certificate is still valid and passes trust and revocation checks - the current KDC cert will continue to be used.
If it fails then a new KDC cert selection process is kicked off and a new KDC cert is picked from the local store if it contains any. If more than one cert qualifies as a potential KDC cert then typically the most recent one will be picked.

The same KDC certificate selection process is invoked when the KDC service is (re)started and every 10 hours afterwards.

One thing to note from a troubleshooting perspective is that it is perfectly possible for the KDC to be unhappy with a DC certificate that is currently being used successfully for LDAPS for example.
I.e. beware of drawing any conclusions from testing if an LDAPS connection to the DC works - the KDC component does additional checks when considering if the cert is a suitable KDC cert candidate.

If the personal store of the computer account doesn't contain any KDC cert at all or if only the Public key part of the potential KDC certificate is present then that will of course cause the KDC cert selection to fail as there will be 0 candidates for a KDC cert in that case.

共用方式為

Deconstructing the KDC certificate processing functionality

其他資源