Access token related query

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. 

Jeff Shahan

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.

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 Jeff Shahan

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 Jeff Shahan 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.

Jeff Shahan

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.

Jeff Shahan

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.