Question related to Sidhistory

Question

Hello Guys, 
 I'm very excited about my first post on the forum. 
 After reading below support article link, I have confusion related to sidhistory. I hope you guys will explain this. https://support.quest.com/kb/72489/considerations-when-migrating-local-groups-with-sid-history 
 How the Access Token Limit Is Reached 
 When a user logs on and authentication is successful, the logon process returns a SID for the user and a list of SIDs for the user&rsquo;s security groups and these comprise the access token. SID history can add additional SIDs to the token. The SIDs in an access token include:&middot; The security principal's SID, including SIDs from the SID history of the principal. The SID from each domain local group that the principal is directly or transitively a member of, for the domain of the workstation or resource. !!!!!!!!!!!! The SID for each global group that the principal is directly or transitively a member of, including SIDs from the SID history of the group. The SID for each universal group that the principal is directly or transitively a member of, including SIDs from the SID history of the group.&middot; The SID for each built-in group the principal is directly or transitively a member of. 
 The SID for each local group that the principal is directly or transitively a member of. 
 Scenario: Let's consider if Domain Local group of source domain migrated to Domain Local group of target domain with sidhistory. So as per above mentioned information, once target user (member of target domain local group) login to target domain joined workstation his access token will contain target domain local group. So my questions are: 
 Q1: It means that his access token will not include sidhistory (Sid of Source Domain Local group). Am I right or wrong? Q2: If sidhistory will not be included, then what's the point and benefit of migrating domain local group with sidhistory? I mean that will never be used. Q3: If sidhistory will be included, then it will only be used if server is moved to target domain as well as resource is secured with Source domain local group in ACL. Correct me if I'm wrong. Looking forward to your prompt reply.

Jeff Shahan · Accepted Answer

So lets not talk about the access token, that only confused the topic. 
 The fact, Domain Local Groups can not be used to secure or grant access to resources in a trusting domain. This is a core functional administrative principle for active directory management. So if you migrate the source domain local groups sid to the target domain local group sidhistory, it adds no value. You have effectively given the office "keys" in one building to someone locked in another building. Now if the office is moved to the other building, those keys would work. 
 So your real question is "how do I maintain access to source domain joined server resources secured using source domain local groups for migrated target users"? 
 Answers: You update the source domain local groups with the target users and group. Quest Migration Manager for Active Directory includes the Active Directory Processing Wizard that handles this target. If that is NOT your question, please restate.

Jeff Shahan · Answer

jones mark personal said: So it means if Source domain global group nested inside source domain local group and source domain global group migrated with QMM, then I need to add migrated target group to source domain local group whether sidhistory is migrated or not. Am I right? 
 Correct. 
 jones mark personal said: My point: Well as far as I understand about Microsoft Group management best practices, Domain Local groups are preferred while applying in resource ACL and assignment of permissions. Global groups are preferred to add users with similar kind of roles into it and then we we make Global group member of Domain Local group. But your statement is completely opposite. So you meant to say that in migration scenario Domain Local groups can not be used to secure or grant access to resources in a trusting domain(Resource domain). 
 You must be misunderstanding my statement. Yes, Microsoft&rsquo;s best practice is to use domain local groups on the DACL on the securable resources and global/universal groups as member with the users as member of the global/universal groups. So we are saying the same thing. The point I was making is that the domain local group applied to the resource ACE must come from the domain the server is a member. Even if you tried, you can not add a domain local groups from any other trusted domain. That is the point I was making. Migration had nothing to do with that statement, 
 jones mark personal said: Let's consider if Domain Local group of Source Domain is migrated to Domain Local group of Target Domain with Sidhistory. It means Target Domain Local group sidhistory attribute having value: <Sid of Source Domain Local group>. Target Domain user is member of Target Domain local group. 
 Agreed. 
 jones mark personal said: Question: If Target Domain user login to Target Domain joined workstation then What Sids will be showing in target user's access token? 
 Depends where the impersonation token is generated. 
 jones mark personal said: Sid of target domain local group + Sidhistory (Sid of Source domain local group) both 
 OR 
 Only Sid of target domain local group 
 In the target domain, the top one. In the source it is different. 
 jones mark personal said: My Guess: Target user's access token will be showing Sid of target domain local group as well as Sidhistory (Sid of Source domain local group) both. Am I correct? 
 Again, you are correct in the target domain. In the source domain is it different. 
 For everything else, you are forgetting how the impersonation tokens are generated by the servers holding the resources you are accessing. If they are within the same domain as the users, it is the same for all servers and workstations with only the server/ workstations local groups. If the servers are members of other trusting domains, no user domain, domain local groups will be found in the impersonation access token. This is the point the support KB is trying to explain. 
 it is not my job to update support KBs. Anyone can comment on any KB they think needs to be changed, corrected and greater detail added.

Former Member · Answer

jones mark personal 
 I'd recommend at this point that if this issue is still ongoing with one of our products, to open a support ticket. this way a support engineer can assist you by taking a deeper look than possible in the community. especially avoiding to divulge any specifics about your work environment and in a more timely and expedite manner https://support.quest.com/contact-support 
 
 Our engineers will be waiting for your request. 
 Thank you

Question related to Sidhistory

How the Access Token Limit Is Reached

Top Replies