mirror of
https://github.com/lldap/lldap.git
synced 2026-04-25 08:15:52 +03:00
[GH-ISSUE #1327] [FEATURE REQUEST] Support substring query for UUID #464
Labels
No labels
backend
blocked
bug
cleanup
dependencies
docker
documentation
duplicate
enhancement
enhancement
frontend
github_actions
good first issue
help wanted
help wanted
integration
invalid
ldap
pull-request
question
rust
rust
tests
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/lldap-lldap#464
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sdwilsh on GitHub (Oct 14, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1327
Motivation
I am trying to get OpenCloud to work with lldap as the IDP.
Describe the solution you'd like
I would like lldap to implement substring for uuid in a group as it does for display name.
Describe alternatives you've considered
The only other alternative is to change OpenCloud, but that project seems to just want everyone to use Keycloak. I've also looked into using another field for the group identifier, but their docs say this, which is why I'm using
entryUUID:Additional context
They have an LDAP query that they do when you are trying to add a person or group to a share that looks like this:
ou=groups,dc=example,dc=com(&(&(objectclass=groupOfUniqueNames)(uid=opencloud-*))(objectClass=groupOfUniqueNames)(|(cn=*Sha*)(entryUUID=*Sha*)))This is somewhat configurable! However, not in a way that I can make work with lldap.
OC_LDAP_GROUP_BASE_DNou=groups,dc=example,dc=comOC_LDAP_GROUP_OBJECTCLASSgroupOfUniqueNamesOC_LDAP_GROUP_SCHEMA_IDentryUUIDThis query currently fails with:
@sdwilsh commented on GitHub (Oct 14, 2025):
Aside: once I get this working, I'll do a PR to add setup instructions for OpenCloud here.
@nitnelave commented on GitHub (Oct 14, 2025):
I'm confused about this usage of entryUuid. It's never going to match anything, no UUID contains the string "Sha"
UUIDs tend to be all or nothing, either you have the whole ID or not. You don't really have cases where you know the user's UUID contains "17de" but that's it
@sdwilsh commented on GitHub (Oct 14, 2025):
I agree that it's weird. My best guess is that it's for admins who know the uuid of the group to be able to easily add it in large organizations (which a self-hoster isn't). However, that does not need to be a substring match then.
This project is a fork of ocis, so this issue might exist there as well. Maybe nobody has tried to add someone to a space and that's why this hasn't come up previously.
@sdwilsh commented on GitHub (Oct 15, 2025):
I did some digging, and I'm pretty sure this is intentional on their part. The code (golang) lives here.
I could maybe work around this by setting the
OC_LDAP_GROUP_SCHEMA_IDvariable to being thenameso that it searchescnandnamewhich both map to the same thing and have a supported substring filter. It just goes against their advice for this (source):...and as a result, I'm worried about what else might break; I certainly couldn't ever rename a group if I did this.
@nitnelave commented on GitHub (Oct 15, 2025):
The substring still doesn't make sense. If you have a user with unique id 123, and then you create a user with unique id 1234, the filter would match both. Could you check with them about that?
@sdwilsh commented on GitHub (Oct 26, 2025):
It looks like they might be open to not doing the query because OpenLDAP also doesn't support the query. In that case, however, it just doesn't return a result, whereas LLDAP returns an error.
Maybe it makes sense for LLDAP to return no results for unsupported queries, but log the usage of an unsupported query?
@nitnelave commented on GitHub (Oct 26, 2025):
I don't think that's the correct stance for a security critical component of a system: I don't know if the query is for a whitelist (which users have access to a resource) or a blacklist. It is probably acceptable to return nothing, but I want to take the more correct (and least surprising) approach of returning an error.
That forces the user to recognize that there is a problem, otherwise some people just don't read the logs.
@sdwilsh commented on GitHub (Oct 27, 2025):
I think that's a fair and reasonable position.
They are open to a PR, so I'm going to close this. Thanks for pushing back and getting me to fix this in the upstream project; it's the right fix.
@nitnelave commented on GitHub (Oct 31, 2025):
I'll have to mention that in rereading the LDAP RFC 4511, it mentions that filters should be evaluated with the 3-valued true/false/undefined logic, with undefined matching nothing. Specifically, it MUST NOT return an error for an unsupported filter.
Given this, I still maintain my stance for LLDAP for the reasons mentioned above, even in the face of non-compliance with the RFC.