not_filters not working about node-ldapjs

[intabulas]

Here is the relevant capture diffs (X'd out the base)

node-ldapjs: 0Z...cU..dc=XXXX, dc=XXX................1./.*userAccountControl:1.2.840.113556.1.4.803:..20.
ldapsearch : 0Z...cU..dc=XXXX,dc=XXX.................1./..1.2.840.113556.1.4.803..userAccountControl..20.

[mcavage]

Hi Mark

Thanks for the report. I'm traveling but will look at this first thing
next week.

Sent from my iPhone

On Nov 2, 2011, at 1:25 PM, Mark Lussier
[email protected]
wrote:

In working on a client using active directory as the ldap server, whenever I use a not equal filter I get no replies. As an example if the filter is "(!(userAccountControl:1.2.840.113556.1.4.803:=2))" to give me all non-disabled accounts, I get no responses.

The parser properly parses the filter and does create a not filter instance, but something (and it may be in the ber serialization) goes horribly wrong and no results are returned, yet the same query works fine with ldapsearch

I apologize for the vauge report but I spent the last few hours stepping through the code and everthing to the point of toBer looks good. A quick and dirty diff of packet capture show differences between this and (As example) the same search with ldapsearch

Reply to this email directly or view it on GitHub:
#28

[mcavage]

Hi,

Can you give me an actual packet dump? I ran this locally with a scrap server and saw identical bytes on the wire between ldapjs and OpenLDAP. Below are the commands I ran, and the wireshark bytes for the filter only.

OpenLDAP:

ldapsearch -x -H ldap://localhost:1389 -LLL -b o=foo "(!(objectclass=*))"

0000   a2 0d 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73     ....objectclass

ldapjs:

ldapjs-search -b o=foo -u ldap://localhost:1389 "(!(objectclass=*))"

0000   a2 0d 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73     ....objectclass

[intabulas]

So with wireshark from ldapsearch with the filter being (!(userAccountControl:1.2.840.113556.1.4.803:=2))

0060  02 01 14 02 01 0a 01 01  00 a2 31 a3 2f 04 2a 75   ........ ..1./.*u
0070  73 65 72 41 63 63 6f 75  6e 74 43 6f 6e 74 72 6f   serAccou ntContro
0080  6c 3a 31 2e 32 2e 38 34  30 2e 31 31 33 35 35 36   l:1.2.84 0.113556
0090  2e 31 2e 34 2e 38 30 33  3a 04 01 32 30 00         .1.4.803 :..20.  

[intabulas]

And from ldapjs with the same base and filter

0060  02 00 c8 02 01 00 01 01  00 a2 31 a9 2f 81 16 31   ........ ..1./..1
0070  2e 32 2e 38 34 30 2e 31  31 33 35 35 36 2e 31 2e   .2.840.1 13556.1.
0080  34 2e 38 30 33 82 12 75  73 65 72 41 63 63 6f 75   4.803..u serAccou
0090  6e 74 43 6f 6e 74 72 6f  6c 83 01 32 30 00         ntContro l..20. 

[intabulas]

notice how the values are transposed. I can email you the pcap's directly if you want

[intabulas]

here are the opts

var opts = {
  base: 'dc=xxxx,dc=xxx',
  filter: '(!(userAccountControl:1.2.840.113556.1.4.803:=2))',
  scope: 'sub',  
};

[mcavage]

Oh ok - I'm pretty sure this has to do with the extensible matching, and not the not filter. I never wired that in, as IMO it's massively overcomplicated for what the average human wants to do server side. That said, I know AD uses it heavily, so it would make sense to fix so the client at least sends it correctly.

Thanks for the trace, I should be able to recreate now that I know that's what you're doing.

m

[intabulas]

I was just going to say that. I looked longer at the packet captures ad ldapjs shows not equalityMatch vs not extensibleMatch from ldapsearch

And sadly AD does

[intabulas]

BTW I did work around it temporarily with an OR group vs doing a NOT on the bitfield and that seems to work for now

[mcavage]

What do you mean? You mean you just used a "normal" OR filter, as opposed
to not with extensible match?

On Mon, Nov 7, 2011 at 1:51 PM, Mark Lussier <
[email protected]>wrote:

BTW I did work around it temporarily with an OR group vs doing a NOT on
the bitfield and that seems to work for now

---

Reply to this email directly or view it on GitHub:
#28 (comment)

[intabulas]

Yup.. ex: search in my test case.. Explicit userAccountControl values effectively (they are off by 1 account) do the same as the doing a ! using the bit flag

filter: '(&(objectcategory=person)(mail=m)(|(userAccountControl=66080)(userAccountControl=66048)(userAccountControl=2080)(userAccountControl=544)(userAccountControl=512)))',

[mcavage]

Ahh ok, cool. Well, I put this on my list to look into supporting for client requests.

[mcavage]

Howdy-

This should be wired in now - I tested on the wire all the examples from the RFC against what openldap is doing with it. Should be good to go.

m

[mcavage]

Oh, and it's in npm as [email protected].

[intabulas]

Works perfectly!

On Nov 8, 2011, at 4:32 PM, Mark Cavage wrote:

Howdy-

This should be wired in now - I tested on the wire all the examples from the RFC against what openldap is doing with it. Should be good to go.

m

---

Reply to this email directly or view it on GitHub:
#28 (comment)