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.  

  • In reply to Jeff Shahan:

    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.
  • In reply to Jeff Shahan:

    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
  • In reply to questmigrator:

    * 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.

  • In reply to Jeff Shahan:

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

    Hi Jeff,

    All works great, fantastic! One last snippet of info needed please, in the ADPW GUI. The section that indicates "Process these Objects", I do not want the tool to work overtime. A brand new Security Delegation model will be created in the Target Forest, that being said what is the best options to choose from for my scenario?

    Thanks,
    Jeffrey
  • In reply to questmigrator:

    ADPW only runs against one domain at a time. You can limit it down to run against a single OU in that domain as well. You only need to process the Group Membership in each of the trusting domains to update the group membership from the source domains.
  • In reply to Jeff Shahan:

    Appreciate all the feedback Jeff! One last explanation please "Linked Attributes" in the wizard?

    Thanks,
    Jeffrey
  • In reply to questmigrator:

    What are you asking? What is a linked Attribute? Or what does ADPW process when linked attributes are selected?
  • In reply to Jeff Shahan:

    What does ADPW process when linked attributes are selected?
  • In reply to questmigrator:

    In your migration uses case, it really does not apply. A Linked Attribute like Manager has a value that is a DN of another relative object in the same directory. In an Intra-forest migration this would useful as the manager of an object was migrated between domains.
  • In reply to Jeff Shahan:

    Thank you for the clarification, for some reason I was thinking Backlinks. I was way off