Resource access via Sid History Vs Resource access via Group membership post Inter-forest Migration

%3CLINGO-SUB%20id%3D%22lingo-sub-1376456%22%20slang%3D%22en-US%22%3EResource%20access%20via%20Sid%20History%20Vs%20Resource%20access%20via%20Group%20membership%20post%20Inter-forest%20Migration%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1376456%22%20slang%3D%22en-US%22%3E%3CDIV%3EHello%2C%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3EGreetings%20of%20the%20day!%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%3CP%3E%3CSPAN%3EResources%20are%20in%20the%20source%20domain.%20%22Domain%20Local%22%26nbsp%3B%3C%2FSPAN%3Egroups%20of%20source%20domain%20are%20applied%20on%20resource%20ACL.%20Those%20source%20domain%20local%20groups%20had%20been%20migrated%20from%20source%20domain%20to%20target%20domain%20using%20Sid%20History%20and%20scope%20of%20the%20source%20domain%20group%20had%20been%20changed%20from%20domain%20local%20group%20(in%20source%20domain)%20to%20Global%20group%20(in%20target%20domain)%20meaning%20that%20now%20global%20group%20in%20target%20domain%20have%20Sid%20of%20source%20domain%20local%20group%20in%20Sid%20History%20attribute.%3CBR%20%2F%3E%3CBR%20%2F%3ESo%20If%20I%20add%20newly%20created%20user%20(created%20in%20target%20domain)%20inside%20migrated%20global%20group%2C%20his%20access%20token%20contains%3A%3CBR%20%2F%3E%3CBR%20%2F%3ESid%20for%20target%20domain%20user%20account%3CBR%20%2F%3ESid%20for%20migrated%20global%20group%20of%20which%20the%20user%20is%20a%20member.%3CBR%20%2F%3ESid%20for%20source%20domain%20local%20group%20in%20Sid%20History%20attribute%20of%20migrated%20global%20group%3CBR%20%2F%3E%3CBR%20%2F%3ESo%20newly%20created%20user%20now%20has%20Sid%20of%20source%20domain%20local%20group%20in%20his%20access%20token%20and%20that%20user%20will%20be%20able%20to%20access%20resource%20without%20source%20domain%20local%20group%20membership%20(either%20directly%20OR%20indirectly%20via%20nesting%20of%20migrated%20global%20group%20inside%20source%20domain%20local%20group).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3E%3CSTRONG%3EPlease%20confirm%20if%20this%20statement%20is%20true%3F%3C%2FSTRONG%3E%3C%2FSPAN%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CSTRONG%3EIf%20the%20above%20statement%20is%20true%20%3CSPAN%3Eand%20access%20on%20resource(source%20domain)%20is%20granted%20on%20the%20basis%20of%20Sid%20History%2C%26nbsp%3B%3C%2FSPAN%3Ethen%20why%20%2F%20what%20is%20the%20point%20of%20nesting%20migrated%20global%20group%20into%20source%20domain%20local%20group%3F%20In%20my%20AD%20infrastructure%2C%20I%20see%20that%20migrated%20global%20group%20is%20nested%20inside%20source%20domain%20local%20group.Why%20is%20this%20required%3F%20What%20is%20the%20main%20reason%3F%20Kindly%20explain.%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%3CSTRONG%3E%26nbsp%3B%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3EI'm%20getting%20confused%20between%20%22Resource%20access%20via%20Sid%20History%20Vs%20Resource%20access%20via%20Group%20membership%22%20as%20the%20title%20says.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%20it%20would%20be%20great%20help%20if%20you%20share%20link%20of%20good%20articles%20for%20below%20mentioned%20topics%20that%20can%20clear%20all%20my%20doubts%20and%20confusion.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSTRONG%3E1-%20Understanding%20Microsoft's%20Best%20Practice%20for%20group%20management%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%3CSTRONG%3E2-%20Resource%20access%20controls%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%3CSTRONG%3E3-%20Sid%20History%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EPlease%20explain%20specific%20to%20all%20queries%20mentioned%20above.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%20in%20advance!%3C%2FP%3E%3C%2FDIV%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1376456%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EActive%20Directory%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EWindows%20Server%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Highlighted
Senior Member
Hello,
 
Greetings of the day!
 

Resources are in the source domain. "Domain Local" groups of source domain are applied on resource ACL. Those source domain local groups had been migrated from source domain to target domain using Sid History and scope of the source domain group had been changed from domain local group (in source domain) to Global group (in target domain) meaning that now global group in target domain have Sid of source domain local group in Sid History attribute.

So If I add newly created user (created in target domain) inside 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 now has Sid of source domain local group in his access token and that user will be able to access resource without source domain local group membership (either directly OR indirectly via nesting of migrated global group inside source domain local group).

 

Please confirm if this 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.

 

I'm getting confused between "Resource access via Sid History Vs Resource access via Group membership" as the title says. 

 

So it would be great help if you share link of good articles for below mentioned topics that can clear all my doubts and confusion.

 

1- Understanding Microsoft's Best Practice for group management

2- Resource access controls

3- Sid History

 

Please explain specific to all queries mentioned above.

 

Thanks in advance!

0 Replies