Migration Manager for Active Directory

Not sure how to approach this migration scenario (5 Forests > 1) Domain E is not clear to me

Hello All,

Source Domains a mix of 2003 & 2008R2 > Target 2012 R2

Migrate Domains A-E > Domain F
Everyone trusts each other (SidHistory enabled)

The following is just one example of the way groups have been setup and nested
(User and resource Forest)
Source Domain A
GG-DomainA (Global security Group)

(User and resource Forest)
Source Domain B
GG-DomainB (Global security Group)

(User and resource Forest)
Source Domain C
GG-DomainC (Global security Group)

(User and resource Forest)
Source Domain D
GG-DomainD (Global security Group)

(Resource Forest for above forests)
Source Domain E
DL-DomainE (Domain Local Security Group) With all GG-Domain (A-D) nested within.  This is just one of a number of groups that are DLs in this forest that were created to give access to data.  100's of DLs with nested groups from the other Domains (GG-DomainA-D).  In turn these DLs (DL-DomainE) have been assigned permissions on the Data that resides in this Forest.


Target Forest F
Migrate Forests A-E here.

Which is the best way to tackle (migrate) such a scenario?

Please assist,
Jeffrey

  • Which is the best way to tackle (migrate) such a scenario?

    Well that is a large, vague question.  Maybe a better question would be about migrating the groups in your example above.

    Assuming a one to one migration of all objects from each of the source domains. A many to one migration for is also an option, it would be a different configuration with the same answer.

    For a one to one migration, the same service attributes for all domain pairs.

    For a many to one migration, each domain pair will require their service attributes for each domain pair.

    The sidhistory matching rule should be enabled on the domain E to domain F domain pair.

    1. Migrate each of the source domain A-D global groups to the target domain F.

    2. Migrate the source domain E domain local groups to domain E.  When the membership is migrated, all target groups created in step 1 will be members of the target domain local groups.  

  • The order of operation really does not matter if the directory sync is running for domain E to domain F domain pair. The link resolved would update the target group membership as the newly migrated groups from domain A-D.

    The only wrinkle to this would be if you wanted to move the resources secured by the domain E domain local groups to prior to executing and/or completing the user migration. In this case you would enable the add source members to target group options when migrating the domain E domain local groups to domain F.
  • Can you please explain what you mean by the following two points?

    * For a one to one migration
    * For a many to one migration

    I have another question that is also been bothering me, say I start migrating user accounts and Groups from Source Domain A GG-DomainA (Global security Group), which in turn is nested in a Domain Local Group in (Resource Forest for above forests) Source Domain E (DL-DomainE). This DL has been assigned permissions to data residing in Domain E.

    Will the user (with Sidhistory along with the Groups SidHistory) that has been migrated from A > F still have access to the resources in E?

    Thank you,
    Jeffrey
  • * For a one to one migration
    DomainA\GG-Resource = DomainF\GG-Resource-DA
    DomainB\GG-Resource = DomainF\GG-Resource-DB
    And so on

    * For a many to one migration
    DomainA\GG-Resource = DomainF\GG-Resource
    DomainB\GG-Resource = DomainF\GG-Resource
    And so on

    Will the user (with Sidhistory along with the Groups SidHistory) that has been migrated from A > F still have access to the resources in E? Actually, no. The domain local group Sid will not present in the users access token, so access will be denied.

    To resolve this you will use the Active Directory Processing Wizard (ADPW) to process group membership in domain E. This will add domain F global groups to the domain E domain local groups, and maintain access.

  • Thank you for the feedback, I will now test this out in my lab prior to going into production.