Dude, where's my Forest Root?

Let's look at a hypothetical worst-case scenario:

ü Your AD infrastructure contains one root domain and one or more child domains.

ü You've lost all the DC's in the Root domain due to hardware failure (Example: putting all DC’s in the root domain on the same SAN)

ü There are no usable System State backups of the DC's in the Root domain available

. ...i.e. you’ve gotten into a situation where you can't recover the forest root domain using any means.

How will this affect AD operations?

In short; Your forest needs to be migrated into a new forest if you’ve lost all DC’s in the forest root domain and can’t recover from a backup.

Off the top of my head, I can think of at least the following bad things which happen when you’ve lost your forest root:

· The Schema Admins and Enterprise Admins groups are gone; you will not be able to make any changes to their membership. However, as long as you have at least one GC in one of the child domains and a user in the child domain was a member of either group you should still get a Sid for the group into your access token when you log on with a user that is already a member of either group.

· Transitive trusts between child domains break, you’ll need to replace these with direct shortcut trusts to restore access from one child domain to another

· Forest trusts will break completely and no new ones can be established (forest trusts are between two forest roots, of which at least one side is now vaporized)

· DCPromo of new DC’s into the child domain may fail *(see notes below)

· DNS Resolution may fail unless the DNS servers in the child domains contain zones other than their own and/or have been configured to resolve external queries outside of the forest.

If your scenario was an empty forest root and all users and services were in a single child domain and no forest trust was in use, losing the forest root may not become immediately visible to the end-users.

Once the forest root is gone however, migrating to a new AD infrastructure is the only long-term alternative.
This would be a good time to:

a) Review the AD Backup and Disaster Recovery strategy

b) Reconsider putting all DC’s on the same physical hardware (effectively introducing a single point of failure for a distributed service)

c) If you were thinking about restructuring the AD infrastructure at some time, then now is the right time to do it.

The initial recommendation for forest root domains when Windows 2000 was released was made based on being able to separate and protect the Enterprise Admins and Schema Admins groups from the Domain Admins in the child domains. This is a valid general security measure that will prevent normal membership changes to those groups but is in itself not enough to fully protect them from a rogue admin in the child domain with physical access to a DC being able to raise their permissions enough to add themselves to either group as described in MS02-001.

 Microsoft has the tool ADMT available to assist customers with migrating/restructuring an AD infrastructure. Exchange has built-in tools for mailbox migrations using the Exchange Migration Wizard.

 

Choosing a Forest Root Domainhttp://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/deploy/dgbd_ads_xsfl.mspx?mfr=true

Recovering Your Active Directory Forest
http://technet.microsoft.com/en-us/library/cc757662.aspx

Forest Recovery Procedures
http://technet.microsoft.com/en-us/library/cc781218.aspx

Restructuring Active Directory Domains Between Forests
http://technet.microsoft.com/en-us/library/cc786927.aspx

ADMT v3.1 Guide: Migrating and Restructuring Active Directory Domains
http://www.microsoft.com/downloads/details.aspx?FamilyID=6D710919-1BA5-41CA-B2F3-C11BCB4857AF&displaylang=en

Active Directory Migration Tool version 3.1
http://www.microsoft.com/downloads/details.aspx?familyid=AE279D01-7DCA-413C-A9D2-B42DFB746059&displaylang=en

What Are Domain and Forest Trusts?
http://technet.microsoft.com/en-us/library/cc757352.aspx

How to use the Exchange Migration Wizard to migrate mailboxes from an Exchange organization
http://support.microsoft.com/default.aspx?scid=kb;en-us;328871

Microsoft Security Bulletin MS02-001Trusting Domains Do Not Verify Domain Membership of SIDs in Authorization Data

http://www.microsoft.com/technet/security/bulletin/ms02-001.mspx

Comments

• Anonymous
  January 01, 2003
  According to this KB: http://support.microsoft.com/kb/254933 "No FSMO role access is required to promote or demote replica domain controllers in an existing domain." Do you think this is correct? If so how can the new DC get a SID? And as you say, when does the DC get is own RID pool?

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  KB254933 has the name "Adding or Removing a Domain During Dcpromo Requires Access to the Domain Naming Master FSMO Role Holder". The paragraph you're referring to is referring to no acces to the DNM FSMO role being required during a DCPROMO if you're adding a second DC (i.e. replica DC) to an existing domain. You still need to be able to access the DNM FSMO DC if you're installing the 1st DC in a new child domain. I haven't looked specifically at whether a new 2nd DC in a domain gets a Rid Pool during dcpromo or after the first reboot or when it finds that it doesn't have any when a request to create a new object with a new Sid is received - you're technically only replicating existing objects from another DC when you run DCPROMO so it might not need a new RID until the next time someone creates an object on the new DC.

• Anonymous
  January 01, 2003
  > DCPromo of new DC’s into the child domain may fail You say "may" fail. Why is that? The dcpromo process will not contact the Schema Master nor the domain naming master while creating a replica DC in an exsiting domain. Creating a new child/grandchild domain will tho fail. Correct? SG

• Anonymous
  January 01, 2003
  The reason I say "may" is that the dcpromo part is unconfirmed - I just ran across that problem with a customer where we were just unable to get another DC into the domain despite our best efforts.  We didn't have time to troubleshoot that further and were fortunate enough to get a working DC from data recovery of the crashed disks. The SM and DNM roles are not relevant for Dcpromo (unless you're trying to create a new domain in which case you need the DNM). The actual amount of time that an orphaned child domain can live hasn't been tested as running one isn't a supported scenario.  60-180 days (depending on the tombstone lifetime setting in the forest) is the most reasonable guess I can make but there might be other factors that reduce that time.   Your best option is to migrate as soon as possible if you've reached that stage.

• Anonymous
  June 30, 2009
  Hello, do you know how much time a sub-domain can exist without the root domain? Thanks.