It's always the simple stuff... I had forgotten to open the Windows Firewall to certsrv.exe on the sub CA.
I now have auto enrollment working like a charm!!!! -----Original Message----- From: Stephen Wimberly [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 8:57 AM To: NT System Admin Issues Subject: RE: PKI Infrastructure / GPO Auto Enroll over Firewall fails. What I'm trying to do: We are attempting to use certificates for SCCM. In the future we would like to extend the certificate structure for IPSEC authentication and we are considering the use of certificates for file encryption. We are utilizing the Enterprise level Windows Server in order to take advantage of the Certificate Templates. The Enterprise Server is generating the root CA and the SCCM certificates outlined in the 'step by step' sccm documentation and publishing those to AD. The problem comes in when the workstation attempts to "AutoEnroll" the certificates. Via network trace I can see that the workstation is requesting something from the Enterprise Server, which is behind a firewall. The firewall blocks the traffic and the Auto Enrollment fails. Since the firewall was the problem, I thought that MAYBE another CA on the same side of the firewall might be in order. So, back to my original question; do I need a CA Server on the same side of the firewall as the workstations? I only have two servers on the same network as the workstations, both are domain controllers. Or MAYBE the problem is elsewhere? The actual error I get is Event ID 13; "Automatic certificate enrollment for local system failed to enroll for one Computer certificate (0x800706ba). The RPC server is unavailable." When I attempt to gain the certificate manually I get the same error. I assume the RPC server is that of the root CA server, which is the Enterprise level server on the other side of the firewall. It's not going to reply. _SHOULD_ the workstation gain everything it needs from the Domain Controller rather than any CA Server??? -----Original Message----- From: Tim Evans [mailto:[EMAIL PROTECTED] Sent: Thursday, November 27, 2008 1:43 PM To: NT System Admin Issues Subject: RE: PKI Infrastructure / GPO Auto Enroll over Firewall fails. Yes, an intermediate CA is the same thing as a subordinate CA. I think subordinate CA is the correct terminology. Sorry about that. >From your description, it's not clear to me what you are trying to do. Why do you have 2 CAs? For my experience, the reason why you have two is so that the root CA can be kept off line for added security. The root CA is used to generate the certificate for the subordinate CA, and isn't used again except for CRL updates and to renew the cert on the subordinate CA. The subordinate CA is the one that is used day to day in issuing certificates. >From you description below, you say that you have an enterprise CA server publishing to AD. Is that your root CA? What does the subordinate CA do? You don't need windows enterprise to issue certificates - you only need it if you want to make changes to the templates of the certs that are issued. ...Tim > -----Original Message----- > From: Stephen Wimberly [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 27, 2008 3:34 AM > To: NT System Admin Issues > Subject: RE: PKI Infrastructure / GPO Auto Enroll over Firewall fails. > > Is the 'intermediate CA' the same thing as a 'subordinate CA.' I > installed the CA services on the DC as a subordinate CA server, maybe > it needs to be an Enterprise CA server? > > Overview: > Windows Enterprise running Enterprise CA Server publishing to AD Two > windows standard running DC ====== Firewall ========== (DCs replicate > via IPSEC) Two windows standard running DC; one running Enterprise > subordinate CA server Workstations. > > > -----Original Message----- > From: Tim Evans [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 26, 2008 4:22 PM > To: NT System Admin Issues > Subject: RE: PKI Infrastructure / GPO Auto Enroll over Firewall fails. > > Our root CA is off line. I only fire it up every couple of months to > keep it patched and update the CRL's. You will need an intermediate CA > online somewhere to issue certificates. The problem is that, if you > want to use certificate templates and modify the defaults, you need > windows enterprise for the intermediate CA that actually issues the > certs. Our root CA is standard, but the intermediate CA is enterprise. > > > ...Tim > > > -----Original Message----- > > From: Stephen Wimberly [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 26, 2008 1:06 PM > > To: NT System Admin Issues > > Subject: PKI Infrastructure / GPO Auto Enroll over Firewall fails. > > > > The plan was to user our SQL Server (the only Enterprise level > > server we > > have) to issue the root CA, publish it to Active Directory and use > GPO > > to push the computer certificate to the workstations. > > > > The plan _almost_ works.... > > > > The workstation fails on auto enrollment because it is sending out a > > request directly to the SQL server (root CA server) to register the > > certificate. (I see this via WireShark) The SQL server is behind a > > firewall and we really don't want to open any more ports. > > > > Is there a way (that I'm obviously missing) to push the certificates > > directly from AD (Server 2003 R2 STANDARD) so there is no required > > communication back to the root CA Server??? I'm wanting all the > > communication to come directly from the domain controller that is in > > the same network. > > > > Do I need to set up the DC as a subordinate CA? > > > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
