[cifs-protocol] Question about DRS client behaviour with linked attributes
timbeale at catalyst.net.nz
Thu Jun 1 00:18:26 UTC 2017
We're trying to add DRS GET_TGT support to Samba and have a question
about the behaviour of linked attributes. We noticed that you can
sometimes get linked attributes that span a partition.
For example you can have an object in the Configuration partition with a
linked attribute to an object in the Domain partition:
serverReference: CN=RWDC,OU=Domain Controllers,DC=SAMDOM,DC=EXAMPLE,DC=COM
And you can also have an object in the Domain partition with a linked
attribute to an object in the Configuration partition:
dn: CN=RWDC,CN=Topology,CN=Domain System
>From what I could see from testing, when the DRS_GET_TGT flag is set in
the ReplicateNCRequestMsg, Windows does not resolve a target object that
is in another partition.
This results in a cyclical dependency between the partitions being
replicated, E.g. you can't commit all the linked attributes in the
Domain partition until all the objects in the Configuration partition
have been received, but you can't commit all the linked attributes in
the Configuration partition until all the objects in the Domain
partition have been received. This problem could be resolved if you
manage to replicate the target object before the link is replicated.
My question is: how does the Windows replication behaviour resolve this
- Does this mean the client always has to replicate the partitions in
parallel? i.e. it can't replicate them in series because it can't commit
an entire partition until it has received portions of another partition.
- What happens when the client encounters a linked attribute with an
unknown target object? ProcessLinkValue() in the MS-DRSR seems to imply
the client will ignore it (if it's already tried with GET_TGT). So how
does the client ensure that it receives the linked attribute eventually?
Thanks for your help.
More information about the cifs-protocol