Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2009-08-05) Forward-links, Back-links And How These Are Maintained

Posted by Jorge on 2009-08-05


This may be an old one, but recently a question was asked about this in one of the best AD forums I know and I thought it would make a good post on my blog.

The question was about the following piece of info which you can find in this book.

image

To explain what is being said in that piece of information let’s just use an example as shown below.

If you have a Global Group in domain A (GG-A) and a DLG in domain B (DLG-B) the following will occur:

(The GG-A could also be a user account)

No Memberships yet…

Domain A:

GC1-A:
GG-A
DLG-B

DC2-A:
GG-A

Domain B:

DC1-B:
DLG-B

GC2-B:
GG-A
DLG-B

GG-A memberOf DLG-B

Domain A:

GC1-A:
GG-A
MemberOf:
DLG-B
Member:

DC2-A:
GG-A
MemberOf:

Domain B:

DC1-B:
DLG-B
Member: GG-A

GC2-B:
GG-A
memberOf: DLG-B
DLG-B
Member: GG-A

GC1-A ? It is a GC and thus it knows about the GG-A group and the DLG-B group. Because membership of DLG groups DO NOT replicate to GCs, it’s membership (DLG-B) attribute is empty. As there is "no" member value, there is no need or possibility to create the memberOf value on GG-A

DC2-A ? It is not a GC and thus it only knows about the GG-A group

DC1-B ? It is not a GC and thus it only knows about the DLG-B group. It is able to have GG-A as a member because the IM FSMO created a phantom object

GC2-B ? Because GC2-B knows of course about the DLG-B group as both are in the same AD domain. Because it is also a GC it knows about GG-A group and it (GC2-B) is able to create the memberOf relation on GG-A to DLG-B.

If you have a Universal Group in domain A (UG-A) and a DLG in domain B (DLG-B) the following will occur:

No Memberships yet…

Domain A:

GC1-A:
UG-A
DLG-B

DC2-A:
UG-A

Domain B:

DC1-B:
DLG-B

GC2-B:
UG-A
DLG-B

UG-A memberOf DLG-B

Domain A:

GC1-A:
UG-A
MemberOf:
DLG-B
Member:

DC2-A:
UG-A
MemberOf:

Domain B:

DC1-B:
DLG-B
Member: UG-A

GC2-B:
UG-A
memberOf: DLG-B
DLG-B
Member: UG-A

GC1-A ? It is a GC and thus it knows about the UG-A group and the DLG-B group. Because membership of DLG groups DO NOT replicate to GCs, it’s membership (DLG-B) attribute is empty. As there is "no" member value, there is no need or possibility to create the memberOf value on UG-A

DC2-A ? It is not a GC and thus it only knows about the UG-A group

DC1-B ? It is not a GC and thus it only knows about the DLG-B group. It is able to have UG-A as a member because the IM FSMO created a phantom object

GC2-B ? Because GC2-B knows of course about the DLG-B group as both are in the same AD domain. Because it is also a GC it knows about UG-A group and it (GC2-B) is able to create the memberOf relation on UG-A to DLG-B.

If you have a Universal Group in domain A (UG-A) and a Universal Group in domain B (UG-B) the following will occur:

No Memberships yet…

Domain A:

GC1-A:
UG-A
UG-B

DC2-A:
UG-A

Domain B:

DC1-B:
UG-B

GC2-B:
UG-A
UG-B

UG-A memberOf UG-B

Domain A:

GC1-A:
UG-A
memberOf: UG-B
UG-B
Member: UG-A

DC2-A:
UG-A
MemberOf:

Domain B:

DC1-B:
UG-B
Member: UG-A

GC2-B:
UG-A
memberOf: UG-B
UG-B
Member: UG-A

GC1-A ? It is a GC and thus it knows about the UG-A group and the UG-B group. Because membership of UG groups DO replicate to GCs, it’s membership (UG-B) attribute is NOT empty. As there is a member value, there is a possibility to create the memberOf value on UG-A

DC2-A ? It is not a GC and thus it only knows about the UG-A group

DC1-B ? It is not a GC and thus it only knows about the UG-B group. It is able to have UG-A as a member because the IM FSMO created a phantom object

GC2-B ? Because GC2-B knows of course about the UG-B group as both are in the same AD domain. Because it is also a GC it knows about UG-A group and it (GC2-B) is able to create the memberOf relation on UG-A to UG-B.

Summarized:

Forward/backlinks are ALWAYS within ONE AD instance, never between AD instances. When creating a relation between objects, both objects must be in the same AD instance and the "relationship rules" must allow that relation to occur (e.g. universal group membership replicates to GCs in other domains, others do not). Forward-links replicate to other DC, they can be delegated permissions to and are editable. Backlinks do not replicate to other DC but are created independently on and by each local DC, canNOT be delegated permissions to and are NOT editable.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: