QMM Intra-Forest Migration

What is an INTRA-forest Migration?

An intra-forest migration is one that an enterprise performs to usually consolidate (entirely way too many) Active Directory Domains into (for the most part) a single AD Domain.   An intra-forest migration is the act of placing all child domain-level objects (user, groups, computers, shared folders, etc.) into a (usually) brand new Active Directory ‘child’ Domain that exists in the same Active Directory Forest as the existing Domains.  Sounds easy! Let’s do it! But wait…


Why INTRA-Forest?

Most companies that choose Intra-Forest migrations do so originally thinking that it’s easier to perform and costs less.  For the most part, that’s probably true; however, poor planning (as with any project) can be significantly more perilous and costly if not properly planned.  Thoroughly planned.  Planning and preparation is the most important (and substantial) level of effort during an Intra-Forest migration.  Execution and implementation is historically much easier.

But Brad – the planning stage of any project is most important, right?  Brad replies “Certainly!” However, if an Intra-Forest migration is not properly planned, the enterprise can very much indeed experience ‘unplanned outages’.  We know that, in the IT Industry, ‘unplanned outages’ can cripple an organizations’ ability to be prosperous.  Another consideration, and often taken for granted, is just how different an Intra-Forest migration is compared to the Inter-Forest migration.  We are bound by Microsoft AD and Exchange Design rules and (sshhh!) limitations!

Intra-Forest Migration approaches (using the QMM Product Suite) require object deletions!*GULP!*  For the reasons you’ll read below, you’ll want to be very methodical in your planning (especially the group preparation described below).  The point to the object deletion evens is to ensure that (throughout the migration timeline) you minimize the amount of time that a Forest has two separate objects containing the same SID.


QMM Intra-forest Migration Approach

Intra-forest migrations, though not historically as common, can be easier to perform than standard Inter-forest migrations.  A change of approach is required to work in a single forest model during the migration.  This blog entry outlines, at a high level, the differences and caveats of a single forest migration (intra-forest consolidation) project.


Intra-Forest Fundamentals

It’s critical to remember and understand that an Active Directory Forest DOES NOT like two separate objects (of any object class) that represent or contain the same SID.  Wait? How can two objects contain the same SID?  If you’ve asked yourself this question, this blog entry is not for you.  The migration industry standard answer is sIDHistory.  sIDHistory is an object attribute that can contain the objectSid of different objects’ SID that should be considered when an object performs the AD-authentication process (during the Kerberos ticket creation process).  A user, group, and computer object can ALL contain a populated sIDHistory attribute.  NOTE:  This sIDHistory attribute is very well protected by Active Directory and can only be manipulated by those with the advanced knowledge of how to do so. *ADUC and a smart human cannot manipulate or clear this attribute*


SID, SID History and Kerberos Authentication

The way that resources are authenticated is via presentation of a SID against an Access Control List (ACL).  The protocol for performing that presentation involves the use of the Kerberos authentication method.  SIDHistory is a multi-valued object attribute that Microsoft implemented to keep a history of all SIDs that an object may have once been known as – essentially, Microsoft hoped to use this to cheat (for lack of a better term) during migrations to avoid re-permissioning (a different blog subject), but as time went by we all learned that this was not totally realistic or scalable.

During the Kerberos authentication process, all SIDs that are related to an object are gathered and presented to the ACL.  All of the SIDs in this case means the object’s objectSID, the SIDs of groups for which the object is a member of, all of the sIDHistory entries associated with this object, and all the sIDHistory values from all of the groups for which this object is a member of.  For example, my user object 1 (with a sIDHistory of user object 2) is a member of 25 groups (these groups also have sIDHistory populated).  User object 2 is also a member of 25 different groups (these groups, too, have sIDHistory populated).  When user 1 is authenticated and the Kerberos ticket is generated, the Kerberos ticket will actually contain user objects 1 and 2 groups PLUS the groups sIDHistory groups taking group membership potentially up to 100 (from the original user object 25 groups).


Caveats of Intra-forest SIDs

Two issues arise from this approach.  First, there is a limit to the number of SIDs that Kerberos can handle and second, all SID’s collected must have a one-to-one relationship to an object in a single forest.

