Question : CA Unable To Autoenroll Certificates

Hi ladies/gents,

As a new joiner to this forum I may not be up to scratch with the etiquettes of how a questions is supposed to be proposed so please bare with me, I'll try and provide the neccessary information so hopefully one of you experts can sort this niggling problem for me.

Problem description:

We currently have three certificate authorities with the following roles:

- Standalone Root Certificate - Offline - Issued certificates to Subordinate CA's and taken offline
- Enterprise Subordinate CA - Online - Issues certificates
- Enterprise Subordinate CA - Online - Issues certificates

 The certificate authorites are spread between two sites, site 1 which is considered the HDQ of operations contains the Standalone Root & one of the Enterprise subordinate machines and Site 2 has the remaining enterprise subordinate server. The 2 physical sites are connected via a Demand-Dial link

  We have encountered a problem whereby certificates are unable to be autoenrolled to the users, when selecting to manually request the desired certificate it does not appear to be published although the neccessary permissions have been provided (Read, Enroll and Autoenroll - Authenticated users). We believe this problem emanated from a merger which took place of two active directory forest which contained the two sites.

Essentially we have 4 sites (Subnets) with 4 DC's, two of the DC's are located in one physical site and the other two sites are also located in another physical site, each of these physical sites were once part of a separate active directory forest, each with their own certificate authorites. An active directory forest trust was instigated which followed onto a fully blown migration and finally decomissioning of the site 2 forest. From this point forward we have reason to believe the autoenrollment feature has never successfully worked.

Diagnostics:

1. We have uninstalled all the CA's and reinstalled again to no avail
2. We have restarted all 4 Domain Controllers to no avail
3. We have checked the event logs and cannot see any visible errors in relation to this problem
4. We have stopped and restarted the certificate services on all certificate authorities
5. The historic certificates which were previously autoenrolled are visible to the users when checking via the MMC certificates snapin, when adding any additional certificates to publish/autoenroll they are not viewable either via the MMC snapin or via the web enrollment page http://localhost/certsrv, when removing the historic certificates and re-adding them to be published and auto-enrolled it presents the existing problem
6. DNS is functioning with the clients able to ping the certificate authorities by hostname and via reverse lookup.

We had issues with the sysvol folder whereby it was unable to replicate the group policies from site 1 to site two, the following instructions were followed which were presented as a microsoft tech article:

"To work around this issue, set the SysvolReady Flag registry value to "0" and then back to "1" in the registry. To do this, follow these steps:
Click Start, click Run, type regedit, and then click OK.
Locate the following subkey in Registry Editor:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
In the details pane, right-click SysvolReady Flag, and then click Modify.
In the Value data box, type 0 and then click OK.
Again in the details pane, right-click SysvolReady Flag, and then click Modify.
In the Value data box, type 1, and then click OK.
Note This will cause Netlogon to share out SYSVOL, and the scripts folder will be present."



I hope the above has been informative, if you require further information please do not hesitate to ask and I will try and provide you with the information as soon as possibly feasible.

Many thanks,

QuadXT

Answer : CA Unable To Autoenroll Certificates

The root should be a standalone because the root's server should be offline, which would be easiest if never joined to the domain.  Since not joined to the domain, it cannot be an enterprise CA.  This is a typical recommended setup.

You do NOT need to bring the root CA online.  It should remain offline.  I presume that when you reinstalled the subordinates that new certificates were issued to them - if not, you do not need to bring the root online, you should keep it offline and use a flash drive, floppy, etc. to transport the data.

What kind of autoenroll certs are you trying to get?  User or computer certs?  If computer certs (e.g. DC or workstation) then you need to view the Certificates MMC snapin under the computer context.  If a user cert (e.g. EFS or email user) then you need to view under the user context.  Look under the Personal - Certificates folders within the respective area for the cert you need.

Also, check the computer context of Certificate MMC under Trusted Root Certification Authorities - certificates - and look for your root certificate there on a domain joined box.  Also, check GPO to make sure it has the current root cert being deployed:
Policy Object Name/Computer Configuration/Windows Settings/Security Settings/Public Key Policies/Trusted Root Certification Authorities
Refer:
http://technet.microsoft.com/en-us/library/cc738131(WS.10).aspx

While in that general area, look around for relevant autoenroll type certificate settings to see if they are set properly.  If you aren't sure, just ask.

Also, check AD Sites & Services - View - Services Node - expand Services - Public Key Services - Certification Authorities.  Your root should be listed, is okay if the subs are or are not listed here but the root must be.  The subs should be listed under Enrollment Services folder.

Open certtmpl.msc (Certificate Templates MMC) and view the properties of the template(s) you are not getting autoenrolled.  In particular, check the Security tab for permissions and make sure that domain\users, DC, computers for each domain is listed for each relevant type for read, enroll, autoenroll - sounds like you looked at this a little bit already.

Open certsrv.msc (CA MMC) on the sub CA and expand CAName (name of the CA) - Certificate Templates and make sure the tempalte is listed - if not then right click - issue template... to assign it to the appropriate CA.  These groups should also be listed within the CERTSRV_DCOM_ACCESS group, which is a local security group on the CA if the CA is not a DC (which is should be just a member server), or if the CA is on a DC, then it would be an AD domain local security group.

You can get clients to recheck for certs by using 'certutil -pulse' - for XP clients they would need the 03 adminpak installed to get certutil, otherwise gpupdate /force and reboot (twice if memory serves, but check after first).

When manually requesting computer certs, you need to do so from the Certificates MMC - computer context.  Then right click Personal - Certificates folder and request the cert from there so it happens under the computer context, not the logged in user.  Even if the user has permission, they are not a computer so will be rejected as being an invalid requestor type.

Make sure your DC's are updated with certs from the correct CA as well.  You can run 'certutil -dcinfo deletebad' then 'certutil -pulse' then reboot the DC (a necessary evil unless 2008 R2, if so ask) - make sure to stagger the DC reboots of course so users can still log in.

Let's start with that for now....