the only thing I changed, after it was not working, was the servername in the general-settings, from an UUID to the fqdn, in the hope it would be better. that's all.
sorry, I double thought of that also, but no, I haven't. I remember that after creating the instance I did set up my usual admin account & then had to add my personal user-account manually, I assumed there was no LDAP-connection (like wallabag), but did'nt check on it due to timely-restrictions. (means also NO time to fiddle with the setup)
only after I added more users to it I checked for an LDAP-plugin and saw it is existent, but was not working. also - due to timely-restirctions - not investigating why it didn't work out of the box.
since I had some time now, I started investigating, especially, since I had to create more and more user-accounts all way long, as the provided media gained on interests.
after 35 years of systemadministration, I know, sometimes unexplainable things happen – it's just not always straight forward as it everyone would suspect.
What I would like to do is that if I try to login to a new WP installation with the cloudron super-administrator user, an administrator user will be automatically generated in WP with my Cloudron access data. And if I enter as a common Cloudron user in WP, a user will be generated with their Cloudron access data with the role that I configure in the ldap plugin.
In this way, if I also changed my login details in Cloudron, it would also change on all WP sites.
This would also be good with the rest of the applications. It would simplify things a lot.
@girish Yes, it does appear to pass the correct credentials, and the function in question seems to give no error. I'll try to debug further on the app side, but for now I think we can just file this as an unexplained weird thing 🤷
This appears to be someone/bot trying out common usernames in one of your apps. Unfortunately this is not too uncommon, but also not an a real issue if you have strong passwords. The requests will be rate-limited as well to prevent proper brute-force attacks.
The internal IP is associated to an app, it may or may not change when an app is restarted. However the ldap logs might indicate there are multiple apps configured to use LDAP. The port is actually dynamic per request, so that is the reason why it does not show in docker ps/inspect
I think there's a genuine case in the future where if we introduce per-app admins, then app admin can access terminal of one app to see traffic (and sniff ldap/db creds) of another app. I think it's an excellent suggestion to remove it!
I didn't thought of any specific LDAP server. It would be great to connect Cloudron to any external LDAP server, that would manage groups and users. For example, connect a Cloudron server to another one so that only one Cloudron server manages the users and groups for both servers.