I have figured out how to get the auto-enroll working! YEAH! Although; when it comes to SCCM the site server seems to require the same "client" certificate as the actual 'clients'. What I am finding is that the certificates I create (duplicate) are Windows Server Enterprise certificates, the domain controller on the other side of the firewall that is a subordinate CA Authority is a Windows Server Standard, not Enterprise. Each time I attempt to manually enroll or auto-enroll one of the certificates I build through the Enterprise templates (which is the reason we are using Enterprise!) the client wants to get a reply from the Enterprise server. This is not going to happen over the firewall!!!
I may just have to RTFM. -----Original Message----- From: Tim Evans [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 02, 2008 11:29 AM To: NT System Admin Issues Subject: RE: PKI Infrastructure / GPO Auto Enroll over Firewall fails. I'm glad to hear that you go it figured out. ...Tim > -----Original Message----- > From: Stephen Wimberly [mailto:[EMAIL PROTECTED] > Sent: Monday, December 01, 2008 10:47 AM > To: NT System Admin Issues > Subject: RE: PKI Infrastructure / GPO Auto Enroll over Firewall fails. > > 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/> ~ ~ 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/> ~
