Domain Migration: “Access Denied“ after Changing Group Type and resource access

support.quest.com/.../considerations-when-migrating-local-groups-with-sid-history

Jeff Shahan

As per the Quest support article you shared, it says that it contains Sids of domain local group according to workstation domain.

Consider the scenario: Resource are in source domain and secured with source domain local group. During migration, source domain local group migrated with sidhistory without converting group type/scope. It means migrated target domain local group now have Sid of source domain local group under sidhistory attribute. If I add new user in migrated target domain local group and that user login to target domain workstation. Now Access token contains Sids of other global and universal groups, Sid of migrated target domain local group and Sid of source domain local group under sidhistory attribute. But ultimately, these Sids(migrated target domain local group Sid and source domain local group Sid under sidhistory) were filtered out while accessing via trust.

Consider another scenario: Resource are still in source domain and still secured with source domain local group. During migration, if I convert source domain local group to global group with sidhistory.  It means migrated group in target domain is scope of "Global" having Sid of source domain local group under sidhistory attribute. Now if I add user under the global group, then access will work as access token have Sid of source domain local group. So in this scenario, group scope is different but access is still working but as per https://activedirectoryfaq.com/2016/09/domain-migration-access-denied-group-type-change/ it says that group type/scope should be identical in each domain.

Please correct me if I'm wrong somewhere according to above mentioned points and help me to understand where and what exactly I'm lacking.  Please answer to below question as well.

