Troubleshooting one of the most important and versatile parts of the Windows PKI world is a fairly complex process, since it involves a plethora of prerequisites in order for it to work correctly. Most of the times, consultants and administrators create a lab before a PKI deployment where autoenrollment usually works relatively easy – especially if the lab does not resemble the true production environment in anything other than the domain names.

In a very recent Windows PKI lab deployment for a major customer, we had a fairly lengthy autoenrollment troubleshooting session. The lab setup was a close-match replica of the production environment, as the Active Directory has been recreated using a backup of an actual production domain controller, as well as restored Exchange servers. The case was interesting: as it always seems to happen, everything was in place for autoenrollment to work, yet the process would not fire up at all.
To make a long story short, and after finding that no firewall, virtualization or general networking issues were involved, we finally tracked the autoenrollment failure down to two issues: the one is frequently seen in large organizations and has to do with GPO (Group Policy Object) precedence and settings’ overlapping. In our case, a GPO with no autoenrollment configured would prevail in the OU that the auto-enrolled users would reside and thus would not push the relevant settings to the clients. The second issue, however, was much more complex to target: as the environment has been set up many years ago, many administrators and third-party software packages have made a lot of changes in the production. One of the changes we found out that created problems, was the membership of two built-in groups: the Users and the Certificate Service DCOM access group. In the first one, the default membership should consist of Authenticated Users, Domain Users and Interactive (it did not, as you can imagine). In the second one, the Authenticated Users group should exist as a member (again, it was not – the list was empty).

We should say that in cases of autoenrollment failures, one should focus on:

1. Certificate template security – make sure your users/computers have Read, Enroll and Autoenroll permissions and that the Authenticated Users group has not been deleted (it should be there with Read-only permissions).
2. GPO precedence – make sure that you create a separate, enforced GPO to enable autoenrollment or, at least, that the GPOs applied to your users/computers finally lead to an enabled state for autoenrollment (RSOP is a great client-side tool to discover such issues).
3. Group membership – the Issuing CA’s computer account should be a member of the Cert Publishers group in the intended enrollment domain; also, the Users and the Certificate Service DCOM Access built-in groups should have the membership detailed previously in this post.
4. Server-side certificate issuance errors – a poorly configured certificate template (for example, one that requires an e-mail address in order for certificates to be issued when some user accounts may not have an e-mail address in AD) could lead to a certificate issuance request that is left in a pending or failed status, as seen in the Certification Authority console. Do check this by manually initiating a certificate request through an MMC console or a Web enrollment page (if configured) and make sure that the manual enrollment method actually succeeds in creating the intended certificate.
5. Networking issues – blocked ports (RPC, HTTPS etc.) as well as problematic networking software or hardware (drivers etc.) could lead to problems in autoenrollment, Again, check if a manual request can succeed.