Open ronaldoviskii opened 7 months ago
welcome[bot]
commented
7 months ago 👋 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.
t4ov
commented
6 months ago Hello, I workaround this issue, by syncing all users to snipeit using LDAP (running ldap sync periodically to create new users), so only one service account can read all JC LDAP, and all other users are being authenticated using SAML.
Debug mode
Describe the bug
When you query the database, you do so using the LDAP user with access to the DN base configured within Jumpcloud. So far there are no problems, it correctly pulls all users into the base.
The problem starts when we try other users, it changes the “dn” line, instead of doing the search with the user querying the database, it changes it to the user who is being searched within the database.
If we give ldap base dn permission to the user being authenticated, he reads himself and can log in. But we cannot leave this option active within the user, our users cannot have access to the entire ldap base.
Reproduction steps
{ "initiated_by": { "type": "user", "username": "ldap.bind" }, "error_message": "", "deref": 0, "start_tls": false, "operation_type": "SEARCH RESULT", "tls_established": true, "dn": "uid=ldap.bind,ou=Users,o=MY_ORG,dc=jumpcloud,dc=com", "filter": "(&(objectClass=inetOrgPerson))", "event_type": "ldap_srch", "connection_id": “00000000-1f28-4e3c-81f8-00000000”, "service": "ldap", "organization": “MY”_ORG, "scope": 2, "@version": "1", "number_of_results": 6, "error_code": 0, "id": “MY_ORG”, "operation_number": 1, "attr": "", "base": "ou=Users,o=MY_ORG,dc=jumpcloud,dc=com", "timestamp": "2023-12-07T14:24:47.542979858Z", "username": "ldap.bind" }
{ "error_message": "", "initiated_by": { "type": "user", "username": "usuario.teste2" }, "deref": 0, "start_tls": false, "operation_type": "SEARCH RESULT", "tls_established": true, "dn": "uid=usuario.teste2,ou=Users,o=MY_ORG,dc=jumpcloud,dc=com", "filter": "(&(objectClass=inetOrgPerson)(uid=usuario.teste2))", "event_type": "ldap_srch", "connection_id": “00000000-88f5-45e0-8244-0000000”, "service": "ldap", "organization": “MY_ORG”, "scope": 2, "@version": "1", "number_of_results": 0, "error_code": 0, "id": “MY”_ORG, "operation_number": 1, "attr": "", "base": "ou=Users,o=MY_ORG,dc=jumpcloud,dc=com", "timestamp": "2023-12-07T14:23:38.355435691Z", "username": "usuario.teste2" }
Expected behavior
What is expected is that in the "dn" line it continues to consult the dn base with the user ldap.bind, thus being able to consult the user.
{ "error_message": "", "initiated_by": { "type": "user", "username": "usuario.teste2" }, "deref": 0, "start_tls": false, "operation_type": "SEARCH RESULT", "tls_established": true, "dn": "uid=ldap.bind,ou=Users,o=MY_ORG,dc=jumpcloud,dc=com", "filter": "(&(objectClass=inetOrgPerson)(uid=usuario.teste2))", "event_type": "ldap_srch", "connection_id": “00000000-88f5-45e0-8244-0000000”, "service": "ldap", "organization": “MY_ORG”, "scope": 2, "@version": "1", "number_of_results": 0, "error_code": 0, "id": “MY”_ORG, "operation_number": 1, "attr": "", "base": "ou=Users,o=MY_ORG,dc=jumpcloud,dc=com", "timestamp": "2023-12-07T14:23:38.355435691Z", "username": "usuario.teste2" }
Screenshots
No response
Snipe-IT Version
v6.2.3
Operating System
Ubuntu
Web Server
jammy
PHP Version
8.1
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