locked
R2 AD Certificate Services running on DC can't issue to R2/win7 clients RRS feed

  • Question

  • Summary: It seems one of my 2008 R2 DC's, that is now also a AD CS, can't issue certificates to 6.1 level clients (Server 2008 R2 and Windows 7).  All the errors revolve around DCOM/RPC unavailability.  All down-level clients and servers are getting their certs.

    This was brought up in another post about autoenrollment of certificates, and wanted to start a different topic specific to this issue.  I'd like to see if anyone has a 2008 R2 DC (AD DS) that is also a CA, and they have 2008R2/win7 clients that can get certs through RPC.

    Setup:
    Win 2008 R2 forest/domain
    single site, 60 client and server computers
    Two domain controllers, with DC01 holding all FSMO roles, AD CS, and RD Gateway.  
    DC01 can get certs fine from itself
    DC02 can't get any certs using MMC or autoenrollment
    Checked the issue certificates log, and all 2003/2008/vista machines have their autoenrollment computer certs
    It seems all the 2008 R2 servers have the same problem, as well as win7 clients
    DC01 gets no errors related to CA, DCOM
    disabling firewalls doesn't help.  all other services on these boxes work fine, and this issue has been present since AD CS was installed a month ago
    certificate issuing works just fine through https
    this is consistent across all templates, computer or user

    Errors show up as on boxes trying to get certs

    • Manual enrollment: "the rpc server is unavailable" when clicking Enroll on a certificate template using the Certificates MMC snapin
    • autoenrollment: Event ID 13 for CertificateServicesClient-CertEnroll "Certificate enrollment for Local system failed to enroll for a Machine certificate with request ID N/A from servername.domain.com\domain-DC01-CA (The RPC server is unavailable. 0x800706ba (WIN32: 1722))."
    • autoenrollment: Event ID 1009 for DistributedCOM: "DCOM was unable to communicate with the computer DC01.domain.com using any of the configured protocols."
    I'ved checked and updated the DCOM AD group mentioned in this article with no change.  bcoover on that post suggests this is a known issue of having the R2 AD CS and AD DS on the same box, but I'd like to get a larger consensus before moving one of those roles.


    Other ideas?  please throw them out.  Thanks.

    Monday, February 1, 2010 3:03 AM

Answers

  • Hi guys,
    Found your thread after upgrading the last of my domain controllers last weekend to Windows 2008 R2. The CA is also on R2
    Same RPC errors, followed these steps to clear it:
    1) Found the new group called Certificate Service DCOM Access. (Different from the old group called CERTSVC_DCOM_ACCESS)
    Of note, the old group had Domain Users, Computers, and Controllers in it. The new one had NOTHING in the membership list.
    2) Added the Domain items to the new group. Waited for the change to replicate to all DC's
    3) Ran the following command on my CA.. certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG
    4) Stopped and started services (net stop certsvc, net start certsvc)
    5) Went to a problem DC and ran the certutil -pulse from the command line.

    Golden.
    Thanks for your help guys, the combined posts really helped me out!
    J

    Monday, March 1, 2010 8:02 PM
  • OK opened a case with Microsoft and we solved it in less then two hours with some serious netmon skills.  Thanks Paul!

    The issue wasn't the CA at all, although I did run through Evil Trunk Monkey's solution above, before we found the real cause.

    My issue was I had a ISA Firewall site-to-site VPN between the client and CA that had "enforce strict RPC compliance" enabled.

    In my case the CA and clients are seperated by an ISA 2006 Firewall site-to-site VPN.  All protocols are allowed, but as documented in this post on the ISA Team's blog, DCOM was being blocked because "enforce strict RPC compliance" was enabled (by default) on the system policy AND on the access rule for the VPN.  You won't see it blocked in ISA logs, but the DCOM  info inside the RPC packets over the ISA tunnel was being blocked.  Other RPC packets were going through fine.  I can only guess why ISA is OK with downversion DCOM clients with strict RPC compliance.

    If you have ISA in the middle, the solution is to add/change the site-to-site access rule as indicated in the above ISA Team blog by going to protocols tab, click filters, and uncheck the box under the RPC option.  Do this on both sides of VPN.  This could also happen if you are using ISA between two subnets, ISA between client VPN and your servers, etc.
    • Marked as answer by sonicbum Wednesday, March 3, 2010 11:05 PM
    Wednesday, March 3, 2010 11:05 PM

All replies

  • Same behaviour here.  I've been tearing my hair out, since my wireless is down without certificates (PEAP.)  Upgraded the domain to 2008 R2, and mostly it's been a good experience.  Certificate Services being the obvious exception.  Only difference here from what you're doing is our root CA is still a 2003 DC in a different site, while the subordinate CA is 2008 R2.  The subordinate CA gets its certifcate from the root CA just fine, and clients can in turn get certs from the web interface on the subordinate.  But the next 2008 R2 server (CA client, if you will, running the new version of IAS to authenticate VPN, Wireless, etc.  this box is also a DC) absolutely cannot get a certificate... we keep getting the RPC errors.  So, the consistent thing is 2008 R2 as CA can't issue to another 2008 Server running AD.

    Everything else is great, replication, DNS, DHCP, all other AD services.  Even the VPN clients are authenticating from the Cisco box to the IAS box.  Unfortunately, with this CA error the wireless clients can't get logged on.

    I've filed a ticket with Microsoft, so we'll see what they come back with.
    Friday, February 5, 2010 9:38 PM
  • Did you find the solution?
    Tuesday, February 9, 2010 9:20 AM
  • I'm still stuck and have moved on to other issues as this one isn't critical yet.  Never opened a case.  Unlike SomeClown our issue is only 2008R2 and Win7 trying to get certs.  2008 can get certs fine.
    Monday, February 15, 2010 9:29 PM
  • Hi guys,
    Found your thread after upgrading the last of my domain controllers last weekend to Windows 2008 R2. The CA is also on R2
    Same RPC errors, followed these steps to clear it:
    1) Found the new group called Certificate Service DCOM Access. (Different from the old group called CERTSVC_DCOM_ACCESS)
    Of note, the old group had Domain Users, Computers, and Controllers in it. The new one had NOTHING in the membership list.
    2) Added the Domain items to the new group. Waited for the change to replicate to all DC's
    3) Ran the following command on my CA.. certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG
    4) Stopped and started services (net stop certsvc, net start certsvc)
    5) Went to a problem DC and ran the certutil -pulse from the command line.

    Golden.
    Thanks for your help guys, the combined posts really helped me out!
    J

    Monday, March 1, 2010 8:02 PM
  • OK opened a case with Microsoft and we solved it in less then two hours with some serious netmon skills.  Thanks Paul!

    The issue wasn't the CA at all, although I did run through Evil Trunk Monkey's solution above, before we found the real cause.

    My issue was I had a ISA Firewall site-to-site VPN between the client and CA that had "enforce strict RPC compliance" enabled.

    In my case the CA and clients are seperated by an ISA 2006 Firewall site-to-site VPN.  All protocols are allowed, but as documented in this post on the ISA Team's blog, DCOM was being blocked because "enforce strict RPC compliance" was enabled (by default) on the system policy AND on the access rule for the VPN.  You won't see it blocked in ISA logs, but the DCOM  info inside the RPC packets over the ISA tunnel was being blocked.  Other RPC packets were going through fine.  I can only guess why ISA is OK with downversion DCOM clients with strict RPC compliance.

    If you have ISA in the middle, the solution is to add/change the site-to-site access rule as indicated in the above ISA Team blog by going to protocols tab, click filters, and uncheck the box under the RPC option.  Do this on both sides of VPN.  This could also happen if you are using ISA between two subnets, ISA between client VPN and your servers, etc.
    • Marked as answer by sonicbum Wednesday, March 3, 2010 11:05 PM
    Wednesday, March 3, 2010 11:05 PM
  • Hi guys,

    I've the same issue and found the following solution:

    1) run dsa.msc. Expand your domain. Expand Builtin. You'll find a group called  Certificate Service DCOM Access (other languages use localised names). Copy that name. It's not required to add Domain Users, Computers or Controllers!

    2) Click on Start, then Programs, then Administrative Tools, then Component Services.
    Expand the Component Services node. Expand the Computers node. Expand Workplace. Expand DCOM Configuration.
    Goto CertSrv Request and Right-click. Select Properties. Goto security tab.

    3) Under Launch and Activation Permissions, click Edit. Add the group Certificate Service DCOM Access from 1) and give it local and remote activation rights.

    4) Under Access Permissions, click Edit. Add the group Certificate Service DCOM Access from 1) and give it local and remote access rights.

    5) from command line run:
    certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG
    net stop certsvc
    net start certsvc

    After this I was able to sucessfully request a Kerberos certificate with mmc.exe

    Best regards, Ralph

     

    • Proposed as answer by Kolibri42 Sunday, May 9, 2010 8:14 AM
    • Edited by Kolibri42 Wednesday, May 26, 2010 7:53 AM
    Saturday, May 8, 2010 12:37 AM
  • I have done all the solutions mentioned above and I still get the RPC Unavailable error. I'm just running a test network and was having so much trouble with it not getting certs that I have set up a whole new test network to test this problem.

    My DC is 2008R2

    My CA is an Enterprise CA on 2008R2. --- I wanted to install it as a Member server but it would only install as Standalone so I added AD and then found I had to upgrade to a DC for Certificate Services.

    I have turned off all firewalls. I restart my servers after each purposed solution. I've added Domain Users, Domain Computers, and Domain Controllers to my CA's security tab in Server Mgr. I added all of them to the DCOM Solution mentioned above. I do have IIS installed but am not running ISA...at least I don't think I am...

    I've done everything and still get the RPC Unavailable with I try to get certs from my DC Server both as a computer account and as a user account. Is it that you can't have CA on 2008R2..? When I had a Standalone Root and Enterprise Sub I had no problem getting it to work but this test network is on one computer virtualized with VMware so I was trying to eliminate one computer instance by just making my Root an Enterprise CA since "security" is not an issue.

    Also, I have no problem pulling Certs locally if I'm logged on the CA grabbing a key recovery cert or a computer cert.

    I just have no idea, and I don't have much more hair left to pull out. Plus, this is really harshing my Zen when I stop and meditate for an hour and then with a fresh new mind get frustrated all over again..!

    Mark ;)

    Thursday, May 20, 2010 7:15 PM