[cifs-protocol] 117060815865307 Question about DRS client behaviour with linked attributes
Tim Beale
timbeale at catalyst.net.nz
Sun Jul 2 22:00:50 UTC 2017
Hi Sreekanth,
Thanks, for your reply. Sorry, I didn't understood the ! notation, which
meant I misunderstood that block of code.
I see that section 3.4.5 describes the ! notation. However, I couldn't
see anything in 3.4.5 that states what happens if the object specified
by the DN doesn't exist. I assume that, in general terms, the value of
the o!attr expression will be null if the object corresponding to the DN
'o' doesn't exist?
However, I think what you're saying is that in this specific
ProcessLinkValue() case, there is some additional
implementation-specific logic here to handle objects that don't exist
locally.
I am still pretty confused by the ProcessLinkValue() pseudo-code. Could
you clarify which of the following statements is true?
1. GET_TGT is only ever used for recycled or deleted objects. It is
never used if a new target object does not exist locally.
2. GET_TGT can also be used if the target object doesn't exist locally
(although this case may involve implementation-specific logic).
Thanks,
Tim
On 30/06/17 06:26, Sreekanth Nadendla wrote:
>
> Hello Tim,
>
> GetDSNameFromAttrVal() only verifies that the DSNAME referenced in the
> attrval is well formed DSNAME. Getting a null from DSNameFromAttrVal
> means the replication partner sent malformed link val which is
> different from unknown object. It just means we have invalidly formed
> data.
>
>
>
> Here the intent of the protocol is to retrieve a syntactically correct
> DN from the attribute. Protocol does NOT say to validate that the name
> actually occurs in the local DIT. As you mentioned, if we get
> INVALID_ATTRIBUTE_SYNTAX here, the replication halts.
>
>
>
> If you get a validly formed DSNAME that refers to an object that does
> not exist in the local directory, the implementation must proceed and
> handle that case. This means creating a DN valued attribute that does
> not refer to an actual object in the local DIT ( An implementation
> specific way of temporarily managing reference to actual object).
>
>
>
> Hope this resolves your pending question.
>
>
>
> Regards,
>
> Sreekanth Nadendla
>
> Microsoft Windows Open Specifications
>
>
>
> *From:*Tim Beale [mailto:timbeale at catalyst.net.nz]
> *Sent:* Monday, June 26, 2017 5:00 PM
> *To:* Sreekanth Nadendla <srenaden at microsoft.com>
> *Cc:* cifs-protocol at lists.samba.org; MSSolve Case Email
> <casemail at microsoft.com>
> *Subject:* Re: 117060815865307 Question about DRS client behaviour
> with linked attributes
>
>
>
> Hi Sreekanth,
>
> Thanks for your reply.
>
> How does this relate to where ProcessLinkValue() is called, in
> particular the setting of the DRS_GET_TGT flag? i.e. the block near
> the end of 4.1.10.6.1:
>
> if (ulResult = ERROR_DS_DRA_MISSING_PARENT) then
> Send IDL_DRSGetNCChanges message again with the same input
> parameters specified in msgIn but this time with msgIn.ulFlags
> containing DRS_GET_ANC field set. It is an error for this
> condition to occur if (DRS_GET_ANC in msgIn.ulFlags) is true
> else if (ulResult = ERROR_DS_DRA_RECYCLED_TARGET) then
> Send IDL_DRSGetNCChanges message again with the same input
> parameters specified in the msgIn but this time with msgIn.ulMoreFlags
> containing DRS_GET_TGT field set.
>
> The documentation here talks about the ERROR_DS_DRA_RECYCLED_TARGET
> error, but not ERROR_DS_INVALID_ATTRIBUTE_SYNTAX error. But in
> ProcessLinkValue(), we're hitting the case where the target object is
> unknown/missing. The amended documentation would imply that in the
> case where the target object is missing/unknown (as opposed to
> deleted/recycled), then we fail the replication (instead of retrying
> with DRS_GET_TGT set).
>
> In my testing with Windows I have seen cases where the Windows DC will
> send a linked attribute with an unknown target object (that hasn't
> been deleted/recycled at all). Resending the GetNCChanges request with
> the DRS_GET_TGT flag set will fix this problem. Am I misunderstanding
> how the protocol works? I was expecting the documentation to look more
> like:
>
> if (targetObject = null or
> (IsRecycleBinEnabled() and targetObject!isRecycled) or
> (not IsRecycleBinEnabled() and targetObject!isDeleted)) then
> if (DRS_GET_TGT in ulMoreFlags) then
> /* nothing to do */
> return 0
> else
> return ERROR_DS_DRA_RECYCLED_TARGET
> endif
>
> Thanks,
>
> Tim
>
>
>
> On 27/06/17 07:17, Sreekanth Nadendla wrote:
>
> Hello Tim, below is the corrected edit for issue #1 you’ve
> reported. MS-DRSR will be updated with this change. The correct
> error code returned would be ERROR_DS_INVALID_ATTRIBUTE_SYNTAX.
>
>
>
> targetObject = GetDSNameFromAttrVal( replValinf.attrTyp,
> replValInf.pAval)
>
>
>
> if (targetObject = null)
>
> return ERROR_DS_INVALID_ATTRIBUTE_SYNTAX
>
>
>
> if ((IsRecycleBinEnabled() and targetObject!isRecycled) or
>
> (not IsRecycleBinEnabled() and targetObject!isDeleted)) then
>
> if (DRS_GET_TGT in ulMoreFlags) then
>
> /* nothing to do */
>
> return 0
>
> else
>
> return ERROR_DS_DRA_RECYCLED_TARGET
>
> endif
>
>
>
> Regards,
>
> Sreekanth Nadendla
>
> Microsoft Windows Open Specifications
>
>
>
> *From:*Tim Beale [mailto:timbeale at catalyst.net.nz]
> *Sent:* Wednesday, June 7, 2017 7:35 PM
> *To:* Sreekanth Nadendla <srenaden at microsoft.com>
> <mailto:srenaden at microsoft.com>
> *Cc:* cifs-protocol at lists.samba.org
> <mailto:cifs-protocol at lists.samba.org>; MSSolve Case Email
> <casemail at microsoft.com> <mailto:casemail at microsoft.com>
> *Subject:* Re: 117060115827644 Question about DRS client behaviour
> with linked attributes
>
>
>
> Hi Sreekanth,
>
> Thanks for the link. I'd already seen that article (or one very
> similar), but it does provide a lot of useful information about
> replication.
>
> The Docs issues I mentioned in the conference call are as follows:
>
> 1). A fortnight ago, I raised a minor issue with MS-DRSR
> 4.1.10.6.14 ProcessLinkValue(). i.e.
> https://msdn.microsoft.com/en-us/library/dd207759.aspx
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fdd207759.aspx&data=02%7C01%7Csrenaden%40microsoft.com%7C46a7a120036b469503df08d4adfdd01e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636324753009373564&sdata=paOhTFuE9pSC5yfXLlZhP9UZWBdUWzVR%2FleL0TVLWXk%3D&reserved=0>
>
> In the following block of code that checks the link target, it
> looks like it's missing a null check for targetObject.
>
> targetObject = GetDSNameFromAttrVal(replValinf.attrTyp,
> replValInf.pAval)
> if ((IsRecycleBinEnabled() and targetObject!isRecycled) or
> (not IsRecycleBinEnabled() and targetObject!isDeleted)) then
> if (DRS_GET_TGT in ulMoreFlags) then
> /* nothing to do */
> return 0
> else
> return ERROR_DS_DRA_RECYCLED_TARGET
> endif
>
> Presumably it should also return ERROR_DS_DRA_RECYCLED_TARGET if
> targetObject is null, as this is what triggers the use of the
> DRS_GET_TGT flag.
>
> 2). Related to this, the error code used here isn't documented,
> i.e. it isn't listed on
> https://msdn.microsoft.com/en-us/library/cc231199.aspx
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fcc231199.aspx&data=02%7C01%7Csrenaden%40microsoft.com%7C46a7a120036b469503df08d4adfdd01e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636324753009373564&sdata=rM3m%2Bv6oVnAKrGM%2Frzu8PV8hX8eCbPfMe59TQdgB8Oc%3D&reserved=0>
>
> I think it should be something like:
>
> ERROR_DS_DRA_RECYCLED_TARGET 0x000021BF
>
> Thanks for your help.
>
> Tim
>
> On 08/06/17 09:56, Sreekanth Nadendla wrote:
>
> Hello Tim, below is the article I mentioned and it provides some useful details about Linked value replication scenarios.
>
> https://technet.microsoft.com/en-us/library/cc772726(v=ws.10).aspx
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftechnet.microsoft.com%2Fen-us%2Flibrary%2Fcc772726%28v%3Dws.10%29.aspx&data=02%7C01%7Csrenaden%40microsoft.com%7C46a7a120036b469503df08d4adfdd01e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636324753009373564&sdata=hxJIraSwimp3qi%2BA6Sr7cRTqCPAitKfiZ2CmucuG4VM%3D&reserved=0>
>
>
>
>
>
> Regards,
>
> Sreekanth Nadendla
>
> Microsoft Windows Open Specifications
>
>
>
> -----Original Message-----
>
> From: Sreekanth Nadendla
>
> Sent: Thursday, June 1, 2017 5:03 PM
>
> To: 'Tim Beale' <timbeale at catalyst.net.nz> <mailto:timbeale at catalyst.net.nz>
>
> Cc: cifs-protocol at lists.samba.org
> <mailto:cifs-protocol at lists.samba.org>; MSSolve Case Email <casemail at microsoft.com> <mailto:casemail at microsoft.com>
>
> Subject: 117060115827644 Question about DRS client behaviour with linked attributes
>
>
>
> Hello Tim, I will be assisting you with this issue.
>
>
>
> Regards,
>
> Sreekanth Nadendla
>
> Microsoft Windows Open Specifications
>
>
>
> -----Original Message-----
>
> From: Tim Beale [mailto:timbeale at catalyst.net.nz]
>
> Sent: Wednesday, May 31, 2017 8:18 PM
>
> To: Interoperability Documentation Help <dochelp at microsoft.com> <mailto:dochelp at microsoft.com>; cifs-protocol at lists.samba.org
> <mailto:cifs-protocol at lists.samba.org>
>
> Subject: Question about DRS client behaviour with linked attributes
>
>
>
> Hi,
>
>
>
> 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:
>
> dn:
>
> CN=RWDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=SAMDOM,DC=EXAMPLE,DC=COM
>
> 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 Volume,CN=DFSR-GlobalSettings,CN=System,DC=SAMDOM,DC=EXAMPLE,DC=COM
>
> serverReference: CN=NTDS
>
> Settings,CN=RWDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=SAMDOM,DC=EXAMPLE,DC=COM
>
>
>
> 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 problem?
>
> - 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.
>
>
>
> Tim
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20170703/f1522415/attachment-0001.html>
More information about the cifs-protocol
mailing list