Changing Scope of Domain Local Group during Migration

Question

Hello Tech Guys, 
 Here is the scenario: 
 Source Domain Local Group is entered in the ACL of the resource and resource is on Source Domain server. Source Domain Local Group has been migrated to Target Domain with sidhistory and during migration group scope has been changed to "Global Group". It means Target Domain Global Group has Sid of Source Domain Local Group under sidhistory attribute. 
 Now if I add newly created Target Domain user to migrated Target Domain Global Group then user should be able to access resource in Source Domain. However, as per https://activedirectoryfaq.com/2014/10/ad-migration-migrate-domain-local-groups-migrating it says that sidhistory of Target Domain Global Group is removed and access is denied while accessing resource in Source Domain. 
 As per my understanding, only Sid/Sidhistory of Domain Local Group is not allowed to cross trust boundary. But since during migration scope has been converted to Global Group, it means Sidhistory is now part of Target Domain migrated Global group. Sid/Sidhistory of Global Group is always allowed to cross trust boundary. So logically Target Domain user should be able to access resource in Source Domain. 
 
 So am I wrong OR information given in article is incorrect OR did I miss something to understand? Please answer and clarify. 
 
 Thanks & Regards, 
 Peter Dan

Jeff Shahan · Accepted Answer

Greetings Peter 
 See this thread on the same topic. ( https://www.quest.com/community/migration-manager-for-ad/f/forum/31580/domain-migration-access-denied-after-changing-group-type-and-resource-access ) 
 It started with the same question and and quickly headed down a dark rabbit hole. There is a flawed premise in the ActiveDirectoryFAQ article. 
 peter dan rock said: As far as this topic is concerned, I did not find any thread which explains why Sidhistory of migrated target domain global group is removed and access denied while accessing resource in source domain despite of the fact that Sid/Sidhistory of Global group is allowed to cross trust boundary. So basically I just want to know is my understanding incorrect or did I miss something to understand? 
 The fact, Domain Local Groups can not be used to secure or grant access to resources in a trusting domain. This is a core functional administrative principle for active directory management. So if you migrate the source domain local groups sid to the target domain local group sidhistory, it adds no value. You have effectively given the office "keys" in one building to someone locked in another building. Now if the office is moved to the other building, those keys would work. 
 The proper way to migrate, using a user and workstation first, servers second strategy is as follows 
 
 Migrate/Merge all in users and groups to target with sidhsitory 
 Update the Group membership for the source domain local groups to append the target users, global and universal groups <-This is how access to source resource is maintained. For Quest Migration Manager, this is done using Active Directory Processing Wizard (ADPW). 
 If server local groups are being used, run a Resource Process Task the Servers to append the target users, global and universal groups in the Server local groups (For this example, only the Groups are being processed) For Quest Migration Manager, this is done using the Resource Update Manager (RUM). 
 
 A. Now when a when a migrated users tries to access the resource access is granted to the following 
 
 Permission granted to source User (SidHistory) 
 Permission granted to source global or universal group (sidhistory) 
 Permission granted to domain local group (via membership of target object in source domain local group) 
 Permission granted to server local group (via membership of target object in source server local group) 
 
 B. So if you changed the domain membership of the server from source to target, now sidhistory for domain global groups would come into play. Only step 1 is needed. NOTE: This is an example for show only. Executing this in production will result in the loss of access to all source users to resources secured by source domain location groups. 
 
 Permission granted to source User (SidHistory) 
 Permission granted to source global or universal group (sidhistory) 
 Permission granted to domain local group (sidhistory) 
 Permission granted to server local group (sidhistory) 
 
 It is normal to process all of the securable resources on a member server, appending permissions for all target objects. The trusted domain local groups will be present on the file system and not provide any access until they the server is moved to the target. However the users, global and universals will grant access. 
 Sid History is a crutch to help speed up the migration. The single longest task in any migration is the processing of the file system permissions. Disks are slow and hold a lot of permissions. So in example A, I only needed up update source domain group membership and source server local group membership. Had sid history not been migrated, I would have has to update all permissions on all resources as an additional task for example A. In the real world, there is alot more then a single server. To the time to complete the resource processing task can be considerable.

Changing Scope of Domain Local Group during Migration

Top Replies