starred/lldap-lldap
1
0
Fork 0
mirror of https://github.com/lldap/lldap.git synced 2026-04-25 08:15:52 +03:00
Code Issues 101 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #893] [FEATURE REQUEST] Return schema in RootDSE for better compatibility with Apache Directory Studio Browser #323

New issue
Closed
opened 2026-02-27 08:16:39 +03:00 by kerem · 6 comments
kerem commented 2026-02-27 08:16:39 +03:00
Owner
Copy link

Originally created by @GCTWorks on GitHub (Apr 8, 2024).
Original GitHub issue: https://github.com/lldap/lldap/issues/893

Motivation
I want to be able to use Apache Directory Studio Browser to browse LLDAP server

Describe the solution you'd like
When creating the connection to LLDAP in Apache Directory Studio, you must enter the baseDN manually because LLDAP is "Missing schema location in RootDSE" and the baseDN(s) cannot be fetched.

I can make this work half way by creating two connections and manually identifying one baseDN as ou=people,dc=example,dc=com or ou=groups,dc=example,dc=com. However, they must be separate connections. It would be nice if there was an OU one level up or some other way to identify the baseDN. Even better would be for that baseDN to be fetchable by the Apache Directory Studio.

Originally created by @GCTWorks on GitHub (Apr 8, 2024). Original GitHub issue: https://github.com/lldap/lldap/issues/893 **Motivation** I want to be able to use Apache Directory Studio Browser to browse LLDAP server **Describe the solution you'd like** When creating the connection to LLDAP in Apache Directory Studio, you must enter the baseDN manually because LLDAP is "Missing schema location in RootDSE" and the baseDN(s) cannot be fetched. I can make this work half way by creating two connections and manually identifying one baseDN as `ou=people,dc=example,dc=com` or `ou=groups,dc=example,dc=com`. However, they must be separate connections. It would be nice if there was an OU one level up or some other way to identify the baseDN. Even better would be for that baseDN to be fetchable by the Apache Directory Studio.
kerem 2026-02-27 08:16:39 +03:00
kerem commented 2026-02-27 08:16:40 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Apr 9, 2024):

I don't know that much about rootDSE and how to respond with the schema. In the spirit of my limited time and to avoid reading the RFC, could you provide an example of a rootDSE response you'd like to see?

<!-- gh-comment-id:2044138190 --> @nitnelave commented on GitHub (Apr 9, 2024): I don't know that much about rootDSE and how to respond with the schema. In the spirit of my limited time and to avoid reading the RFC, could you provide an example of a rootDSE response you'd like to see?
kerem commented 2026-02-27 08:16:40 +03:00
Author
Owner
Copy link

@GCTWorks commented on GitHub (Apr 9, 2024):

I am not too sure myself. I actually only extremely recently made myself familiar with LDAP because I wanted to use your tool in my homelab, and I had needs for work.

Some searching came up with what I think might be a good explanation of rootDSE here: link

What I think this means is that there is no schema returned when it (Apache Directory Studio) tries to fetch the root of the directory server.

What this results in is the following error message.
image

Also, if there is no "namespaceless" root, then Apache Directory Studio is restricted to a connection to LLDAP that has a baseDN of ou=people,dc=example,dc=com or ou=groups,dc=example,dc=com, but not both in the same connection. I think it is looking for a level above.

I hope this clarifies. I could also be way off base as I am very very new to this stuff and may not have any idea what I am talking about, but I am trying to learn.

By the way... I really like your LLDAP tool. It is amazing for small homelabs to dip feet into LDAP. My friends and I that are on the homelab journey together are enjoying its use. I appreciate the hard work.