The Max Packet size is the value that controls how large a Kerberos ticket can be when validating access to a hosted resource (i.e., file share, NTFS resource).  The short version is that a single Kerberos ticket can contain approximately 128 SID’s (based on standard Windows Operating Systems).  Thus, if every object associated with a migration also has a SID History value that number actually drops to 64.  To be clear; these are very “average” numbers – there are many factors that will control how many objects your Kerberos ticket can contain/reference and those variations require a complete paper of their own to describe (MS has some published –https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx AND https://support.microsoft.com/kb/327825 ).

Duplicate SIDs will break the Kerberos authentication process.  Thus if sIDHistory is in play AND the object to which the sIDHistory is referencing (the original object) still exists in the forest, the Kerberos ticket will not build properly and authentication can be eventually denied.  The solution to this is to delete the original object as soon as you bring sIDHistory forward with the migrated object.



This blog entry contains terms that are used throughout the migration industry that might confuse those of us that don’t deal with migrations on a regular basis – I hope this helps.

SOURCE Domain – The ‘SOURCE’ Domain is any domain from which we are migrating from.

TARGET Domain – The ‘TARGET’ Domain is any domain that we are migrating objects to.

Logical Migration – The logical migration is the act of migrating objects when the intent is not to introduce a change to that object.  For instance, I logically migrate a user object from the Source Domain to the Target Domain, the end user is NOT YET affected – It could simply be, at the object level, pre-creating/stubbing/pre-staging the object in the Target Domain in preparation for ‘something’. The important takeaway here is to remember that a logically migrated object is not in a state to be USED by that end user.

Physical Migration – The physical migration is the act of migrating an object when we expect it to be USED immediately.  This is (from the end user’s point of view) the even that we introduce a ‘change’ to the end user.


Intra-Forest Group Preparation

This is an extremely complex subject: how to prepare ALL Forest-wide groups for the Intra-Forest migration.  This is a recommended pre-requisite before any migration activity is performed: CONVERT all (source and target) Global Groups to Universal.  This means ALL Global Groups in the Forest. (at least all groups EXCEPT Builtin groups)  This, for some organizations (depending on cross-Domain contamination), is an arduous task.  Why Brad?

During a QMM Intra-Forest migration, we need to ensure that all groups are capable of having members from different Domains within the Forest as members at any given time.  This is CRITICAL!

Global Groups can only contain members that are from the same Domain that the Global Group exists.  For example, Domain A “Global Group 1” can only contain Domain A objects as members.  This is no good.

NOTE:  To perform this pre-requisite, however, you will undoubtedly have to contend with the use of a script (executed several times) due to groups being member of other groups.  You cannot convert certain groups to Universal until other groups (that might be members) have been converted first.  There are several scripts out there that can help streamlining this pre-requisite.


Order of Operations

NOTE: The following high-level order of operations are in the context of using Quest Migration Manager – and the details of these events should be carefully planned, tested, and documented.  For those of you most familiar with QMM and have further questions about any of the events below, please contact me or Coherence, Inc.

The steps of an Intra-forest migration at a high level are as follows:

  1. Upgrade source Global groups to Universal (This is a MUST)
  2. Physically migrate all groups to target Domain.
    1. Migrate groups with Sid History and adding source members.
    2. Delete source groups
    3. Change admin point to target for all groups.
    4. Resource Process workgroup data (i.e., file servers, etc.)
    5. Execute ADPW in all domains to update group membership of Source users
    6. Optional but recommended:  Clean up sidHistory on migrated groups.
  3. Create user “stubs” in target. (i.e., Logically Migrate)
    1. Migrate user accounts, skipping sAMAccountName (migration session)
    2. DO NOT copy SID History, Password, Security Descriptor, and Mailbox.
  4. Resource process and move all workstations. (delete the source computer accounts during the physical migration – if QMM Directory Sync is running, be sure NOT to sync deletions)
    1. Exclude serviceprincipalname attribute from computer objects
  5. Resource process servers for ACL only (not required, but recommended).
  6. Migrate users (Physical Migration)
    1. Verify RMAD session ran recently (in case of an object restore requirement)
    2. Migrate selected users with Password, SID History, Mailbox, and sAMAccountName
    3. Run ADPW with custom map to update TARGET ‘Update Group Membership”. Verify migration
    4. If SQL servers present, SQL Wizard run with custom map
    5. Delete source users
  7. Migrate Servers (physical migration)
    1. Resource Process (do not double acl, replace the acl).
    2. Join to target domain
  8. Cleanup
    1. If MS SQL present, re-run SQL Wizard with all objects.
    2. Re-run ADPW, clean up legacy memberships.
    3. Verify RMAD run and user ADPW to cleanup SID History.
    4. Remove source domain.

Note that you may choose to “loop” on step three for sets of users at a time.  You may also choose to loop on step 2 for sets of groups at a time.


Leave a Reply