snipe-it
snipe-it copied to clipboard
LDAP synchronization not fully work
Debug mode
- [X] I have enabled debug mode
- [X] I have read checked the Common Issues page
Describe the bug
After successfully filling out the LDAP configuration form, the "Test LDAP Sync" function displays all users as expected. However, when attempting to test the binding of a user, it fails and returns the message:
Login Failed. <USER> did not successfully bind to LDAP.
No errors are visible in the logs or in debug mode. Yet, upon inspecting the password hashes in the database, a suspicious pattern emerges as all of them appear to be identical. This suggests a potential bug that might be causing the authentication failure during the LDAP bind process.
Reproduction steps
- Install Snipe v6.1.2 v6.2.2 v6.2.3
- Try to connect to your LDAP server and try to bind an user
Expected behavior
A successfull user bind, if the credentials are valid.
Screenshots
Snipe-IT Version
6.2.3
Operating System
Ubuntu 22.04 LTS
Web Server
Nginx
PHP Version
8.1 8.2
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
👋 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.
Same Problem.
For a IT-Company it is very Hard do manuell managed 1k Users.
Exist a solution?
Which LDAP-Server do you use? If the testsync is successful and the the test login isn't, it is often a problem with the Ldap authentication query. E. g. vor the MS AD it is sAMAccountname not uid,
@MouseMadeContent
We are using an openLDAP.
In a Version about past one and a half year Snipe and LDAP was working for us.
Ok, i test it in the evening with an openldap - but did you try it with uid= instead uid=? in the Ldap authentication query?
@MouseMadeContent Yes, without "?" , I have already tried it.
I've also tested some various configuration from our other systems where LDAP works but without success.
It would be really helpful to know if the problem is a software bug or only a false configuration...
Hey, so I finally got an openldap installed for testing. First - I am not an expert, I am more familiar with MS AD.
But here are my 2 cents.
Check how the users are created, is the RDN based on CN or UID. This post is very helpful: https://stackoverflow.com/questions/18177486/login-to-ldap-with-uid-instead-of-cn-in-dn-input
To prove this theory, I created 2 users for testing:
If my username field in Snipe is "CN" I can only login with the CN name (chris hope) and if I use UID I can use the user's UID.
And in my case, I had to give the users access to Bind because I did a fresh install.
ldapmodify -Y EXTERNAL -H ldapi:/// <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcAccess olcAccess: to * by dn.base="dc=example,dc=org" read by * none EOF
Maybe this informations are helpful
Bye Chris
Stack OverflowI'm running into a problem using LDAP to authenticate logins.I already created a user with all basic info and try to login through phpldapadmin with detail :
Login DN: cn=Sample User,ou=people,dc=
@MouseMadeContent
Thank you for your prompt response. I've configured already my binding client based and cross-tested it with another client from a working service. Your LDAP user login sounds functional, which leads me to believe that the issue might lie in the configuration specific to Snipe.
To help specify my the problem, could you kindly share the configuration details you have set up for LDAP on your Snipe instance? I would help me very much.
You can find the configuration at https://snipe.xxx.com/admin/ldap .
Thank you !
Yes, of course - here are my LDAP Settings
But as i said, that works only, when my DN starts with uid:
BR Chris
Thanks for your pictures, but i can't see any misconfigurations in my settings.
Here are my settings:
I also tested
Base Bind DN ou=employees,ou=users,dc=xxx,dc=de
LDAP Filter &(cn=*)
Ends up in ldap_search(): Search: No such object
and
Base Bind DN ou=users,dc=xxx,dc=de
LDAP Filter &(cn=*)
which prompted me Login Failed. test.user did not successfully bind to LDAP.
The LDAP logs says in the last example:
Nov 14 10:46:28 ldap slapd[919]: conn=919587 fd=53 TLS established tls_ssf=256 ssf=256
Nov 14 10:46:28 ldap slapd[919]: conn=919587 op=1 BIND dn="cn=snipe-it,ou=clients,dc=xxx,dc=de" method=128
Nov 14 10:46:28 ldap slapd[919]: conn=919587 op=1 BIND dn="cn=snipe-it,ou=clients,dc=xxx,dc=de" mech=SIMPLE ssf=0
Nov 14 10:46:28 ldap slapd[919]: conn=919587 op=1 RESULT tag=97 err=0 text=
Nov 14 10:46:28 ldap slapd[919]: conn=919588 fd=54 ACCEPT from IP=:56894 (IP=0.0.0.0:389)
Nov 14 10:46:28 ldap slapd[919]: conn=919588 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Nov 14 10:46:28 ldap slapd[919]: conn=919588 op=0 STARTTLS
Nov 14 10:46:28 ldap slapd[919]: conn=919588 op=0 RESULT oid= err=0 text=
Nov 14 10:46:28 ldap slapd[919]: conn=919588 fd=54 TLS established tls_ssf=256 ssf=256
Nov 14 10:46:28 ldap slapd[919]: conn=919588 op=1 BIND dn="uid=test.user,ou=users,dc=xxx,dc=de" method=128
Nov 14 10:46:28 ldap slapd[919]: conn=919588 op=1 RESULT tag=97 err=49 text=
Nov 14 10:46:28 ldap slapd[919]: conn=919588 op=2 BIND dn="cn=snipe-it,ou=clients,dc=xxx,dc=de" method=128
Nov 14 10:46:28 ldap slapd[919]: conn=919588 op=2 BIND dn="cn=snipe-it,ou=clients,dc=xxx,dc=de" mech=SIMPLE ssf=0
Nov 14 10:46:28 ldap slapd[919]: conn=919588 op=2 RESULT tag=97 err=0 text=
Nov 14 10:46:28 ldap slapd[919]: conn=919588 op=3 UNBIND
Nov 14 10:46:28 ldap slapd[919]: conn=919588 fd=54 closed
And I understand this error, because my user instead of exists hereuid=test.user,ou=users,dc=xxx,dc=de
is located there "uid=test.user,ou=employees,ou=users,dc=xxx,dc=de
.
But if I move the user directly to users,I'll get again the error ` ldap_search(): Search: No such object ``
Today I tried to roll back to the last version, where I know that it has worked and it works.
The LDAP version checkbox isn't there anymore, could this be a part of the problem?
No, we removed the LDAP version checkmark because in a decade of running this software, the answer has always been 3.
@snipe Thanks for your Response, do you know which changes related to the LDAP part was done from the v5.4.3 to version 6.x.x which could cause our problem with the bind in the newer versions?
@brakzh, which version did you roll-back to? I am having a similar problem in v6.2.3.
I rolled back to 5.4.3 but I dont tested newer versions before the 6.x.x releases.
do you know which changes related to the LDAP part was done from the v5.4.3 to version 6.x.x
There have been nearly 5k commits since v5.4.3. I couldn't possibly tell you off the top of my head what changed since then. You're welcome to go through the release notes of each version since then, but we have thousands of users/customers who use LDAP successfully.
v6.2.2 to v6.2.3 does not show any LDAP changes.
I thinkso i have a solution. Please Show my merge request and the description.
First I checked the LDAP settings and used Linux CLI to see if it was my system. This was not the case.
Then I checked in which model the Admin Ldap Settings are used. This is under app/Models/Ldap.php.
After activating the debug mode and checking the variables with \Log::debug("");
$baseDn, $userDn, $username, $password
and the functions findAndBindUserLdap()
and bindAdminToLdap()
I noticed that the variables and the bind call are correct. But the If query negates the true to a false. As a result, the true branch of the If statement is not entered and an error occurs.
I do not know why the negation is chosen at this point. I can now test users in the GUI under Administration -> Ldap
@snipe @uberbrady @Godmartinz
@Alpha6333 Thank you for your solution in our MR, now we can use snipe in our company with a working ldap login.
What ist the solution from your team for the openldap problem?
See issue ticket for team anwser https://github.com/snipe/snipe-it/pull/14003
Hello, does this have to be uid? Login Failed if using cn. yongjie.xu did not successfully bind to LDAP.