In the source Domain environment the Domain Admins and Domain Users groups were used to assign permissions to resources. Is it possible to migrate these groups to the target domain using QMM tools and then rely on their SIDHistory to access resources residing in the source domain?
As per this Microsoft KB - Well-known security identifiers in Windows operating systems - http://support.microsoft.com/kb/243330/en-us
SID: S-1-5-domain-512
Name: Domain Admins
Description: A global group whose members are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined a domain, including the domain controllers. Domain Admins is the default owner of any object that is created by any member of the group.
SID: S-1-5-domain-513
Name: Domain Users
Description: A global group that, by default, includes all user accounts in a domain. When you create a user account in a domain, it is added to this group by default.
SID: S-1-5-32-544
Name: Administrators
Description: A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Admins group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group.
SIDs of well known GLOBAL groups will have domain portion (like S-1-5-domain-512) so will be unique.
SIDs of LOCAL Groups are not going to be unique.
Migration of SIDs for the builtinAD objectsis associatedwith TWO problems:
1. Migrating the actual SID. You can use third party tools (like QMM) to migrate built in groups.
a) Local Groups: since migrating built-in Local Groups with SIDHistory will cause SID duplications as shown above, they can only be migrated without SIDHistory.
b) Global Groups:
- Prior to QMM 8.2 it was possible to migrate built-in Global Groups with SIDHistory using QMM.
WORKAROUND 1
Moving file server to the target domain and migrating SIDHistory with Sidhist.vbs Visual Basic script that is included with the ClonePrincipal Windows Server 2003 Support Tool or following this KB for QMM 8.4: QMM 8.4 and ability to migrate SIDHistory for the built-in AD objects -https://support.quest.com/kb/SOL55958. It will work then without a trust within the target domain.
WORKAROUND 2
Migrating built-in Groups to the target so that they become matched to some groups in the target and therefore recorded in the mapping file. Then process source resources with the QMM RUM (Resource Updating Manager) so that Built-in SIDs in the ACLs are appended with the non-builtin Target Groups SIDs that are allowed over the 2003 trust (appended is preferred over replaced as the latter would involve more risks since original builtin SIDs would be removed). While doing so please also take into consideration the following:
When built in Domain Users group is merged into new group or renamed during migration, subsequent users migrations are changing Primary Group for those users
https://support.quest.com/migration-manager-for-ad/kb/41937
Note: It is important to know that well known objects are not migrated by default and in order to migrate them you need to uncheck Active Directory default objects (such as Administrators or Domain Users) under Skip objects tab under the Domain Pair properties.
Here are the steps required to migrate a builtin group such as Domain Users:
1. Migrate and rename the source Domain Users to the target via a migration session using an import file to rename the group in target to something different than domain users, such as 'domain users target'. https://support.quest.com/migration-manager-for-ad/kb/16917
2. Then within QMM right-click on the domain pair and select Properties. Then on the Skip Objects tab ensure that the option "Active Directory Default Objects" is unchecked so they will not be skipped within the sync (the synchronization is what will populate the membership of the newly created target group)
3. Because the "Active Directory Default Objects" option was unchecked in step 2, now all other default groups from the source must be explicitly excluded from the synchronization by going to the Synchronization Properties | Specify Source Scope | Set Filter | Exclude List. Then select all other default objects (like Enterprise Admins, Domain Guests, etc) to explicitly exclude from the synchronization by adding them to this list.
4. Then let the Synchronization run to ensure the newly created target Domain Users Target group's membership is populated correctly.
5. Then resource process the source resource using RUM or vmover.exe
