Closed RogerSik closed 4 years ago
Screenshot for better explanation.
Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!
Yes it is still relevant.
Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!
Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!
This issue has been automatically closed because it has not had recent activity. If you believe this is still an issue, please confirm that this issue is still happening in the most recent version of Snipe-IT and reply to this thread to re-open it.
This bug still appears with snipe-it 5.0.7.
There is a solution for Active Directory, but not for other LDAP services.
There are some other issues with the same bug: https://github.com/snipe/snipe-it/issues/8315 https://github.com/snipe/snipe-it/issues/8214 (there are using Univention Corporate Server Core Edition for LDAP) https://github.com/snipe/snipe-it/issues/7587
@wilkis3 Those older issues don't seem relevant, since they are all pre-v5, and LDAP/AD was completely rewritten in v5 - and certainly a lot of people are able to use OU syncing (in v4 as well) using Location-specific OUs. That's currently the only way to sync multiple OUs, and always has been.
Hey @snipe @wilkis3 and me are working with thesame SnipeIT instance. We updated it to the version 5.0.7
The synchronization is not the problem. This working fine, we have every ldap account avaible to browse in SnipeIT.
The problem is that its not possible that 2 accounts which are in 2 differnt OUs are able to login.
Hey @snipe, @uberbrady the problem is like @RogerSik descriped. I'll will show you the bug more precisely.
The user authentification with m.wilke
works, but only for direct users of this specific OU.
The user authentification with m.wilke
, cn=m.wilke,ou=Internal,ou=Crowd,ou=Users,dc=basecom,dc=de
or all others seperations failed.
I got the following debug message:
LOG.debug: Connection failed
In both secenarios the Test LDAP Sync shows me the correct sample of 10 users from the LDAP Server.
We also found a other weird thing.
Our SnipeIT have two different locations. Location 1 have the following LDAP Search OU: ou=Internal,ou=Crowd,ou=Users,dc=basecom,dc=de
and Location 2 this LDAP Search OU: ou=MSO-Digital,ou=Crowd,ou=Users,dc=basecom,dc=de
If I trigger the LDAP Sync with php artisan snipeit:ldap-sync --location="LocationnameTwo"
all user accounts thats match by the LDAP Filter at the Admin LDAP/AD settings and not the location-specific LDAP Search OU goes to Location 2.
It seems like we are not the only one with this issue? (https://github.com/snipe/snipe-it/issues/8214#issuecomment-751598669) @uberbrady could you reopen this issue please?
We faced the same problem. User from root branch (e.g. "ou=People,dc=com") could login, but user form inner branch (e.g. "ou=Deaprtment1,ou=People,dc=com") can't do this
Checked versions 4.9.5 and 5.1.5
It seems like a bug. Please reopen this issue
I have exactly same issue with V6.4.0 Only user from Base DN can login, users in inner branches can't. Hope this can be resolve in some way.
Please confirm you have done the following before posting your bug report:
Describe the bug The option "LDAP Basis Bind DN" is used as login.
Example Base Bind DN: dc=basecom,dc=de There are 2 users:
both can't login. With debug on it is visible that the username r.sikorski and example01 gets added to the base dn.
When setting:
r.sikorski can login but example01 not, but atleast one of the users can login.
Expected behavior All users which match the LDAP Filter should be able to login.
Screenshots If applicable, add screenshots to help explain your problem.
Server (please complete the following information):
Desktop (please complete the following information):
Additional context