Friday, February 10, 2012 9:08 PM
I've checked and tried almost every other post on these boards trying to find a solution to this issue. I have multiple domain controllers all running Windows Server 2008 R2. I'm unable to enroll certificates to these other domain controllers from the CA.
When ever I attempt to do so I recieve a..
Certificate enrollment for Local system failed to enroll for a DomainController certificate with request ID N/A from FQDN/CA (The RPC server is unavailable. 0x800706ba (WIN32: 1722)).
I've checked permissions under dcomcnfg.exe, i've verifiied no firewalls are in place, and the CA is handing out certs to users as needed. I've also verified that certutil -ping -config fqdn\ca from another domain controller and completes sucessfully.
Connecting to xxxx.xxxx.xxxx.com\intra-terra-ca ...
Server "intra-TERRA-CA" ICertRequest2 interface is alive
CertUtil: -ping command completed successfully.=
Anyone have any other thoughts? Not sure what else to try.
Saturday, February 11, 2012 5:41 AM
Are you able to issue certificates to any other DC int your domain or does this apply to all your DCs?
Can you check:
- The members of the group Certificate Service DCOM Access and verify that DCs are included directly or inderectly
- The Permissions on your CA server and verify the DCs have the Request Certificates permission directly or inderectly
Monday, February 13, 2012 2:52 PM
Thanks for the reply.
Both those options appear to be set correctly. On the CA, the domain controller security group has permissions to request certificates. I also specifically added another DC directly for testing and the same issue occurs.
Ive also verified that the domain controller security group is listed in the Certificate Service DCOM Access group as well.
*Edit* I forgot to answer your first question. It occurs across the entire environment on every DC other then the CA. Also, end users are able to recieve certificates from the CA for local machines.
- Edited by IT Ninja Master Monday, February 13, 2012 2:56 PM
Tuesday, February 14, 2012 8:54 AM
- are the DC accounts members of the Users group on the CA machine?
- are the DC accounts allowed to "Access this computer from network" on the CA machine?
- download PSEXEC to one of the problematic DCs. Start CMD under local system account of the DC by using PSEXEC -D -I -S CMD. From the command line running under the local system, try some network access against the CA computer, such as DIR \\ca\someshare, MSINFO32 and connect to the CA, COMPMGMT.MSC and connect to the CA, etc.
- you can also download Network Monitor to an affected DC or the CA and try to capture the traffic that is (non)happening during a manual certificate request for the template.
- Marked As Answer by IT Ninja Master Tuesday, February 14, 2012 2:39 PM
Tuesday, February 14, 2012 2:38 PM
I just tried making the DC account members on the users group on the CA machine and that resolved the issue perfectly.
Tuesday, February 14, 2012 2:58 PM
You never need to add any computer accounts to the local users group on the CA server to have this running (unless you do have some really special requirements), so please check the User Rights Assignment policies on the CA server for a more sustainable solution.
Tuesday, February 14, 2012 6:35 PM
Hasain, he is running the CA on one of the DCs and I am afraid, in that case you need to be member of Users group on the DC (unfortunatelly that means on all DCs as well). I have myself reported this issue in this newsgroup as a bug some time ago. I was not able to make it work without the client being member of Users group. It is not matter of any user right actually. I blame some internal DCOM permissions on DCs. It is just not able to start the COM server without the client being member of Users group. The permissions are on a registry key as I used Process Monitor to troubleshoot the issue. On member servers it works normally.
- Edited by Ondrej SevecekMVP Tuesday, February 14, 2012 6:40 PM
Tuesday, February 14, 2012 6:37 PM
one followup - here is my previous post on this issue:
it actually seems to be registry related, sory for confusion in my recent post.
- Edited by Ondrej SevecekMVP Tuesday, February 14, 2012 6:39 PM