LDAP login not working (LDAP login test not working as well)

[masternas]

Expected Behavior (or desired behavior if a feature request)

I have created an LDAP server and my users have been uploaded onto snipe it successfully via LDAP.
The users are supposed to be able to log in to Snipe it Application.

---

Actual Behavior

But ldap users cannot log in and the ldap login test fails. (Please find attached)

Please confirm you have done the following before posting your bug report:

• I have enabled debug mode yes
• I have read checked the Common Issues page yes

---

Provide answers to these questions:

• Is this a fresh install or an upgrade? fresh install

• Version of Snipe-IT you're running v5.1.5 build 6055 (gd9d5b4d73)

• Version of PHP you're running 7.4.3

• Version of MySQL/MariaDB you're running

• What OS and web server you're running Snipe-IT on Ubuntu, Apache

• What method you used to install Snipe-IT (install.sh, manual installation, docker, etc) manual installation using git

• WITH DEBUG TURNED ON, if you're getting an error in your browser, include that error

• What specific Snipe-IT page you're on, and what specific element you're interacting with to trigger the error : LDAP page for testing and log on page

• If a stacktrace is provided in the error, include that too.

• Any errors that appear in your browser's error console.
  Attachment :
  

[uberbrady]

I'm sorry I'm doing this by phone. But almost always I've seen this, it's been "append domain to username" checkbox?

[masternas]

Still isn't working, with or without the checkbox checked.

[csayre]

Does the debug log show anything regarding testing the ldap login?

[madd15]

Can you provide screenshots of your LDAP config?

It appears that usernames are not being picked up from your LDAP server

[paulb-smartit]

I've encountered the same issue, and it's a bit of a quirky implementation of LDAP auth.

The way it works is by using the "LDAP Authentication query" value and "Base Bind DN* value, sandwiched with your user ID.

eg.

LDAP Authentication query: uid=
Base Bind DN: ou=staff,ou=people,dc=domain,dc=tld

becomes:

uid=[My User ID].ou=staff,ou=people,dc=domain,dc=tld

Which means it won't do a subtree search the user must match the exact DN.

I trie setting my "Base Bind DN" to "dc=domain,dc=tld in the hope it would find my user, but it doesn;t work that way. I checked the OpenLDAP and saw it was passing exacly the DN to look for and not searching, ie. DN=uid=[My User ID].dc=domain,dc=tld - which doesn't exist :(

[daudo]

I've just been hit by the same issue.

We usually don't use the uid as the unique username attribute, but instead use the mail attribute, rendering the "LDAP Authentication query" to look for entries like

mail=foobar@example.com,ou=hq,dc=example,dc=com

But of course, no such DN exists in the DIT, but only uid=foobar,ou=hq,dc=example.com.

IMHO, the "authentication query" should be a real query/filter, as its name says.

[rmalchow]

+1 from me. i was going crazy over this - expecting some weird mistake on my side. i think its reasonable to expect a subtree query. if anyone is worried about backwards compatibility, then one option would be to make it switchable (like apache directory studio:

and default to "one level" - this would also avoid frustration on the user's side (like i experienced) when it is not working as expected.

[rmalchow]

wouldnt call it a bug though ... just a quirk. allowing selecting "subtree" would deffo be an improvement. :)

[uberbrady]

LDAP is absolutely a tough pain point for us to support and it does tend to call for a lot of esoteric knowledge of the protocol and how your directory has been configured. We've had customers who have wanted something similar - a query function that might not be based on uid=blah,etc=blah,whatever=blah - so this is definitely something we'd want to build in when we re-do the LDAP system. It probably would be set up as some kind of 'compatibility mode' versus 'search mode' or something along those lines. (Happy to workshop those mode names, too).

Also, I'm always interested in hearing about other implementations that people think are good models for us to follow (ideally ones where I can at least see the source code). We don't really need to re-invent the wheel here; this has been done before. I just want us to do it as well as others do it.

This would be something we would address in the Great re-LDAP'pening sometime post v6.

[rmalchow]

@uberbrady i've been looking at your code - and although LDAP doesnt seem too esoteric to me anymore, PHP certainly is a weak point. i'd still be happy to help explaining LDAP things if you want me to. the basic pattern for something like this is this:

• you use the "bind user" to connect to the LDAP server (LDAP servers in the old days did allow searches without an initial bind, this is generally frowned upon today)
• you run a search (e.g. (|(uid=$username)(mail=$username)) (note the RPN for the "OR") to find the user (and their full DN)
• you perform another "bind" (read: authentication) with the full DN you just found and the user's password

note that

• building the query can lead to LDAP injection (your library probably offers a query builder that takes care of escaping to mitigate this)
• the query is often a free-form configuration option, this makes it possible to also filter by other criteria, such as the "memberOf" attribute in AD:
  (&(userPrincipalName=$username)(memberOf=cn=snipe-it-users,ou=xyz,o=foo,...))
  in this scenario, you will need a reasonable placeholder for the username

[Vaxter]

I have patched this for myself in ldapLogin function to search for the user by username, fetch the cn from it, and let the rest of the app take it's course, but this is a hack and should not be done this way.
The entire setting and user searching procedure should be completely changed here.
If someone needs this hack for OpenLDAP, configure SnipeIT so that:
Username Field: uid
LDAP Authentication query: cn=

And change LdapAd.php in app/Service on line 130 so that in else block search is done.
After this ldapLogin function beginning should look like this:

    public function ldapLogin(string $username, string $password): User
    {
        if ($this->ldapSettings['ad_append_domain']) { //if you're using 'userprincipalname', don't check the ad_append_domain checkbox
            $login_username = $username . '@' . $this->ldapSettings['ad_domain']; // I feel like could can be solved with the 'suffix' feature? Then this would be easier.
        } else {
            $ldapUser = $this->ldap->search()->findBy('uid', $username);
            if ($ldapUser) {
              $login_username = $ldapUser->getFirstAttribute('cn');
            } else {
              $login_username = $username;
            }
        }

[taeys]

Thanks @Vaxter that literally solved our issue....
But isn't that something snipeit should fix in general?