I totally understand the caveats, and this discussion is just what I was hoping to get to with the ask. I think that it being the user's responsibility to configure group mappings if they want to use that feature is a very reasonable approach that strikes the right balance of maintainability and functionality. It's worth noting to people that it's an advanced thing you should only be working on if you know what you're doing and that it's not something that Cloudron can or should support beyond basic information about how the LDAP server side works.

A lot of this varies app-to-app, and frankly, I think it's appropriate to leave the nuances of the choices a user might make about how those apps behave to said user. Some apps are super powerful here, like Metabase, which can basically automate all of the role/group assignments for you if configured right, ranging all the way back to EspoCRM, which is basically non-existent in its support for group mappings besides basic login filters, which is already better handled by Cloudron anyway, and plenty of others like osTicket that are somewhere in between.

I think good points have been raised about the security concerns and sync issues, and it's worth making it clear where the line is on what's provided vs. what's possible. Furthermore, as packages update into the future and more support for group mappings is added, it would be unreasonable imo to expect Cloudron packages to anticipate everyone's preferences/needs. Patterns of use will vary hugely based on how the systems are deployed and by whom. The points above all sounds like you've gotten a pretty clear idea over the years of this one coming up about how to equalize the flexibility and clarify the boundaries for expectations with such a feature, all of which sound exceedingly reasonable, whether groups are implicitly all LDAP or explicitly configured in or not (minor detail to my mind).

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