[Feature Request]: Please use anonymous bind for LDAP authentication

[phep]

Is your feature request related to a problem? Please describe.

If I'm correct the LDAP authentication mechanism in Snipe-IT works roughly like this (provided there's no error):

1. the user fill the username / password form
2. a BIND request is made to the LDAP server with the binddn of the user in order to check her credentials,
3. a SEARCH request is made (with the previously opened connection) with a filter being the ANDed concatenation of the filter set in the LDAP configuration panel (say "&(cn=*)") and the user identifier (say "uid=alice"), therefore producing a filter similar to (&(cn=*)(uid=alice)).

This has the disadvantages that it forces to add a "search" capability to every (Snipe-IT) user in the LDAP database ACL set, which might not be a (and certainly was not our) standard setting (while this is/can be hopefully compounded by more stricter ACL set elsewhere in the LDAP server config). As far as we're concerned, Snipe-IT is the first web-app I found doing this, hence the first web-app that forced us to give this "search" capability to our users (which are all potential users of Snipe-IT).

Describe the solution you'd like

In every other web app we use (LMS, ticketing system, CMS, ...) the LDAP authentication follows a path similar to:

1. the user fill the username / password form
2. a BIND request is made to the LDAP server with a special binddn created for the web app needs,
3. using this connection a search is made with some filter having at least the "uid=alice" part to ascertain the user entry exists,
4. a new anonymous BIND with the user binddn is made through the current connection in order to check the user credentials
5. the connection is closed.

This second approach certainly has the disadvantages that it requires the creation of an LDAP entry specific to the web application. On the other hand it doesn't enforce the default LDAP ACL to be set to anything different from "none" instead of "search" in the first approach.

Besides, the anonymous bind approach factorises all of the application related LDAP ACL on the web application binddn entry in the ACL set.

Describe alternatives you've considered

The main drawback to my eyes of the anonymous bind approach is the need for an application specific LDAP account but since Snipe-IT precisely needs this specific binddn for other features could you consider changing the way LDAP authentication works in favour of the second scenario exposed above ?

Additional context

I understand this is a heavily sys-admin-oriented request ;-).

[welcome]

👋 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.

[uberbrady]

This is a pretty reasonable ask, and we've had a few attempts at implementing this:

#11715
and
#11544
and
#11041

(Which are all looking at the problem from a slightly different direction; that of being able to log in to 'subtrees' rather than reducing the permissions required on the bind user). Ideally, if we could handle both of those with a sufficiently minimal enough changeset, that would be perfect - solving two problems at once. I have taken a stab at that, myself, for sure, but testing it is so hard, and making changes to the LDAP subsystem is so scary that we've really been dragging our feet on solving the problems.

[uberbrady]

I wanted to follow up on this @phep - we ended up changing the LDAP binding mechanism to pretty much exactly what you've described. It's here in this PR: #18058 . It uses the admin creds to search for your user, then it opens up another connection and tries to bind as that user. If that fails, it falls through to the 'old' way. If I'm right and it's working the way I intended, that should mean that you can pull the search capability from your users. Are you seeing it work that way?