How access is granted by source domain local group in target domain resource permission ACL (via migrated group membership or via sidhistory or both) and how exactly access check is performed?

Question

Hello,

I've source domain local group applied on resource ACL. Resource have been migrated to target domain server along with ACL permissions as-is. Source domain local group have also been migrated to target domain using sidhistory and scope has been converted to Global group in target domain. This migrated global group (having sid of source domain local group in sidhistory attribute) is nested inside source domain local group as well. So if I add newly created user in migrated global group, then user is able to access resource.

So my question is how access is granted to user because source domain local group will not be recognized in target domain (as authorization scope is limited to the domain where it's created)?

Is this because of the fact that user's token containing sid of source domain local group in sidhistory attribute will be compared to source domain local group applied on resource ACL? But how source domain local group will be recognized while access check (because of authorization scope is limited to local domain only)?

OR

Is this because of the fact that migrated global group is nested inside source domain local group which is applied on resource ACL? Does access check is performed against migrated global group directly by ignoring source domain local group? Does access check is also performed against nested group which is not directly applied on resource ACL?

Kindly answer and explain technically specific to mentioned points in above scenario. Please explain also how exactly access check is performed in this scenario OR in general.

Answer 1

Hi,
From what i researched,

Resources within the source and target domains resolve their access control lists (ACLs) to SIDs and then check for matches between their ACLs and the access token when granting or denying access. If the SID or the SID history matches, access to the resource is granted or denied, according to the access specified in the ACL.

After objects are migrated to the target domain, resources contain the ACL entries of the source domain objects. If you are using SID history to provide access to resources during the migration, the SIDs from the source domain remain in the ACLs to enable users to access resources while the migration is in progress.

SID history helps you to maintain user access to resources during the process of restructuring Active Directory domains. And the SID history is used for temporarily during the migration, it is not suggested to be used when the migration is completed .It is recommended to use the new sid for the permission granting in the target domain.

For your questions:
1,How access is granted to user because source domain local group will not be recognized in target domain?

Resources contain the ACL entries of the source domain objects. If you are using security identifier (SID) history to provide access to resources during the migration, the SIDs from the source domain remain in the ACLs so that users can access resources while the migration is in progress.
After the migration is complete, the SIDs from the source domain are no longer needed. The Security Translation Wizard in the Active Directory Migration Tool (ADMT) is used to replace the source domain SIDs with the target domain SIDs.

Would you please tell how did you migrate the resource, did you already run the Security Translation Wizard already? If yes, the new SIDs have been used to access the resource.

Translating Security on Your Member Servers