Q: Resources resides on servers in source domain. Source domain local groups are applied in resource ACL. During migration, servers have been moved from source domain to target domain. Those source domain local groups have also been migrated to target domain without sidhistory. Scope of the migrated group in target domain is "Global". Migrated target group (scope: Global) is nested inside source domain local group. If I add newly created users (in target domain) under migrated target group(scope: Global), then will those users will be able to access resources through migrated target group membership (as sidhistory isn't migrated)?  If yes, does it mean that access token of those users contains Sid of migrated target group as well as Sid of source domain local group?

Looking forward to prompt reply with answer and explanation of above mentioned question and scenario.

Thanks in advance!

First off the URL you linked (https://activedirectoryfaq.com/2016/09/domain-migration-access-denied-group-type-change/ ) it is clear the issue they encountered was due to someone changing the group type after the migration. Had this change not happened, there would have been no URL to reference. Again, the resource ACE in the ACL was for a domain global group. The target domain migrated group was changed to domain local by someone that did not understand the impact of their change. 

If target equivalent migrated group is also "domain local" then how accessing resources on source domain will work for members of migrated target domain local group (having sid of source domain local group under sidhistory attribute) because access token will not be able to cross trust boundary? 

Correct Access through the target domain local group would not allow the resources to be accessed by target users.  

Access should also be working if group scope is not identical that's why changing target domain local to target global group will allow the token to cross trust boundary. 

This was the initial state of the target group. It was migrated as a domain global group. Someone changed the groups to domain local and caused the issue. 

The facts 

• Resources resides on servers in source domain. 
• Source domain local groups are applied in resource ACL.
• servers membership have changed from source domain to target domain. 
• The source domain local groups have also been migrated to target domain without sidhistory. 
• Scope of the migrated group in target domain is "Global". 
• Migrated target group is a member of the source domain local group. 

If I add newly created target users to the target group, will those users will be able to access resources? 
Yes, they will have access to the resource. 

If yes, does it mean that access token of those users contains Sid of migrated target group as well as Sid of source domain local group?
No, not exactly. The domain local group is picked up in the token when access to the resource is requested. 

Jeff Shahan

Migrated target global group is also nested inside source domain local group. Resources are secured with only source domain local group.

In last part of your reply, you said that target user's access token will only include migrated target global group SID not source domain local group SID. But how access is granted to target user because migrated target global group SID doesn't match with source domain local group Sid( resource ACL). Please explain.

As per the Quest support article you shared, it says that it contains Sids of domain local group according to workstation domain. 

Actually the KB I shared was linked in the ActieDirectoryFAQ and that link was broken. Additionally I would say workstation membership is not really a vaild point for consideration.

The facts

• Resource are in source domain
• secured with source domain local group. 
• Source domain local group migrated with sidhistory 
• If I add new user in migrated target domain local group and that user login to target domain workstation. Now Access token contains Sids of other global and universal groups, Sid of migrated target domain local group and Sid of source domain local group under sidhistory attribute. But ultimately, these Sids(migrated target domain local group Sid and source domain local group Sid under sidhistory) were filtered out while accessing via trust.

If I add new user in migrated target domain local group and that user login to target domain workstation. Now Access token contains Sids of other global and universal groups, Sid of migrated target domain local group and Sid of source domain local group under sidhistory attribute. But ultimately, these Sids(migrated target domain local group Sid and source domain loca

gauravbhadauriaer2008 said:

As per the Quest support article you shared, it says that it contains Sids of domain local group according to workstation domain.

Consider the scenario: Resource are in source domain and secured with source domain local group. During migration, source domain local group migrated with sidhistory without converting group type/scope. It means migrated target domain local group now have Sid of source domain local group under sidhistory attribute. If I add new user in migrated target domain local group and that user login to target domain workstation. Now Access token contains Sids of other global and universal groups, Sid of migrated target domain local group and Sid of source domain local group under sidhistory attribute. But ultimately, these Sids(migrated target domain local group Sid and source domain local group Sid under sidhistory) were filtered out while accessing via trust.

Consider another scenario: Resource are still in source domain and still secured with source domain local group. During migration, if I convert source domain local group to global group with sidhistory.  It means migrated group in target domain is scope of "Global" having Sid of source domain local group under sidhistory attribute. Now if I add user under the global group, then access will work as access token have Sid of source domain local group. So in this scenario, group scope is different but access is still working but as per https://activedirectoryfaq.com/2016/09/domain-migration-access-denied-group-type-change/ it says that group type/scope should be identical in each domain.

Please correct me if I'm wrong somewhere according to above mentioned points and help me to understand where and what exactly I'm lacking.  Please answer to below question as well.

Q: Resources resides on servers in source domain. Source domain local groups are applied in resource ACL. During migration, servers have been moved from source domain to target domain. Those source domain local groups have also been migrated to target domain without sidhistory. Scope of the migrated group in target domain is "Global". Migrated target group (scope: Global) is nested inside source domain local group. If I add newly created users (in target domain) under migrated target group(scope: Global), then will those users will be able to access resources through migrated target group membership (as sidhistory isn't migrated)?  If yes, does it mean that access token of those users contains Sid of migrated target group as well as Sid of source domain local group?

group Sid under sidhistory) were filtered out while accessing via trust.

Was there a question? I sure don't see it. 

The facts

• Resource are  in source domain
• secured with source domain local group. 
• Migrate the the domain local group with sidhistory
• Convert target domain local group to global group with sidhistory.  

Now if I add user to the target global group, then access will work as access token have Sid of source domain local group. So in this scenario, group scope is different but access is still working but as per https://activedirectoryfaq.com/2016/09/domain-migration-access-denied-group-type-change/ it says that group type/scope should be identical in each domain.

Again the ActiveDirectoryFAQ article in about how someone's migration was shot in the foot by some Admin changing the script type post migration. So what is says "group type/scope should be identical in each domain." is really Don't change the group types during migration. I have told you this exact thing at least twice in prior posting. 

We really need to stop looking so low, at the token. Look higher at the group membership is where we really should be looking. 

The token is generated at logon and new access token is generated each time you access a server. Based on that servers domain membership and the trusts in place. So my answer is correct but because we are talking at a low level it is confusing. 

Jeff Shahan

Sorry to comment on your reply and correcting your statement. Please re-validate your statement.

User mentioned that

• Resources resides on servers in source domain. 
• Source domain local groups are applied in resource ACL     ----------->     (they did not mention that equivalent migrated target "Global group" is also applied in resource ACL)
• servers membership have changed from source domain to target domain. 
• The source domain local groups have also been migrated to target domain without SID History and during migration scope has been changed to "Global" group.
• Migrated target global group is member of the source domain local group.

So user asked - If they add newly created target users to the migrated target Global group, then will those users will be able to access resources?

Your Reply: Yes, they will have access to the resource.

My Point:

I think access will not work as target user's access token will only contain SID of migrated target "Global group" not SID of  Source Domain local group as server has been moved to target domain. Since equivalent migrated target "Global group" is not applied in resource ACL, so access to resource should NOT be working. Correct!

Thanks

You are correct. Access fails for one reason "servers membership have changed from source domain to target domain"

• Resources resides on servers in source domain. 
• Source domain local groups are applied in resource ACL  
• servers membership have changed from source domain to target domain. 
• The source domain local groups have also been migrated to target domain without SID History and during migration scope has been changed to "Global" group.
• Migrated target global group is member of the source domain local group