Access token related query

Hello Support Representatives,

I have general query regarding Access Token. I hope you guys will answer and explain it.

So during migration, servers(containing resources) have been migrated from source domain to target domain. Source Domain Local groups are appended in resource DACL. These source domain local groups have been migrated to target domain without Sidhistory and during migration group scope has been changed to "Global". These migrated global groups nested inside source domain local groups.

If target domain users are member of migrated global group and target users login to target domain joined workstation, then what Sids will be included in access token? Will Access token include both - Sid of migrated target group as well as Sid of source domain local groups? 

Please clarify - Does access token of user contain Sid of recursive groups which are inter domain and scope not matching to direct group of user as per above example.

Another scenario: This time Servers (containing resources) are in source domain only. Source Domain Local groups are appended in resource DACL. These source domain local groups have been migrated to target domain without Sidhistory and during migration group scope has been changed to "Global". These migrated global groups nested inside source domain local groups. If source and target domain users both are member of migrated global group and target users login to target domain joined workstation and source users login to source domain joined workstation then what Sids will be included in access token? I guess target users will not be able to access resource as his token will not include source domain local group because he logged in via target domain joined workstation. But what about source user login to source domain joined workstation, will his access token include both - Sid of migrated target group as well as Sid of source domain local groups? 

Please clarify - Does access token of user contain Sid of recursive groups which are inter domain and scope not matching to direct group of user as per above example.

Please answer and explain both scenarios. 

Top Replies

Parents
  • The facts

    • Servers domain membership has been MOVED from source domain to target domain. 
    • Source Domain Local groups are appended in resource DACL.
    • These source domain local groups have been migrated to target domain without Sidhistory and the group type has been changed to Global. 
    • These migrated global groups nested inside source domain local groups.

    The questions

    1. If target domain users are member of migrated global group and target users login to target domain joined workstation, then what Sids will be included in access token?
      The access token in the target will contain Target user, Target Global Group sids. 
    2. Will Access token include both - Sid of migrated target group as well as Sid of source domain local groups? 
      The token will only have the source domain local group when access is requested to a source domain joined server. 

    Changing the Domain membership of the server from the source domain to the target domain, orphans the source domain local access control entries (ACE) in the access control lists (ACL) as the Source Domain Local group will NEVER be present in the Access Token. Had the servers NOT been moved to the target domain, access would have worked. 

    The facts

    • Servers domain membership is the source domain 
    • Source Domain Local groups are appended in resource DACL. 
    • These source domain local groups have been migrated to target domain without Sidhistory 
    • The group scope has been changed to "Global". 
    • These migrated global groups nested inside source domain local groups. 

    The questions

    1. If source and target domain users both are member of migrated global group and target users login to target domain joined workstation and source users login to source domain joined workstation then what Sids will be included in access token? 
    • First, Source users can not be a member of a target global group. 
    • Source Users token has Source domain global, source domain local and source domain universal. The source user will have access to the Source Servers resources secured using the source domain local groups. 
    • Target Users token has Target domain global, source domain local and source domain universal. The Target user will have access to the Source Servers resources secured using the source domain local groups. 

    As a rule with all of the migration I have been involved in, there is rarely a reason I would have changed the group scopes. Quest's migration tools offers utilities to process the group membership and resource permissions that meet the access control. 

  • Thank you so much for your support. I just have only last query left. Post that, I will mark your reply as verified answer. I hope you will understand and explain this too.

    The facts:

    • Servers domain membership has been MOVED from source domain to target domain. 
    • Source Domain Local groups are appended in resource DACL.
    • These source domain local groups have been migrated to target domain without Sidhistory and the group type has been changed to Global. 
    • These migrated global groups nested inside source domain local groups.

    You said:

    The token will only have the source domain local group when access is requested to a source domain joined server. 

    So it means it also hold true if target user is transitively member of source domain local group. Such as in this case: target user is member of migrated target global group and migrated target global group is member of source domain local group. Am I right?

    You said:

    "Changing the Domain membership of the server from the source domain to the target domain, orphans the source domain local access control entries (ACE) in the access control lists (ACL) as the Source Domain Local group will NEVER be present in the Access Token. Had the servers NOT been moved to the target domain, access would have worked". 

    So my question is:

    Q1: Orphans the source domain local access control entries (ACE) in the access control lists (ACL). Does it mean that Sid of source domain local group will show in ACL rather than showing name of source domain local group? What is exact meaning of orphans source domain local group access control entries (ACE) in the resource access control lists (ACL)? 

    If target domain user is member of migrated target Global Group and target user login to target domain joined workstation.

    You said: Then target user's access token will contain Sid of  target user and Sid of migrated target Global Group Sid

    So my question is:

    Q2: Since resource server has been moved to target domain and only source domain local groups are applied in resource ACL, so while performing access check Sid of migrated target Global Group in target user's access token will be compared directly against Sid of migrated target global group (which is nested inside source domain local group in resource ACL) by ignoring Sid of source domain local group Sid?

    Please elaborate and explain technically how exactly access check is happening here in terms of Sid and access token?

    Another Scenario (Sidhistory included)

    • Servers domain membership has been MOVED from source domain to target domain. 
    • Source Domain Local groups are appended in resource DACL.
    • These source domain local groups have been migrated to target domain WITH Sidhistory and the group type has been changed to Global. 
    • These migrated global groups nested inside source domain local groups.

    So my question is:

    Q3: Please elaborate and explain technically how exactly access check is happening in this scenario (Sidhistory included) in terms of Sid, sidhistory and access token?

    Looking forward to answers with technical explanation specific to above mentioned questions and scenarios. Thanks in advance ! :-)

  • Please answer and explain last query as mentioned above.

  • Does it mean that Sid of source domain local group will show in ACL rather than showing name of source domain local group? if the ACE in the ACL resolves or not is a simply cosmetic. 

    What is exact meaning of orphans source domain local group access control entries (ACE) in the resource access control lists (ACL)?  In this cases, it means it will not longer function to allow or deny access to the resource. 

    Since resource server has been moved to target domain and only source domain local groups are applied in resource ACL, so while performing access check Sid of migrated target Global Group in target user's access token will be compared directly against Sid of migrated target global group (which is nested inside source domain local group in resource ACL) by ignoring Sid of source domain local group Sid? Since only source domain local groups are present in the resource ACL and the Server is a member of the Target. This means that NO source domain local groups are a member of the server access token, so no access to the resource is granted. 

    Q3: The source domain local groups are present in the resource ACL, the Server is a member of the Target AND the source domain local group SIDs are present as Sid History on the Target domain local group. So access token has the source domain local groups in it. Access is granted. to the resource. 

Reply
  • Does it mean that Sid of source domain local group will show in ACL rather than showing name of source domain local group? if the ACE in the ACL resolves or not is a simply cosmetic. 

    What is exact meaning of orphans source domain local group access control entries (ACE) in the resource access control lists (ACL)?  In this cases, it means it will not longer function to allow or deny access to the resource. 

    Since resource server has been moved to target domain and only source domain local groups are applied in resource ACL, so while performing access check Sid of migrated target Global Group in target user's access token will be compared directly against Sid of migrated target global group (which is nested inside source domain local group in resource ACL) by ignoring Sid of source domain local group Sid? Since only source domain local groups are present in the resource ACL and the Server is a member of the Target. This means that NO source domain local groups are a member of the server access token, so no access to the resource is granted. 

    Q3: The source domain local groups are present in the resource ACL, the Server is a member of the Target AND the source domain local group SIDs are present as Sid History on the Target domain local group. So access token has the source domain local groups in it. Access is granted. to the resource. 

Children
No Data