[PR #1344] [MERGED] Fix LDAP base scope search to return NoSuchObject for non-existent entries #1267

New issue

Closed

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

kerem commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/lldap/lldap/pull/1344
Author: @Copilot
Created: 10/31/2025
Status: ✅ Merged
Merged: 11/16/2025
Merged by: @nitnelave

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

📝 Commits (1)

7d04be4 ldap: Fix LDAP base scope search to return NoSuchObject for non-existent entries

📊 Changes

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

View changed files

📝 crates/ldap/src/search.rs (+80 -0)

📄 Description

LLDAP was returning Success with zero entries for base scope searches on non-existent objects, breaking LDAP clients that expect RFC 4511 compliant error codes. This caused issues with Python's ldap library and Ansible's ldap modules.

# Before: incorrect success response
$ ldapsearch -x -H ldap://localhost:3890 -s base \
  -b "uid=nonexistent,ou=people,dc=example,dc=com" "(objectClass=*)"
result: 0 Success

# After: RFC 4511 compliant error
result: 32 No such object

Changes

Core fix: Added check in do_search() to return LdapResultCode::NoSuchObject when base scope searches return empty results
Tests: Added coverage for base scope searches on both existent and non-existent users/groups

The fix is scoped to base searches only - subtree and one-level searches continue returning success with zero entries as per spec.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

esm.ubuntu.com

Triggering command: /usr/lib/apt/methods/https (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Configure Actions setup steps to set up my environment, which run before the firewall is enabled

Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

This section details on the original issue you should resolve

<issue_title>[BUG] Unexpected return for ldapsearch, success instead of error</issue_title>
<issue_description>Describe the bug
LLDAP does not return the expected return for an ldapsearch.
One of the bad effects of this is that ldap python's library can have unexpected behaviors. See the additional context for a concrete example.

To Reproduce
Steps to reproduce the behavior:

Run the following command:
ldapsearch -x -H ldap://localhost:3890 -s base -b uid=bsamson,ou=people,dc=example,dc=com -D uid=admin,ou=people,dc=example,dc=com -w password "(objectClass=*)" 
You get the following return from lldap:
[...]
# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAUCAQAEAA==
pagedresults: cookie=

# numResponses: 1
Expected behavior
The expected behavior would be for LLDAP to return the following error:
[...]
# search result
search: 2
result: 32 No such object

# numResponses: 1
Specifically the result:32 No such object.

Additional context
For more context, I found this bug while trying to solve the following ansible issue https://github.com/ansible-collections/community.general/issues/10393</issue_description>

Comments on the Issue (you are @copilot in this section)
@nitnelave That is very much me misreading the spec and not realizing that "no result" should be an error (I still find it weird, but *shrug*).
This needs to be fixed indeed.</comment_new>

Fixes lldap/lldap#1343

💬 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/1344 **Author:** [@Copilot](https://github.com/apps/copilot-swe-agent) **Created:** 10/31/2025 **Status:** ✅ Merged **Merged:** 11/16/2025 **Merged by:** [@nitnelave](https://github.com/nitnelave) **Base:** `main` ← **Head:** `copilot/fix-ldapsearch-unexpected-return` --- ### 📝 Commits (1) - [`7d04be4`](https://github.com/lldap/lldap/commit/7d04be417872ae45251248b18269c622f37109a7) ldap: Fix LDAP base scope search to return NoSuchObject for non-existent entries ### 📊 Changes **1 file changed** (+80 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `crates/ldap/src/search.rs` (+80 -0) </details> ### 📄 Description LLDAP was returning `Success` with zero entries for base scope searches on non-existent objects, breaking LDAP clients that expect RFC 4511 compliant error codes. This caused issues with Python's ldap library and Ansible's ldap modules. ```bash # Before: incorrect success response $ ldapsearch -x -H ldap://localhost:3890 -s base \ -b "uid=nonexistent,ou=people,dc=example,dc=com" "(objectClass=*)" result: 0 Success # After: RFC 4511 compliant error result: 32 No such object ``` ## Changes - **Core fix**: Added check in `do_search()` to return `LdapResultCode::NoSuchObject` when base scope searches return empty results - **Tests**: Added coverage for base scope searches on both existent and non-existent users/groups The fix is scoped to base searches only - subtree and one-level searches continue returning success with zero entries as per spec. > [!WARNING] > > <details> > <summary>Firewall rules blocked me from connecting to one or more addresses (expand for details)</summary> > > #### I tried to connect to the following addresses, but was blocked by firewall rules: > > - `esm.ubuntu.com` > - Triggering command: `/usr/lib/apt/methods/https` (dns block) > > If you need me to access, download, or install something from one of these locations, you can either: > > - Configure [Actions setup steps](https://gh.io/copilot/actions-setup-steps) to set up my environment, which run before the firewall is enabled > - Add the appropriate URLs or hosts to the custom allowlist in this repository's [Copilot coding agent settings](https://github.com/lldap/lldap/settings/copilot/coding_agent) (admins only) > > </details>  <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>[BUG] Unexpected return for ldapsearch, success instead of error</issue_title> > <issue_description>**Describe the bug** > LLDAP does not return the expected return for an ldapsearch. > One of the bad effects of this is that ldap python's library can have unexpected behaviors. See the additional context for a concrete example. > > **To Reproduce** > Steps to reproduce the behavior: > 1. Run the following command: > ```bash > ldapsearch -x -H ldap://localhost:3890 -s base -b uid=bsamson,ou=people,dc=example,dc=com -D uid=admin,ou=people,dc=example,dc=com -w password "(objectClass=*)" > ``` > 2. You get the following return from lldap: > ```bash > [...] > # search result > search: 2 > result: 0 Success > control: 1.2.840.113556.1.4.319 false MAUCAQAEAA== > pagedresults: cookie= > > # numResponses: 1 > ``` > > **Expected behavior** > The expected behavior would be for LLDAP to return the following error: > ```bash > [...] > # search result > search: 2 > result: 32 No such object > > # numResponses: 1 > ``` > > Specifically the `result:32 No such object`. > > **Additional context** > For more context, I found this bug while trying to solve the following ansible issue https://github.com/ansible-collections/community.general/issues/10393</issue_description> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > <comment_new><author>@nitnelave</author><body> > That is very much me misreading the spec and not realizing that "no result" should be an error (I still find it weird, but *shrug*). > > This needs to be fixed indeed.</body></comment_new> > </comments> > </details> - Fixes lldap/lldap#1343  --- 💬 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>