Resource Access - Sid vs Sid History vs group membership vs all

Hello,

This sounds very basic question. Excuse me for my little knowledge.

However, I still need to fully understand how access is granted on resource (source domain / target domain) to any user (migrated with or without Sid History / newly created in target domain). Is access granted on resource to user on the basis of group membership or Sid or Sid History or all required? Let me explain what I mean

For example, if I migrate groups from source to target domain using Sid History. All resources are in the source domain. Source groups are applied on resource ACL in source domain. If I add a non-migrated user (newly created in the target domain) into a migrated group in the target domain then

Q1: Should the non-migrated user be able to access resource (based on permissions granted to source group) in the source domain just via Sid History (without any group membership) because user token will have the Sid of source group in Sid History attribute of migrated group? OR do I also need to add non-migrated user in source group either via direct membership or adding migrated group nested into source group?

Q2: Should the migrated user be able to access resource in source domain just via Sid History OR group membership is also required?

I'm confused. Kindly explain.

Parents
  • Hi,

    Q1 To the point, if the resource you are accessing was given permissions via a group and that group was migrated(with SidHistory) from DOMAINA > DOMAINB.  Then you can add the newly created user from DOMAINB, to the migrated group that came from DOMAINA.  You can not add a user cross forest directly into a Global/Universal Group, it must be a DOMAIN Local Group.  But you can also add them directly to the ACE...…..which is dirty and not best practice.

    Q2, Depends how your environment is setup, every environment is different. You can give access directly to the User or to the Group, the latter is cleaner.  Then migrating SidHistory depends on what your conclusion is on the prior statement, regardless migrate SidHistory with Users/Groups...…..then cleanup at the end.

    Does that make sense?

    Cheers

Reply
  • Hi,

    Q1 To the point, if the resource you are accessing was given permissions via a group and that group was migrated(with SidHistory) from DOMAINA > DOMAINB.  Then you can add the newly created user from DOMAINB, to the migrated group that came from DOMAINA.  You can not add a user cross forest directly into a Global/Universal Group, it must be a DOMAIN Local Group.  But you can also add them directly to the ACE...…..which is dirty and not best practice.

    Q2, Depends how your environment is setup, every environment is different. You can give access directly to the User or to the Group, the latter is cleaner.  Then migrating SidHistory depends on what your conclusion is on the prior statement, regardless migrate SidHistory with Users/Groups...…..then cleanup at the end.

    Does that make sense?

    Cheers

Children
  • Hi

    Now I am more confused between group membership vs Sid History.  You're saying that I can add newly created user to the migrated group (contains Sid of source group ) and will be able to access resource . But what about group membership? I thought access is always granted on the basis of group not Sid History. How access is granted if migrated group is not nested in source group? How actual permissions applied on source group will inherit to members of migrated group if migrated group is not nested in source group? I mean then what is the point of group membership if access is granted on the basis of Sid/Sid History? Then why is it required to add users in groups, why can't we add Sid of group in Sid History attribute?

    Please explain.

  • We seam to be missing a basic understanding of how Microsoft's Best Practice for group management, resource access controls are implemented. Without that basic foundation, a complex topic like sid history is going to be even more confusing. 

    You're saying that I can add newly created user to the migrated group (contains Sid of source group ) and will be able to access resource . Depending on the group type/scope, yes. 

    But what about group membership? Too vague of a question.  

    I thought access is always granted on the basis of group not Sid History. You were wrong. 

    How access is granted if migrated group is not nested in source group? Again, too vague and without context. Please restate.

    How actual permissions applied on source group will inherit to members of migrated group if migrated group is not nested in source group? Confusing at best. Permissions applied on source group have not bearing on resources that group members can access. 

    I mean then what is the point of group membership if access is granted on the basis of Sid/Sid History?Access is and always have been at the Access Token/SID level. Without group membership how would a user get the groups sid in their access token. 

    Then why is it required to add users in groups, why can't we add Sid of group in Sid History attribute? You can't, Sid history is forest unique, that's why. And if you could how would you manage permissions and audit access post migration? 

  • This question here:

    Then why is it required to add users in groups, why can't we add Sid of group in Sid History attribute?

    ...can be interpreted two ways:

    1)  ...why can't we add Sid of [source] group into [target Users'] Sid History attribute?

    Answer:  Because you are mixing object classes and AD probably won't allow it

    OR

    2)  ...why can't we add Sid of [source] group into [target Groups'] Sid History attribute? [and not bother with re-permissioning]

    Answer:  Technically you can (and most often do) but it is strongly recommended to perform re-permission / re-ACL and cleanup.

    What's really making this discussion complicated is the issue around the change of the group scope from Domain Local to Global during the migration.  In my mind, it begs the question of assessing the practicality of doing this - i.e. as part of Discovery, did someone look at the memberships of all those source Domain Local groups and determine whether there were any "foreign" members (i.e. from domains not included among the QMM AD domain pairs).  

  • Thank you    

    Groups has been migrated from source domain to target domain using Sid History and scope of the group has been changed from domain local group (source domain) to Global group (target domain) meaning that now migrated global group in target domain has Sid of source domain local group in Sid History attribute.


    As you said, Access is and always have been at the Access Token/SID level. "Without group membership how would a user get the groups Sid in their access token". So If I add newly created user (created in target domain) in migrated global group, his access token contains:

    Sid for target domain user account
    Sid for migrated global group of which the user is a member.
    Sid for source domain local group in Sid History attribute of migrated global group

    So newly created user (created in target domain) has Sid of source domain local group in Sid History attribute as part of access token and user will be able to access resource without group membership(either directly or indirectly via group nesting) of source domain local group.

    Please confirm if above statement is true.

    If the above statement is true and access on resource(source domain) is granted on the basis of Sid History, then why / what is the point of nesting migrated global group into source domain local group? In my AD infrastructure, I see that migrated global group is nested inside source domain local group. Why is this required? What is the main reason?

    Kindly explain.

    It would be great help if you share link of articles for below mentioned topics:

    1- Understanding Microsoft's Best Practice for group management,

    2- Resource access controls

    3- Sid History

    Thanks in advance Pray

  • - Google will provide you lots of articles about these topics.  If you have specific questions about relating this knowledge to how the Quest tools work, please post here.

  • Hi ,

    Yes, I have query related to resource process by RUM.

    If the resources had been migrated on file server of target domain, the resources are secured with source domain local groups, those source domain local groups were migrated to the target domain using Sidhistory and scope of the source domain group had been changed from domain local group (in source domain) to Global group (in target domain). Apart from this, migrated global group(target domain) is also nested inside domain local group(source domain).

    So it means access is now being controlled by target group with Sidhistory. Then, how does RUM handles this and how access is retained for source domain users who are direct members of source domain local groups? What should I do with those source domain local groups?

    Please explain.

  • A RUM Processing job will search for the domain local groups in the file system ACLs and append (assuming you use the right setting), your target global group equivalents into the ACLs.  Once you have satisfied yourself (through testing) that users' access is correct, then you could run a cleanup Processing job to remove the Domain Local Groups.  Once this processing is complete, the groups' SIDHistory is no longer important assuming of course that the group memberships (direct or nested) in the target provide the correct users access.






  • Could you please elaborate the issue around the change of the group scope from domain local to Global during the migration? How it affects if source domain local groups contains "Foreign" members and how ADPW handles this?




  • 1. Don't change the group scope.  Domain Locals CAN have trusted domain member and Domain Globals can not.