<!-- gh-comment-id:2046078146 --> @GCTWorks commented on GitHub (Apr 9, 2024): I am not too sure myself. I actually only extremely recently made myself familiar with LDAP because I wanted to use your tool in my homelab, and I had needs for work. Some searching came up with what I think might be a good explanation of rootDSE here: [link](https://learn.microsoft.com/en-us/windows/win32/adschema/rootdse) What I think this means is that there is no schema returned when it (Apache Directory Studio) tries to fetch the root of the directory server. What this results in is the following error message. ![image](https://github.com/lldap/lldap/assets/13966442/71180da7-6d2f-497b-8b9f-2950c4ece045) Also, if there is no "namespaceless" root, then Apache Directory Studio is restricted to a connection to LLDAP that has a baseDN of `ou=people,dc=example,dc=com` or `ou=groups,dc=example,dc=com`, but not both in the same connection. I think it is looking for a level above. I hope this clarifies. I could also be way off base as I am very very new to this stuff and may not have any idea what I am talking about, but I am trying to learn. By the way... I really like your LLDAP tool. It is amazing for small homelabs to dip feet into LDAP. My friends and I that are on the homelab journey together are enjoying its use. I appreciate the hard work.
kerem commented 2026-02-27 08:16:40 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Apr 9, 2024):

@FirstYear hey, do you know what's needed in the rootDSE for this? I made the minimum effort to be compliant, but this is stretching my knowledge.

I guess I need to declare and implement the DC level above the OUs, and declare a schema?

<!-- gh-comment-id:2046105132 --> @nitnelave commented on GitHub (Apr 9, 2024): @FirstYear hey, do you know what's needed in the rootDSE for this? I made the minimum effort to be compliant, but this is stretching my knowledge. I guess I need to declare and implement the DC level above the OUs, and declare a schema?
kerem commented 2026-02-27 08:16:40 +03:00
Author
Owner
Copy link

@Firstyear commented on GitHub (Apr 9, 2024):

I'll save you the trouble of reading the (whole) RFC:

https://www.rfc-editor.org/rfc/rfc4512#section-4.4

"""
To discover the DN of the subschema (sub)entry holding the subschema
controlling a particular entry, a client reads that entry's
'subschemaSubentry' operational attribute. To read schema attributes
from the subschema (sub)entry, clients MUST issue a Search operation
[RFC4511] where baseObject is the DN of the subschema (sub)entry,
scope is baseObject, filter is "(objectClass=subschema)" [RFC4515],
and the attributes field lists the names of the desired schema
attributes (as they are operational). Note: the
"(objectClass=subschema)" filter allows LDAP servers that gateway to
X.500 to detect that subentry information is being requested.
"""

So this really glosses over whats going on.

In the rootdse you have:

# ldapsearch -H ldap://172.17.0.2:3389 -x -b '' -s base \* +
...
dn:
objectClass: top
subschemaSubentry: cn=schema
...

subschemaSubentry is operational, so only return it on + or when requested.

The client then searches with that as the base dn, you just respond with a single entry with a ton of attributes representing the schema.

These entries are defined in https://www.rfc-editor.org/rfc/rfc4512#section-4.2 again with the usual level of "specific but not clear" as we would expect from an LDAP rfc.

And easy way to "cheat" and check this would be to look at what something else does. So here's an ldif I prepared for you.

ldapsearch -H ldap://172.17.0.2:3389 -x -b 'cn=schema' -s base '(objectClass=subschema)' \+

