Hi Matthieu,

Here is a final update for this issue.  [MS-ADTS] 3.1.1.3.4.1.3 has additional 
qualifiers regarding MaxBytes (shown below).  The changes will be public in the 
next normal refresh of the document set.

Bryan

3.1.1.3.4.1.3   LDAP_SERVER_DIRSYNC_OID
[...]
MaxBytes specifies the maximum number of bytes to return in the reply message.

The minimum value for MaxBytes is 0x100000. When a lower value is specified, 
the value is ignored and the maximum number of bytes in the reply message is 
0x100000.

The maximum value for MaxBytes is determined by the size in bytes of a response 
with the maximum number of objects that can be returned in a single search as 
specified by the MaxPageSize policy, section 3.1.1.3.4.6. When a higher value 
is specified, the value is ignored and the maximum number of bytes in the reply 
message is the size in bytes of a response with the MaxPageSize number of 
objects.


-----Original Message-----
From: Bryan Burgin 
Sent: Tuesday, March 08, 2011 5:10 PM
To: '[email protected]'
Cc: '[email protected]'; '[email protected]'; MSSolve Case Email
Subject: RE: [REG:111012761781621] Dirsync control

Hi Matthieu,

We concluded our investigation.  The outcome is below.  We are in the process 
of updating the documentation to reflect these findings.

The minimum value for MaxBytes is 0x100000. When a lower value is specified, 
the value is ignored and the maximum number of bytes in the reply message is 
0x100000.
The maximum value for MaxBytes is determined by the size in bytes of a response 
with the maximum number of objects that can be returned in a single search as 
specified by "MaxPageSize", [MS-ADTS] section 3.1.1.3.4.6. When a higher value 
is specified, the value is ignored and the maximum number of bytes in the reply 
message is the size in bytes of a response with "MaxPageSize" objects.

Bryan

-----Original Message-----
From: Bryan Burgin
Sent: Tuesday, March 08, 2011 11:01 AM
To: '[email protected]'
Cc: '[email protected]'; '[email protected]'; MSSolve Case Email
Subject: RE: [REG:111012761781621] Dirsync control

Hi, Matthieu,

Just a quick note.  I believe we have an answer for you, but we are having the 
protocol architect review our findings.  I should have a final answer to you 
soon.

Bryan

-----Original Message-----
From: Bryan Burgin
Sent: Tuesday, March 01, 2011 3:02 PM
To: '[email protected]'
Cc: [email protected]; [email protected]; MSSolve Case Email
Subject: RE: [REG:111012761781621] Dirsync control

Matthieu,

I have been working with the product group on this issue and that work is 
continuing.  The feedback is incomplete, but let me pass on what we have:

"The 'size' element on the DirSyncControlValue represents the maximum number of 
bytes expected in the reply. Please disregard the contents of 
http://msdn.microsoft.com/en-us/library/Aa366978.  An  investigation regarding 
the upper and lower limits for the 'size' attribute is underway.  The 
documentation will be updated when the investigation is complete."

Thank you for your patience.

Bryan

-----Original Message-----
From: Matthieu Patou [mailto:[email protected]]
Sent: Wednesday, February 23, 2011 10:55 PM
To: Bryan Burgin
Cc: [email protected]; [email protected]; MSSolve Case Email
Subject: Re: [REG:111012761781621] Dirsync control

Hi Bryan,
On 22/02/2011 01:52, Bryan Burgin wrote:
> Hi, Matthieu,
>
> I'm working through your three DIRSYNC issues.  Regarding this one, I have an 
> inquiry filed with the product group for more clarification.  I also see that 
> [MS-ADTS] 3.1.1.3.4.1.3 "LDAP_SERVER_DIRSYNC_OID" specifies bytes as well.  
> However, elsewhere I'm also seeing number of attributes.
>
> I do see notes in our code that comes close to the "The key value seems to be 
> around 1000000 (1050000 more exactly)" observation that you cited.  I'm 
> finding #define MAX_ATTIBUTES 1048576, which is a more natural (in Base 2 
> terms) number of 0x100000.
Well it seems more to be the minimum value for the maximum attributes, like if 
you specify a value smaller than this you will have at most
1058576 attributes.
> When you did your experiment with "schema" using 200000 (returning 464 
> results) and 2000000 (returning 879 results), how many bytes were returned?  
> This observation might suggest 'size' is a byte count, depending on your 
> answer.
Well that's pretty hard to say as our tool tend to refromat some data to make 
them easier to read (ie. SIDs, Security Descriptors, binary blobs, ...).
So is this a "size" or a "maximum # of attributes" ?

