[Feature Request]: Use the LDAP bind account as a passthrough for LDAP Auth requests

[MrHackino]

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

Since the release of v6.0 of Snipe-IT and changes done to LDAP internals there is an issue notably on JC where LDAP accounts requesting to log on an instance need to be set as a bind account.

Previously a LDAP account was set a "Bind DN" which is the one handling requests of authentication and probing of a LDAP.

Describe the solution you'd like

My question is, is it possible to integrate an option to allow both options, using a pass-through account or not, into Snipe-IT?

Describe alternatives you've considered

Currently I don't have any since I would like to use LDAP feature and my LDAP server is Jumpcloud.

Additional context

My case seems quite specific and I am interested to know if other users in the same configuration as me encountered this issue

Thank you in advance for any answer and insight to my 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.

[sashasimkin]

Hey @MrHackino, why did you close this FR? I'm getting the exact same behavior now, trying to introduce Snipe-it to my organization. My deployed version is 6.1.0.
By the looks of it, #5153 is the same issue too, although was overrun by an unrelated AD problem and closed, while the original author left.

tl; dr: I feel like implementing ONELEVEL or SUBTREE from this comment can solve the issue: #9903 (comment)

Can this FE be re-opened please?

---

I've done some investigation and was able to successfully log in by doing quite a few live patches to the code.

ldapservice is the JumpCloud user that has JumpCloud permission that enables search: "enable as bind DN".

The bind_dn as user xxx works(bind function returns 1) in JumpCloud, but returns no results upon search. I suppose because that user doesn't have specific JumpCloud permission that enables searching: "enable as bind DN".

[2023-05-09 12:34:33] production.DEBUG: Attempting to bind to LDAP for LDAP test
[2023-05-09 12:34:33] production.DEBUG: Filter query: (&(!(uid=ldapservice))(objectClass=inetOrgPerson)(uid=alex))
[2023-05-09 12:34:33] production.DEBUG: userDn: uid=xxx,ou=Users,o=...,dc=jumpcloud,dc=com
[2023-05-09 12:34:33] production.DEBUG: Status of binding user: uid=xxx,ou=Users,o=...,dc=jumpcloud,dc=com to directory: (directly!) success
[2023-05-09 12:34:33] production.DEBUG: ldap_username: uid=ldapservice,ou=Users,o=...,dc=jumpcloud,dc=com
[2023-05-09 12:34:33] production.DEBUG: Status of binding Admin user: uid=alex,ou=Users,o=...,dc=jumpcloud,dc=com to directory instead: FAILURE

Afterward, I was able to login w/ more custom logs & code changes to allow binding as admin, by returning true from the bindAdminToLdap function.

[2023-05-09 12:39:01] production.DEBUG: Preparing to test LDAP login
[2023-05-09 12:39:01] production.DEBUG: ldap_username: uid=ldapservice,ou=Users,o=...,dc=jumpcloud,dc=com
[2023-05-09 12:39:01] production.DEBUG: Attempting to bind to LDAP for LDAP test
[2023-05-09 12:39:01] production.DEBUG: Filter query: (&(!(uid=ldapservice))(objectClass=inetOrgPerson)(uid=xxx))
[2023-05-09 12:39:01] production.DEBUG: userDn: uid=xxx,ou=Users,o=...,dc=jumpcloud,dc=com
[2023-05-09 12:39:01] production.DEBUG: Status of binding user: uid=xxx,ou=Users,o=...,dc=jumpcloud,dc=com to directory: (directly!) success
########### ^ I've intentionally removed `!` from the condition here, so that the code proceeds to bindAdminToLdap here https://github.com/snipe/snipe-it/blob/v6.1.0/app/Models/Ldap.php#L122 #########
[2023-05-09 12:39:01] production.DEBUG: ldap_username: uid=ldapservice,ou=Users,o=...,dc=jumpcloud,dc=com
[2023-05-09 12:39:01] production.DEBUG: ldapbind is 1
[2023-05-09 12:39:02] production.DEBUG: It worked! xxx successfully binded to LDAP.

[snipe]

@sashasimkin you should probably open your own issue here versus resurrecting this one from a year ago

[sashasimkin]

hi @snipe, thanks for the prompt reply!

I don't feel like duplicating the request, as it'll be literally a copy-paste of MrHacko's, environment, and Snipe's major versions are the same. I only did extra research for the same cause.

If you think I'd better open my own or just an issue - let me know please (sorry for being stubborn :))

[snipe]

@uberbrady any workarounds that you can think of?

[sashasimkin]

I'm planning to use SAML for authentication and LDAP for user sync (I think it's also what docs suggest on the SAML documentation page) as a workaround.

But there's still value for this to work natively, so I'd not need an extra connection between Snipe & JumpCloud.

I'd be happy to provide any necessary context or testing to have this feature implemented.

[snipe]

