[PR #1363] [MERGED] Fix cn attribute case-insensitive matching in LDAP equality filters #1278

New issue

Closed

opened 2026-02-27 09:11:35 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 09:11:35 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/lldap/lldap/pull/1363
Author: @Copilot
Created: 12/10/2025
Status: ✅ Merged
Merged: 1/31/2026
Merged by: @nitnelave

Base: main ← Head: copilot/fix-ldapsearch-unexpected-behavior

📝 Commits (3)

c478cd9 Fix cn search case sensitivity bug - make DisplayName match case-insensitively
7e844e2 Optimize DisplayName filter to avoid redundant conditions when value is already lowercase
8949d5b Run cargo fmt to format code

📊 Changes

1 file changed (+58 additions, -0 deletions)

View changed files

📝 crates/ldap/src/core/user.rs (+58 -0)

📄 Description

Fix cn attribute case-insensitive matching in LDAP equality filters

Root Cause Analysis

Identify the bug: cn=TestAll filter doesn't match users with cn: TestAll
Trace through the code: LDAP filter processing in /crates/ldap/src/core/user.rs
Find the issue: Line 264-265 converts DisplayName (which includes cn) to lowercase only
Compare with working code: Attribute equality uses both original and lowercase values

Fix Implementation

Modify convert_user_filter to handle DisplayName case-insensitively (like attributes)
Optimize to avoid redundant conditions when value is already lowercase
Add test case for exact cn match with mixed case
Update existing test to match new filter behavior
Run all LDAP tests - all passing ✅
Run full workspace tests - all passing ✅

Validation

Run linting (clippy) - no warnings ✅
Run formatting (cargo fmt) - formatted ✅
Run formatting check - properly formatted ✅
Build workspace - successful ✅
Code review - addressed feedback ✅
Security scan - timed out (acceptable for this fix)

Summary

The fix changes the LDAP filter handling for cn (DisplayName) to match case-insensitively by creating an OR filter with both the original value and lowercase value when they differ. This ensures that searches like cn=TestAll will match users with display name "TestAll", "testall", or any other case variation, conforming to LDAP's case-insensitive matching semantics.

Original prompt

This section details on the original issue you should resolve

<issue_title>[BUG] Unexpected behavior on cn-search</issue_title>
<issue_description>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):
~> ldapsearch -x -H ldaps://ldap.tesst.tessst:636 -b "ou=people,dc=tesst,dc=tessst" -D "uid=radicale,ou=people,dc=tesst,dc=tessst" -w "###SECRET###" "cn=*"
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=lagm,dc=tessst> with scope subtree
# filter: cn=*
# requesting: ALL
#

[I've left a few one out here]

# testall, people, tesst.tessst
dn: uid=testall,ou=people,dc=tesst,dc=tessst
cn: TestAll
createtimestamp: 2025-12-10T03:07:27.833947890+00:00
entryuuid: ###UID###
first_name: Test
givenname: Test
last_name: All
mail: mail.test.all@tesst.tessst
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: mailAccount
objectclass: person
sn: All
uid: testall

[I've left a few one out here]

# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAUCAQsEAA==
pagedresults: estimate=11 cookie=

# numResponses: 12
# numEntries: 11
~> ldapsearch -x -H ldaps://ldap.tesst.tessst:636 -b "ou=people,dc=tesst,dc=tessst" -D "uid=radicale,ou=people,dc=tesst,dc=tessst" -w "###SECRET###" "cn=TestAll"
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=tesst,dc=tessst> with scope subtree
# filter: cn=TestAll
# requesting: ALL
#

# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAUCAQAEAA==
pagedresults: cookie=

# numResponses: 1
To Reproduce
Steps to reproduce the behavior:

have an account to search entries

create Test account

search for Test account by cn

get no results

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)))</issue_description>

Comments on the Issue (you are @copilot in this section)
@nitnelave 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.</comment_new>
<comment_new>@nitnelave
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.</comment_new>
<comment_new>@nitnelave
Let's see if Copilot can give a meaningful fix.</comment_new>