Matthieu
> I'll respond more when I get feedback from the product group.  If you have an 
> update on your end, please let me know.
>
> Bryan
>
> -----Original Message-----
> From: Matthieu Patou [mailto:[email protected]]
> Sent: Monday, January 31, 2011 12:06 PM
> To: Bryan Burgin
> Cc: [email protected]; [email protected]; MSSolve Case Email
> Subject: Re: [REG:111012761781621] Dirsync control
>
> Hi Bryan,
>
> So let's look at
> ./bin/ldbsearch --controls="dirsync:1:0:20000" -H ldap://172.16.100.25 
> -U administrator%totoTATA123 ./bin/ldbsearch 
> --controls="dirsync:1:0:200000" -H ldap://172.16.100.25 -U
> administrator%totoTATA123 ./bin/ldbsearch 
> --controls="dirsync:1:0:2000000" -H ldap://172.16.100.25 -U
> administrator%totoTATA123
>
> So ldbsearch is our tool to do ldap request.
>
> --controls="dirsync:1:0:200000" is to add the DIRSYNC control to the request, 
> after the first colon there is parameters for the control, each seperated by 
> colon. The first one is the critical/non-critical indicator (here critical), 
> the second one is the flags (LDAP_DIRSYNC_OBJECT_SECURITY, ...) (here we 
> don't have any), the third is the size/maxAttributeCount (here 200000) and 
> the forth one is the cookie itself encoded in base64 (here absent).
>
>
> It is ok like this ? Feel free to ping me if you need more infos.
>
> Matthieu
>
>
> On 28/01/2011 01:41, Bryan Burgin wrote:
>> Hi, Matthieu,
>>
>> I can help you with this.  Let me do some preliminary research.  Can you 
>> send more info re the command line arguments of your ./bin/ldbsearch tool so 
>> that I can replicate it with our LDP tool?
>>
>> Bryan
>>
>> -----Original Message-----
>> From: Obaid Farooqi
>> Sent: Thursday, January 27, 2011 9:13 AM
>> To: [email protected]
>> Cc: [email protected]; [email protected]; MSSolve Case Email
>> Subject: RE:[REG:111012761781621] Dirsync control
>>
>> Hi Matthieu:
>> Thank you for contacting Microsoft regarding your question about MS-DRSR. A 
>> member of protocol documentation team will be in touch soon.
>>
>> Regards,
>> Obaid Farooqi
>> Escalation Engineer | Microsoft
>>
>> -----Original Message-----
>> From: Matthieu Patou [mailto:[email protected]]
>> Sent: Thursday, January 27, 2011 3:43 AM
>> To: [email protected]; [email protected]; Interoperability 
>> Documentation Help
>> Subject: Dirsync control
>>
>> Hello Doc team,
>>
>> I'm starting to work on the implementation of the dirsync control for samba4.
>>
>> I've got some questions about the maxsize parameter in the dirsync 
>> control
>>
>> Paragraph 5.112.1.5 DirSyncControlValue of DRSR.pdf says
>>
>> size: In the request control value, this field indicates the maximum number 
>> of bytes expected in the reply. In the reply control value, it is set to 0.
>>
>> But quite a lot pages on msdn like
>> http://msdn.microsoft.com/en-us/library/Aa366978, says 
>> maxAttributeCounmaxAttributeCount
>> t: Specifies the maximum number of attributes to return.
>> This value may also be used to limit the amount of data returned.
>>
>> What is the good definition ?
>>
>> Also it seems that lower value limit so that if you specify a size 
>> (or
>> maxAttributeCount) smaller than that value it's ignored, I discovered this 
>> by doing like this:
>> ./bin/ldbsearch --controls="dirsync:1:0:200" -H ldap://172.16.100.25 
>> -U
>> administrator%totoTATA123
>> ./bin/ldbsearch --controls="dirsync:1:0:2000" -H ldap://172.16.100.25 
>> -U
>> administrator%totoTATA123
>> ./bin/ldbsearch --controls="dirsync:1:0:20000" -H
>> ldap://172.16.100.25 -U administrator%totoTATA123 ./bin/ldbsearch 
>> --controls="dirsync:1:0:200000" -H ldap://172.16.100.25 -U
>> administrator%totoTATA123 ./bin/ldbsearch 
>> --controls="dirsync:1:0:2000000" -H ldap://172.16.100.25 -U
>> administrator%totoTATA123
>>
>>     As in every case the same amount of data is returned.
>>
>> When trying with another bigger partition: schema
>>
>> ./bin/ldbsearch --controls="dirsync:1:0:200000" -H ldap://172.16.100.25 -U 
>> administrator%totoTATA123  -b
>> "CN=Schema,CN=Configuration,DC=w2k8r2,DC=home,DC=matws,DC=net"   yield
>> 464 results
>>
>> ./bin/ldbsearch --controls="dirsync:1:0:2000000" -H
>> ldap://172.16.100.25 -U administrator%totoTATA123  -b 
>> "CN=Schema,CN=Configuration,DC=w2k8r2,DC=home,DC=matws,DC=net"  yield
>> 879 results
>>
>> The key value seems to be around 1000000 (1050000 more exactly), can you 
>> confirm if there is a lower value, and if any upper value ? And if so is it 
>> implementation dependent.
>>
>> Also it seems that even if I specify a size of 2MiB (2 * 10^6 Bytes) the 
>> result size in way bellow this limit, how the size is calculated then ?
>>
>> Regards.
>>
>> Matthieu
>>
>>
>>
>>
>> --
>> Matthieu Patou
>> Samba Team        http://samba.org
>> Private repo      http://git.samba.org/?p=mat/samba.git;a=summary    
>>
>>
>>
>> Microsoft is committed to protecting your privacy.  Please read the 
>> Microsoft Privacy Statement for more information.The above is an email for a 
>> support case from Microsoft Corp.REPLY ALL TO THIS MESSAGE or INCLUDE 
>> [email protected] IN YOUR REPLY if you want your response added to the 
>> case automatically. For technical assistance, please include the Support 
>> Engineer on the TO: line. Thank you.
>>
>
> --
> Matthieu Patou
> Samba Team        http://samba.org
> Private repo      http://git.samba.org/?p=mat/samba.git;a=summary
>
>
>


--
Matthieu Patou
Samba Team        http://samba.org
Private repo      http://git.samba.org/?p=mat/samba.git;a=summary



_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol

Reply via email to