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

Hello

Q1: As per https://activedirectoryfaq.com/2016/09/domain-migration-access-denied-group-type-change/ it says to keep authorization group "domain local" in source environment.  Then the types would be identic on both domains. So my question is 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? 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. Please let me know if I missed anything or did not understand correctly. Please explain the scenario mentioned on above mentioned article.

Q2: 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?

Kindly answer above mentioned questions and provide explanation. Looking forward to prompt reply.

Thanks in advance!

Parents
  • 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. 

  • 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.

Reply
  • 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.

Children
  • 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.