These are the steps to troubleshoot autoenrollment problems. The basis for this article was produced by a veteran field troubleshooting engineer, Roger Grimes. The article assumes that certificates that a user or machine should be receiving automatically from an issuing CA server on the network are not showing up in the end-users certificate store (i.e. Personal store in the Certificates console - certmgr.msc).

Table of Contents

Verify Setup

  1. Issuing CA’s computer account is in Cert Publishers group for the domain. You can verify this by using Active Directory Users and Computers (dsa.msc) and looking at the Users folder for the membership of Cert Publishers.
  2. Ensure the group policy objects have Autoenrollment enabled, see Configuring Group Policy for more information.
  3. User or computer has Read, Enroll, and Autoenroll permissions on the certificate template being requested.
  4. You can run certutil.exe –Template when logged in as the end-user to see if the end-user has Read and Enroll permissions (but it will not reveal which certs the user has Autoenroll permissions to)
  5. Make sure certificate request isn’t pending or failed status in Certification Authority console.

Ensure Autoenrollment is enabled in Group Policy

  • View appropriate effective GPOs (using Active Directory Users and Computers or the Group Policy Management console)
  • On the client computer, run rsop.msc and check both user and computer configuration objects,
  • Rsop results will only show what was pushed by GPOs, not what actually was applied.
  • To see that autoenrollment is actually turned on the computer, check the following registry keys for a DWord value of 7 in AEPolicy:
    • HKEY_CURRENT_USER\Software\Policies\Microsoft\Cryptography\AutoEnrollment (for user certs)
    • HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Cryptography\AutoEnrollment (for PC certs
      • If no values are there, check the non-GPO locations (but it means AD GPOs are not working):
    • HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\AutoEnrollment
    • HKEY_CURRENT_USER\Software\ Microsoft\Cryptography\AutoEnrollment

If none of these keys have AEPolicy = 7, Autoenrollment is not turned on.

Force Autoenrollment and View the Results

If previous steps above are set correctly, force Autoenrollment and look into Application log to see what happens when Autoenrollment takes place. First, set new registry key to turn on more detailed autoenrollment auditing: In HKCU\Software\Microsoft\Cryptography\Autoenrollment and HKLM\Software\Microsoft\Cryptography\Autoenrollment, create a new DWORD value named AEEventLogLevel and set its value to 0.

Open up Application Log in Event Viewer (eventvwr.exe).

Force Autoenrollment:

gpupdate /force

In the Application event log, refresh the log to see what happens during autoenrollment.

Two computer autoenrollment messages (start, stop) should occur first, followed by two user autoenrollment messages (start, stop) in 30 sec. – 2 minutes. Any issued certs should appear in the log as Event ID 18’s or 19’s. Stop and Start messages are event IDs 2 and 3.

If there are any valid autoenrollment certificates to be issued, they should issue here.

Note: If the CA administrator configured the templates to not duplicate certificates if one already exists in Active Directory, you will have to delete the user’s certificate in Active Directory in order for Autoenrollment to pull down a new certificate.

Troubleshooting GPO Errors

If you do see any GPO errors, you can turn on Group Policy logging on the client. Trigger Group Policy manually (gpupdate /force). Then check the policy log.

For XP

  • Set the following registry flag:
    • Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    • Flag - DWORD: UserEnvDebugLevel
    • Value: 0x00030002
  • Rename the current GPO log file, userenv.log, to userenv.old

Check the following log file for any errors: %windir%\debug\usermode\userenv.log

Additional Resources