All places that call c.connect() need the port and host or socketPath about node-ldapjs

[mcavage]

Nope, I haven't seeen that one. I've put more personal testing into the
server than the client. I think you are correct about the socket connect
calls; those were an afterthought for reeconnect cases. I think what ill
probably do is simplify and just get rid of all that and expose the
on(error) more prominently. Anyway, I'm on the road for the next couple
days, so ill take a look realistically tomorrow evening or Friday. Thankd
for the report, and in advance for whatever you find is broken with AD.

M

-- Sent from my droid phone.
On Aug 30, 2011 9:23 PM, "instanceof" <
[email protected]>
wrote:

I am still trying to trace why querying ActiveDirectory 2008 is returning
filter errors, but I noticed that the handlers for end, close, error and
timeout call

c.connect();

Socket.connect() seems to be undefined when called with no parameters.
Might need one helper function that always calls connect() and figures out
whether it is a port,host or socketPath from createClient and always call
connect the same way.

Not sure if you have seen this error or not. It ends in the EAFNOSUPPORT
anytime Socket.connect() is called with something it does not like.

Node: v0.4.11
ldapjs: 0.1.1

2011-08-31 04:03:25Z DEBUG - Client: 192.168.4.65: sending request:
{"messageID":1,"protocolOp":"BindRequest","version":3,"name":{"rdns":[{"CN":"Search
User"},{"CN":"Users"},{"DC":"carefx"},{"DC":"local"}],"length":4},"authenticationType":"Simple","credentials":"password","controls":[]}
2011-08-31 04:03:25Z DEBUG - Client: 192.168.4.65:undefined: response
received:
{"messageID":1,"protocolOp":"LDAPResult","status":0,"matchedDN":"","errorMessage":"","referrals":[],"controls":[]}
2011-08-31 04:03:25Z DEBUG - Client: 192.168.4.65:undefined: sending
request:
{"messageID":2,"protocolOp":"SearchRequest","baseObject":{"rdns":[{"ou":"SBSUsers"},{"ou":"Users"},{"ou":"MyBusiness"},{"DC":"carefx"},{"DC":"local"}],"length":5},"scope":"base","derefAliases":0,"sizeLimit":0,"timeLimit":10,"typesOnly":false,"filter":"(objectclass=*)","attributes":[],"controls":[]}
2011-08-31 04:03:25Z ERROR - Client: 192.168.4.65:undefined: received
unsolicited message:
{"messageID":0,"protocolOp":"LDAPResult","status":2,"matchedDN":"","errorMessage":"00000057:
LdapErr: DSID-0C0C0B58, comment: The server was unable to decode a search
request attribute description list, the filter may have been invalid, data
0,
v1771\u0000","referrals":[],"responseName":"1.3.6.1.4.1.1466.20036","controls":[]}
2011-08-31 04:03:25Z WARN - Client: 192.168.4.65:undefined unexpected
connection error Error: EAFNOSUPPORT, Address family not supported by
protocol family

node.js:134
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: EAFNOSUPPORT, Address family not supported by protocol family
at doConnect (net.js:555:5)
at Socket.connect (net.js:715:5)
at Socket.
(/usr/local/lib/node_modules/ldapjs/lib/client.js:180:11)
at Socket.emit (events.js:64:17)
at Array. (net.js:837:12)
at EventEmitter._tickCallback (node.js:126:26)

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

[instanceof]

So, did some more testing to narrow it down. It seems that you have to specify at least one attribute in the search opts and it will then work.

The original error alludes to something with attributes list...

{"messageID":0,"protocolOp":"LDAPResult","status":2,"matchedDN":"","errorMessage":"00000057:
LdapErr: DSID-0C0C0B58, comment: The server was unable to decode a search
request attribute description list, the filter may have been invalid, data
0,
v1771\u0000","referrals":[],"responseName":"1.3.6.1.4.1.1466.20036","controls":[]}

....

client.bind(bindUser, bindPassword, function(err) {
assert.ifError(err);

var opts = {
attributes: ['dn', 'sAMAccountName', 'mail', 'cn'], /* Errors if attributes is missing or is an empty array */
// filter: '(sAMAccountName=jeff)',
scope: 'sub'
};

client.search(searchbase, opts, function(err, res) {
assert.ifError(err);

res.on('searchEntry', function(entry) {
  console.log('entry: ' + JSON.stringify(entry.object));
});
res.on('error', function(err) {
  console.error('error: ' + err.message);
});
res.on('end', function(result) {
  console.log('status: ' + result.status);
  client.unbind(function(err) {
    assert.ifError(err);
  });
});

});
});

Next is to look at how the defaults for attributes is setup if it is not given in the search opts.
May have to resort to a packet capture to see how ldapsearch sends the request if no attributes are specified and compare to ldapjs on the wire.

On the plus side, it does work with AD if you give the attribute list.

[instanceof]

I used a packet logger do dump the traffic for an ldapjs search with no attributes given and ldapsearch with no attributes given. Then a second search with ldapjs and just ['dn'] for attributes and ldapsearch returning just dn. In the case with no attributes specified to return from the search, ldapsearch has a null terminator after the filter, but ldapjs does not. In the case requesting the dn attributes returned from the search, ldapjs has a null terminator after the filter and so does ldapsearch.

ldapsearch-none

00000000h FF03 0021 4500 0090 A559 4000 4006 0A18 C0A8 0565 C0A8 0441 CEE1 ...!E....Y@[email protected]..
0000001Ah 0185 BEF6 BF59 E54E 8B3F 8018 FFFF BC5B 0000 0101 080A 1AD8 66CF .....Y.N.?.....[........f.
00000034h 0953 FA6A 305A 0201 0263 5504 356F 753D 5342 5355 7365 7273 2C6F .S.j0Z...cU.5ou=SBSUsers,o
0000004Eh 753D 5573 6572 732C 6F75 3D4D 7942 7573 696E 6573 732C 4443 3D63 u=Users,ou=MyBusiness,DC=c
00000068h 6172 6566 782C 4443 3D6C 6F63 616C 0A01 020A 0100 0201 0002 0100 arefx,DC=local............
00000082h 0101 0087 0B6F 626A 6563 7463 6C61 7373 3000 .... .... .... .... .....objectclass0.

ldapjs-none

00000000h FF03 0021 4500 0092 2A1A 4000 4006 8555 C0A8 0565 C0A8 0441 CEFC ...!E...*.@[email protected]..
0000001Ah 0185 5C29 3E2D F31C 18F8 8018 FFFF 33FE 0000 0101 080A 1ADF 8491 ..)..........3...........
00000034h 0954 B0EE 305C 0201 0263 5704 396F 753D 5342 5355 7365 7273 2C20 .T..0...cW.9ou=SBSUsers,
0000004Eh 6F75 3D55 7365 7273 2C20 6F75 3D4D 7942 7573 696E 6573 732C 2044 ou=Users, ou=MyBusiness, D
00000068h 433D 6361 7265 6678 2C20 4443 3D6C 6F63 616C 0A01 020A 0100 0201 C=carefx, DC=local........
00000082h 0002 010A 0101 0087 0B6F 626A 6563 7463 6C61 7373 .... .... .... ..........objectclass

ldapsearch-dn

00000000h FF03 0021 4500 0094 FD9B 4000 4006 B1D1 C0A8 0565 C0A8 0441 CF0B ...!E.....@[email protected]..
0000001Ah 0185 0D5F 05FA 9D15 44DD 8018 FFFF 30C6 0000 0101 080A 1AE7 0818 ..._....D.....0...........
00000034h 0955 7193 305E 0201 0263 5904 356F 753D 5342 5355 7365 7273 2C6F .Uq.0^...cY.5ou=SBSUsers,o
0000004Eh 753D 5573 6572 732C 6F75 3D4D 7942 7573 696E 6573 732C 4443 3D63 u=Users,ou=MyBusiness,DC=c
00000068h 6172 6566 782C 4443 3D6C 6F63 616C 0A01 020A 0100 0201 0002 0100 arefx,DC=local............
00000082h 0101 0087 0B6F 626A 6563 7463 6C61 7373 3004 0402 646E .... .... .....objectclass0...dn

ldapjs-dn

00000000h FF03 0021 4500 0098 4788 4000 4006 67E1 C0A8 0565 C0A8 0441 CF0F ...!E...G.@[email protected]....e...A..
0000001Ah 0185 D037 DA28 4DD4 218A 8018 FFFF DBF1 0000 0101 080A 1AE8 DB3F ...7.(M.!................?
00000034h 0955 A05B 3062 0201 0263 5D04 396F 753D 5342 5355 7365 7273 2C20 .U.[0b...c].9ou=SBSUsers,
0000004Eh 6F75 3D55 7365 7273 2C20 6F75 3D4D 7942 7573 696E 6573 732C 2044 ou=Users, ou=MyBusiness, D
00000068h 433D 6361 7265 6678 2C20 4443 3D6C 6F63 616C 0A01 020A 0100 0201 C=carefx, DC=local........
00000082h 0002 010A 0101 0087 0B6F 626A 6563 7463 6C61 7373 3004 0402 646E ..........objectclass0...dn

It seems like lib/search_request.js has a conditional block that starts a sequence and ends it if there are attributes
SearchRequest.prototype._toBer = function(ber) {
...
if (this.attributes && this.attributes.length) {
ber.startSequence(Ber.Sequence | Ber.Constructor);
this.attributes.forEach(function(a) {
ber.writeString(a);
});
ber.endSequence();
}
...

Something about starting a sequence causes the filter to be null terminated before writing the attributes out.

[mcavage]

Hi Jeff,

Thanks so much for that packet trace, that helps a lot. I just pushed fixes for everything you've found into master. Can you pull it down and see if that fixes your errors (it should fix all of them). If so, I'll publish it out to npm later today.

m

[instanceof]

Yes, that fixes the search error when no attributes are specified.

It seems to get hung up on the responses with all the attributes in AD now. I get one or two searchEntries and then it stops. There are tons of attributes in AD with binary values. I will start to narrow down which attributes are causing a problem.

I think we can close this issue.

[mcavage]

Great, I'll publish later on. As to the binary attrs, I forgot to doc that
client side they almost certainly don't work, since the client needs to
base64 encode before presenting back, which it currently doesn't do (I just
didn't get around to it yet). If you send me a trace of what AD is kicking
back it won't be hard to fix. Although I am curious as to what it does when
you say it just 'stops'.

-- Sent from my droid phone.
On Sep 2, 2011 11:36 AM, "instanceof" <
[email protected]>
wrote:

Yes, that fixes the search error when no attributes are specified.

It seems to get hung up on the responses with all the attributes in AD
now. I get one or two searchEntries and then it stops. There are tons of
attributes in AD with binary values. I will start to narrow down which
attributes are causing a problem.

I think we can close this issue.

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