Certificate cross AD forest trust

Posted on 2008-10-21
Medium Priority
Last Modified: 2010-04-21
I have a new forest trust between two Windows Server 2003 servers, Forest A and Forest B. My Enterprise Root CA is installed in Forest A. Auto enrollment for computers with GPO is configured and is working i Forest A.
Now I need to autoenroll computer certificates i Forest B. How do I do this?

On Technet I found information on how to publish certificates in a foreign AD by running the following command;

certutil -setreg CA\AlternatePublishDomains +"DomainName"

Here is the link I found it on; http://technet.microsoft.com/en-us/library/cc786746.aspx
Is this the right thing for me to do?

Then whats next? Do I need to give permission on the Win2003 Server i Forest B to able to distribute new certificate in Forest B? Do I need CA installed on that machine or does it get all information from Forest A.
Question by:U_Mansson
  • 4
  • 3
LVL 31

Expert Comment

ID: 22775303
We had looked into doing this once ourselves and the simple answer is that you need to have a CA in the forest that you need autoenrollment for.  We had even contacted Brian Komar (one of the world's top experts on PKI who has written some of the best books) on this topic, and he confirmed this for us.  Manually issued certs are not an issue - only the autoenrollment process itself.

You should be able to use your root CA to issue a new CA cert to an issuing subordinate or policy server in the new domain and still work with the same root.  If you had set up your PKI correctly initially, it shouldn't really matter for domain membership as the root should have been created and kept offline (hence never joined to a domain) and so the issuing sub CAs should be added to the desired domains.  That way even if Forest A goes away, Forest B would not be affected.  That being said, if this was not done 1) maybe this would be a good time to convert to a proper infrastructure and 2) if absolutely need be you should be able to use the root from A to create the sub in B.

Author Comment

ID: 22775376
Hi Paranormastic

Thank you for your answer.

We currently have a Enterprise Root CA, I guess with the information you have given me that we should change/reinstall that to a Stand Alone CA instead.
And then after that go ahead and install the sub CA server in Forest B. Then from that server issue the cert by autoenrollment.

Did I understand you correctly?
LVL 31

Expert Comment

ID: 22775644
It should still be an Enterprise Root CA, just not joined to a domain.  Stand-alone CA is usually when you don't want to integrate with AD at all.  You can use the same Ent. Root CA to have Ent Sub CA in multiple domains/forest.  Join the last tier of CAs to the appropriate domains.
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.


Author Comment

ID: 22775678
Ok, I didn't know that! Interesting.

So I just install an Enterprise Root CA on a stand alone (workgroup) machine. Then the sub CA are members of Forest A and Forest B. I thought it was a prereq to be a member of a domain for a enterprise root ca.
LVL 31

Accepted Solution

Paranormastic earned 2000 total points
ID: 22775902
Also keep in mind that by reinstalling the root CA that you will be needing to reissue the CA cert for the CA in forest A.  Although a good idea in the long run, it is a bit of a (royal) pain in the short term.  Make sure to backup everything in the ca first - do a full system state backup.  Also backup seperately, just to be on the safe side, the CA database, CA private keys and so forth - this can be done easily in the Certificate Authorities MMC GUI using the backup option in there.

Note that this will affect your existing issued certs.  You might want to bring up the new environment in parallel if you can to reduce cutover time.  For replacement certs, where possible, create a new CSR (in IIS make a temp site to do this and keep it until the cert is replaced).  Have all these ready so you can process them immediately and get them installed with nominal downtime.  If you have a very large number of these, I can provide you a scirpt, but its kind of big and if you just have a couple dozen certs or so it probably isn't worth trying to figure it out.  The general command line method you can use from your workstation with certutil installed or on the CA itself is:
certreq -submit -attrib certificatetemplate:%templatename% -config %CA.FQDN%\%CAName% -f %PathToCSR%\%certreq.txt% %OutPath%\%ServerName%.cer >> c:\CertLog\SubmitCSR.log

If you were thinking of maybe going to 2008 CA, now might be a good time to do that as well.  There are some nice new features in that such as the new crypto algorithms (eliptic curve, etc.), proper support for OCSP (very nice if you issue a decent number of certs, more appropriately if you have to revoke a number of them causing your CRL to grow - this keeps CRL downloads down for Vista and newer clients), and so forth.

Plan this out and test it before doing it - I like to keep a VM environment for testing PKI stuff.  Install it like you have and and then try the migration that way so you are familiar with what you need to do, and do the real thing off-hours.

I don't remember the scenario exactly for moving just the root off the domain but keeping the sub joined - I believe that you do not need to completely decom cert services from AD for that, but just in case here is the link for that in case you do and then rejoin it using just the new CA:http://support.microsoft.com/kb/889250

Keep in mind you will need to redistribute your new root cert via GPO, etc. to your clients again in both forests.

Standard edition is fine for offline root and policy CAs, the online issuing CAs you will probably want to be enterprise edition - this goes for both 2003 and 2008 server.  

When building the new root, there are 2 ideas to use for transporting the CRL, etc. from the root to the issuing - 1) for highest security use a USB flash drive or other removable media 2) for still very good security but easier maintainability set up a small private switch (netgear, linksys ok) to set up a private network and connect to 2nd nic on sub CA.  Do NOT route on sub ca between LAN and private network.  You can then create simple batch files with scheudled tasks to move the CRL over every 1/2 CRL validity period (e.g. if crl is good for 1 month, use 'certutil -crl' to make a new one by script every 2 weeks)
LVL 31

Expert Comment

ID: 22775941
Only the issuing CA's need to be on the domain, and really only for auto-enroll functions which are tied into AD.  The term 'enterprise' throws everyone off at first - I'm not really sure what a better term would be but I wish they would come up with one.
They all need to be enterprise CAs - that is what gets you AD integration.  Offline tiers do not and should not be joined to domains.  Barring 3rd party requirements, you can use the same root for as many domains, forests, etc. as you want.  And you can issue non-autoenroll certs wherever - many companies take advantage of this with close business partners for sending secured emails, etc. You can even use smartcard authentication cross-forest, although this is complicated to set up.  Sorry, rambling a bit this morning... must be time for coffee!

Author Closing Comment

ID: 31508210
Thank you very much for your excellent answer on this subject.

Kind regards
Ulf M.

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Wouldn't it be nice if objects in Active Directory automatically moved into the correct Organizational Units? This is what AutoAD aims to do and as a plus, it automatically creates Sites, Subnets, and Organizational Units.
Transferring FSMO roles is done when an admin wants to split roles between certain Domain Controllers or the Domain Controller holding the Roles has been forcefully demoted using dcpromo / forceremoval
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
Are you ready to implement Active Directory best practices without reading 300+ pages? You're in luck. In this webinar hosted by Skyport Systems, you gain insight into Microsoft's latest comprehensive guide, with tips on the best and easiest way…

578 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question