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

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

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

    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.