Troubleshooting autoenrollment

  • Article

From my colleague Maria in the Domains team – a collection of useful bits for troubleshooting autoenrollment issues:

On a Windows Server 2003-based or Windows XP-based computer, you cannot obtain certificates from a Windows Server 2008-based certification authority (CA).

This issue can occur if the CA is configured to use SHA2 256 encryption or higher encryption (SHA2 384 or SHA2 512) and the enrolling clients are legacy clients.

See KB 968730 (Hotfix)

Event id 80; Source Microsoft-Windows-CertificationAuthority on a windows 2008 certificate server
Active Directory Certificate Services could not publish a Certificate for request ##### to the following location on server DC.DOMAIN.COM: CN=user,OU=OU, DC=domain,DC=com.  Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344).

ldap: 0x32: 00002098: SecErr: DSID-03150E8A, problem 4003 (INSUFF_ACCESS_RIGHTS)

  • Check that the Cert Publishers group has permission to read and write to the userCertificate attribute on the user object in AD that is specified in the event.

Enhanced Event Logging

By default, autoenrollment logs errors/failures and successful enrollments in the Application event log on the client machine.

To enable enhanced logging of the autoenrollment process to include warning and informational messages, the following registry values must be created.

- SOFTWAREMicrosoftCryptographyAutoEnrollment

AEEventLogLevel

(Create a new DWORD value named "AEEventLogLevel", set value to 0.)

NOTE: This value can be created under either HKLM or HKCU, depending on which context you need to troubleshoot. In this case I’d like us to set it on both.

If you enable logging and don't see any events, check to see if Autoenrollment has been disabled:

SOFTWAREPoliciesMicrosoftCryptographyAutoEnrollmentAEPolicy

If it’s set to 0x00008000 hex (32768 dec ) then it’s disabled (0x00008000==AUTO_ENROLLMENT_DISABLE_ALL).

Again, this should be checked under HKLM or HKCU depending on the whether computer or user Autoenrollment is of interest.

 

Permissions

On the CA server:

- Verify membership of the CERTSVC_DCOM_ACCESS group.  
If you have more issuing CA’s on member servers, this will need to be checked on all of them for the local groups. verify that the following groups are members: Domain Users and Domain Computers.

If there are users or computers in other domains in the forest that also need to enroll against the CA, then those users and computers will also need to be added to the CERTSVC_DCOM_ACCESS group.

If a CA has been installed on a DC in the domain then this group may be a Domain Local group instead.

- Verify that CERTSVC_DCOM_ACCESS has been added to the DCOM Security Limits on the CA.

a. Click on Start, then Programs, then Administrative Tools, the Component Services.

b. Expand the Component Services node.

c. Expand the Computers node.

d. Right-click on My Computer and select Properties from the context menu.

e. Click on the COM Security tab.

f. Under Access Permissions, click Edit Limits.

g. Verify that the CERTSVC_DCOM_ACCESS group has been granted Allow Local Access and Allow Remote Access permissions.

h. Click Cancel.

i. Under Launch and Activation Permissions, click Edit Limits.

j. Verify that the CERTSVC_DCOM_ACCESS group has been granted All Local Activation and Allow Remote Activation permissions.

k. Click Cancel.

l. Click Cancel.

m. Close Component Services

If you had to change the permissions/members of the CertSVC_DCOM_ACCESS group then you may in certain cases need to run the following to get the CA to recognize the updated DCOM security settings.
 
certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG net stop certsvc
net start certsvc

 

On the clients:

- Verify distributed DCom is enabled:

Run dcomcnfg and select the tab “Default Properties” and verify they have “Enable Distributed COM on this computer”.

Also check for default authentication level"  -  Connect and the "default impersonation level" - Identify.

 

Common errors and their causes:

Autoenrollment 15 with 0x8007054b is due to problems getting to a DC in the domain, common cause is name resolution. Suggested troubleshooting includes verify network connectivity and name resolution.

Autoenrollment 15 with 0x80072751 “ A socket operation was attempted to an unreachable host” – is commonly due to the client being logged on with cached credentials, otherwise check network connectivity, firewalls and name resolution again.

Autoenrollment 13 is further into the chain, where we actually can try enroll for a certificate but fails. Depending on the error code provided in event id 13, there are a few different approaches:

0x800706ba - The RPC server is unavailable

  • Verify that the client can get a certificate using the Manual Enrollment via the MMC Certificate Wizard.
  • Check network connectivity to all of the available certification authorities listed in the Enrollment Services object listed in the Active Directory:CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=Domain,DC=com
  • Verify that the Certificate Services service is running on the certification authority.
  • Check for firewalls and proxy settings.
  • Use Portqry to verify that the necessary RPC ports are opened.

0x8009400f- too many active sessions

By default, the Windows Server 2003 certification authority allows only 20 concurrent sessions to the CA database. To increase the maximum number of sessions to 30 (highest tested limit for Windows Server 2003):

  • certutil -setreg dbsessioncount 30
  • net stop certsvc && net start certsvc

0x80070005 - Access is denied

This error occurs when attempting to bind to the certification authority to generate the certificate request

http://support.microsoft.com/kb/903220

 

Error: The certificate request failed. The revocation function was unable to check revocation because the revocation server was offline.

The client does not have a valid certificate revocation list (CRL) from the issuing CA that it can use to check if a certificate has been revoked.  Verify that all certification authorities in the chain have valid CRL’s published. To test this, run the following command against the issuing certification authority certificate:

certutil –v –verify –urlfetch <Issuing_CA_Certificate>

The certutil –urlfetch combination can also be run against any certificate that you want to verify CRL’s for – but note that it will use the security and proxy settings of the user that runs it so if you have implemented proxy servers or similar then you should make sure that the account you’re running this with has the same proxy settings and permissions as the security principal that logs the event.

 

Further reading:

Troubleshooting Certificate Enrollment
http://blogs.msdn.com/windowsvistanow/archive/2008/04/08/troubleshooting-certificate-enrollment.aspx

Troubleshooting (Certificate Autoenrollment in Windows Server 2003)
http://technet.microsoft.com/en-us/library/cc755801(WS.10).aspx

Certificate Autoenrollment in Windows Server 2003
http://msdn.microsoft.com/en-us/library/bb643324.aspx

Certificate Autoenrollment in Windows XP
http://technet.microsoft.com/en-us/library/bb456981.aspx

Windows Server 2003 and Windows XP clients cannot obtain certificates from a Windows Server 2008-based certification authority (CA) if the CA is configured to use SHA2 256 or higher encryption
http://support.microsoft.com/kb/968730