Implement RootDSE support with LDAP attribute filtering per RFC 4512

[Copilot]

Implementation Plan for RootDSE Support

Understanding the Issue

• SSSD (System Security Services Daemon) is trying to query the LDAP server's RootDSE
• RootDSE is a special LDAP entry with base DN of "" (empty string) and filter "(objectClass=*)"
• Currently returns "No such object" (error 32)
• Should return server capabilities information

Implementation Checklist

• Add RootDSE search handler to LdapEngine.js
  • Create handler for empty base DN ("")
  • Return entry with proper attributes (objectClass, namingContexts, supportedLDAPVersion)
  • Ensure it's accessible without authentication (anonymous bind)
• Implement LDAP attribute filtering for RootDSE
  • No attributes = return all attributes (default)
  • + = return operational attributes (namingContexts, supportedLDAPVersion)
  • * = return user attributes only (objectClass)
  • * with specific attributes = return user attributes + requested operational attributes (SSSD pattern)
  • Specific names = return only requested attributes
• Create tests for RootDSE functionality
  • Test anonymous access to RootDSE
  • Verify returned attributes match spec
  • Test with actual ldapsearch command
  • Test attribute filtering with +, *, and specific attributes
  • Test SSSD's pattern: * with specific operational attributes
• Manual verification with ldapsearch command
• Run existing tests to ensure no regression
• Code review and security check

Original prompt

---

This section details on the original issue you should resolve

<issue_title>SSSD Log error</issue_title>
<issue_description>```
(2026-02-10 16:05:07): [be[default]] [sdap_get_rootdse_done] (0x0040): [RID#24] RootDSE could not be retrieved. Please check that anonymous access to RootDSE is allowed

According to Gemini, this can be fixed by implementing the RootDSE LDAP spec. Essentially, we currently return this:

root@base-test:~# LDAPTLS_REQCERT=allow ldapsearch -H ldaps://ldap -x -s base -b "" "(objectClass=*)" +

extended LDIF

LDAPv3

base <> with scope baseObject

filter: (objectClass=*)

requesting: +

search result

search: 2
result: 32 No such object

numResponses: 1

We should instead return something like this:

dn:
objectClass: top
namingContexts: dc=example,dc=com
supportedLDAPVersion: 3

In the above example, namingContexts should equal the value of $LDAP_BASE_DN. This would also enable support for complete SSSD autoconfig.</issue_description>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes SSSD Log error #133

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[runleveldev]

@copilot create a test and confirm that using ldap attributes in a search (such as namingContexts and supportdLDAPVersion) still return the attribute. In addition the special attribute "+" in a search should return all operational attributes. A standard search (attributes "*" requested) shouldn't return any operational attributes however.

[Copilot]

@copilot create a test and confirm that using ldap attributes in a search (such as namingContexts and supportdLDAPVersion) still return the attribute. In addition the special attribute "+" in a search...

I've implemented attribute filtering for RootDSE searches and added comprehensive tests. The implementation now correctly handles:

1. + selector - Returns operational attributes (namingContexts, supportedLDAPVersion) + objectClass
2. * selector - Returns user attributes only (objectClass for RootDSE)
3. Specific attributes - Returns only the requested attributes (e.g., namingContexts, supportedLDAPVersion)
4. No attributes specified - Returns all attributes (default behavior)

All tests pass, including the new tests for attribute filtering. See commit ef55a6a.

[runleveldev]

@copilot SSSD sends this request for RootDSE discovery, make sure it works:

debug: RootDSE Search - Filter: (objectclass=*), Scope: 0, Attributes: ["*","altServer","namingContexts","supportedControl","supportedExtension","supportedFeatures","supportedLDAPVersion","supportedSASLMechanisms","domainControllerFunctionality","defaultNamingContext","lastUSN","highestCommittedUSN"]

[Copilot]

@copilot SSSD sends this request for RootDSE discovery, make sure it works:

debug: RootDSE Search - Filter: (objectclass=*), Scope: 0, Attributes: ["*","altServer","namingContexts","supportedContr...

Fixed in commit 2f1efee. The RootDSE handler now correctly handles SSSD's request pattern where * is combined with specific operational attribute names. When this pattern is detected, it returns user attributes (objectClass) plus any specifically requested operational attributes that we support (namingContexts, supportedLDAPVersion).

Added a test case that verifies this SSSD scenario works correctly.

[runleveldev]

LGTM