rootDSE (still) not readable

[klongeiger]

While trying to use the LDAP for authentication from a bunch of macOS clients, I ran into a problem. Apparently, the rootDSE is still not readable (or empty), despite running a current version of Cloudron. I know there was a fix for this issue in 7.2, but either it isn't fixed for all cases or the fix did not work for our specific instance for some unknown reason.

I verified that the server is actually reachable from the client machine, ldapsearch returns the expected user table. But for the reasons stated above, opendirectoryd deems the server unreachable since the initial reading of the rootDSE returns an empty result.

Is there a way to fix the access privileges manually?

I'd appreciate your help.

[nebulon]

I don't think we have implemented this, at least I am not sure how exactly such a LDAP query looks like. After reading https://ldapwiki.com/wiki/RootDSE I am not fully sure what this all means. Looks like so far no one had required this, despite it apparently being a must have.

If you can explain in more detail what is expected, most likely we can add this to the next patch release.

[klongeiger]

@nebulon The way I understand it, issuing a search with

ldapsearch -b '' -s base -H ldaps://<actualhostname>:636

should return the rootDSE from the ldap server. According to specs, this should work without prior authentication as it exposes required information to the client. On our Cloudron instance, this search returns

ldap_sasl_interactive_bind_s: No such object (32)
	additional info: No tree found for: 

Running the example from the Cloudron Docs

ldapsearch  -x -b "ou=users,dc=cloudron" -D "cn=admin,ou=system,dc=cloudron" -W -H ldaps://<actualhostname>:636

works fine, the user data is returned, so the host is reachable and auth works as well. Changing the original query to include authentication returns the same error 32.

I ran the search against an open test server and it worked as expected (even though it required auth):

ldapsearch -H ldap://ldap.forumsys.com:389 -D "cn=read-only-admin,dc=example,dc=com" -W -b '' -s base        
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#

#
dn:
objectClass: top
objectClass: OpenLDAProotDSE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

The actual problem is that the opendirectoryd process on the client interprets the error 32 reply as an unreachable server, even if the actual user data would be available.

The release notes for Cloudron 7.2 lists "respond to rootDSE" under Various fixes, so I assumed that the fix didn't work for our specific instance and hoped that there was a way to fix the (probable) configuration error on our end manually.

[nebulon]

@klongeiger ah right, this was only implemented for the ldap server, which is serving the apps installed on that Cloudron. Looks like you are referring to the user directory feature, which exposes LDAP features to the public. That however is a different ldap server internally and does not have the rootDSE implemented. I will add that for the next release then.

[nebulon]

I have now added rootDSE support for the directory server (the exposed LDAP) as well in https://git.cloudron.io/cloudron/box/-/commit/6d8c3febac04e20141719174ca2a2cb76ecab9eb

Will be part of next patch release then. The example to run is:

# ldapsearch -b '' -s base -H ldaps://my.<cloudron.com>:636 -x
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#

#
dn:
objectclass: RootDSE
objectclass: top
objectclass: OpenLDAProotDSE
supportedLDAPVersion: 3
vendorName: Cloudron LDAP
vendorVersion: 1.0.0

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

[klongeiger]

That's great! Thank you very much.