Thing is some apps store the email (just like they store username) in the database. This means that when you change the email in Cloudron, it doesn't change in the app (depends on the app). So, just to keep things easier across apps, we decided to keep login username based as much as possible (since in Cloudron, you cannot change the username, we don't have a problem).

Even if we could just get LDAP groups working with Nextcloud that'd be a big win imho given how many of us use Nextcloud (I think I'm correct in assuming it's the 2nd most popular app on Cloudron?)

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

@nebulon said in Extra fields in LDAP:

The phonenumber for Mattermost is one such use-case, but that can be also solved without custom fields.

Assuming there might be a need for this in the future - what was the solution you thought of?

Also, even if app's don't use the fields, just having the Cloudron User directory more fleshed out might be a good thing for reference sake.

@nebulon nice i like this sort of reply 🙂

Yup, saw that! It's on my todo list now to update peertube accordingly.

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

This is implemented in 5.4

Yes those log lines indicate a login attempt by an app. Each app makes the requests on the Cloudron local network. So different IPs indicate different apps.

In your case it looks like someone/bot tries to login to some or your apps.

@nebulon said in Does anybody use the plugin LDAP write in Nextcloud ?:

That is correct, our ldap server does not allow any modification or writes to the user directory.

that is smart, because it is so easy to mess with LDAP

I will lock this thread in favor of https://forum.cloudron.io/topic/2189/ldap-ad-server to not divert the discussion

@YurkshireLad We don't use an external LDAP server ourselves but our customers use Active Directory or Okta often.

OpenLDAP should work well with Cloudron's integration though.

Merci beaucoup!

@xavierl I have pushed a new version of synapse that allows matrix to manage it's own users. If you re-install synapse, you will see this option.

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!

The latest LAMP app now has LDAP addon enabled. For existing installations, LDAP will still be off (sorry).

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.

There was some more discussion on this happening at https://git.cloudron.io/cloudron/box/issues/69

Short answer, we won't add this for now as apps use user groups in too many different ways and a mapping will be very complex and confusing.