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?

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

Parents
  • the fact that user's token containing sid of source domain local group

    That is why. 

    Normally changing the scope/type of group is not something that is done during a migration. Normally the target migrated objects are added to the source domain local group by the Active Directory Processing Wizard. 

    migrated global group is nested inside source domain local group

    This has no effect in this case. In fact this is redundant. 

  • Thanks for your reply

    Follow-up queries for further clarification.

    As I understand correctly, access is granted as user's token containing sid of source domain local group in sidhistory attribute compared to source domain local group applied on resource ACL. It means source domain local group will still be recognized while access check (irrespective of authorization scope is limited to source domain only).

    Migrated global group is nested inside source domain local group. You said this is redundant and has no effect in this case. Could you please explain and elaborate it ? 

    My question is then why did we add target migrated objects to the source domain local group by the Active Directory Processing Wizard at first place.

    Looing forward to explanation on above mentioned points for clarification.

  • Migrated global group is nested inside source domain local group. You said this is redundant and has no effect in this case. Could you please explain and elaborate it ? 

    It is redundant because you changed the group scope/type in the first place. That allowed the token to cross the trust boundary in the first place.  

    As I understand correctly, access is granted as user's token containing sid of source domain local group in sidhistory attribute compared to source domain local group applied on resource ACL.

    You need to read this from the ACL to the token for access. That is how the OS works. Access request, ACL enumerates ACEs, the ACEs are read from the top to bottom. ACE = Sid access level or deny. If sid in token matches sid in ACE and Access level is deny, enumeration stops access is denied. If no deny exist for the sid, enumeration continues. Deny are always the tope ACEs in an ACL. If sid in token matches sid in ACE and Access level, access is granted. 

    My question is then why did we add target migrated objects to the source domain local group by the Active Directory Processing Wizard at first place.

    I can not start to explain why you converted the target group from domain local group to a domain global group. That was a odd step to do. ADPW would not have added the target group to the source group anyway. You did that manually too. ADPW would have added the target objects that matched the source objects that were members of the source domain local group to provide access.

    It means source domain local group will still be recognized while access check (irrespective of authorization scope is limited to source domain only).

    Again, you manually messed with authorization scope when you converted the target group type/scope.

  • Thank you 

    I just have only last query left in this thread.


    "If access is granted by source domain local group, migrated target equivalent group (having sid of source domain local group under sidhistory attribute ) is nested inside source domain local group, and that source domain local group is applied in Target resource permission ACL."

    Then my question is while resource process why do I have to remove those source domain local group and apply directly target equivalent migrated group in target resource permission ACL? Please explain.

    Because as we know that source domain local group are also granting access to target resource as per permission defined in ACL. Source Domain Local group aren't sitting idle. Then why do we still have to remove Source Domain Local Group from permission ACL?

    Do I also have to delete these source domain local group completely from Source domain OR Do I just need to remove these Source Domain Local groups from target resource permission ACL?

    Please answer and technically explain.

  • You are asking the wrong questions. 

    1. During a normal migration, The source file system resource is secured by two Domain Local Groups, Source\Resource-Read (sid 1-1) and Source\Resource-Write  (sid 1-2)Source\Resource-Read  (sid 1-2) has a member Source\Bob (sid 1-3) and Source\Carol (sid 1-4). Source\Resource-Write (sid 1-2) has two members Source\Ted (sid 1-5) and Source\Alice (sid 1-6). Next you migrate these 6 source objects to the target, without sid history. Target\Resource-Read (sid 2-1) and Target\Resource-Write (sid 2-2) . Target\Resource-Read (sid 2-1) has a member Target\Bob (sid 2-3) and Target\Carol (sid 2-4). Target\Resource-Write (Sid-2-2) has two members Target\Ted (sid 2-5) and Target\Alice (sid 2-6).  

    2. Since you did not migrate sidhistory, the target users and groups do not have access to the source file system resource. What change would you make to allow these target users to have access to the source file system resource? Answers, Add Target\Bob (sid 2-3) and Target\Carol (sid 2-4) to Source\Resource-Read  (sid 1-2) and add Target\Ted (sid 2-5) and Target\Alice (sid 2-6) to Target\Resource-Write (Sid-2-2). 

    3. Now you move the server hosting the file system resource from the source domain to the target domain. Everyone that has access loses access. What change do you make to restore access? Answer, Add  Target\Resource-Read (sid 2-1), Target\Resource-Write (sid 2-2) to the Access Control List AND Add Source\Bob (sid 1-3) and Target\Carol (sid 1-4) to Target\Resource-Read (sid 1-2) and add Source\Ted (sid 1-5) and Source\Alice (sid 1-6) to Target\Resource-Write (Sid-2-2).
    Note: Using a migration session to migrate the domain local groups, there is an option to Add Source members to corresponding Target Group that would have address this as well. 

    4. Now you are done with the migration and you turn off the all of the source domain controllers. All of you migrated users have still have access, but when you look at the access control list of the file system resource you see the following:

    • Target\Resource-Read : Read
    • Target\Resource-Write : Write
    • 1-1 : Read
    • 1-2 : Write

    What should you do to resolve this unmanageable condition?  Answer, delete the sid based access control entries. 

    So now how would we automate this during a larger scale migration? What part of Migration Manager for Active directory can automate each of these?

    1. Migration Session
    2. Active Directory Processing Wizard (ADPW)
    3. Resource Update Manager, Processing Target Task
    4. Resource Update Manager, Processing Target Task

  • You are asking the wrong questions. 

    Now lets add Sid History

    1. During a normal migration, The source file system resource is secured by two Domain Local Groups, Source\Resource-Read (sid 1-1) and Source\Resource-Write  (sid 1-2)Source\Resource-Read  (sid 1-1) has a member Source\Bob (sid 1-3) and Source\Carol (sid 1-4). Source\Resource-Write (sid 1-2) has two members Source\Ted (sid 1-5) and Source\Alice (sid 1-6). Next you migrate these 6 source objects to the target, WITH sid history. Target\Resource-Read (sid 2-1, SidHistory 1-1) and Target\Resource-Write (sid 2-2, SidHistory 1-2) . Target\Resource-Read (sid 2-1, SidHistory 1-1) has a member Target\Bob (sid 2-3, SidHistory 1-3) and Target\Carol (sid 2-4, SidHistory 1-4). Target\Resource-Write (Sid-2-2, SidHistory 1-2) has two members Target\Ted (sid 2-5, SidHistory 1-5) and Target\Alice (sid 2-6, SidHistory 1-6).  

    2. Since migrated sidhistory, but the target users and groups do not have access to the source file system resource. Why not? Answer, Domain local group sids are do not cross the trust boundary. What change would you make to allow these target users to have access to the source file system resource? Answers, Add Target\Bob (sid 2-3, SidHistory 1-3) and Target\Carol (sid 2-4, SidHistory 1-4) to Source\Resource-Read  (sid 1-2) and add Target\Ted (sid 2-5, SidHistory 1-5) and Target\Alice (sid 2-6, SidHistory 1-6) to Source\Resource-Write (Sid-2-2). 

    3. Now you move the server hosting the file system resource from the source domain to the target domain. Everyone that has access loses access. What change do you make to restore access? Answer, Add  Target\Resource-Read (sid 2-1, SidHistory 1-1), Target\Resource-Write (sid 2-2, SidHistory 1-2) to the Access Control List AND Add Source\Bob (sid 1-3) and Source\Carol (sid 1-4) to Target\Resource-Read (sid 2-1, SidHistory 1-1) and add Source\Ted (sid 1-5) and Source\Alice (sid 1-6) to Target\Resource-Write (Sid-2-2, SidHistory 1-2).

    4. Now you are done with the migration and you turn off the all of the source domain controllers. All of you migrated users have still have access, but when you look at the access control list of the file system resource you see the following:

    • Target\Resource-Read : Read
    • Target\Resource-Write : Write
    • Target\Resource-Read : Read
    • Target\Resource-Write : Write

    Why do I see duplicated Access Control Entries?  Answer, the SIDs on the ACL resolves to objects with SID in Sid History. 

    So now how would we automate this during a larger scale migration? What part of Migration Manager for Active directory can automate each of these?

    1. Migration Session with SidHistory Enabled
    2. Active Directory Processing Wizard (ADPW)
    3. Resource Update Manager, Processing Target Task
    4. Resource Update Manager, Processing Target Task

    How do you remove sid history from the target objects? Answer:  Active Directory Processing Wizard can remove sid history of the objects it processes (scope) for the sid history we applied (mapping) 

  • "If access is granted by source domain local group, migrated target equivalent group (having sid of source domain local group under sidhistory attribute ) is nested inside source domain local group, and that source domain local group is applied in Target resource permission ACL."

    First off it is not common for the "migrated target equivalent group" type allows it nested inside source domain local group. So were are already working in a unnormal condition. 

    Then my question is while resource process why do I have to remove those source domain local group and apply directly target equivalent migrated group in target resource permission ACL? Please explain.

    Normally with a Domain Local group this is NOT an option. You can not use a trusted domain's Domain Local groups on a resource in a trusting domain. See #2 in my others posts. 

    Because as we know that source domain local group are also granting access to target resource as per permission defined in ACL. Source Domain Local group aren't sitting idle. Then why do we still have to remove Source Domain Local Group from permission ACL?

    This is an incorrect statement " source domain local group are also granting access to target resource as per permission defined in ACL".
    When the server hosting the resource is no longer joined to the source, the domain local groups from the source no longer control access. The ACL is still provisioned to sid 1-1 read and sid 1-2 write, but now they are resolve to target local groups because of sid history.

    If you delete the source group or decommission the source domain, the net results are the same. No impact for Target users.

    If you were to remove sid history from the target domain local group, access to the resources would be lost. The access control entries would not resolve to a domain object if the source domain did not exist. See #4 in the both posts.

    The goal of any migration is that the end state should be one that leave no trace of the migration. No Sid History on the objects and unresolved sid in the access control lists. 

