From william at blackhats.net.au  Tue Oct  4 19:52:55 2022
From: william at blackhats.net.au (William Brown)
Date: Wed, 5 Oct 2022 09:52:55 +1000
Subject: [python-ldap] dirSync control, no Cookie
In-Reply-To: <PH7PR12MB5710206204B1DE4AB3262F4F9D499@PH7PR12MB5710.namprd12.prod.outlook.com>
References: <PH7PR12MB5710206204B1DE4AB3262F4F9D499@PH7PR12MB5710.namprd12.prod.outlook.com>
Message-ID: <92830F28-F630-4C84-B015-B612E4ABE0CD@blackhats.net.au>



> On 16 Sep 2022, at 03:55, Christopher Paul <chris.paul at rexconsulting.net> wrote:
> 
> Hello Python-LDAP,
> 
> I am trying to use python-ldap to  LDAPSearch w/the MS DirSync control '1.2.840.113556.1.4.841'. 
> My ldap.controls.LDAPControl ends up looking like this:
> 
>>>> dirSync.ctrl1.controlType
> '1.2.840.113556.1.4.841'
>>>> dirSync.ctrl1.criticality
> True
>>>> dirSync.ctrl1.encodedControlValue
> b'0\x08\x02\x01\x00\x02\x01\x00\x04\x00'
> 
> This sets flags: 0, maxBytes: 0, with a null Cookie. 
> I get a result using "result4":
> 	adldapconn.result4(msgid=ldap.RES_ANY, all=1, add_ctrls=1, add_intermediates=1, add_extop=1, timeout=30)
> 
> It seems to work in as much as it was able to submit the control and control value to AD (though null cookie), and AD returns the answer with cookie value.
> 
> The problem is that the result4 contains "None, None" for the 3rd and 4th fields, so I cannot get the cookie.
> 
>>>> res=dirSync.dirSync()
> result is (101, [('CN=Jed Tanner,CN=Users,DC=adlab,DC=rexconsulting,DC=net', {'objectGUID': [b't\xfafq\xa6\xa7\xdcI\x8e\xd7\xfe\xde\xdb\xab\xfaa'], 'description': [b'Most Awesome Test User'], 'instanceType': [b'4']}, [])], 2, [], None, None)
> 
> I tried LDAPObject.extop_result too and get (None, None).
> 
> So with no cookie, I cannot make my next control value, though I do see it in tcpdump/wireshark, so know that AD is sending it back.
> 
> Is this a problem with python-ldap or am I doing something wrong? 
> 

I think the cookie value is a control on the search result done message isn't it? Not the last search entry? 

Anyway, it'd probably be best to see what you have code-wise (heck it could even be a good submission I think content sync is already in python-ldap) 


--
Sincerely,

William


From william at blackhats.net.au  Sun Oct  9 22:37:47 2022
From: william at blackhats.net.au (William Brown)
Date: Mon, 10 Oct 2022 12:37:47 +1000
Subject: [python-ldap] dirSync control, no Cookie
In-Reply-To: <PH7PR12MB571077E321410D83E59CC6A99D5F9@PH7PR12MB5710.namprd12.prod.outlook.com>
References: <PH7PR12MB5710206204B1DE4AB3262F4F9D499@PH7PR12MB5710.namprd12.prod.outlook.com>
 <92830F28-F630-4C84-B015-B612E4ABE0CD@blackhats.net.au>
 <PH7PR12MB571077E321410D83E59CC6A99D5F9@PH7PR12MB5710.namprd12.prod.outlook.com>
Message-ID: <4E04B88F-1887-40D5-BEB1-4DA7456B420D@blackhats.net.au>



> On 8 Oct 2022, at 02:30, Christopher Paul <chris.paul at rexconsulting.net> wrote:
> 
>> -----Original Message-----
>> From: William Brown <william at blackhats.net.au>
>> Sent: Tuesday, October 4, 2022 7:53 PM
>> To: Christopher Paul <chris.paul at rexconsulting.net>
>> Cc: python-ldap at python.org
>> Subject: Re: [python-ldap] dirSync control, no Cookie
>> 
>> 
>> Anyway, it'd probably be best to see what you have code-wise (heck it could
>> even be a good submission I think content sync is already in python-ldap)
> 
> Hi William,
> 
> I don't mind sharing my experimental code. I have attached to this message. 
> I have been trying this using Redhat 8.4 with python 3.6.8 and python-ldap 3.3.1.
> 
> 

Hey mate, sorry about the delay. I've looked into this further today for you, and it looks like your definition to send the control was correct! 

The issue you are hitting is result4 gives a 6 tuple response:

+ rcode, resset, id, response_controls, _, _  = adldapconn.result4(msgid=ldap.RES_ANY, all=1, add_intermediates=1, add_extop=1, timeout=30)


But that alone isn't everything. I can see in my testing that the response controls aren't being decoded. I think in this case because while you are passing in a correctly encoded control to the server, there is no way for the library to decode the dirsync control.


The best example for you to "follow" to duplicate this (and quite honestly, would be a good PR to the python ldap project) would be to add "winsync.py" to https://github.com/python-ldap/python-ldap/tree/master/Lib/ldap/controls . You can model this on the "similar" syncrepl control source found here:

https://github.com/python-ldap/python-ldap/blob/master/Lib/ldap/syncrepl.py

Most notably, what you need is the https://github.com/python-ldap/python-ldap/blob/master/Lib/ldap/syncrepl.py#L70 with "encodeControlValue", and the reverse https://github.com/python-ldap/python-ldap/blob/master/Lib/ldap/syncrepl.py#L149 on the same type (since ad winsync uses the same OID in both directions. 


