Solved

Certificate cross AD forest trust

Posted on 2008-10-21
7
3,107 Views
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.
0
Comment
Question by:U_Mansson
  • 4
  • 3
7 Comments
 
LVL 31

Expert Comment

by:Paranormastic
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.
0
 
LVL 8

Author Comment

by:U_Mansson
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?
0
 
LVL 31

Expert Comment

by:Paranormastic
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.
0
Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 8

Author Comment

by:U_Mansson
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.
0
 
LVL 31

Accepted Solution

by:
Paranormastic earned 500 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)
0
 
LVL 31

Expert Comment

by:Paranormastic
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!
0
 
LVL 8

Author Closing Comment

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

Kind regards
Ulf M.
0

Featured Post

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

Starting in Windows Server 2008, Microsoft introduced the Group Policy Central Store. This automatically replicating location allows IT administrators to have the latest and greatest Group Policy (GP) configuration settings available. Let’s expl…
A quick step-by-step overview of installing and configuring Carbonite Server Backup.
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …

706 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

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now