@David-0 the Service Account Username should be set to cn=admin,ou=system,dc=cloudron and Service Account Password should be the Bind password.
There are two separate LDAP servers - internal one and an external one. The external facing one can be authenticated against by the one and only "virtual admin user" i.e the admin CN above. Cloudron admin and Cloudron users don't have the permissions to search for other users in the external facing server.
Got it. Thank you so much for the update. Sorry about my mis-perception/understanding of the tone. Thank you all for the great support you provide us all!
@adisonverlice2 ah, I see, thanks. So, intent of Cloudron's Directory Server is not to replace/compete with AD. It's just a way for apps to authenticate. It's not meant to replace a full blown LDAP like manage user profiles (pictures), groups, organization trees etc.
@nebulon It took a while to look into it - on my external facing URL it was my proxy & firewall that was blocking it. I switch to using the local IP & changed the Base DN as you mentioned & it is now pulling in users.
Thanks for your help!
I think some products expect LDAP data to be structured in a certain way ("schemas"). Not sure what pfsense expects to exist in LDAP. Maybe they are supporting OpenLDAP or something?
@fbartels thank you very much for this important point. In my answer I completely forgot to point out the potential pitfalls of already existing external apps. So @pbischoff in your requirements concept you should take a closer look at the needs of the external apps. The moment they need something specific like office printers, pictures, phone numbers .... you are lost with the built in LDAP directory server.
@TomsFreitas an idea is to then check cloudron server logs.
LDAP logs are suppressed by default. For this:
Edit /etc/systemd/system/box.service
Find the Environment= line. Change "DEBUG=box:*,connect-lastmile,-box:ldap" to "DEBUG=box:*,connect-lastmile"
systemctl daemon-reload
systemctl restart box
Now, maybe something appears in /home/yellowtent/platformdata/logs/box.log .
@sufian-mughal Currently, this is not possible. This is because LDAP has no standard way of passing through LDAP information.
That said, usually apps are able to enable 2FA independently of LDAP. This means that users manage 2FA inside the app instead of Cloudron - it works this way for GitLab/Gitea etc for example.
For matrix, upstream is still working on it - https://github.com/matrix-org/matrix-spec-proposals/pull/1998
I think there may be an issue in the mapping between the Synology LDAP and Cloudron LDAP If you look at the first screenshot provided by imc67, we have the option to select which LDAP profile to use. If you use the standard profile, you immediately run into the issues that imc67 described. However if you change the profile to custom (see screenshot below), everything checks out fine except for the "Check server schema" which goes away if one enables CIFS plain text authentication. But then you still get stuck when the Synology tries to join the Cloudron directory.
[image: 1744372954639-4e73954b-31d8-4432-a657-ccab1fd989ca-image-resized.png]
[image: 1744373380929-e85d7121-05fd-4a61-9082-c2ff648d3252-image-resized.png]
[image: 1744373443601-809c7691-aae3-4fc0-bfe8-cec2cc30507f-image-resized.png]
I'm trying to find the logs on the synology to get more details.
Here are the synology docs for how to join a Synology NAS to an external LDAP directory: https://kb.synology.com/en-me/DSM/help/DSM/AdminCenter/file_directory_service_join?version=7
