locked
KDC Event ID 29 - The KDC cannot find a suitable certificate to use for smart card logons... RRS feed

  • Question

  • I am getting the event (below) every day on a new 2008 domain controller that I brought up recently. The DC has a domain controller certificate, that was automatically issued by an online enterprise CA. This CA is located in another domain (child domain) within the same forest. The 2008 DC is in the top-lvel domain.  None of the other domain controllers , which are 2003, are reporting this message. I ran certutil.exe, and it successfully verifies all domain controller certificates, including the certificate on my new 2008 DC. Any ideas why these messages continue to appear?

    The Key Distribution Center (KDC) cannot find a suitable certificate to use for smart card logons, or the KDC certificate could not be verified. Smart card logon may not function correctly if this problem is not resolved. To correct this problem, either verify the existing KDC certificate using certutil.exe or enroll for a new KDC certificate.
    Monday, April 20, 2009 1:23 PM

Answers

  • Hi Brandon,

    Thank you for your efforts in working closely with us.

    We were able to repro this event ourselves by taking a CA offline. We noticed that when starting the KDC service, an attempt to validate the DC cert is made and that attempt fails with KDC_ERR_KDC_NOT_TRUSTED since the revocation server was offline along with the CA.

     

    This is likely what is happening with you as well. To confirm the same, please create the following registry value on your Windows Server 2008 servers and restart the KDC to see if the warning event goes away.

     [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\kdc]

    "UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors"=dword:00000001

    After you set this DWORD value to 1, the Kerberos clients will ignore "Revocation unknown" errors that are caused by an expired CRL.

    After you perform the test, please revert the registry value back and let us know the result:

    1. Does the warning go away after you configure the above registry value?
    2. Where do you put the CRL to?

    Please feel free to let us know if anything is unclear.


    Laura Zhang - MSFT
    • Marked as answer by Brandon.M Wednesday, May 13, 2009 1:38 PM
    Monday, May 11, 2009 7:22 AM
  • Hi Brandon,

     

    Thank you for your update.

     

    I performed deep research on this issue today. As this issue goes away if you configure the UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors registry value to 1,  this means that the warning is caused by the failed CRL check. Then I checked the certificate output that you collected. I noticed that the CDP extension of the root CA certificate is empty. I think that this is the root cause for the warning message. When the KDC service is started, it tries to validate the DC certificate and check the CA CRL. As the CDP for the root CA certificate is empty, the revocation check failed and the warning is recorded.

     

    CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0

      Issuer: CN=***Root CA, DC=***, DC=com

      NotBefore: 1/18/2007 1:48 PM

      NotAfter: 1/18/2022 1:49 PM

      Subject: CN=***Root CA, DC=***, DC=com

      Serial: ……………

      Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)

      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)

      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

      ----------------  Certificate AIA  ----------------

      No URLs "None" Time: 0

      ----------------  Certificate CDP  ----------------

      No URLs "None" Time: 0

      ----------------  Certificate OCSP  ----------------

      No URLs "None" Time: 0

      --------------------------------

     

    I understand that the CA is an offline and it would be a good design to have an empty CDP. You can safely ignore this warning. It does not mean that your CA or DC certificate has any problems. Meanwhile, if you do not want to see the warning, you may set the UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors registry value to 1 to work around it. After you set this registry value to 1, the Kerberos client will ignore “Revocation unknown” error that is caused by an expired CRL.

     

    Again, thank you for your understanding and patience.

    • Marked as answer by Brandon.M Wednesday, May 13, 2009 1:38 PM
    Wednesday, May 13, 2009 9:35 AM

