[GH-ISSUE #999] [BUG] unable to search using firstname #362

Open
opened 2026-02-27 08:16:52 +03:00 by kerem · 4 comments
Owner

Originally created by @ggodlewski on GitHub (Oct 13, 2024).
Original GitHub issue: https://github.com/lldap/lldap/issues/999

Describe the bug

I'm unable to search using first name.

According to https://github.com/lldap/lldap/issues/998#issuecomment-2408959241 this should work?

ldapsearch -x -b "ou=people,dc=example,dc=com" -H ldap://localhost:3890 -D cn=admin,ou=people,dc=example,dc=com -W "firstName=Grzegorz"
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=example,dc=com> with scope subtree
# filter: firstName=Grzegorz
# requesting: ALL
#

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

# numResponses: 1

I also tried givenName:

ldapsearch -x -b "ou=people,dc=example,dc=com" -H ldap://localhost:3890 -D cn=admin,ou=people,dc=example,dc=com -W "givenName=Grzegorz"
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=example,dc=com> with scope subtree
# filter: givenName=Grzegorz
# requesting: ALL
#

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

# numResponses: 1

I do have user with following name:

ldapsearch -x -b "ou=people,dc=example,dc=com" -H ldap://localhost:3890 -D cn=admin,ou=people,dc=example,dc=com -W "givenName"
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: givenName 
#

# admin, people, example.com
dn: uid=admin,ou=people,dc=example,dc=com

# gg2, people, example.com
dn: uid=gg2,ou=people,dc=example,dc=com
givenName: Grzegorz

# ggodlewski, people, example.com
dn: uid=ggodlewski,ou=people,dc=example,dc=com
givenName: Grzegorz

# readonly, people, example.com
dn: uid=readonly,ou=people,dc=example,dc=com
givenName: readonly

# test, people, example.com
dn: uid=test,ou=people,dc=example,dc=com

# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAUCAQUEAA==
pagedresults: estimate=5 cookie=

# numResponses: 6
# numEntries: 5
Originally created by @ggodlewski on GitHub (Oct 13, 2024). Original GitHub issue: https://github.com/lldap/lldap/issues/999 **Describe the bug** I'm unable to search using first name. According to https://github.com/lldap/lldap/issues/998#issuecomment-2408959241 this should work? ``` ldapsearch -x -b "ou=people,dc=example,dc=com" -H ldap://localhost:3890 -D cn=admin,ou=people,dc=example,dc=com -W "firstName=Grzegorz" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: firstName=Grzegorz # requesting: ALL # # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MAUCAQAEAA== pagedresults: cookie= # numResponses: 1 ``` I also tried `givenName`: ``` ldapsearch -x -b "ou=people,dc=example,dc=com" -H ldap://localhost:3890 -D cn=admin,ou=people,dc=example,dc=com -W "givenName=Grzegorz" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: givenName=Grzegorz # requesting: ALL # # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MAUCAQAEAA== pagedresults: cookie= # numResponses: 1 ``` I do have user with following name: ``` ldapsearch -x -b "ou=people,dc=example,dc=com" -H ldap://localhost:3890 -D cn=admin,ou=people,dc=example,dc=com -W "givenName" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: givenName # # admin, people, example.com dn: uid=admin,ou=people,dc=example,dc=com # gg2, people, example.com dn: uid=gg2,ou=people,dc=example,dc=com givenName: Grzegorz # ggodlewski, people, example.com dn: uid=ggodlewski,ou=people,dc=example,dc=com givenName: Grzegorz # readonly, people, example.com dn: uid=readonly,ou=people,dc=example,dc=com givenName: readonly # test, people, example.com dn: uid=test,ou=people,dc=example,dc=com # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MAUCAQUEAA== pagedresults: estimate=5 cookie= # numResponses: 6 # numEntries: 5 ```
Author
Owner

@gabay commented on GitHub (Oct 19, 2024):

I took a look at what happens:

In short - the first (and last) name is stored as a case-sensitive blob in the table "user_attributes"
While preforming the search - name is transformed to a lower-case blob, resulting in a mismatch when comparing the blobs...

To verify this - you could set first name to "grzegorz" (lowercase) and see that your query works regardless of the query case :)

A quick hack would be making all names lower-case all the time.

<!-- gh-comment-id:2424162815 --> @gabay commented on GitHub (Oct 19, 2024): I took a look at what happens: In short - the first (and last) name is stored as a **case-sensitive blob** in the table "user_attributes" While preforming the search - name is transformed to a **lower-case blob**, resulting in a mismatch when comparing the blobs... To verify this - you could set first name to "grzegorz" (lowercase) and see that your query works regardless of the query case :) A quick hack would be making all names lower-case all the time.
Author
Owner

@nitnelave commented on GitHub (Oct 26, 2024):

Yeah, that'll require a bit more design work. Currently, attributes are not stored in an easily-searchable format, especially if the case is different.
I can make a small fix that doesn't lowercase the search filter, so at least it'll find if you have the exact spelling and casing, but it's not ideal.

<!-- gh-comment-id:2439657998 --> @nitnelave commented on GitHub (Oct 26, 2024): Yeah, that'll require a bit more design work. Currently, attributes are not stored in an easily-searchable format, especially if the case is different. I can make a small fix that _doesn't_ lowercase the search filter, so at least it'll find if you have the exact spelling and casing, but it's not ideal.
Author
Owner

@broeng commented on GitHub (Jan 13, 2025):

Just fyi, @nitnelave the small fix you suggest, is actually what I have implemented in !1074.

I hit this issue with Samba reading sambaSID ID's from LLDAP, and expecting to use them for lookup later. They also contain uppercase characters.

<!-- gh-comment-id:2587252874 --> @broeng commented on GitHub (Jan 13, 2025): Just fyi, @nitnelave the small fix you suggest, is actually what I have implemented in [!1074](https://github.com/lldap/lldap/pull/1074). I hit this issue with Samba reading sambaSID ID's from LLDAP, and expecting to use them for lookup later. They also contain uppercase characters.
Author
Owner

@broeng commented on GitHub (Jan 22, 2025):

Should be fixed with merge of PR #1074

<!-- gh-comment-id:2606886345 --> @broeng commented on GitHub (Jan 22, 2025): Should be fixed with merge of PR #1074
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/lldap-lldap#362
No description provided.