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
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 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.
Office 365 Training for IT Pros

Learn how to provision tenants, synchronize on-premise Active Directory, implement Single Sign-On, customize Office deployment, and protect your organization with eDiscovery and DLP policies.  Only from Platform Scholar.


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

On Demand Webinar: Networking for the Cloud Era

Did you know SD-WANs can improve network connectivity? Check out this webinar to learn how an SD-WAN simplified, one-click tool can help you migrate and manage data in the cloud.

Question has a verified solution.

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

Had a business requirement to store the mobile number in an environmental variable. This is just a quick article on how this was done.
After seeing many questions for JRNL_WRAP_ERROR for replication failure, I thought it would be useful to write this article.
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…
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.
Suggested Courses

765 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