Question related to Sidhistory

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’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:·      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.·    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.

Top Replies

  • In general, SIDHistory is a temporary "stopgap" for allowing access to resources before re-permissioning is completed.

    Having said that, your goal in planning a domain migration project should always be to try and get re-permissioning completed on all of your servers before you cutover your first users to their new domain. When fully exploited, QMM's powerful Resource Updating Manager (RUM) can help you to get this done efficiently. Thus, ideally, you should not need to rely on SIDHistory at all.

  • Thank you  for explaining about sidhistory. I would appreciate if you could answer questions related to Access Token and clear up my confusion.

    Questions came into my mind after reading Quest Support article. Below is the link for reference.

    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’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:·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.·    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.

    Kindly reply specific to above mentioned questions and explain.

    Thanks.

    Mark Jones

  • He did give you an answer. You just did not like it. 

    Q1: Yes. Domain local group to access or secure anything outside of the domain. Sid history does not change that.

    Q2: Depends on the migration workflow. No two migration are handled the same way. It all comes down to business requirements and current and future infrastructure configuration. 

    Q3: you are correct. 

  • So as I understand correctly, target user's access token will also include sidhistory of target domain local group only if source domain local migrated with sidhistory.

    But then why it's not mentioned in support article? That's why confusion came.

    They just mentioned about Sid (not sidhistory) of domain local group. However, for other groups they mentioned both Sid and sidhistory.

    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.

    Please reply.

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

  • Thank you for acknowledgement.

    So it means I've have to append/replace target equivalent users and target equivalent groups both in source domain local groups membership or ACL only if those target users and target groups are migrated using QMM. 

    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? Please confirm.

    You said: 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.

    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). Please confirm.

    My original question was:

    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. 

    Question: If Target Domain user login to Target Domain joined workstation then What Sids will be showing in target user's access token?

    Sid of target domain local group + Sidhistory (Sid of Source domain local group) both

    OR

    Only Sid of target domain local group

    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? Please confirm.

    Reason why I asked this because of Quest support article - https://support.quest.com/kb/72489/considerations-when-migrating-local-groups-with-sid-history

    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’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:·      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.·    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.

    -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    So as you can see -They just mentioned about "Sid (not sidhistory) of domain local group". However, for other groups (Global & Universal) they mentioned both Sid and sidhistory.   -->  That's why I got confused and post this question.

    But I think that 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 even though if target user login to target domain joined workstation. Am I correct? Please confirm.

    Suggestion: If I'm right, please update Quest support article.


     

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

    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’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, 

    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. 

    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. 

    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. 

    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
    0 Former Member over 3 years ago in reply to Jeff Shahan

     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