Ondrej Žilinec – IT Blog

Today I tried to split two domain created in one AD forest.

Scenario

I had 1st created domain domain.local which was top-forest root domain. It contained two domain controllers (SRVDC01.domain.local (W2008R2) and SRVDC02.domain.local(WS8)). Second domain I’ve created was domain2.local which was in same AD forest, but in different AD tree. I had little problem when creating new domain domain2.local, because SRVDC02.domain.local was powered off for couple days. DCPromo on SRVXX01.domain2.local was complaining about some replication problems. So I needed to power it on and force replication. It was weird, because SRVDC2.domain.local haven’t hold any of FSMO roles. When it was all done, all looked up and running.

Starting the division

We have to think about division first. Differences between top-forest root domain and others are:

• top-forest root domain contains Schema Master FSMO role
• top-forest root domain contains Naming Master FSMO role
• top-forest root domain contains AD Groups Schema Admins
• top-forest root domain contains AD Group Enterprise Admins

None of those contains any other AD besides top-forest.

First of all we need to delete implicit AD trust between domains. When you launch AD domains and trusts you can see two way “Tree Root” trusts.

You can notice that you cannot delete this trust via GUI. So let’s use command line :-). I used following netdom command on both domains:

netdom trust /d:domain2.local domain.local /remove /twoway /force

This worked only on site top-forest root domain. After deleting trust on domain domain.local I was not able to delete trust on domain2.local.

Now we need to remove all evidence from domain.local about domain2.local by:

Removing server from Sites by ADSI Edit

Remove server SRVXX01.domain2.local in ADSI Edit from path:

Configuration --> Sites --> CN=<Site-name>

Removing domain from Metadata using ntdsutil.exe

 

ntdsutil: metadata cleanup

metadata cleanup: connections

server connections: connect to server SRVDC01

Binding to SRVDC01 ...

Connected to SRVDC01 using credentials of locally logged on user.

server connections: q

metadata cleanup: select operation target

select operation target: list domain

Found 2 domain(s)

0 - DC=domain,DC=local

1 - DC=domain2,DC=local

select operation target: select domain 1

No current site

Domain - DC=domain2,DC=local

No current server

No current Naming Context

select operation target: q

metadata cleanup: remove selected domain

"DC=domain2,DC=local" removed from server "SRVDC01"

 

So now top-forest root domain domain.local doesn’t know anything about domain2.local domain.

When we try this steps do in domain2.local we receive Access Denied error.

Also when we dig into FSMO roles. We have to know that in AD forest there is only one holder for Naming Master FSMO role and only one holder for Schema Master FSMO role. Other three FSMO roles are in each domain. In this situation we have all five roles in top-forest root domain where we are all set. We have problem in underlying domain domain2.local because we are missing those two AD forest-wide FSMO roles. DCs can seize FSMO roles to other DCs if those DCs with roles are gone and never come back online. So let’s seize those two FSMO roles in domain2.local to DC in domain2.local:

The problem is Insufficient Rights. And here is a huge problem. These FSMO roles can be seized only by users with membership of Schema Admin and Enterprise Admin AD groups.

So now we know that we are missing forest-wide groups in domain2.local.

Only way I can fake accounts identity in new domain is to create same named groups, but most important, those groups have to have same SIDs. It’s not possible to change SID for existing accounts in domain, so only think I can think of, is to use sIDHistory field. This field of AD object is used mostly when migrating accounts from one domain to other. After two days I want not able to fill this field with SIDs from old domain, so I think it’s not possible. If you know how to do so, please, let me know.

Another thing is that RootDSE Naming Context is not replicating to all domains – it’s just in top-root forest domain and all information in this context is poiting to this top-forest root domain.

Conclusion

It’s not supported and possible to split two AD domain in one AD Forest. There is too many informations connecting all domains to top-forest root domain. All domains in AD Forest are tight together.

Thanks Ondrej Sevecek (www.sevecek.com) for active discussion about this topic over e-mails.