Cloudron Forum

That's great! Thank you very much.

@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.

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.