Windows 2008 R2 CA cert request error

Here's an error from the requesting client:

Log Name:      Application
Source:        Microsoft-Windows-CertificateServicesClient-CertEnroll
Date:          12/29/2011 10:44:27 AM
Event ID:      13
Task Category: None
Level:         Error
Keywords:      Classic
User:          123\jdoe
Computer:      comp1.hq.123.org
Description:
Certificate enrollment for Local system failed to enroll for a Machine certificate with request ID N/A from abc_v5.hq.123.org\hq-abc_V5-CA (The RPC server is unavailable. 0x800706ba (WIN32: 1722)).

On the CA-Server:
Can you please check if the
a) Authenticated users
b) interactive and domain users  were missing from builtin\users group.

If yes, can you please Add
a) Authenticated users
b) interactive and domain users to builtin\users group.

after the above activity you need to restart the CA Service

Have you tested this from multiple computers?

Have you double-checked your server and client since the problem started to make sure the firewall hasn't been reactivated by a change in OU location, GPO or antivirus installation?

Can you verify that DNS properly resolves from that client, and there are no hosts file entries for that server?

You issue is that you can not request certs for computers from a 2008 R2 CA.  You need to install the Web Enrollment services if you want to be able to do this.  With that said, AutoEnrollment of computer certs will work fine.  But if you want to go out and manually request a cert, this must be done from the Web Enrollment Service.  http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=1746

I set this up on a seperate machine and had to create an account that could "request on behalf of".  The link above should provide what you need.  I know it is strange, but you can not request a computer certificate unless this has been implemented.  I have this configured and working like a champ.  The cool thing is that you can export the reg key and import to configure on each client after the first initial configuration.  Hope this helps!

Lville Systems Jockey

This forum maybe of interest where debugging log can be enabled to see where possible failure lies and it was solved due to gpo customised setting restricting outgoing ntlm authentication.
 http://social.technet.microsoft.com/Forums/ar/winserversecurity/thread/813e944b-a517-4b2f-9807-4e3ac3d6a79d

Another here http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/8bb5807f-73ba-4092-abc8-283d8fced6c4?prof=required

Authenticated users, interactive and domain users were and are members of the of the builtin\users group.

I have checked this on multiple machines, and the same problem occurs on all.

The firewall is and has been disabled on the CA.

DNS resolution works fine and there are no host entries on the server.

Certificate enrollment policy web service, certificate authority web enrollment and certificate enrollment web service are all installed on this CA.

Here again is where I’m having trouble:

1.      From a Windows 7 domain computer I open an MMC with the certificates snap-in installed (Local computer)
2.      I right click on “Personal” and choose All Tasks > Request new certificates.
3.      I choose “Computer” in the Active Directory Enrollment Policy section of the cert enrollment wizard.
4.      After I click “enroll” I get the error message listed above.

Tballin:
Did you see my comment above?  It is my experience that you have to install the Certifficate Enrollment Web service and the Certificate Enrollment Policy Web Service.  It is added under roles.  See screenshot.  And post from above.
-Lville Systems Jockey

LouisvilleSystemsJockey,

I think you missed my comments above - those services are already installed:

"Certificate enrollment policy web service, certificate authority web enrollment and certificate enrollment web service are all installed on this CA."

What if you try manually requesting the certificate from the Certificates MMC? Just think thinking whether the template has allow permissikn for the machine, probably it is already has.

 By default, the Computer certificate template has Read and Enroll permissions for computers in the local domain.  So if you want to use this certificate template for computers in other domains, you will need to add a security group that contains the computers from your new domain and grant this group Read and Enroll permissions.  it should be possible from the Security tab of the certificate template. Just thinking Loud.

Probably you already saw this link before
 http://technet.microsoft.com/en-us/library/cc731429(v=ws.10).aspx

Yes, that would be the first option I would think if it was on the domain.  I'm was just assuming it is not domain joined and connecting from the internet.  Big assumption.

Requesting certificates manually using the certificates MMC is the only way I have tried...

FYI -

Not sure having to put in the actual ip address is going to help to isolate the issue. I saw in some forum which they resolved similar error but due to in btw vpn restrict rpc protocol
 http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/64cb4674-c307-43ba-a066-869d1490b50c

Looks like not easy to drill down as all necessary right are avail, maybe now is to make sure nothing in btw client and ca server....

this old link has couple of troubleshooting guide, may help but seems like you have done that already...
 http://blogs.technet.com/b/askds/archive/2007/11/06/how-to-troubleshoot-certificate-enrollment-in-the-mmc-certificate-snap-in.aspx

Using the IP address didn't make a difference.

FYI, I've tried running certutil -Ping -Config CAMachineName\abc_v5.hq.123.org on the CA (server abc_v5.hq.123.org) and I get the same thing!

what if it is certutil -Config "abc_v5.hq.123.org\CAMachineName" -Ping ?
- Also CAMachineName is the subject name of the certificate for that CA

one tedious way is to sniff machine traffic to see if it does resolve the fqdn correctly or there are some RST packet along the way for negotiation, though I understand that pinging (not using certutil) can reach the CA.

Quite strange though

Sorry we couldn't get a quicker resolution; I'm glad you got it running.

This was the solution