LDAP sync works - login/test fails if user not in base DN #12331

dvdp · 2023-01-10T12:52:16Z

Debug mode

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

Describe the bug

I'm trying to get LDAP login working on my freshly installed Snipe-IT v6.0.14 build 9038.
Configured the LDAP server settings (we're using 389-DS with ldaps) and the 'Test LDAP synchronizaton' works fine, however if I try to authenticate any user, I get " Login Failed. did not successfully bind to LDAP. "
So I did some more testing to make sure I got the settings correct and found out that I can get authentication to work if the user is in the base bind DN and not in one of the sub-OU's of that DN. E.g.:
user 'Danny' is in ou=ICT,ou=authorized,dc=foo,dc=bar
If I set base bind dn to ou=authorized,dc=foo,dc=bar, authentication fails (LDAP user sync lists the user though)
If I set base bind dn to ou=ICT,ou=authorized,dc=foo,dc=bar, authentication works ....
That looks like a bug to me - if sync (which does an LDAP search) nicely lists all users of the sub-OUs, authentication should also work for a user in one of those sub-OUs.

Reproduction steps

Create an ou (e.g. authorized) with a sub-OU (e.g. ICT)
Enter a user in that sub-OU
Set LDAP base bind DN to the top OU
Test LDAP sync (should work)
Test LDAP user authentication -> fails
Set LDAP base bind DN to the sub-OU
Test LDAP user authentication -> works

Expected behavior

authentication should also work for any user in a sub-OUs of the base bind DN (regardless of the number of levels below that OU)

Screenshots

No response

Snipe-IT Version

v6.0.14 build 9038

Operating System

Ubuntu

Web Server

apache

PHP Version

8.4.33

Operating System

No response

Browser

No response

Version

No response

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

No response

Additional context

No response

welcome · 2023-01-10T12:52:18Z

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

nsty · 2023-01-11T10:46:00Z

This doesn't sound like a bug to me. Typically a freshly created user is not allowed to log in if I remember right. The user either needs to be marked manually with login enabled or using an LDAP flag. The LDAP Active Flag might be configured wrong in your settings. You can check the /users page to see if login is actually enabled for each user.
If this is not the problem, I think you should name the LDAP server you are using. Might also be a server setting.

dvdp · 2023-01-11T11:15:55Z

Hm - I don't agree - login / LDAP test succeeds when I change just the base bind dn. As I said, sync works so I got all LDAP users imported/synced and I marked all logins enabled.

On January 11, 2023 11:46:11 AM GMT+01:00, nsty ***@***.***> wrote: This doesn't sound like a bug to me. Typically a freshly created user is not allowed to log in if I remember right. The user either needs to be marked manually with login enabled or using an LDAP flag. The LDAP Active Flag might be configured wrong in your settings. You can check the /users page to see if login is actually enabled for each user. If this is not the problem, I think you should name the LDAP server you are using. Might also be a server setting. -- Reply to this email directly or view it on GitHub: #12331 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

-- Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

nsty · 2023-01-11T12:33:21Z

You are right. I can just tell you that it's working for me. We use several levels of OUs and nested group filters. I also tested with a new user on our AD (regarding #12296 ). But I just noticed, we are still on 6.0.13 on production because of #12288 . Might be all the same issue with the default LDAP group introduced in 6.0.14.

dvdp · 2023-01-22T14:22:21Z

Well, I found this in App/Models/Ldap.php on line 98:
$userDn = $ldap_username_field.'='.$username.','.$settings->ldap_basedn;
I guess that explains - that restricts things to users only in the base DN

Imho the better option is to first search the user in the base dn and then grab the user dn from the search result

dvdp · 2023-01-22T14:35:52Z

... so this is my workaround - added this after line 118 $filterQuery = "({$filter}({$filterQuery}))";
(so basically use the filter to search for the user first and then get the user dn from the search result)

$res = ldap_search($connection, $baseDn, $filterQuery);
$first = ldap_first_entry($connection, $res);
$userDn = ldap_get_dn($connection, $first);

xuanfm · 2023-02-06T09:45:28Z

i think you should downgrade your php version.youd better dont use more then 8.1(include)，my php 8.1 down to 8.0 it works

dvdp · 2023-02-06T16:27:08Z

If you analyze what I changed to fix things you'll see that this is very unrelated to the php version. Just go through the details of my findings, you'll see that things depend on how you have setup LDAP in terms of OUs. Bottom line: if your user dn does not reflect a dn in the base OU, authentication fails but user sync still works because of the search filter.
Grabbing the correct user DN using a search first fixes that (= my fix)
(for the record: to make the code work for both LDAP and AD, those lines should be inserted a little bit higher then I mentioned, just before the line " if ($settings->is_ad == '1') {" )
My guess is that either your users are in the base DN and not in some sub-OU of it or you have an earlier Snipe-IT version which doesn't have this problem (at least that is what I'm told).

