Generic Credentials Possible? about passport-ldapauth HOT 5 CLOSED

Don't know what you mean by brute force, but the credentials in the opts are not the ones you're validating. This, like other local(ish) strategies, validates the user input credentials from the req object.

I've explained the authentication steps in http://stackoverflow.com/a/30611120/3349511

You don't need to use the custom callback method of passport though, just use

app.post('/login/', passport.authenticate('ldapauth'));

from passport-ldapauth.

Thank you for the quick response. Brute force simply means coding something for a specific purpose rather than being flexible (for example, putting the actual password in bindCredentials).

I didn't clarify that in my original post but I am using the default username and password values (req.body.username and req.body.password) and that is what I want to validate. I read the SO post and I still am not completely following.

Using my example above where the admin account is in the ou=system, is there a way for passport-ldapauth to locate the admin account without using the uid in the bindDN field? I need to configure this eventually to validate credentials on an LDAP server for which I don't have the admin user id or password. In that case, what would I enter for the bindCredentials?

Thank you again.

from passport-ldapauth.

No. You could leave the credentials empty if your server supports anonymous binding, but if not you will need an account for performing the query to locate the user DN based on the user input. The user password is of course used in binding after the user DN is first located.

In general a full DN is needed for bind, and that's why there's an admin account that can perform a search by substituting part of the search filter with user provided account information. In other words - the DN search cannot be perfomed without binding to the server first, and the bind cannot be done without a DN.

Since the DN is something users don't know or remember it is searched for using a simple information the users know such as username or email.

You could of course implement e.g. a strategy that expects the user to provide a full DN on login page, e.g. CN=Karen Berge,CN=admin,DC=corp,DC=Fabrikam,DC=COM, or a strategy that defines a DN template, e.g. CN={{username}},CN=admin,DC=corp,DC=Fabrikam,DC=COM, in the options and then would replace {{username}} with user provided input, but both are pretty bad to use. Former one of course because user's don't know their DN, and the latter one because it would only allow login for users in predefined organization.

from passport-ldapauth.

I was able to get passport-ldapauth working with my local LDAP server. Yay! Thank you for your help.
I did need to put the binding credentials into the OPTS as anonymous binding was not enabled (as you suggested).

I am now attempting to connect to an ldap server at my company and I'm having some issues. When I attempt to connect using similar OPTS to my local LDAP server, I receive the following error message (sorry for the JSON format):

Error Received: {"dn":"","code":49,"name":"InvalidCredentialsError","message":"80090308: LdapErr: DSID-0C0903A8, comment: AcceptSecurityContext error, data 52e, v1db1\u0000"}

I contacted the IT team who manages the LDAP servers and they informed me that this message is more likely because my client doesn't trust the server than this being a response from the server. They provided me with certificates to attempt to remedy the problem.

I've updated my OPTS to be the following:

var OPTS = {
    server: {
        url: '<ldapserver>:636',
        bindDn: '<full DN provided by LDAP team>',
        bindCredentials: '<password>',
        searchBase: 'ou=User Accounts,DC=<domain1>,DC=<domain1>,DC=<domain3>',
        searchFilter: 'sAMAccountName={{username}}',
        tlsOptions: {
            ca: [
                fs.readFileSync('<path/to/Entrust-Intermediate-Chain-L1K-10-23-2024-text.cer>'),
                fs.readFileSync('<path/to//Entrust-Intermediate-Chain-Root-G2-09-22-2024-text.cer>'),
                fs.readFileSync('<path/to/Entrust-Root-for-G2-L1K-11-27-2026-text.cer>')
            ]
        }
    }
};

Is this the correct way to include multiple files? Does the order matter? Your example only includes one file.

When I attempt to connect using this, I receive the following error stack trace in my server console:
_events.js:141
throw er; // Unhandled 'error' event
^

Error: unable to get local issuer certificate
at Error (native)
at TLSSocket. (_tls_wrap.js:1013:38)
at emitNone (events.js:67:13)
at TLSSocket.emit (events.js:166:7)
at TLSSocket._init.ssl.onclienthello.ssl.oncertcb.TLSSocket._finishInit (_tls_wrap.js:582:8)
at TLSWrap.TLSSocket._init.ssl.onclienthello.ssl.oncertcb.ssl.onnewsession.ssl.onhandshakedone (tls_wrap.js:424:38)

If I change the OPTS to list the certificates as "cert" instead of "ca", I receive the "AcceptSecurityContext" error I listed first. The format of these .cer files is PEM:
-----BEGIN CERTIFICATE-----
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MTEyNzIwMjM0MloXDTI2MTEyNzIw
-----END CERTIFICATE-----

Should I set them to ca or cert? I believe I'm very close but I was hoping you could provide some help. Thank you for all of your assistance!

from passport-ldapauth.

It turns out, I didn't need the certificates at all. If you notice, the searchBase points to an ou string with a space in it. I simply needed to escape the space. Thank you for all of your help, vesse! I'm closing the issue.

from passport-ldapauth.