@girish 👍🏻

Without being able to debug this further, for a start, the filter seems wrong. The Cloudron provided user records would have the following objectClass attribute:

objectclass: [ 'user', 'inetorgperson', 'person' ]

so use one of those three entries there. Also Cloudron has no attribute uidNumber maybe using entryuuid works there though.

That's great! Thank you very much.

@nebulon Thanks a lot for the info. I'm going to try it out when I have some spare hours left this week.

I'll report back.....

@nebulon Issues solved it was my issues by doing wrong LDAP Filter.

@nebulon can you maybe have a look into the other thread, I am a bit stuck but it would be important to get this right for a porject of mine.

@girish wait ... true 🙂
6a136902-e13f-47d9-b8be-68193a8688b4-image.png

@girish
ok, thanks I will open a ticket with them for a MySQL issue with pixeldroid.

@girish happy to report that this is working like a charm, thanks a lot!

@nebulon Would be great to see this in Cloudron 8 🙂 In combination with Nextcloud Group Folders this would give any admin a huge flexibilty in terms of rights and role models.

@nebulon

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.

hab's gut derweil
cheers
günter

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.

This is possible?

@briankb-0 NodeBB FTforumW. 👍

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.