LDAP Authentication not working

[foamrider]

Hi

I'm trying to get the LDAP authentication to work. I'm using the following LDAP settings

Bind Search:

{"filter": "(&(objectclass=person)(sAMAccountName=#{username}))", "scope": "sub", "userDN": "bind@domain.local", "password": "passwd"}

Distinguished Name (DN):

DC=domain,DC=local

When I try logging in, I get the "username not found or incorrect password".

If I type the incorrect password (seems like LDAP is correct):

Bind before search bind@domain.local passwd
LDAP search dn DC=domain,DC=local
LDAP search options { filter: '(&(objectclass=person)(sAMAccountName=john))',
  scope: 'sub' }
Attempt to bind CN=John Doe,OU=Users,OU=Parent,DC=domain,DC=local
{ [InvalidCredentialsError: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1]
  dn: [Getter],
  code: [Getter],
  name: [Getter],
  message: [Getter] }
{ [Error: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1 [49]]
  error: 49,
  reason: '80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1\u0000',
  details: undefined,
  message: '80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1\u0000 [49]',
  errorType: 'Meteor.Error' }

Which is kinda expected, but it shows that the LDAP search is working. Now, if I type the correct password:

Bind before search bind@domain.local passwd
LDAP search dn DC=domain,DC=local
LDAP search options { filter: '(&(objectclass=person)(sAMAccountName=john))',
  scope: 'sub' }
Attempt to bind CN=John Doe,OU=Users,OU=Parent,DC=domain,DC=local

And there it stops, and I receive (client side) the same error as if the password was incorrect.

Am I missing something, or is this a bug?

[ninja-]

yes your problem is probably sAMAccountName

[foamrider]

I'm using AD, so sAMAccountName should be correct. The issue is the same if I replace sAMAccountName with mail. It still find the correct user, but stops on "Attempt to bind".

[ninja-]

can you try authenticating on "ldapsearch" tool ?

[foamrider]

ldapsearch tool is working fine, returning data for the user specified in the filter

I tried with Bind on my bind-user, but also with my personal account, both worked fine with ldapsearch tool.

[ninja-]

@drtomasso can you share the exact command you used to ldapsearch ?

[foamrider]

With my bind user:

ldapsearch -b dc=itumnot,dc=local -H ldap://192.168.110.40 -D bind@itumnot.local -W "(&(objectclass=person)(mail=tomas@xxx.xxx))"

With my own user:

ldapsearch -b dc=itumnot,dc=local -H ldap://192.168.110.40 -D tomas@itumnot.local -W  "(&(objectclass=person)(mail=tomas@xxx.xxx))"

I'm running Ubuntu 14.04 LTS

[foamrider]

It works if my LDAP/AD password is equal to the password used in the Bind Search. How can I use LDAP accounts without having to have the same password?

[ninja-]

@drtomasso sounds exactly like a bug

[foamrider]

Is there a variable for password as there is for the username? As a temporary workaround?

[emcguinness]

Not that I have seen. I have tried against my ldap server with different passwords for the accounts without issue. I do have an AD server I can test against at work tomorrow to see if I can recreate this.

[Megatronic79]

Hi @drtomasso,

Works fine on AD 2003 and 2008 and OpenLDAP:

My Filter I just tested with is

{"filter": "(&(objectCategory=person)(objectclass=user)(memberOf=CN=ROCKET_CHAT_USERS,OU=General Resource Accounts,DC=domain,DC=internal)(|(mail=#{username})(sAMAccountName=#{username})))", "scope": "sub", "userDN": "rocket.service@domain.internal", "password": "mypass"}

This will only authenticate users in the Group - ROCKET_CHAT_USERS and if their using the correct username (sAMAccountName) \ Email (mail) and password.

Cant reproduce what you're seeing at this stage. :(

[foamrider]

Seems like the username I was trying with, was already created locally in Rocket. When this happend, I could not login with neither my AD password nor my Rocket password. The error (and failsafe) could be improved, but that's not probably high priority.