sangdrax8 · 2023-03-10T14:05:19Z

This explains exactly what I have experienced on the latest version. I was able to set the base DN to match where my users are, since this currently works for my structure. However that is just luck, there isn't any requirement that this would have been true.

Miguel23-06 · 2023-04-12T11:43:29Z

... so this is my workaround - added this after line 118 $filterQuery = "({$filter}({$filterQuery}))"; (so basically use the filter to search for the user first and then get the user dn from the search result)

$res = ldap_search($connection, $baseDn, $filterQuery); $first = ldap_first_entry($connection, $res); $userDn = ldap_get_dn($connection, $first);

Friend, thank you very much, I had been trying to solve this for days.

dhumpf · 2023-06-21T08:34:23Z

Same issue here, I changed the workaround a little bit:
I moved lines 143-153 to line 122 in app/Models/Ldap.php,
then added another if statement to get the userDn.

So now it's really findAndBindUserLdap as the Function name suggests.

Lines 122-138 look like that block:

    if (! $results = ldap_search($connection, $baseDn, $filterQuery)) {
        throw new Exception('Could not search LDAP: ');
    }

    if (! $entry = ldap_first_entry($connection, $results)) {
        return false;
    }

    if (! $userDn = ldap_get_dn($connection, $entry)) {
        return false;
    }

    if (! $user = ldap_get_attributes($connection, $entry)) {
        return false;
    }

    if (! $ldapbind = @ldap_bind($connection, $userDn, $password)) { ....

Edit: Maybe solved within the following issue #9903 ?

Currently, snipe-it relies on a manually crafted user DN to bind a user and therefore check if they exist, and *then*, it searches in LDAP if the user is found when applying the filter. This works nicely when the base_dn is "fixed". In a company with multiple business lines or business units, though, there might be more than one OU for LDAP users, and in that case, crafting the DN manually might fail. This patch aims at crafting the userDn from a ldap_search, assuming the user field is unique. If more than 1 user is found, the user field is not unique and the login method will throw. This increases significantly the LDAP login flexibility. Fixes snipe#12331

snipe assigned uberbrady Jan 11, 2023

athompsoncmc mentioned this issue Jan 25, 2023

Preexisting LDAP users can log in, new users cannot #12296

Open

2 tasks

P-EB linked a pull request Nov 29, 2023 that will close this issue

Fixed #12331: Change the way userDn is build for non-AD login #13972

Open

10 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LDAP sync works - login/test fails if user not in base DN #12331

LDAP sync works - login/test fails if user not in base DN #12331

dvdp commented Jan 10, 2023 •

edited

welcome bot commented Jan 10, 2023

nsty commented Jan 11, 2023

dvdp commented Jan 11, 2023 via email

nsty commented Jan 11, 2023

dvdp commented Jan 22, 2023

dvdp commented Jan 22, 2023

xuanfm commented Feb 6, 2023

dvdp commented Feb 6, 2023

sangdrax8 commented Mar 10, 2023

Miguel23-06 commented Apr 12, 2023

dhumpf commented Jun 21, 2023 •

edited

LDAP sync works - login/test fails if user not in base DN #12331

LDAP sync works - login/test fails if user not in base DN #12331

Comments

dvdp commented Jan 10, 2023 • edited

Debug mode

Describe the bug

Reproduction steps

Expected behavior

Screenshots

Snipe-IT Version

Operating System

Web Server

PHP Version

Operating System

Browser

Version

Device

Operating System

Browser

Version

Error messages

Additional context

welcome bot commented Jan 10, 2023

nsty commented Jan 11, 2023

dvdp commented Jan 11, 2023 via email

nsty commented Jan 11, 2023

dvdp commented Jan 22, 2023

dvdp commented Jan 22, 2023

xuanfm commented Feb 6, 2023

dvdp commented Feb 6, 2023

sangdrax8 commented Mar 10, 2023

Miguel23-06 commented Apr 12, 2023

dhumpf commented Jun 21, 2023 • edited

dvdp commented Jan 10, 2023 •

edited

dhumpf commented Jun 21, 2023 •

edited