Is SCIM not an option for you? We generally recommend SAML + SCIM over SAML + LDAP, just because LDAP can be such a pain in the ass to work with.

[uberbrady]

I'm pretty sure that even before v6, we still had to 'bind' to the LDAP server in order to have the user who was logging in actually be able to check their password. LDAP doesn't expose passwords or hashes - the only way you can check if the user can log in or not is to try and bind as that user. If password syncing was enabled when the user was able to log in via LDAP, then the 'local password fallback' would work for a time - but eventually as users change their passwords, the 'local passwords' in Snipe-IT would fall out of sync. Just one possible guess as to what could've happened there.

Regardless, I get the idea of not wanting to set that bind permission on all of one's users.

The best workaround I can come up with is to try and do authentication instead using SAML. The periodic LDAP syncs will still allow newly-created (or updated) users to exist in the system, but the actual authentication into those users would be via SAML.

For what it's worth, that's usually the best user experience for the end-user. Additionally, you can lock down who exactly can log in by restricting the users who are authorized to use the app on the SAML side - which is another thing that people tend to like.

[sashasimkin]

@snipe I'm reading about SCIM right now, and looks like it's not an option because our Snipe-it installation is deployed into a private subnet on AWS, while we access it through VPN, so the communication works as long as it's initiated from Snipe-it. Setting any private routing between JumpCloud and Snipe-IT is not possible unfortunately :(

@uberbrady yes, this is what caught my surprise too, as the setting in JumpCloud seems to be misnamed.

From my debugging, I saw that binding as user works despite the "Enable as Bind DN" setting. In my tests ldap_bind function always returns 1 with the correct password, and that's why I needed to amend the condition to fallthrough to bindAdminToLdap.

The difference is whether you're able to search the directory after the bind.

• "Enable as Bind DN" = false: Able to bind, not able to search the directory
• "Enable as Bind DN" = true: Able to bind, able to search the directory

For context, this is how they describe it in JumpCloud:

---

We have several other things integrated over LDAP, which all work with existing JumpCloud settings: grafana, nexus, argocd

---

I'll be settings up SAML as a workaround and keep monitoring this FR to maybe remove SAML in future :)

Thanks for the prompt and detailed responses, I appreciate it!

[MrHackino]

@snipe I'm reading about SCIM right now, and looks like it's not an option because our Snipe-it installation is deployed into a private subnet on AWS, while we access it through VPN, so the communication works as long as it's initiated from Snipe-it. Setting any private routing between JumpCloud and Snipe-IT is not possible unfortunately :(

@uberbrady yes, this is what caught my surprise too, as the setting in JumpCloud seems to be misnamed.

From my debugging, I saw that binding as user works despite the "Enable as Bind DN" setting. In my tests ldap_bind function always returns 1 with the correct password, and that's why I needed to amend the condition to fallthrough to bindAdminToLdap.

The difference is whether you're able to search the directory after the bind.

• "Enable as Bind DN" = false: Able to bind, not able to search the directory
• "Enable as Bind DN" = true: Able to bind, able to search the directory

For context, this is how they describe it in JumpCloud:

We have several other things integrated over LDAP, which all work with existing JumpCloud settings: grafana, nexus, argocd

I'll be settings up SAML as a workaround and keep monitoring this FR to maybe remove SAML in future :)

Thanks for the prompt and detailed responses, I appreciate it!

Hello @sashasimkin,

I am sorry, sadly I cannot help you we dropped Snipe-IT after this change because the implementation of LDAP is considered as non-standard per our security policies and also poses a security risk to our infrastructure.

The standard implementation considered is that any user which desires to get authenticated must request the bind user which itself does the LDAP request to the server.

In our case we had to enable bind status to every user on our LDAP server, the user itself doing the request.

Meaning anyone could probe it and requests information from it. So the use of a bind LDAP account was nullified and in breach of our security policies.

Best regards.

[sashasimkin]

Ah, I see @MrHackino, thanks for the information and details. That's exactly my concern too, although what you described in the FR initially must improve that behavior and keep the LDAP secure, w/ only the bind account having the permission to search.

Small update from me on the matter - I just configured SAML integration with JumpCloud, starting tests within the org, but works like a charm for my account 🎉

[MrHackino]

Ah, I see @MrHackino, thanks for the information and details. That's exactly my concern too, although what you described in the FR initially must improve that behavior and keep the LDAP secure, w/ only the bind account having the permission to search.

Small update from me on the matter - I just configured SAML integration with JumpCloud, starting tests within the org, but works like a charm for my account 🎉

The case you are describing was the standard method in the v5 but the LDAP implementation was reworked in v6. Our organization is sticking to the LDAP protocol because it is the easiest and most secure way for us instead of SAML.

We switched to an alternative to answer this issue and not leave a potential vulnerabilities.

Hope it will helps.

Edit: After consulting our CISO this is also the standard way of implementation. No user other than the LDAP bind account should be able to query the LDAP. Even if it is in read only.