ldaps issue

[dave-irvine]

I get the feeling this will be fun to debug, but here we go.

Previously on 1.x (node 0.10.x) I was able to successfully connect and query my LDAP server using LDAPS (uri: "ldaps://x.y.z"), however this has subsequently broken with the 2.0.7 release (and an upgrade to node 5.x).

If I call bind after this:

var ldapClient = require('ldap-client');
var uri = 'ldaps://x.y.z';
var ldap = new ldapClient({
    uri: uri,
    starttls: false
});

then I eventually get:

{ [LDAPError: Timeout] name: 'LDAPError', message: 'Timeout' }

after a pause.

I'm not using starttls, just ldaps, and as I said, this worked before.

By the look of the traffic on the server side, there is no SSL initiation going on, although the connection arrives on the correct port.

Any clues would be great!

[dave-irvine]

If I drop the 2.0.7 release and pull straight from master (I see there are a few unpublished commits), then I get:

node: ../LDAPCnx.cc:71: static void LDAPCnx::Event(uv_poll_t*, int, int): Assertion `status == 0' failed.

Don't know if this is related or just because master is broken

[jeremycx]

2.0.7 doesn't even have TLS support :)

As far as master goes, TLS still isn't quite complete yet - I ran into a ton of problems with automatic reconnection under TLS - I should have something ready at the end of today.

[jeremycx]

Alright, pushed 3.0.0 -- give it a try, close if you're happy :)

[dave-irvine]

I'm now getting the assertion failure again unfortunately

node: ../LDAPCnx.cc:95: static void LDAPCnx::Event(uv_poll_t*, int, int): Assertion `status == 0' failed.

[jeremycx]

I forgot to clobber an assert(), but that also means that assert isn't firing for me. Hmmm.

I removed the assert, pull from master and try it now.

[dave-irvine]

OK the assert has gone but now we're back to

{ [LDAPError: Timeout] name: 'LDAPError', message: 'Timeout' }

:( not sure what is happening here, as soon as I switch back to old node and old ldap-client, everything works again!

[jeremycx]

Can you give me a small code sample that exhibits the issue above?

[dave-irvine]

Sure:

var uri = ldapConfig.schema + ldapConfig.host;

var LDAP = require("ldap-client");
var ldap = new LDAP({
    uri: uri
});

function doBind(cb) {
    var bind_options = {
        binddn: ldapConfig.binddn,
        password: ldapConfig.password
    };

    ldap.bind(bind_options, function (err) {
        if (err) {
            console.log(err);
            ldap.close();
            return;
        }

        if (cb) { cb(); }
    });
}

doBind(function () {
    console.log('bind ok!');
});

Where ldapConfig has similar properties to the following, obviously using real values but replaced here:

schema: 'ldaps://',
host: 'my.ldap.server',
binddn: 'ldapuser@my.domain',
password: 'ldapuserspassword'

I've also tried binddn in the following format:

CN=ldapuser,OU=Users,DC=my,DC=domain

[jeremycx]

I'm betting you're connecting via ldaps to a server with a self-signed certificate. The default in the new version is to reject bad certs by default. You can switch this off though:

var ldap = new LDAP({
    uri: 'ldaps://localhost',
    validatecert: LDAP.LDAP_OPT_X_TLS_NEVER
}, function(err) {
    // connection ready
});

Also, your binddn above isn't a dn, but this makes me curious - I've seen (somewhere) some kind of automapping between dc=my,dc=domain and cn so you can do something like the above -- do you have any background on why you expected ldapuser@my.domain to work in the first place (I'm thinking there may be a switch I can turn on somewhere or something to get this behaviour from the underlying library).

[robertrossmann]

@jeremycx That binddn is one of the user authentication formats supported by Active Directory, in this particular case, I believe it's userPrincipalName.

You can read about all the supported formats here, if you like.

[jeremycx]

That's a nice server feature.. :)

Please close this Issue if things are working now, but get back in touch if there's still problems.

[dave-irvine]

Self-signed cert was my first thought but our server is properly certified. I've used the option you provided and I'm still getting a timeout.

I use the command line ldapsearch tool to check that the underlying OpenLDAP library is able to connect (this continues to work fine), and historically I've used the @ format binddn with this tool so I just carried this over when I started using ldap-client.

I'm just really confused why this works with the old version of this and not the new one. I've trawled through your source and I can't see anything really that you used to pass to the underlying library and are no longer passing. I'm a bit stumped :(

[dave-irvine]

I suppose it is worth noting that I've been sniffing traffic on our LDAP server.

Using the old version of the lib, the first traffic to arrive (after some preamble) when I call open() is the SSL negotiation, I can see the certificates passing over, and then all future traffic is encrypted and I can see nothing else in plaintext.

With the new version of the lib, the first traffic to arrive (after some preamble) is the binddn and password, in plaintext, and then the SSL negotiation, however no additional traffic follows.

So my feeling is the new version is doing things the wrong way around, maybe related to us no longer being able to explicitly call open()?