Nethserver-delegation needs testers

what do you mean ?

you must trust the user with the delegation :slight_smile:

please what is buggy, what enhancements we can bring

Excuse my English is so bad.

First: is that the delegated user can change admin account settings, how is posible to block the admin account so the delegated user can not touch the admin settings.

So I can delegate safely to a user to add and delete acounts for mail (is an example)

The bug was the browser, I changed de URL adress from zero, and now is working so well.


How can we move modules like this out of “testing” stage? So we can call them “stable” and close this topic?
@dev_team any hint?

not (yet) possible, I just change the Json authorisation of nethgui, you use all the official modules but delegated to your user. In fact it could be a new feature request that the admin & the administrator users are not deletable however this modification is out of my hand, because there are official modules.

I think moving the package in nethforge repository ( should be enough.

new version of nethserver-delegation

yum install

the new features are

* Sat Sep 09 2017 stephane de LAbrusse <> 0.1.7-1.ns7
- ldif file creation with a random name
- chmod ldif file 0600
- remove the key name when the user/group is deleted

* Fri Sep 08 2017 stephane de Labrusse <> 0.1.6-1.ns7
- Automatic activation of the shell access if the sudo power is enabled

Now when you set the sudo privilege, automatically you activate the user’s shell access, it works but I would confirm it on several servers before to release it.

Kudo to @mrmarkuz


Awesome! I can confirm that it works on 2 of my Nethservers. :+1: But it only works in one direction: Enabling sudo changes users shell to /bin/bash, but disabling does not change it back. A user sudoenabled once has SSH access forever, even if disabling sudo. So I think what’s missing is the possibility to change SSH access in “Users and Groups”. So delegate module would be able to revert to the default setting in “Users and Groups” but may override it when user is delegated. Just in idea…

1 Like

Yeah it is the official behaviour, if the shell access is allowed to a user, you cannot remove it when you use the samba AD accoount provider, or you must delete the user and recreate it.

It makes me think that it is something not finished @dev_team

Indeed I could remove the bash access myself in the module, or wait to see if a PR is needed in the core

1 Like

This would be the fastest solution and ok for me, but when I really think about it the best approach would be to change it in “Users and Groups” module, because it is not logical or intuitive to say: "When creating a user you are able to set SSH access once, but for disabling you have to install another module."
Another approach would be to have the ability to change SSH access only in your delegation module…so a newly created user has no SSH access per default. Again just ideas…

It’s the desired behavior, since we do not want to directly edit the AD using any LDAP client.
Actually it is a limitation of samba-tool.

By the way, I just added a card to NethServer project, but we need to review it and decide if it worth implementing it.


Please more tests needed also with openldap (nethserver-directory)

1 Like

Did another test with Samba AD(ldap will follow) and noticed just 2 points:

  • A not sudo delegated user gets a “403 - Forbidden” error window, when entering NetworkAdapter page. I had to close the error window. Clicking OK shows the error again.
  • If you logout a delegated user, the url is kept, and if you login with a not delegated user for that specific page afterwards you get an empty “403 - Forbidden” page. Maybe redirect users to profile page per default?
1 Like

good catch the ‘Admin todo messages’ must be delegated also, probably I need to delegate it by default. WHen you delegate all panels you don’t have this bug (because ‘Admin todo messages’ is delegated)

1 Like

Un message a été déplacé vers un nouveau sujet : Redirect the user logout to the Dashboard

new version of nethserver-delegation

yum install


* Mon Sep 18 2017 stephane de LAbrusse <> 0.1.8-1.ns7
- Allow Admin todo by default
1 Like

Works as expected! :ok_hand:
Maybe put away the admin todo messages checkbox in module user settings, because now it has no function anymore…
Another thought: Some admin todo messages may include a link(i.e. Check Firewall rules) to a not delegated module -> 403 forbidden error

1 Like

do you have an example that I can reproduce please

I deactivated the firewall to produce an admin todo message:

When I now click on “Check firewall rules” I get a 403 error, because it links to /FirewallRules/CheckRules:

1 Like


When having delegation to Firewall Rules, you won’t get the 403 error, so there are delegations that depend on others.

[root@testserver ~]# cat /etc/nethserver/todos.d/* | grep url
            "url": '/NetworkAdapter?renameInterface'
            "url": '/NetworkAdapter'
            "url": '/Account'
    msg = {"action": {"label": _('Change password strength'), "url": '/Password'}, "text": _('Password policy is too weak'), "icon": "warning"}
            "url": "/BackupData"
    msg = {"action": {"label": _('Check firewall rules'), "url": '/FirewallRules/CheckRules'}, "text": _('The firewall is NOT running'), "icon": "exclamation-triangle"}
    msg = {"action": {"label": _('Deep Packet Inspection (DPI) module is not available'), "url": '/Shutdown'}, "text": _('Restart the system and select a Linux kernel with DPI module support'), "icon": "refresh"}
            "url": '/BackupConfig#!BackupConfig_Reinstall'
            "url": '/BackupData'

So Admin Todo, NetworkAdapter, Account, Password, BackupConfig, BackupData, FirewallRules and Shutdown are a “delegation group”.

I changed on my testserver from AD to LDAP, gave new passwords and delegations are working as good as with AD.

These rpms are on Steph repositories, so I’d like to set up a process to

  • define them “stable” enough
  • close a topic like this
  • announce that NethServer has a delegation module :slight_smile:

What do you think guys?