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. 

  • Let me put my question in simple words.

    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 we did not migrate sidhistory, the target users and target groups(Domain Local) do not have access to the source file system resource. What change would we 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).

    It means target users are now members of both migrated target domain local group and source domain local group.

    So my question is how access is granted by adding target users to source domain local groups as per above mentioned scenario? According to Microsoft and Quest articles, If target user login to target domain joined workstation, then in his access token will only include target domain local group not source domain local group. Apart from that, target domain local group SID will not cross trust boundary while attempting to source domain resource. So how access is granted in above mentioned scenario?

    https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/logging-on-user-account-fails

    https://support.quest.com/kb/72489/considerations-when-migrating-local-groups-with-sid-history

    Why workstation criteria for domain local group is not applied here as per above mentioned support articles? Kindly answer specific to above mentioned query and provide explanation.

Reply
  • Let me put my question in simple words.

    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 we did not migrate sidhistory, the target users and target groups(Domain Local) do not have access to the source file system resource. What change would we 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).

    It means target users are now members of both migrated target domain local group and source domain local group.

    So my question is how access is granted by adding target users to source domain local groups as per above mentioned scenario? According to Microsoft and Quest articles, If target user login to target domain joined workstation, then in his access token will only include target domain local group not source domain local group. Apart from that, target domain local group SID will not cross trust boundary while attempting to source domain resource. So how access is granted in above mentioned scenario?

    https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/logging-on-user-account-fails

    https://support.quest.com/kb/72489/considerations-when-migrating-local-groups-with-sid-history

    Why workstation criteria for domain local group is not applied here as per above mentioned support articles? Kindly answer specific to above mentioned query and provide explanation.

