Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have recently been delegated the task to setup a CA in our domain environment and have a question on why Microsoft does somethings the way they do lol. I have been trying to read up on what the best practices are for going about this task, and have decided that in an ideal CA environment you should have one “offline” Root CA, and then two subordinate CAs for redundancy/issuing the certs. That is all good, I understand how this works and why, but in messing with a sandbox I have setup, the way you go about adding certificate authorities to a domain environment seems extremely trivial and against all of their best practices…

Dooes anyone know what the purpose is of an Enterprise Root CA that is integrated into Active Directory? From what I have read, once you setup an Enterprise Root CA that is integrated into Active Directory, it stays with Active Directory for the long haul and must not be turned off/renamed/touched under any circumstances. If this is true, that seems to go against the practice of setting up a standalone root CA, adding the subordinates, and then taking the root offline.

Thanks for any feedback you may have to offer!

share|improve this question
    
this right here seems like good reading that will set you straight technet.microsoft.com/en-us/library/cc700804.aspx - it's for server 2003, but I doubt the design requirements change much. –  SpacemanSpiff Jun 1 '12 at 4:08

1 Answer 1

up vote 1 down vote accepted

A root CA can easily be made an enterprise CA because that's the deployment that makes sense in some scenarios. A lot of deployments don't want or need an offline standalone root, or any intermediates at all; those can work just fine with an enterprise root. Say, for instance, if you're not issuing more than a couple of long-lived templates (so availability isn't a huge concern) and don't need to publish CRLs often.

I'm right there with you on it being a little too easy to just toss up a poorly planned CA - you develop an appreciation for how carefully they should be planned after reviewing the documentation, but it's not obvious when you're doing the install (and don't get me started on the simultaneous necessity and obscurity of capolicy.inf - put that stuff in the GUI!).

I've dealt with cleaning up these half-baked deployements more than I'd care to admit, but pulling them down is definitely doable (make sure all clients trust the new root, strip the templates from the old CA, bump the template version to force a re-enroll against the new CA); it just requires much more work and careful planning than was put into the initial sloppy deployment.

share|improve this answer
    
Thanks for the response! I really appreciate it! I rushed through the process of setting up the root ca in my sandbox and setup the enterprise CA instead of a standalone one for my Offline Root CA... Ended up recreating the environment as I really couldn't figure out how to remove all traces of the root CA and its subordinates... You wouldn't happen to have any documentation on this process by chance, would you? :P Thanks again! –  user1110302 Jun 1 '12 at 5:26
    
Most of the nuking can be done through the Enterprise PKI snap-in to MMC - the Manage AD Containers option. Stripping everything out of there for the unwanted CA gets rid of those objects in the Configuration partition of AD, which should cover your needs as far as getting rid of references to that CA. –  Shane Madden Jun 1 '12 at 5:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.