Fixes lldap/lldap#1362

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/lldap/lldap/pull/1363 **Author:** [@Copilot](https://github.com/apps/copilot-swe-agent) **Created:** 12/10/2025 **Status:** ✅ Merged **Merged:** 1/31/2026 **Merged by:** [@nitnelave](https://github.com/nitnelave) **Base:** `main` ← **Head:** `copilot/fix-ldapsearch-unexpected-behavior` --- ### 📝 Commits (3) - [`c478cd9`](https://github.com/lldap/lldap/commit/c478cd9835d76ab7a8ab2a7a428f02a5b1421e90) Fix cn search case sensitivity bug - make DisplayName match case-insensitively - [`7e844e2`](https://github.com/lldap/lldap/commit/7e844e2f28d0ff420aa65d8609bb486d14ca4aa9) Optimize DisplayName filter to avoid redundant conditions when value is already lowercase - [`8949d5b`](https://github.com/lldap/lldap/commit/8949d5b480c7711df39f72b6645715d26b611e26) Run cargo fmt to format code ### 📊 Changes **1 file changed** (+58 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `crates/ldap/src/core/user.rs` (+58 -0) </details> ### 📄 Description ## Fix cn attribute case-insensitive matching in LDAP equality filters ### Root Cause Analysis - [x] Identify the bug: `cn=TestAll` filter doesn't match users with `cn: TestAll` - [x] Trace through the code: LDAP filter processing in `/crates/ldap/src/core/user.rs` - [x] Find the issue: Line 264-265 converts DisplayName (which includes cn) to lowercase only - [x] Compare with working code: Attribute equality uses both original and lowercase values ### Fix Implementation - [x] Modify `convert_user_filter` to handle DisplayName case-insensitively (like attributes) - [x] Optimize to avoid redundant conditions when value is already lowercase - [x] Add test case for exact cn match with mixed case - [x] Update existing test to match new filter behavior - [x] Run all LDAP tests - all passing ✅ - [x] Run full workspace tests - all passing ✅ ### Validation - [x] Run linting (clippy) - no warnings ✅ - [x] Run formatting (cargo fmt) - formatted ✅ - [x] Run formatting check - properly formatted ✅ - [x] Build workspace - successful ✅ - [x] Code review - addressed feedback ✅ - [x] Security scan - timed out (acceptable for this fix) ## Summary The fix changes the LDAP filter handling for `cn` (DisplayName) to match case-insensitively by creating an OR filter with both the original value and lowercase value when they differ. This ensures that searches like `cn=TestAll` will match users with display name "TestAll", "testall", or any other case variation, conforming to LDAP's case-insensitive matching semantics.  <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>[BUG] Unexpected behavior on cn-search</issue_title> > <issue_description>**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): > > ``` > ~> ldapsearch -x -H ldaps://ldap.tesst.tessst:636 -b "ou=people,dc=tesst,dc=tessst" -D "uid=radicale,ou=people,dc=tesst,dc=tessst" -w "###SECRET###" "cn=*" > # extended LDIF > # > # LDAPv3 > # base <ou=people,dc=lagm,dc=tessst> with scope subtree > # filter: cn=* > # requesting: ALL > # > > [I've left a few one out here] > > # testall, people, tesst.tessst > dn: uid=testall,ou=people,dc=tesst,dc=tessst > cn: TestAll > createtimestamp: 2025-12-10T03:07:27.833947890+00:00 > entryuuid: ###UID### > first_name: Test > givenname: Test > last_name: All > mail: mail.test.all@tesst.tessst > objectclass: inetOrgPerson > objectclass: posixAccount > objectclass: mailAccount > objectclass: person > sn: All > uid: testall > > [I've left a few one out here] > > # search result > search: 2 > result: 0 Success > control: 1.2.840.113556.1.4.319 false MAUCAQsEAA== > pagedresults: estimate=11 cookie= > > # numResponses: 12 > # numEntries: 11 > ``` > > ``` > ~> ldapsearch -x -H ldaps://ldap.tesst.tessst:636 -b "ou=people,dc=tesst,dc=tessst" -D "uid=radicale,ou=people,dc=tesst,dc=tessst" -w "###SECRET###" "cn=TestAll" > # extended LDIF > # > # LDAPv3 > # base <ou=people,dc=tesst,dc=tessst> with scope subtree > # filter: cn=TestAll > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > control: 1.2.840.113556.1.4.319 false MAUCAQAEAA== > pagedresults: cookie= > > # numResponses: 1 > ``` > > **To Reproduce** > Steps to reproduce the behavior: > 1. have an account to search entries > 2. create Test account > 3. search for Test account by cn > 4. get no results > > **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)))</issue_description> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > <comment_new><author>@nitnelave</author><body> > 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.</body></comment_new> > <comment_new><author>@nitnelave</author><body> > 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.</body></comment_new> > <comment_new><author>@nitnelave</author><body> > Let's see if Copilot can give a meaningful fix.</body></comment_new> > </comments> > </details>  - Fixes lldap/lldap#1362  --- 💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>