# schema
dn: cn=schema
objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass X-ORIGIN 'RFC 4512' )
objectClasses: ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName X-ORIGIN 'RFC 4512' )
objectClasses: ( 2.5.20.1 NAME 'subschema' AUXILIARY MAY ( dITStructureRules $ nameForms $ dITContentRules $ objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse ) X-ORIGIN 'RFC 4512' )
objectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' SUP top AUXILIARY X-ORIGIN 'RFC 4512' )
...
attributeTypes: ( 2.16.840.1.113730.3.1.2384 NAME 'passwordTPRDelayValidFrom' DESC '389 Directory Server password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN '389 Directory Server' )
attributeTypes: ( 2.16.840.1.113730.3.1.582 NAME 'nsDS5ReplicaCredentials' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.1 NAME 'sudoUser' DESC 'User(s) who may  run sudo' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'SUDO' )
attributeTypes: ( 2.16.840.1.113730.3.1.2274 NAME 'nsslapd-instancedir' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' )
attributeTypes: ( 2.16.840.1.113719.1.301.4.24.1 NAME 'krbHostServer'  EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributeTypes: ( 1.3.18.0.2.4.1139 NAME 'printer-info' DESC 'Descriptive information about this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'rfc3712' )
....
matchingRules: ( 2.5.13.17 NAME 'octetStringMatch' DESC 'The octetStringMatch rule compares an assertion value of the Octet String syntax to an attribute value of a syntax (e.g., the Octet String or JPEG syntax) whose cor
responding ASN.1 type is the OCTET STRING ASN.1 type.  The rule evaluates to TRUE if and only if the attribute value and the assertion value are the same length and corresponding octets (by position) are the same.' SYNTAX
 1.3.6.1.4.1.1466.115.121.1.40 )
matchingRules: ( 2.5.13.18 NAME 'octetStringOrderingMatch' DESC 'The octetStringOrderingMatch rule compares an assertion value of the Octet String syntax to an attribute value of a syntax (e.g., the Octet String or JPEG s
yntax) whose corresponding ASN.1 type is the OCTET STRING ASN.1 type.  The rule evaluates to TRUE if and only if the attribute value appears earlier in the collation order than the assertion value.  The rule compares octe
t strings from the first octet to the last octet, and from the most significant bit to the least significant bit within the octet.  The first occurrence of a different bit determines the ordering of the strings.  A zero b
it precedes a one bit.  If the strings contain different numbers of octets but the longer string is identical to the shorter string up to the length of the shorter string, then the shorter string precedes the longer strin
g.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
...
ldapSyntaxes: ( 2.16.840.1.113730.3.7.1 DESC 'SpaceInsensitiveString' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'TelephoneNumber' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
<!-- gh-comment-id:2046193949 --> @Firstyear commented on GitHub (Apr 9, 2024): I'll save you the trouble of reading the (whole) RFC: https://www.rfc-editor.org/rfc/rfc4512#section-4.4 """ To discover the DN of the subschema (sub)entry holding the subschema controlling a particular entry, a client reads that entry's 'subschemaSubentry' operational attribute. To read schema attributes from the subschema (sub)entry, clients MUST issue a Search operation [[RFC4511](https://www.rfc-editor.org/rfc/rfc4511)] where baseObject is the DN of the subschema (sub)entry, scope is baseObject, filter is "(objectClass=subschema)" [[RFC4515](https://www.rfc-editor.org/rfc/rfc4515)], and the attributes field lists the names of the desired schema attributes (as they are operational). Note: the "(objectClass=subschema)" filter allows LDAP servers that gateway to X.500 to detect that subentry information is being requested. """ So this really glosses over whats going on. In the rootdse you have: ``` # ldapsearch -H ldap://172.17.0.2:3389 -x -b '' -s base \* + ... dn: objectClass: top subschemaSubentry: cn=schema ... ``` subschemaSubentry is operational, so only return it on `+` or when requested. The client then searches with that as the base dn, you just respond with a single entry with a ton of attributes representing the schema. These entries are defined in https://www.rfc-editor.org/rfc/rfc4512#section-4.2 again with the usual level of "specific but not clear" as we would expect from an LDAP rfc. And easy way to "cheat" and check this would be to look at what something else does. So here's an ldif I prepared for you. ``` ldapsearch -H ldap://172.17.0.2:3389 -x -b 'cn=schema' -s base '(objectClass=subschema)' \+ # schema dn: cn=schema objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass X-ORIGIN 'RFC 4512' ) objectClasses: ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName X-ORIGIN 'RFC 4512' ) objectClasses: ( 2.5.20.1 NAME 'subschema' AUXILIARY MAY ( dITStructureRules $ nameForms $ dITContentRules $ objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse ) X-ORIGIN 'RFC 4512' ) objectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' SUP top AUXILIARY X-ORIGIN 'RFC 4512' ) ... attributeTypes: ( 2.16.840.1.113730.3.1.2384 NAME 'passwordTPRDelayValidFrom' DESC '389 Directory Server password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN '389 Directory Server' ) attributeTypes: ( 2.16.840.1.113730.3.1.582 NAME 'nsDS5ReplicaCredentials' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) attributeTypes: ( 1.3.6.1.4.1.15953.9.1.1 NAME 'sudoUser' DESC 'User(s) who may run sudo' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'SUDO' ) attributeTypes: ( 2.16.840.1.113730.3.1.2274 NAME 'nsslapd-instancedir' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) attributeTypes: ( 2.16.840.1.113719.1.301.4.24.1 NAME 'krbHostServer' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributeTypes: ( 1.3.18.0.2.4.1139 NAME 'printer-info' DESC 'Descriptive information about this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'rfc3712' ) .... matchingRules: ( 2.5.13.17 NAME 'octetStringMatch' DESC 'The octetStringMatch rule compares an assertion value of the Octet String syntax to an attribute value of a syntax (e.g., the Octet String or JPEG syntax) whose cor responding ASN.1 type is the OCTET STRING ASN.1 type. The rule evaluates to TRUE if and only if the attribute value and the assertion value are the same length and corresponding octets (by position) are the same.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) matchingRules: ( 2.5.13.18 NAME 'octetStringOrderingMatch' DESC 'The octetStringOrderingMatch rule compares an assertion value of the Octet String syntax to an attribute value of a syntax (e.g., the Octet String or JPEG s yntax) whose corresponding ASN.1 type is the OCTET STRING ASN.1 type. The rule evaluates to TRUE if and only if the attribute value appears earlier in the collation order than the assertion value. The rule compares octe t strings from the first octet to the last octet, and from the most significant bit to the least significant bit within the octet. The first occurrence of a different bit determines the ordering of the strings. A zero b it precedes a one bit. If the strings contain different numbers of octets but the longer string is identical to the shorter string up to the length of the shorter string, then the shorter string precedes the longer strin g.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) ... ldapSyntaxes: ( 2.16.840.1.113730.3.7.1 DESC 'SpaceInsensitiveString' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'TelephoneNumber' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) ```
kerem commented 2026-02-27 08:16:40 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Apr 10, 2024):

Oh, geez, it's more complicated than I thought... I was hoping for adding a couple of lines to the hardcoded rootDSE 😅

Thanks a lot!

<!-- gh-comment-id:2046533436 --> @nitnelave commented on GitHub (Apr 10, 2024): Oh, geez, it's more complicated than I thought... I was hoping for adding a couple of lines to the hardcoded rootDSE 😅 Thanks a lot!
kerem commented 2026-02-27 08:16:40 +03:00
Author
Owner
Copy link

@Firstyear commented on GitHub (Apr 10, 2024):

but for once it's not twice as complicated as it should be.

<!-- gh-comment-id:2046534450 --> @Firstyear commented on GitHub (Apr 10, 2024): but for once it's not twice as complicated as it should be.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dependabot/github_actions/codecov/codecov-action-6
copilot/fix-equality-filters-list-attributes
dependabot/github_actions/docker/build-push-action-7
dependabot/github_actions/docker/metadata-action-6
dependabot/github_actions/docker/setup-buildx-action-4
dependabot/github_actions/docker/login-action-4
copilot/update-download-artifact-action
copilot/fix-opensuse-warnings
copilot/fix-1268
copilot/fix-727
copilot/fix-898
copilot/fix-1256
copilot/fix-1251
copilot/fix-1249
copilot/fix-1206
user-attribute-form
user-ui
group-ui
server-user-attribute-schema
crates
haveibeenpwned
v0.6.2
v0.6.1
v0.6.0
v0.5.0
v0.4.3
v0.4.2
v0.4.1
v0.4.0
v0.3.0
v0.2.0
v0.0.1
Labels
Clear 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

Mirrored from GitHub Pull Request

  
question

   
rust

   
rust

   
tests

   
wontfix
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
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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#323
No description provided.