Server: write for user_ldap

[pierreozoux]

Currently, the user_ldap application is able to read an ldap server.

At IndieHosters, we use Nextcloud as our center piece for hosting and as a control panel.
(We even forked the shop, to add our own items, like WordPress hosting).

One feature that is missing for us is the possibility to let our users, manage their organization. For this, there is not much nice ldap webui (no, ldapmyadmin is not an option).

If the user_ldap application would allow to also write ldap, this would be amazing for us.

[MariusBluem]

@blizzz

[blizzz]

@pierreozoux We have no plans or intentions to integration write support into the LDAP backend. However, we provide the ILDAPProvider Interface. Using this you can create an application that benefits from existing configurations and also gives you an LDAP link (via its getLDAPConnection() method), so it should be fairly easy to create an app taking advantage of it. I hope that helps.

[jancborchardt]

@MariusBluem please don’t close the issue – this is a valid request and even though it’s not being actively worked on, anyone could pick this up. :)

@pierreozoux @blizzz wouldn’t a great integration be if the people from LDAP could be edited just as the other people from the users management? There doesn’t need to be an entirely new app created for it.

[MariusBluem]

@MariusBluem please don’t close the issue – this is a valid request and even though it’s not being actively worked on, anyone could pick this up. :)

I did not close it because of I think it isnt a valid request ... @blizzz pointed out, that it should/could be created as part of a new app - so no need to keep this issue open over here? @jancborchardt

@pierreozoux @blizzz wouldn’t a great integration be if the people from LDAP could be edited just as the other people from the users management? There doesn’t need to be an entirely new app created for it.

Would be very nice 👍 Then ... we should leave this issue open 🙈😅

[blizzz]

@pierreozoux @blizzz wouldn’t a great integration be if the people from LDAP could be edited just as the other people from the users management? There doesn’t need to be an entirely new app created for it.

Typically, there is already an LDAP Management Tool in use, when LDAP is available. You can argue about adding write support for the standard fields like email… Requirement would be to have this opt-in.

One feature that is missing for us is the possibility to let our users, manage their organization. For this, there is not much nice ldap webui (no, ldapmyadmin is not an option).

Now, what exactly is meant with "manage their organization"? Our interface is very simplified compared to LDAP possibilities, e.g. at Nextcloud you can only have one email address. Also typically within an LDAP management you would edit other attributes, create organizational units, tamper with schemas etc. This would be totally out of scope, and an app of its own the proper place.

[jancborchardt]

Well – that doesn’t mean that you shouldn’t be able to edit the fields which we expose. Of course we don’t want to add extra stuff from LDAP, but simple editing of emails etc could be possible.

[alantygel]

Hi,
I'm writing this plugin: https://gitlab.com/eita/ldapusermanagement , which does this job. It uses Nextcloud hooks and user_ldap configs to :

• Create/delete users;
• Create/delete groups;
• add/remove users from groups.

I would be happy if you could test it.

The infrastructure for allowing to edit displayName and email is done. However, because user_ldap backend do not implement canChangeDisplayName, the OC\AccountManager::userUpdated dispatcher is not fired, and thus I cannot listen to this modification.

Do you have any suggestion on how to overcome this issue?

best,
alan

[blizzz]

However, because user_ldap backend do not implement canChangeDisplayName, the OC\AccountManager::userUpdated dispatcher is not fired, and thus I cannot listen to this modification.

Do you have any suggestion on how to overcome this issue?

Since the backend does not implement this method, you cannot really enforce it. Or work around it, because the user is tied to the backend. The only way that comes to my mind right now is to extend the API (you've seen \OCP\LDAP*?). I guess some sort of a plugin manager where you can register and fetch additional feature handlers would come handy for this case.

[viniciuscb]

Hi @blizzz . I work with @alantygel and I've tried to do as you suggested, an extension of \OCA\User_LDAP\User_LDAP and \OCA\User_LDAP\User_Proxy. Without change the user_ldap code, we cannot replace the backend generated by the user_ldap plugin, just append a new backend, and this don't solve our problem.

We will implement the method setDisplayName in the same way the user_ldap plugin uses to implement setPassword: we will add a new setting to enable setDisplayName, implement this in the user_ldap app and send a new PR.

[blizzz]

Without change the user_ldap code, we cannot replace the backend generated by the user_ldap plugin, just append a new backend, and this don't solve our problem.

Yes, understood.

We will implement the method setDisplayName in the same way the user_ldap plugin uses to implement setPassword: we will add a new setting to enable setDisplayName, implement this in the user_ldap app and send a new PR.

Please not, this won't scale with any other potentially, additional writing.

What I suggested is to make it possible to add plugins to the LDAP user backend.

It indeed requires:

• a public LDAP Plugin Manager (\OCP\LDAP\PluginManager) with methods to
  
  
  
  • register a type of plugin
  
  
  • fetch the types of plugins
  
  
• the user_ldap backend to read the plugins when implementActions is called and use them when setDisplayName etc. (the corresponding type) are called.
• eventually you can hook in all the write support that you want by creating a separate app for it

Given, it may look like overkill and too specific for the backend. OTOH I don't want to further bloat the LDAP backend. A design choice was to have it read only, and the API is the only connection point we can have. The setPassword feature is an exception, because LDAP policies may require to change it.

Perhaps @nickvergessen has another idea out of this dilemma?

[viniciuscb]

Hi @blizzz . We are preparing a PR proposal in the lines you suggested: structuring plugins infrastructure for user_ldap.
But now, for the createUser action inside our plugin, we have a problem, and would like to hear your opinion:
LDAPProvider offers the method getLDAPConnection, which needs an $uid. The problem is that,as we are getting a connection to create a new user, the $uid does not exist yet in any LDAP Backend, and the LDAPProvider does not return a connection.
So, we are thinking on three possibilities to solve this:

1. Make the param $uid not obligatory in LDAPProvider->getLDAPConnection;
2. Create a new public method in LDAPProvider, getAdminLDAPConnection or getLDAPConnectionForNewUser, which calls $this->backend->getNewLDAPConnection with $uid=null;
3. Leave to the plugin the task to do it's own binding to LDAP, without using the ldap_user infrastructure.

What do you think?

[viniciuscb]

We've implemented the suggestion by @blizzz . We hope it's useful ;-)

[blizzz]

@viniciuscb thank you :) I left my review, a bit of polish left, looks good in general!

[awesome-manuel]

@viniciuscb It seems the gitlab link is not valid anymore. Is your plugin still available somewhere?
I found https://github.com/KircheNeuenburg/ldaporg, but this seems to be less integrated with ldap_user than what you suggested.

[viniciuscb]

Hi, @awesome-manuel , the link have changed indeed. This is the new address:

https://gitlab.com/eita/rios/user_ldap_extended

Please keep in touch to clarify any doubts.

[blizzz]

Let me close this since write support is possible through the plugin system.