mirror of
https://github.com/lldap/lldap.git
synced 2026-04-25 08:15:52 +03:00
[GH-ISSUE #1362] [BUG] Unexpected behavior on cn-search #474
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#474
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 @LageTs on GitHub (Dec 10, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1362
Originally assigned to: @Copilot on GitHub.
Describe the bug
I switched from 0.5.0 to 0.6.2 and got errors on my radicale service. Regardless of that I found some behavior that I didn't expect for two ldapsearch requests to my service (changed the dc and UID for privacy but it was identical on command execution, others untouched):
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I would expect the result to include exactly that one entry that has cn=TestAll, not more, not less than that.
Logs
I couldn't find any logs. Searched for lldap specific logs and in my system log (/var/log/messages)
Additional context
I'm not really sure If I didn't make any false assumptions, please feel free to correct me, if so. LLDAP is installed on alpine-lxc in proxmox as binaries from github.
I noticed this as my radicale instance needs user names to be case sensitive as far as I know. My other services are running fine as they doesn't need this and work with uid requests which return the expected result for case-insensitive searches.
My radicale ldap_filter was like this before. I think this is not relevant:
ldap_filter = (&(cn={0})(|(memberOf=cn=radicale,ou=groups,dc=tesst,dc=tessst)(memberOf=cn=superuser,ou=groups,dc=tesst,dc=tessst)))
@nitnelave commented on GitHub (Dec 10, 2025):
The LDAP verbose logs would help
LLDAP_VERBOSE=true, logs are on standard output for LLDAP.But the LLDAP protocol is by and large case insensitive. If radicale expects case sensitive usernames, that's not really compatible with LLDAP and there's not much I can do about that.
@LageTs commented on GitHub (Dec 10, 2025):
But than is behavior is still other than expected. If the cn is set to "TestAll" and i search for "cn=TestAll" it still should return that user. Or if I set it to "TestAll" and search for "cn=testall" or even of other way round and it is set to "testall" and i search for "cn=testall" or "cn=TestAll". But only if it is set in lower-case the search returns the user.
So assume the following user:
I get this replys:
But if case-insensitive, I would expect both to return the following. If case-sensitive I would expect the first one to return the following, but both don't:
As upper-case-letters a allowed in ldap-cn according to https://datatracker.ietf.org/doc/html/rfc4519#section-2.3
If i set the user to be like this:
Than the search works like I would it expect as case-sensitive so it returns the user on "cn=testall" but not on "cn=Testall"
In the following the log output of the lldap session with first an search for "cn=*" and than the two commands from above with ldapsearch.
@nitnelave commented on GitHub (Dec 10, 2025):
Oh, sorry, I misunderstood. You're saying that if the filter has an uppercase name, it doesn't match a user with the same casing? Then that's definitely a bug.
@nitnelave commented on GitHub (Dec 10, 2025):
Let's see if Copilot can give a meaningful fix.
@nitnelave commented on GitHub (Dec 11, 2025):
Sorry, coming back to this issue with a slightly different angle: "cn" (common name) is the display name on LLDAP, are you sure you want to use that to identify users? There are no restrictions on it, including multiple users sharing a display name, or a user taking an admin's display name.
The filter should be done on "uid", not "cn".
It's a separate issue that cn matching doesn't respect the casing well, but that's common with all the "user-defined" attributes (which cn is represented as, even though it's hardcoded). Fixing that would require a bigger architectural change (which would fix other issues around user defined attributes, like date or integer inequalities).
@LageTs commented on GitHub (Dec 16, 2025):
I've thought a bit about your comment and read through radicale's documentation again and found something interesting which I will share for documentation reasons:
Since version 3.4.0 there is the new config option
ldap_user_attribute = cnwith which you can filter by uid and then use the cn as display name. Alternatively one could force lower case user names withlc_username = TrueNevertheless I hope that the unexpected behavior will be fixed in next version.
Thanks for your help!