All replies

  • Hi,

     

    Thank you for your post.

     

    Regarding the KDC 29 event, Please collect the following information on the Windows Server 2008 DC for further research:

     

    1.    Run the command certutil -dcinfo verify > dcinfo.txt and press Enter.

    2.    Run the command ldifde -d "CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRoot,DC=com" -f PKI.txt and press Enter.

    3.    After that, please zip the dcinfo.txt and PKI.txt and upload to the following space:

    https://sftasia.one.microsoft.com/choosetransfer.aspx?key=c5c395bc-ca22-49b8-b87b-01eb7fde76c7
    Password:
    Tn2d0]LeI%V#%Yw

     

    I look forward to your response.

    Tuesday, April 21, 2009 11:49 AM
  • Hi Brandon,

     

    I want to check if you have time to collect the information. If there is anything unclear, please feel free to let me know.

     

    Have a nice day.

    Friday, April 24, 2009 2:39 AM
  • I never received an email alert from your first reply. I will get this info tomorrow.

    Friday, April 24, 2009 2:59 AM
  • Info has been sent. Thanks

    I should mention that our PKI consists of an offline Root CA and an online Enterprise Subordinate CA. The Enterprise SubCA is in a child domain. The DC with the KDC event messages in dcinfo.txt is Swampoak.
    Friday, April 24, 2009 1:23 PM
  • Hi Brandon,

     

    Thank you for the information.

     

    I have checked the files and noticed the error code 0x80092013 (server offline) which may result in the KDC 29 event:

     

    The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)

    ------------------------------------

    Revocation check skipped -- server offline

     

    A possible cause could be that the crl of the root CA has been expired. If so, please republish the new CRL on root CA and check the result.

     

    If the CDP contains a LDAP URLs, you can republish the crl by performing the following steps:

    1.    Copy the new CRL file from root CA to the issuing CA.

    2.    On the issuing CA, run the command certutil –dspublish –f <path of the RootCA.crl>

     

    For more information:

     

    Troubleshooting Certificate Status and Revocation

    http://technet.microsoft.com/en-us/library/cc700843.aspx#XSLTsection130121120120

     

    Example Scenario for Contoso

    http://technet.microsoft.com/en-us/library/cc779714.aspx

     

    If there is anything unclear, please feel free to let me know.

    Monday, April 27, 2009 10:29 AM
  • I did notice that error and thought that may be the cause of the event log warnings. I updated the Root CA's CRL in CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com. I then ran certutil -dcinfo verify and it appears that I am no longer getting the "unable to check revocation" error. I will verify tomorrow to see if the event log messages stop. I brought up another new 2008 DC that is getting the same event, so I will check that one as well. My Windows 2003 DC's never reported this warning in the event logs.

    I did not know how often the Root CA CRL needs to be updated in Active Directory. As I mentioned, the Root CA is offline, so some manual steps are required.

    I will post tomorrow whether the Event 29's have stopped or are still showing up.

    Thanks.
    • Edited by Brandon.M Tuesday, April 28, 2009 2:44 PM
    Tuesday, April 28, 2009 2:43 PM
  • Hi Brandon,

     

    Thank you for your update.

     

    You can simply view the .crl file to check if it has expired. For more information about CRL publication, you can refer to the following articles:

     

    AD CS: The CRL publication interval for a stand-alone root CA should be at least 30 days

    http://technet.microsoft.com/en-us/library/dd379541.aspx

     

    Revoking certificates and publishing CRLs

    http://technet.microsoft.com/en-us/library/cc782162.aspx

     

    Regarding the KDC event 29, as far as I know, it is a new event introduced in Windows Server 2008. As a result, such warning is not logged on Windows Server 2003 domain controllers.

     

    967623          You receive a Key Distribution Center "Event ID: 29" event message on a Windows Server 2008-based domain controller

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;967623

     

    I look forward to your response.

    Wednesday, April 29, 2009 10:30 AM
  • Unfortunately, I am still receiveing the KDC event messages on both 2008 domain controllers.

    Wednesday, April 29, 2009 2:32 PM
  • Hi,

     

    Please collect the information (dcinfo.txt and pki.txt) again and upload to the space for further research.

     

    In addition, I would like to confirm whether the CAs are running on Windows Server 2003 machine or Windows Server 2008 machine.

     

    I look forward to your response.

    Thursday, April 30, 2009 10:01 AM
  • I sent the updated info to the address from above. I think it uploaded successfully, but if you didn't get it, let me know and I'll send it again.

    The CAs are both running Windows Server 2003. The Root is running Standard edition and the Enterprise SubCA is running Enterprise edition.
    Thursday, April 30, 2009 1:24 PM
  • Hi,

     

    I have checked the file. Here is my findings:

     

    1.    The computer name of the domain controllers are different in this dcinfo.txt file. There is no Swampoak. I would like to confirm which one is Windows Server 2008 domain controller.

    2.    The domain controller Buckeye and Madrone both have 2 KDC certificates, one is expired and the other one is valid:

     

     

    *** Testing DC[0]: MADRONE

     

    ** KDC Certificates for DC MADRONE

    Certificate 0:  -à Valid

    Serial Number: 116bbdd90000000000b6

    Issuer: ***

    NotBefore: 12/15/2008 2:28 AM

    NotAfter: 12/15/2009 2:28 AM

    Subject: CN=madrone.****

    Certificate Template Name (Certificate Type): DomainController

    Non-root Certificate

    Template: DomainController, Domain Controller

     

     

    Certificate 1:   --à Expired

    Serial Number: 15c2f00b000000000028

    Issuer: ****

    NotBefore: 3/9/2007 3:05 PM

    NotAfter: 3/8/2008 3:05 PM

    Subject: EMPTY (DNS Name=madrone.****)

    Non-root Certificate

    Template: DomainControllerAuthentication, Domain Controller Authentication

     

     

    *** Testing DC[1]: BUCKEYE

     

    ** KDC Certificates for DC BUCKEYE

    Certificate 0:  -à Expired

    Serial Number: 15c4ddc2000000000029

    Issuer: *****

    NotBefore: 3/9/2007 3:07 PM

    NotAfter: 3/8/2008 3:07 PM

    Subject: EMPTY (DNS Name=buckeye.****)

    Non-root Certificate

    Template: DomainControllerAuthentication, Domain Controller Authentication

     

     

    Certificate 1: -à Valid

    Serial Number: 115f34ec0000000000b4

    Issuer: ****

    NotBefore: 12/15/2008 2:15 AM

    NotAfter: 12/15/2009 2:15 AM

    Subject: CN=buckeye.****

    Certificate Template Name (Certificate Type): DomainController

    Non-root Certificate

    Template: DomainController, Domain Controller

     

    Suggestion:

    1.    Please delete the expired certificate and then reboot the domain controller and test the issue again.

    2.    If the issue persists, please request a new Domain Controller Authentication certificate on the domian controller and check the result.

    Tuesday, May 5, 2009 10:06 AM
  • My bad. I sent your the wrong dcinfo. Swampoak is in the root domain. I ran certutil in the other domain. The expired cert is on buckeye, a Windows 2003 domain controller. It, nor any of my 2003 DC's, report the KDC warning that the 2008 DC's report. Buckeye has a current certificate and it works fine. I can delete the expired certificate on that, but I doubt it will have any effect to my issue.

    I sent you a dcinfo.txt for both 2008 domain controllers that are reporting the KDC warning.
    Tuesday, May 5, 2009 2:46 PM
  • Hi Brandon,

     

    Based on the current situation, I suggest that we request a new Domain Controller Authentication (not Domain Controller) certificate on a Windows Server 2008 domain controller and then reboot the domain controller to see if the event goes away. If the issue persists, please run the certutil command again and upload the output to me.

     

    Thanks.

    Wednesday, May 6, 2009 7:10 AM
  • Ok, I now have "Domain Controller Authentication" certificates installed on both 2008 DC's. I uploaded the updated certutil info. At the time I enrolled the certificates, I checked the event log. The application log shows a successful enrollment, and our good friend KDC 29 popped up in the system log on both servers. I will check tomorrow if they are still appearing.

    Wednesday, May 6, 2009 8:53 PM
  • The warnings are still showing up.
    Thursday, May 7, 2009 1:51 PM
  • Hi Brandon,

     

    I am sorry to hear that.

     

    For further research, please run the following commands on the Windows Server 2008 domain controller Lightwood and upload the output files to me:

     

    certutil –store my 676c8b8b0000000000f1 SavedCert676c8b8b0000000000f1.cer

    certutil –store my 37bad2650000000000ed SavedCert37bad2650000000000ed.cer

    certutil –verify –urlfetch SavedCert676c8b8b0000000000f1.cer>SavedCert676c8b8b0000000000f1.txt

    certutil –verify –urlfetch SavedCert37bad2650000000000ed.cer>SavedCert37bad2650000000000ed.txt

     

    certutil –TCAInfo>TCAInfo.txt

     

    certutil –dsTemplate –v DomainController>DomainController.txt

    certutil –dsTemplate –v DomainControllerAuthentication>DomainControllerAuthentication.txt

    certutil –dsTemplate –v DirectoryEmailReplication>DirectoryEmailReplication.txt

     

    certutil –store –v ACRS>ACRS.txt

    certutil –store –GroupPolicy –v ACRS>GroupPolicyACRS.txt

    certutil –store –Enterprise –v ACRS>EnterpriseACRS.txt

     

    Note:

     

    ·         Press Enter after each command.

    ·         The first two commands save the specified certificates to files.


    Thanks.

    Friday, May 8, 2009 8:06 AM
  • Files uploaded. The command, certutil –store –Enterprise –v ACRS, failed with cannot find file specified. It runs fine when I drop the ACRS parameters. I uploaded a second file called ent_store.txt that includes the output of certutil -store -enterprise -v.

    Saturday, May 9, 2009 4:02 PM
  • Hi Brandon,

    Thank you for your efforts in working closely with us.

    We were able to repro this event ourselves by taking a CA offline. We noticed that when starting the KDC service, an attempt to validate the DC cert is made and that attempt fails with KDC_ERR_KDC_NOT_TRUSTED since the revocation server was offline along with the CA.

     

    This is likely what is happening with you as well. To confirm the same, please create the following registry value on your Windows Server 2008 servers and restart the KDC to see if the warning event goes away.

     [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\kdc]

    "UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors"=dword:00000001

    After you set this DWORD value to 1, the Kerberos clients will ignore "Revocation unknown" errors that are caused by an expired CRL.

    After you perform the test, please revert the registry value back and let us know the result:

    1. Does the warning go away after you configure the above registry value?
    2. Where do you put the CRL to?

    Please feel free to let us know if anything is unclear.


    Laura Zhang - MSFT
    • Marked as answer by Brandon.M Wednesday, May 13, 2009 1:38 PM
    Monday, May 11, 2009 7:22 AM
  • Thank you for all your help.

    I added the registry value and I will check tomorrow to see if the events warnings have stopped.

    The Root CA CRL is published in Active Directory, as followed by Joson's instructions above, and is also out on our corporate web site. I verified that the CDP is working by browsing the URL from the domain controller and receiving a prompt to Open/Save the CRL. I also verified the AIA.
    Monday, May 11, 2009 5:28 PM
  • The warnings stopped on the DC that I added the registry value to. I have removed the UseCachedCRLOnly value.
    Tuesday, May 12, 2009 1:29 PM
  • Hi Brandon,

     

    Thank you for your update.

     

    I performed deep research on this issue today. As this issue goes away if you configure the UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors registry value to 1,  this means that the warning is caused by the failed CRL check. Then I checked the certificate output that you collected. I noticed that the CDP extension of the root CA certificate is empty. I think that this is the root cause for the warning message. When the KDC service is started, it tries to validate the DC certificate and check the CA CRL. As the CDP for the root CA certificate is empty, the revocation check failed and the warning is recorded.

     

    CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0

      Issuer: CN=***Root CA, DC=***, DC=com

      NotBefore: 1/18/2007 1:48 PM

      NotAfter: 1/18/2022 1:49 PM

      Subject: CN=***Root CA, DC=***, DC=com

      Serial: ……………

      Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)

      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)

      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

      ----------------  Certificate AIA  ----------------

      No URLs "None" Time: 0

      ----------------  Certificate CDP  ----------------

      No URLs "None" Time: 0

      ----------------  Certificate OCSP  ----------------

      No URLs "None" Time: 0

      --------------------------------

     

    I understand that the CA is an offline and it would be a good design to have an empty CDP. You can safely ignore this warning. It does not mean that your CA or DC certificate has any problems. Meanwhile, if you do not want to see the warning, you may set the UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors registry value to 1 to work around it. After you set this registry value to 1, the Kerberos client will ignore “Revocation unknown” error that is caused by an expired CRL.

     

    Again, thank you for your understanding and patience.

    • Marked as answer by Brandon.M Wednesday, May 13, 2009 1:38 PM
    Wednesday, May 13, 2009 9:35 AM
  • Thanks.

    Certificates issued by the Root CA do have a CDP and AIA entry, just not the Root certificate itself. In the output that I sent you, I see that the subCA certificate contains the CDP and AIA URLs that are configured on the Root CA. Those are the top-level CDP and AIA locations. Not sure why the KDC is trying to check for a CDP and AIA on the Root certificate itself. There is nothing above it.

    Oh well, I can just ignore these warnings. I just want to make sure there was nothing wrong with my configuration. Something definetly has changed with the KDC service in 2008 considering that my 2003 DC's are not reporting this same warning. Maybe Microsoft will address this in a future release or update.

    Wednesday, May 13, 2009 1:38 PM
  • Hi Brandon,

    Yes, you are correct. The SubCA certificate contains CDP and AIA URLs, and they are accessible.

     

    As I mentioned earlier, the KDC 29 is a new event introduced in Windows Server 2008. Therefore, you do not encounter such event in Windows Server 2003. According to the information we collected, I believe that the PKI environment works well. You can safely ignore the warning.

     

    Again, thank you for your efforts.

    Have a nice day.

    Friday, May 15, 2009 10:53 AM
  • Hi,

    I also noticed this problem on my DCs today after finding that I couldn't log on with a smart-card: Hardly surprising since that is what this 29 error is trying to tell you!

    I set the registry fix suggested here and sure enough the error message went away. But I still couldn't use a smart-card. I also noticed the output from certutil -dcinfo verify included the following line:

    ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)

    Suggests the offline CA isn't the source of the error then?

    So I checked the "Enterprise PKI" snap-in and noted an error on the Delta CRL location. The Delta CRL file exists and is valid; it is also published from a Web site which has been moved to a Windows 2008 server running IIS 7. I quickly dug this up:

    http://blogs.technet.com/pki/archive/2008/02/25/how-to-avoid-delta-crl-download-errors-on-windows-server-2008-with-iis7.aspx

    No more 29 errors, no reg fix hiding them, and most importantly the smart-cards work!

    Might have nothing in common with Brandon's problem although I note he too is using HTTP locations, but no mention of delta CRLs?

    Paul B

    Friday, May 22, 2009 4:01 PM
  • Good info.

    I am not using delta CRLs, but I'll check into this when I get back into the office. My CA's are running on Windows 2003, so no IIS 7. However, I believe I have URLScan configured on that server and allowDoubleEscaping may be disabled if it is.
    Friday, May 22, 2009 4:56 PM
  • Hi!

    I had similar problems.
    This post helped me!

    thanks..


    César Kumazawa - MCT, MCTS
    Friday, July 15, 2011 1:08 PM
  • Hi

    When I set up wireless AP with Windows 2008 R2 CA, I encountered same issue. After reviewing out put from "certutil -dcinfo verify >c:\temp\dcinfo.txt" I found that cert for KDC is expired.

    Then go to mmc and open certificate console, request a new certificate and restart KDC service. It solved problem.

    Hope this helps.

    Tuesday, July 22, 2014 6:32 PM