Once you have that, I think you'll find that the control will work "a bit nicer" :) 

Hope that helps! 



--
Sincerely,

William


From chris.paul at rexconsulting.net  Fri Oct  7 12:30:25 2022
From: chris.paul at rexconsulting.net (Christopher Paul)
Date: Fri, 7 Oct 2022 16:30:25 +0000
Subject: [python-ldap] dirSync control, no Cookie
In-Reply-To: <92830F28-F630-4C84-B015-B612E4ABE0CD@blackhats.net.au>
References: <PH7PR12MB5710206204B1DE4AB3262F4F9D499@PH7PR12MB5710.namprd12.prod.outlook.com>
 <92830F28-F630-4C84-B015-B612E4ABE0CD@blackhats.net.au>
Message-ID: <PH7PR12MB571077E321410D83E59CC6A99D5F9@PH7PR12MB5710.namprd12.prod.outlook.com>

> -----Original Message-----
> From: William Brown <william at blackhats.net.au>
> Sent: Tuesday, October 4, 2022 7:53 PM
> To: Christopher Paul <chris.paul at rexconsulting.net>
> Cc: python-ldap at python.org
> Subject: Re: [python-ldap] dirSync control, no Cookie
> 
> 
> Anyway, it'd probably be best to see what you have code-wise (heck it could
> even be a good submission I think content sync is already in python-ldap)

Hi William,

I don't mind sharing my experimental code. I have attached to this message. 
I have been trying this using Redhat 8.4 with python 3.6.8 and python-ldap 3.3.1.

Thanks,

Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dirSync.py
Type: application/octet-stream
Size: 1320 bytes
Desc: dirSync.py
URL: <https://mail.python.org/pipermail/python-ldap/attachments/20221007/f6dc067d/attachment.obj>

From ondra at mistotebe.net  Mon Oct 10 07:18:03 2022
From: ondra at mistotebe.net (=?utf-8?B?T25kxZllaiBLdXpuw61r?=)
Date: Mon, 10 Oct 2022 13:18:03 +0200
Subject: [python-ldap] dirSync control, no Cookie
In-Reply-To: <4E04B88F-1887-40D5-BEB1-4DA7456B420D@blackhats.net.au>
References: <PH7PR12MB5710206204B1DE4AB3262F4F9D499@PH7PR12MB5710.namprd12.prod.outlook.com>
 <92830F28-F630-4C84-B015-B612E4ABE0CD@blackhats.net.au>
 <PH7PR12MB571077E321410D83E59CC6A99D5F9@PH7PR12MB5710.namprd12.prod.outlook.com>
 <4E04B88F-1887-40D5-BEB1-4DA7456B420D@blackhats.net.au>
Message-ID: <Y0P/a4xNAIrtq/Q2@mistotebe.net>

On Mon, Oct 10, 2022 at 12:37:47PM +1000, William Brown via python-ldap wrote:
> But that alone isn't everything. I can see in my testing that the
> response controls aren't being decoded. I think in this case because
> while you are passing in a correctly encoded control to the server,
> there is no way for the library to decode the dirsync control.

Ah, good catch, maybe we should also let the user choose to accept
controls that we can't interpret (as a generic ResponseControl), rather
than dropping them altogether.

Thanks,
Ondrej

From michael at stroeder.com  Mon Oct 10 09:57:50 2022
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 10 Oct 2022 15:57:50 +0200
Subject: [python-ldap] dirSync control, no Cookie
In-Reply-To: <Y0P/a4xNAIrtq/Q2@mistotebe.net>
References: <PH7PR12MB5710206204B1DE4AB3262F4F9D499@PH7PR12MB5710.namprd12.prod.outlook.com>
 <92830F28-F630-4C84-B015-B612E4ABE0CD@blackhats.net.au>
 <PH7PR12MB571077E321410D83E59CC6A99D5F9@PH7PR12MB5710.namprd12.prod.outlook.com>
 <4E04B88F-1887-40D5-BEB1-4DA7456B420D@blackhats.net.au>
 <Y0P/a4xNAIrtq/Q2@mistotebe.net>
Message-ID: <cda540bc-b70f-4a65-d001-c9aee24932c0@stroeder.com>

On 10/10/22 13:18, Ond?ej Kuzn?k wrote:
> On Mon, Oct 10, 2022 at 12:37:47PM +1000, William Brown via python-ldap wrote:
>> But that alone isn't everything. I can see in my testing that the
>> response controls aren't being decoded. I think in this case because
>> while you are passing in a correctly encoded control to the server,
>> there is no way for the library to decode the dirsync control.
> 
> Ah, good catch, maybe we should also let the user choose to accept
> controls that we can't interpret (as a generic ResponseControl), rather
> than dropping them altogether.

First of all the complete response data received at lower protocol level 
can always be observed by setting trace_level=2 when invoking 
ldap.initialize() or LDAPObject() no matter whether the response control 
value could be decoded.

In general the control type registry dict KNOWN_RESPONSE_CONTROLS was 
never meant to be immutable. Every code part can and should register 
custom response control classes therein the same like all ldap.controls 
sub-modules are doing it.

Additionally LDAPObject.result4() accepts an optional key-word argument 
resp_ctrl_classes which can be used to fully override 
KNOWN_RESPONSE_CONTROLS in case one only wants to decode a certain 
subset of acceptable response controls.

One could of course register class ResponseControl with any control type 
to get access to the control value bytes. This only makes sense for 
debugging purpose though.

Ciao, Michael.