Changing Scope of Domain Local Group during Migration

This topic and reference link has already been covered this month. Also there is no reason to convert group type as part of a migration.  There is a proper way to handle a migrate and a way to make things harder. Changing group type is one of them. 

Thank you Jeff Shahan for your reply.

As first time community member, I was expecting concrete answer of my question. Since I'm new to Migration stuff, it's quite possible that I missed something to fully understand about usage and functioning of Sidhistory. That's why I post this question to clear things out. 

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?

I apologize for your inconvenience If I did something wrong to ask this question. However, I would appreciate if my question is answered and explained.

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

1. Migrate/Merge all in users and groups to target with sidhsitory 
2. 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).
   
3. 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. 

Jeff Shahan

Thank you for understanding my perspective and providing insight about the topic. I appreciate that you explained the best possible way to handle migration without changing group scope.

Just last clarification is required regarding Sidhistory so that I'm absolutely clear. As you said, we don't need to change group scope while migration. But let's consider for a while, we did this at first place. 

So as per scenario mentioned below:

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.

Clarification: Now if I add newly created Target Domain user to migrated Global Group (Target Domain) then Target Domain user should be able to access resource in Source Domain via Sidhistory of migrated Global Group (Target Domain) because Sidhistory (Sid of source Domain Local Group) is now part of migrated Global Group (Target Domain ) & Sid/Sidhistory of Global Group is always allowed to cross trust boundary. So access should be granted to Target Domain user as per mentioned reason. Am I right?

Please reply and confirm specific to the scenario. Then I'll be all set.

Thanks again in advance!

Sure. That would work, but again there was no reason to change the scope of the group. Simple add the target object that match the source objects to the source local group. This the right way to handle it. 

Remember when you change the scope of the groups authority (where is can be used to grant access) you change the scope of membership (where a member can come from). So if the member is is from a trusted domain, they will have to be removed to allow you to convert it. 

what is easier, change the scope of the group to add the target members to the source groups? 

Jeff Shahan

Thanks for your prompt reply.

So below statement as mentioned in article - https://activedirectoryfaq.com/2014/10/ad-migration-migrate-domain-local-groups-migrating

Their statement: sidhistory of migrated Global Group (Target Domain) is removed while accessing resource (secured with Source Domain Local Group) in Source Domain. 

It is actually incorrect and wrong. We can't reply on this. Right? Please confirm.

It is wrong. If it was true, changing the scope of a domain local group to a domain global group with the sidhistory of the source local group would not grant access to a resource secured with the source domain local group. Besides sidhistory of a migrated global group is not the Sid that access to the source resource is controlled. So there or not does not matter. You must have a key for the lock to open the door. The statement is tell us a key that does not open the lock is being discarded. Why would it matter one way or the other? 

Jeff Shahan

You said: Besides sidhistory of a migrated global group is not the Sid that access to the source resource is controlled.

My point: Each Sid or Sidhistory is a key and each ACE on resource DACL is lock. So when Target Domain user will try to access resource in Source Domain, then Sidhistory will also be included and that will be compared against Sid of source Domain Local group ACE. Since there is match, so access to resource is allowed or denied as per permission granted to Source Domain Local group. In other words, if Sidhistory not included then access will not work. So as per my understanding, Sidhistory of migrated Global Group (Target Domain) is actually play role while accessing resource in source domain. 

But you said, access to the source domain resource isn't controlled by Sidhistory of migrated Global Group. Please explain what I missed to understand and also explain then how access to the source domain resource is controlled (if Sidhistory does not control or play any role).

peter dan rock said:

Their statement: sidhistory of migrated Global Group (Target Domain) is removed while accessing resource (secured with Source Domain Local Group) in Source Domain. 

peter dan rock said:

But you said, access to the source domain resource isn't controlled by Sidhistory of migrated Global Group.

Based on the quoted text below, the error in their statement is clearly written 

peter dan rock said:

resource (secured with Source Domain Local Group) in Source Domain. 

peter dan rock said:

My point: Each Sid or Sidhistory is a key and each ACE on resource DACL is lock. So when Target Domain user will try to access resource in Source Domain, then Sidhistory will also be included and that will be compared against Sid of source Domain Local group ACE. Since there is match, so access to resource is allowed or denied as per permission granted to Source Domain Local group. In other words, if Sidhistory not included then access will not work. So as per my understanding, Sidhistory of migrated Global Group (Target Domain) is actually play role while accessing resource in source domain. 

 Only is the source domain local group’s Sid is present on a target global groups sidhistory. But that is not how the statement was worded.