Children
  • How access is granted by adding target users to source domain local groups as per above mentioned scenario? 

    Lets take Ted for example. When Ted logs onto his workstation, a token is generated. When Ted accesses a resource on a server, a new token is generated. It is this New token generated by the server that has domain local groups for the domain the server is a member of. So Ted target joined workstation has Target\Resource-Write in the token and the Source joined server has Source\Resource-Write in the token.

  • Hi

    Just want to clarify few points.

    As you said above, The token will only have the source domain local group when access is requested to a source domain joined server.

    Q1: So my question is this applicable only for Domain Local groups for the domain the server is member of?

    Suppose in a multi domains single forest, there are 2 domains: Domain A and Domain B. If resources resides in Domain B joined servers. Those resources ACL contains Universal groups of Domain B. Domain A user is member of Domain B universal groups.

    Q2: So domain A user logs on to a Domain A joined workstation, access token is generated for Domain A user on the logon workstation. So does this initial token contain Domain B universal group?

    OR

    Does Domain B universal group SID is only added in the server token when access is requested to Domain B joined server resource secured with Domain B universal group?

    Q3: In general, I want to know token generated after logon also contains SID for each global group that the principal is directly or transitively a member of and SID for each universal group that the principal is directly or transitively a member of whether those global and universal groups belongs to domains  different from domain of logon user?

    Q4: How token generated by server is different from token generated after logon to the workstation? How access token differs from Kerberos Ticket and Service Ticket in terms of functionality? Where and how Kerberos Ticket and Service Ticket is used in relation to access token?

    Please explain.

    Thanks for your support in advance!

  • When you logon to a workstation, the workstation authenticates the user to the domain controller it has it's secure channel connected to. If the user account is located in a trusted domain, the domain controller connects to the trusted domain controller it has a secure channel with. 

    • Domain User
    • Workstation's Local Groups
    • Workstation's Domain Local Groups
    • Authenticating Domain Global Groups and Forest Universal Groups

    When you try to access a resource on a remote server, that server will authenticate your request, following the same path as above.

    • Domain User
    • Server's Local Groups
    • Server's Domain Local Groups
    • Authenticating Domain Global Groups and Forest Universal Groups

     Q1: So my question is this applicable only for Domain Local groups for the domain the server is member of?

    Suppose in a multi domains single forest, there are 2 domains: Domain A and Domain B. If resources resides in Domain B joined servers. Those resources ACL contains Universal groups of Domain B. Domain A user is member of Domain B universal groups.

    • Domain A User
    • Server's Local Groups
    • Server's Domain B Local Groups
    • Authenticating Domain B Global Groups and Forest Universal Groups 

    Q2: So domain A user logs on to a Domain A joined workstation, access token is generated for Domain A user on the logon workstation. So does this initial token contain Domain B universal group? Yes

    • Domain A User
    • Workstation's Local Groups
    • Workstation's Domain A Local Groups
    • Authenticating Domain Global Groups and Forest Universal Groups

    OR

    Does Domain B universal group SID is only added in the server token when access is requested to Domain B joined server resource secured with Domain B universal group? No

    Q3: In general, I want to know token generated after logon also contains SID for each global group that the principal is directly or transitively a member of and SID for each universal group that the principal is directly or transitively a member of whether those global and universal groups belongs to domains  different from domain of logon user?

    See the top of this post. 

    Q4: How token generated by server is different from token generated after logon to the workstation? How access token differs from Kerberos Ticket and Service Ticket in terms of functionality? Where and how Kerberos Ticket and Service Ticket is used in relation to access token?

    Leave the authentication protocol out of this. This is already complex enough.

  • Thank you so much  for explanation. I don't have any queries but I just need you to validate my understanding on below mentioned points.

    Looking forward to your prompt reply.

    As I understand correctly, 

    When a user logs on to a Windows domain, the operating system generates an access token. This access token is used to determine which resources the user may access. The user access token includes the following data:

    • User SID.
    • SIDs of all global and universal security groups that the user is a member of.
    • SIDs of all nested global and universal security groups.

    As you told access token contains Universal(Forest) groups. These universal groups can belong to any domain in the forest irrespective of logged on user's domain. Please confirm.

    Every process executed on behalf of this user has a copy of this access token.

    When the user attempts to access resources on a computer, the service through which the user accesses the resource will impersonate the user by creating a new access token based on the access token created at user logon time. This new access token will also contain the following SIDs:

    • SIDs for all domain local groups in the remote server's domain that the user is a member of.
    • SIDs for all machine local groups on the remote server that the user is a member of.

    The service uses this new access token to evaluate access to the resource. If a SID in the access token appears in any ACEs in the DACL, the service gives the user the permissions specified in those ACEs.

    Scenario:

    There are 2 forests. Forest A and Forest B. There is 2 way forest trust relationship between these forests. Resource is in Forest B. There is Universal Group named UG-A created in Forest A. User-A is member of UG-A. This Universal Group UG-A is applied in Forest B resource ACL. So if User-A in Forest A tries to access resource in Forest B, then his access token contains Sid of Universal Group (UG-A) which will cross the trust boundary and evaluate access to the resource. So in this case, access is granted.

    So it means all SIDs (Sids included in access token generated after logon to workstation + Sids included in new access token generated by server) will be compared against any ACEs in resource ACL while accessing resource on remote server(whether or not remote server belongs to same domain or different domain or same forest or different forest). Please confirm.

  • I understand this making harder to understand. Sorry for the inconvenience. But I request please confirm and validate my understanding on above mentioned points last time. I assure that then I'll not continue further on this. I don't want to bother you again on this.

    Thanks for your understanding.

  • When a user logs on to a Windows domain, the operating system generates an access token. This access token is used to determine which resources the user may access. The user access token includes the following data:

    • User SID.
    • SIDs of all global and universal security groups that the user is a member of.
    • SIDs of all nested global and universal security groups. (This is redundant to the point above, users are members of groups either explicitly (Directly) or implicitly (indirectly through nesting) 

    As you told access token contains Universal(Forest) groups. These universal groups can belong to any domain in the forest irrespective of logged on user's domain. Please confirm.

    NOTE
    : The Forest wide security groups only apply in an intra-forest login. In an inter-forest logon, with an external trust, only the universal groups from within the trusted domain are included. 

    In this question you omitted to say where the user login was happening. It that is the workstation logon, the workstation local groups are also included as I explained above. If it is a member server the member server local groups are included. Additionally you omitted the Domain local groups that the server/workstation is a member of. 

    Every process executed on behalf of this user has a copy of this access token.

    Not really. The remote host users SID of the token to create it's own "Impersonation" Token. This was explained in my prior reply. 

    When the user attempts to access resources on a computer, the service through which the user accesses the resource will impersonate the user by creating a new access token based on the access token created at user logon time. This new access token will also contain the following SIDs:

    • SIDs for all domain local groups in the remote server's domain that the user is a member of.
    • SIDs for all machine local groups on the remote server that the user is a member of.

    No, the new impersonation token will be created and only include the following: 

    • Domain User
    • Server's Local Groups
    • Server's Domain Local Groups
    • Authenticating Domain Global Groups and Forest Universal Groups (See NOTE ABOVE)

    Scenario:

    • There are 2 forests. Forest A and Forest B.
    • There is 2 way forest trust relationship between these forests.
    • Resource is in Forest B.
    • There is Universal Group named UG-A created in Forest A.
    • User-A is member of UG-A.
    • This Universal Group UG-A is applied in Forest B resource ACL. (This is contrary MS Resource Access Control Best Practice AGUDLP See https://en.wikipedia.org/wiki/AGDLP)

    So if User-A in Forest A tries to access resource in Forest B, then his access token contains Sid of Universal Group (UG-A) which will cross the trust boundary and evaluate access to the resource. So in this case, access is granted.

    You took a long way to get there, buy yes, the UG-A granted the access.

    So it means all SIDs (Sids included in access token generated after logon to workstation + Sids included in new access token generated by server) will be compared against any ACEs in resource ACL while accessing resource on remote server(whether or not remote server belongs to same domain or different domain or same forest or different forest). 

    No. Not all Domain Local groups do NOT cross the trust boundary. You left them out of this scenario, but your statement:

    Sids included in access token generated after logon to workstation + Sids included in new access token generated by server

    But again the sid included are not all that are in the workstations token. It is a new token created by the resource holding server you are accessing. So it is not Workstation + Server + Domain , it is User + Server + domain.

  • Thank you so much for your reply. Sorry again, but there seems to be contradiction. That's why I'm writing. I've found below Microsoft article which says the same thing which I mentioned in my previous reply. 

    As per below link, it does not say you told that token will include "Authenticating Domain Global Groups and Forest Global Groups". Please have a look.

    https://docs.microsoft.com/en-us/windows/win32/ad/how-security-groups-are-used-in-access-control

    Confusion arises because of statement: "Authenticating Domain Global Groups and Forest Global Groups" mentioned in previous replies.

    I hope you will cross check and clear this out.

    Suppose there are 2 domains Domain A and Domain B. Resource is in Domain B joined server. User belongs to Domain A. So when user login on Domain A  and try to access resource in Domain B joined server. So in this case, I just want to confirm that Authenticating Domain is only Domain A not Domain B. Correct?

    So it means it can contain only Domain A Global groups, Domain A Universal groups and Domain B Universal groups. So forest global groups mean all universal groups of all domains in a forest (intra-forest logon). Correct?

    Another confirmation:

    In Inter-forest logon, there are 2 situations: external trust and forest trust. 

    So incase of external trust: Global groups with in trusted domain are not included in the token, only universal groups with in trusted domain are included in the token. Correct? 

    But in case of forest trust: Both Global groups from authenticating domain and all Universal groups within trusted forest are included in token. Correct?

    So in case of external trust: Only universal groups (within trusted domain) Sids will cross trust boundary. Correct?

    But in case of forest trust: Sids of Global groups from authenticating domain as well as Sids of Universal groups with in trusted forest will cross trust boundary. Correct?

    So in short, only Global groups Sids and Universal groups Sids cross trust boundary always. Domain Local groups Sids never cross trust boundary. Correct?

    Please reply and validate/confirm if my understanding is correct on all above mentioned points and close the discussion.

    Thank you again for your extreme support. I really appreciate your patience and cooperation.

  • Its my humble request, just to reply final time on above mentioned points. Because I found very difficult to find these details with clarity available anywhere on the net. I hope you can understand the concern on this matter and will support final time.

    Thank you.

  • Your support has been commendable so far. I am really happy :-) extreme helping nature. I don't want to loose any hope. Literally, I'm  not getting answers and explanations anywhere on the other technical forums and support forums . Kindly understand from my standpoint and just explain final time. OR alternatively, you can share some URLs of reference or support articles where I can find answers and explanations of above mentioned points which includes this stuff.

    Thanks in advance!

  • FYI, I am not "Support" I am a "Principal Strategic Systems Architect" handle migration solutions with 20+ years of field migration experience. I know this stuff off the top of my head. So to supply you with links, I would have to take time and find the links. That is not something I have time to do.