View Issue Details

IDProjectCategoryView StatusLast Update
0032706mantisbtldappublic2023-07-03 14:48
ReporterMickoloh Assigned Todregad  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionnot fixable 
Platformhttpd/2.4.53, php/8.0.27OSRedHat Enterprise LinuxOS Version9.2
Product Version2.25.7 
Summary0032706: Unable to use user's own username/password for ldap_bind operations
Description

It appears as though the only two options for ldap_bind operations is to use anonymous bind, or a hard coded binddn/bindpw in config/config_inc.php. I would propose a config file option (something like a Boolean $g_ldap_bind_by_user?) that would, when set to ON/TRUE/1 use the user's supplied username and password for all ldap_bind operations.

Steps To Reproduce

Using an LDAP server that doesn't allow anonymous bind, while also not configuring a hard coded binddn/bindpw.

Additional Information

RHEL9.2
httpd/2.4.53
php/8.0.27
Schema 211
10.5.16-MariaDB
FIPS 140-2

TagsNo tags attached.

Activities

dregad

dregad

2023-06-07 12:25

developer   ~0067834

The request makes sense, but I'm not sure it's feasible considering that LDAP requests do not only occur for authentication (i.e. at login time), but also whenever user information needs to be retrieved from the directory (e.g. email or realname, see ldap_cache_user_data() ).

So, I'm not sure how this could be implemented in a secure manner, as we would somehow need to store the user's password so it can be reused to bind whenever an LDAP query needs to be made...

Unless you have a better idea or suggestions ?

Mickoloh

Mickoloh

2023-06-08 13:49

reporter   ~0067836

Agreed - I was pondering that too, as I was looking at the code, wondering how you'd get around passing passwords around to every and all functions, and caching it somewhere seems risky as well (as it'd need to be in a reversible "hash" or in clear text). This may not have a good (as in secure) solution. :/

dregad

dregad

2023-06-09 02:58

developer   ~0067837

Based on my analysis and your feedback, I'm resolving this as "not fixable".

Feel free to reopen if you come up with an idea that could meet the requirement in a secure manner.

Mickoloh

Mickoloh

2023-06-09 08:28

reporter   ~0067838

Fair enough - thank you for the consideration!