Reply
  • "If access is granted by source domain local group, migrated target equivalent group (having sid of source domain local group under sidhistory attribute ) is nested inside source domain local group, and that source domain local group is applied in Target resource permission ACL."

    First off it is not common for the "migrated target equivalent group" type allows it nested inside source domain local group. So were are already working in a unnormal condition. 

    Then my question is while resource process why do I have to remove those source domain local group and apply directly target equivalent migrated group in target resource permission ACL? Please explain.

    Normally with a Domain Local group this is NOT an option. You can not use a trusted domain's Domain Local groups on a resource in a trusting domain. See #2 in my others posts. 

    Because as we know that source domain local group are also granting access to target resource as per permission defined in ACL. Source Domain Local group aren't sitting idle. Then why do we still have to remove Source Domain Local Group from permission ACL?

    This is an incorrect statement " source domain local group are also granting access to target resource as per permission defined in ACL".
    When the server hosting the resource is no longer joined to the source, the domain local groups from the source no longer control access. The ACL is still provisioned to sid 1-1 read and sid 1-2 write, but now they are resolve to target local groups because of sid history.

    If you delete the source group or decommission the source domain, the net results are the same. No impact for Target users.

    If you were to remove sid history from the target domain local group, access to the resources would be lost. The access control entries would not resolve to a domain object if the source domain did not exist. See #4 in the both posts.

    The goal of any migration is that the end state should be one that leave no trace of the migration. No Sid History on the objects and unresolved sid in the access control lists. 

Children
No Data