[cifs-protocol] [REG: 117070616001855] [MS-DRSR] Calling GetNCChanges with DRS_GET_TGT flag

[Tim Beale]

Hi Edgar,

>> Request more detail in case of cross-partition target

We understand that it requires implementation-specific behaviour to
resolve an unknown target object when the linked attribute spans
partitions. This was answered for us in 117060115827644.

>> Target object is only recycled, as opposed to Target-object is unknown
>> (linked-attribute and you don't know the target, you send DRS_GET_TGT)

This is what I'm confused about. I inferred from the MS_DRSR Docs that
the client uses DRS_GET_TGT if it receives a linked attribute with an
unknown target object. However, the answers we received for
117060815865307 seemed to imply that DRS_GET_TGT is only used if the
target object is deleted/recycled (as opposed to simply being a
new/unknown object). Could you please clarify this - should the client
use it in either case, or is it only the deleted/recycled case where the
flag is actually required?

>> Implementation-specific statement regarding client using DRS_GET_TGT

Basically it's the following block of code in 4.1.10.6.14
ProcessLinkValue() that I find confusing/misleading.

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

I don't think the proposed Docs change for 117060815865307 makes this
any easier to understand. Documentation-wise, I think there's room for
the following minor improvements:

1. Section 3.4.5 describes the ! notation. However, I couldn't see
anything that describes what happens if the object specified by the DN
doesn't exist. I would assume the attribute returned would be null.
2. If the target object doesn't exist, the current code looks like the
4.1.10.6.14 block will fall through and add a hanging link to an unknown
object. Is that the intended behaviour? A comment stating that would be
nice.
3. If there is other implementation-specific behaviour in the
4.1.10.6.14 block, then a comment stating "The actual behaviour here may
be implementation-specific" would be nice.
4. I also just noticed the above block is missing an endif.

Thanks for your help,

Tim

On 07/07/17 04:51, Edgar Olougouna via cifs-protocol wrote:
>
> Please provide any additional write-up as necessary. We will review
> this and follow-up.
>
>  
>
> Implementation-specific statement regarding client using DRS_GET_TGT
>
> Request more detail in case of cross-partition target
>
> Target object is only recycled, as opposed to Target-object is unknown
>
> (linked-attribute and you don't know the target, you send DRS_GET_TGT)
>
>  
>
> Thanks,
>
> Edgar
>
>
>
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at lists.samba.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20170710/652877c5/attachment.html>