none
KerberosAuthentication certificates constantly requested from domain controllers RRS feed

  • Question

  • As the title says, some of my domain controllers (2 out of 3) are each requesting a KerberosAuthentication certificate 3-4 times per day.  The one that is not constantly requesting the certificates is in another site by itself.  Is this normal?
    Tuesday, September 18, 2018 6:20 PM

All replies

  • are the requests successfull or failed?

    do all your domain controllers have auto enrollment for certificates enabled?


    Please remember to mark the replies as answers if they helped.


    • Edited by Proed Tuesday, September 18, 2018 6:24 PM
    Tuesday, September 18, 2018 6:23 PM
  • They are all successful.

    As far as I can tell it's not enabled, is there a command I can use to tell if I was looking at the correct GPO?

    Tuesday, September 18, 2018 6:41 PM
  • As the title says, some of my domain controllers (2 out of 3) are each requesting a KerberosAuthentication certificate 3-4 times per day.  The one that is not constantly requesting the certificates is in another site by itself.  Is this normal?

    The most likely reason can be that these domain controllers cannot perform revocation checking for their certificates (validation fails with RevocationOffline error), thus autoenrollment performs certificate reenrollment.

    Vadims Podāns, aka PowerShell CryptoGuy
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: PowerShell File Checksum Integrity Verifier tool.

    • Proposed as answer by Proed Tuesday, September 18, 2018 7:34 PM
    Tuesday, September 18, 2018 6:44 PM
  • As part of the certificate renewal a while back I migrated from server 2003 R2 to 2012 R2.  I did notice today that the CRL is incorrect.  The paths are all specified using <ServerDNSName> under CA Properties>Extensions, but the certificate still shows the old CA server name for the CRL.  On top of that, I have 6 entries under the extensions tab and only HTTP and LDAP show up on the cert.  What did I do wrong there?
    Tuesday, September 18, 2018 6:54 PM
  • Apparently, you missed sections related to migration to new server with different name in the ADCS migration guide (if you used that guide).

    Vadims Podāns, aka PowerShell CryptoGuy
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: PowerShell File Checksum Integrity Verifier tool.

    Tuesday, September 18, 2018 7:00 PM
  • I followed this guide https://blogs.technet.microsoft.com/canitpro/2014/11/11/step-by-step-migrating-the-active-directory-certificate-service-from-windows-server-2003-to-2012-r2/ which doesn't mention anything about extra steps if the hostname if different.  I can't find the guide you are talking about, a link would be nice.
    Tuesday, September 18, 2018 7:08 PM
  • I've updated the registry key (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\org\CAServerName) that was still referencing the old CA.  I couldn't really find anything regarding changing this after the fact.  I rebooted, is there anything else that needs to be done?  The root CA still lists the old CRL but it looks like anything new is showing up as the new CRL.

    Tuesday, September 18, 2018 7:54 PM
  • I followed this guide

    You can use blogs as additional reference, but they are not official and they imply that you are using officilal migration guide: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee126170(v=ws.10). If blog doesn't mention something, it doesn't mean that it doesn't exist in official guides. To be precize, the blog didn't mention this part which you miss: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee126140(v%3dws.10)#verifying-certificate-extensions-on-the-destination-ca

    I've updated the registry key

    it was incorrect step. As specified in the migration guide, you had to add new entries in CDP and AIA extensions with hardcoded <ServerDNSName> variable that points to old server name.

     


    Vadims Podāns, aka PowerShell CryptoGuy
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: PowerShell File Checksum Integrity Verifier tool.

    Tuesday, September 18, 2018 8:43 PM
  • I don't see anywhere in the guide you linked about adding new entries in CDP and AIA extensions with hardcoded <ServerDNSName> variable that points to old server name.  There is a section about container permissions, which I had an incorrect setting on CDP that I fixed, but everything else was correct.  What do you mean by CDP and AIA extensions?

    The certificates are still being requested at a rate of 3-4 per day and I have verified the CRL for the new certificates is correct.  I do not see any errors in event log either.

    • Edited by adam.sage Monday, September 24, 2018 12:47 PM
    Monday, September 24, 2018 12:45 PM
  • Vadims Podans do you have any other ideas?
    Thursday, October 25, 2018 11:45 AM
  • Sorry, I have no other ideas.

    Vadims Podāns, aka PowerShell CryptoGuy
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: PowerShell File Checksum Integrity Verifier tool.

    Thursday, October 25, 2018 3:10 PM
  • It's been a year, so I'm bumping this again in hopes someone else sees it.  Anyone have any ideas?  My DC's are still requesting up to 10 certs a day.
    Wednesday, November 13, 2019 7:35 PM
  • as i'm currently not sure what your CRL validation looks like, can you review with pkiview.msc and with

    certutil -verify [Certificate]

    I suggest, you go to one of the two dc's export one of the certificates (private key is not required) from your pki that resideds under Cert:\LocalMachine\My\, save it for example to your desktop and verify it with the certutil command i wrote above, to see if it can be verified


    Please remember to mark the replies as answers if they helped.

    Sunday, November 17, 2019 1:31 PM