Exactly. You need to setup Enterprise Subordinate CA. Standalone CAs are useless in domain envionments, because they don't support certificate templates, autoenrollment, MMC-based enrollment and so on. All these features are available on Enterprise CAs only. In order to install Enterprise CA you MUST have Enterprise Admins permissions, because Configuration naming context is replicated between domain controllers in the forest (not only current domain) and are writable for Enterprise Admins (domain admins permissions are insufficient).My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Indeed, I installed the sub ca with my domain admin account. I removed the sub ca, rebooted, logged on with my enterprise admin account and at least, I can install the sub ca as an enterprise. Thanks!Peter Van Keymeulen, IT Infrastructure Solution Architect, www.edeconsulting.be

Indeed, I installed the sub ca with my domain admin account. I removed the sub ca, rebooted, logged on with my enterprise admin account and at least, I can install the sub ca as an enterprise. As you said, I will play with the permissions because the root CA will not be reachable from within some sites. That's the only reason why we install sub CAs. Thanks for the support !!Peter Van Keymeulen, IT Infrastructure Solution Architect, www.edeconsulting.be

> So, even if we do automatic enrollment, we do not need a sub CA on the sites that are NOT able to connect to the root CA? no. Clients must be able to contact CA server directly for enrollment.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

OK. Since each computer should be able to connect to the CA, which is not possible, I have to install a subordinate CA in each of these sites. How do I configure the computers in these sites to contact and use the sub CA on their own site instead of the root CA? I can use site based GPOs, but I can see any parameter (in the Public Key Policies part) to assign a CA to a site. peter Peter Van Keymeulen, IT Infrastructure Solution Architect, www.edeconsulting.be

> Since each computer should be able to connect to the CA, which is not possible, I have to install a subordinate CA in each of these sites. yes. > How do I configure the computers in these sites to contact and use the sub CA on their own site instead of the root CA? you don't need. Clients will automatically figure out which CA is reachable.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Thanks. I'll setup sub CA in our DEV environment and have a small test.Peter Van Keymeulen, IT Infrastructure Solution Architect, www.edeconsulting.be

In the past, I installed and configured several CAs to use by SCCM or Exchange. But that were always single enterprise Root CAs without other CA server involved. So, Im not familiar with subordinate CAs, sorry for the questions, but its not that clear for me. How will these clients find a reachable CA? I installed a subordinate CA but I can't find any information about this CA in the configuration naming context while the Root CA info is in there. I just installed the sub ca and imported the root ca certificate. The sub ca started without any issues. But I cant believe that this is the only thing I should do. I stopped the root CA service and tried to renew an existing client certificate, and, as I thought it would be, the request failed because the root ca is no longer reachable. Without any additional task, the root certificate will be distributed among all computers that are member of the forest, by default. But how does the intermediate or subordinate CA certificate comes onto my clients? Should I publish this in AD, in opposite to the root ca certificate? Peter Van Keymeulen, IT Infrastructure Solution Architect, www.edeconsulting.be

if you setup Enterprise CA, then it automatically introduces itself in AD (Enrollment Services container).My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

yes, but what about the subordinate CA ??Peter Van Keymeulen, IT Infrastructure Solution Architect, www.edeconsulting.be

doesn't matter whether this is root or subordiante CA.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

we're now already 2 hours after the sub ca setup and the enrollment services OU in the ad config still only contain the root ca server, not the sub ca??Peter Van Keymeulen, IT Infrastructure Solution Architect, www.edeconsulting.be

make sure if you have installed Enterprise CA (not Standalone CA).My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

the root ca is an enterprise ca and his information is stored in AD config. The sub ca is a stand alone, that was the only type I could select during the installation. This sub ca is installed in a child domain of the domain where the root ca has been installed. Can that be the problem?Peter Van Keymeulen, IT Infrastructure Solution Architect, www.edeconsulting.be

Exactly. You need to setup Enterprise Subordinate CA. Standalone CAs are useless in domain envionments, because they don't support certificate templates, autoenrollment, MMC-based enrollment and so on. All these features are available on Enterprise CAs only. In order to install Enterprise CA you MUST have Enterprise Admins permissions, because Configuration naming context is replicated between domain controllers in the forest (not only current domain) and are writable for Enterprise Admins (domain admins permissions are insufficient).My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

On Wed, 22 Feb 2012 19:59:03 +0000, Peter Van Keymeulen wrote: the root ca is an enterprise ca and his information is stored in AD config. The sub ca is a stand alone, that was the only type I could select during the installation. This sub ca is installed in a child domain of the domain where the root ca has been installed. Can that be the problem? Yes, standalone CAs will not appear in that container. You need to ensure that you're logged on with an account that is both a local admin and an Enterprise Admin in order to create an Enterprise CA. Paul Adare MVP - Forefront Identity Manager http://www.identit.ca To iterate is human; to recurse, divine. -- Robert Heller

However, if using multiple Enterprise CAs at multiple locations, by default, you cannot guarantee autoenrollment requests will be serviced by the local CA as any one of the forest Enterprise CAs could be chosen. If access to remote Enterprise CAs will be firewalled, this constraint needs to be considered; based upon the original design premise, this is an important consideration I think... I believe this default behaviour can be prevented by correctly permissioning certificate templates on each local Enterprise CA. Cheers JJJason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

1) Enterprise CA is a forest-wide service. So, you can keep at least 1 Enterprise CA in each forest (regardless of how many domains there). 2) certificate templates are installed in Configuration naming context, so they are visible for each forest member. 3) for multi-domain environment it is recommended to push CA certificate to Active Directory. Any current forest member will receive these certificates.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Thanks for the answer. So, even if we do automatic enrollment, we do not need a sub CA on the sites that are NOT able to connect to the root CA? Are their circumstances where client computers on these sites needs direct access to the CA, which they don't have? peterPeter Van Keymeulen, IT Infrastructure Solution Architect, www.edeconsulting.be

We have an earth spanned MPLS network without firewalls between sites. All computers, regardless their AD or physical site, can talk to each other. Currently, we have only one CA in the enterprise, an enterprise Root CA on a 2008R2 domain controller on our main site. We now need to add new physical/AD sites from which only domain controllers can talk with only domain controllers from other sites. Computers or servers on these new sites cannot communicate with computers outside their own site. Question is what about our CA? I read a lot of documentation but as usually with MS doc, they explain you what all the buttons in an Airbus A380 serves for, but not how to fly the plane J. If Im not wrong: We do NOT need a subordinate CA in these new sites as long as we do NOT use auto enrollment (for workstation authentication for example). Is that correct? If we want to use auto enrollment and we need to install an subordinate CA in these sites: do we need to create new certificate templates on that SUB CA? if we use the cert templates from our root CA, clients are always connecting the root CA instead of the SUB CA? Is that correct?using GPOs, at the site level, is it enough to import the SUB CA certificate into the intermediate certification authorities and do not import the Root CA certificate into the trusted root cer. GPO setting? Is that correct? Thank a lot in advance. Regards, PeterPeter Van Keymeulen, IT Infrastructure Solution Architect, www.edeconsulting.be