Users change password remotely?

Many NS sysadmins prefer to deny access to the Server Manager. I feel they will not change idea with Cockpit too…

I like the LDAP client approach to change the user’s password. Many (mail) applications already provide it. Maybe @webtop_team could think about it.

Definitely a dedicated web app would be a valuable module to complete the picture!

I could be wrong, but I would expect so for centralized accounts (if we were talking about user/group creation/deletion that would be a different thing, as NethServer might trigger some events for other modules). NethServer also cleans the SSSD cache after the password change.

Password policy shall remain unchanged or make self service password conf file aware of related db props. For other features, like (un)blocking users after password change, I don’t know.

I tested Self Service Password with LDAP and it seems to work, I changed my password and still could login to Nextcloud and Roundcube.

I followed these docs:

https://ltb-project.org/documentation/self-service-password/1.3/start

My /usr/share/self-service-password/conf/config.inc.local.php:

<?php
$lang = "de";
$show_menu = true;
$keyphrase = "secret123";
$ldap_binddn = "";
$ldap_bindpw = "";
$ldap_base = "dc=directory,dc=nh";
$ldap_filter = "(&(objectClass=person)(uid={login}))";
$use_questions = false;
$use_sms = false;
$use_tokens = false;
$who_change_password = "user";
4 Likes

WebTop has always supported user password change within the user session, when domain is in ldap-mode or webtop-mode, and it has always been possible since version 4 in our XStream based infrastructures.
If I well remember this feature was disabled in NS7 installations for some reason, probably because ldap users management is delegated to NS7 ldap manager or any other external one (as per the integration with AD).

I don’t see any problem in enabling this again, through any kind of new setting: if the ldap user has rights to change it, we should have ways to do it, as we already do in our clouds.

1 Like

This would make a killer module on top of NS!

IMHO it’s a matter of perspective…
Using current or future admin web interface can let the structure of the service left as is.
Implementing a new module/interface could break the structure, therefore is a project choice which way choose.
IMHO admin interface is the right tool…

When you have remote users, you currently have three options:

  • Expose the server manager to the entire Internet
  • Allow/require users to connect to a VPN in order to change their passwords
  • Do not allow users to change passwords at all

None of the options, IMO, are very good. The first requires that I expose the entire system administration capability to the Internet, protected only by what I hope is a strong password (and trusting–or hoping–that there are no remotely-exploitable vulnerabilities in it). The second requires that my (mostly non-technical) users install VPN software on their machines and configure it to connect to my server, and puts them on my home LAN where they have no reason to be. And the third means that the only way they can change their passwords is for me to do it for them, meaning I know their passwords.

By contrast, a password-change system of the sort I’m suggesting (and I do need to play with Self Service Password) avoids all these problems:

  • It only exposes the ability to change passwords (and ideally would exclude admin users)
  • Nothing needs to be installed on my users’ computers, and they don’t need to come into my network
  • They can change passwords at their convenience, making it more likely to actually happen
  • I never need to know their passwords

Simply sounds better for security all around.

Did you configure it to use the default virtual host or a separate one? Because I’m running into “Access Denied” when I add it under the default virtual host, despite having this in that virtual host’s configuration:

#
# 50selfservicepassword
#

Alias /ssp /usr/local/self-service-password

<Directory /usr/local/self-service-password>
        AllowOverride None
        Require all granted
        DirectoryIndex index.php
        AddDefaultCharset UTF-8
</Directory>

<Directory /usr/local/self-service-password/scripts>
        AllowOverride None
        Require all denied
</Directory>

(taken from their docs, but with the “IfVersion” directives removed since we know which Apache version we’re dealing with). Here’s what my log is showing:

[Mon Dec 31 16:51:53.220503 2018] [authz_core:error] [pid 9030] [client 192.168.1.199:62197] AH01630: client denied by server configuration: /usr/local/self-service-password

I agree.

I’ve played with self-service password a little more using its own virtualhost rather than the default (just editing its included virtual host config file to have my domain) and local LDAP, and the local config settings @mrmarkuz posted above (but with language set to ‘en’).

  • I confirm that it works to change the user’s password, and he can log in to Nextcloud, Roundcube, and the server manager with the new password.
  • Locked users are unable to set their passwords using this tool (not a surprise, as I understand the “lock” is accomplished using the password in some way).
  • System password policy is not respected. However, self-service password has its own password complexity settings, which could be templated to match the system policy.
2 Likes

Nice! Would you care to share your notes on this please?

TIA

ps. A fail2ban config for such a service would be welcomed.

  • Environment is a NS 7.6 VM with local LDAP accounts provider.
  • Follow the instructions here to install from the LTP repo.
  • Edit /etc/httpd/conf.d/self-service-password.conf to change ServerName to something on your domain. Also update whatever’s doing DNS for your LAN to point that name to that system.
  • systemctl reload httpd
  • Create /usr/share/self-service-password/conf/config.inc.local.php with the contents @mrmarkuz posted above (I only changed the language).
  • Browse to whatever ServerName you specified above and start changing passwords!

To do:

  • Figure out Active Directory (although this might be a less-important feature in an AD environment–users with computers joined to the domain can change their passwords that way)
  • See if it’s possible to exclude admins from changing their passwords
  • Enforce SSL for the password change
  • Agreed, fail2ban for this would be pretty much essential
  • Although the background image looks nice, maybe change that and the logo to something that better matches the rest of the neth admin stuff
  • Possibly implement reCAPTCHA? It’s another Google thing, which isn’t ideal, but it should provide a good bit of protection against automated brute-force attacks.
2 Likes

The project as default setting leave the admin interface available on red interface. I can understand and endorse the choice of not allow internet connection from all address to admin interface.

But…
All hosting providers allow to change the password from public interface.
All hosting providers allow the connection for admin interface from whole internet.

If user password should be changed from any of the application added to nethserver, there should be a write access on account providers, just like other webservices.
If there will be a separate service/interface for change password, there will be another place which should be protected by a hopely strong password. Even for root.
If the admin access is not safe/strong enough for public internet, should not be allowed access as default settings, which could be useful only for few uses/cases.

Add an application which is not 2FA IMO can only increase footprint for vulnerability without adding anything useful.
OTOH, maybe a prop for the user defining which subnet is allowed for login… Could ease the pain for Internet access to cockpit/nethgui…

True. I believe that’s a poor design decision.

To a degree, but there are significant differences:

  • With a hosting provider, everybody is remote, including the admin (the hosting provider’s customer)–and they certainly don’t expose their own administrative interface to the Internet.
  • The Neth server manager provides much more control over the system than what a typical hosting provider exposes.
  • These are separate functions, and should be treated separately. If an attacker is able to compromise an admin password, exposing the password change function means that attacker can change the password (which is certainly a bad thing)–but if the admin interface isn’t exposed to the Internet, that attacker still won’t be able to log in to it.

Yes, and that’s one way to go about it. Not ideal if only some of several web apps have the capability to change passwords (it means you can change your password for everything, but you have to use this specific app to do it), but definitely one possibility.

Why? If that interface doesn’t run as root (it doesn’t), and it doesn’t require administrative privileges to do its thing (it doesn’t; it uses the user’s credentials to change that user’s password), it wouldn’t seem to have the ability to compromise the system. I don’t see that it should need to be protected behind another password–though as I noted above, I’d prefer it not have the capability to change an admin’s password.

That wouldn’t do anything to help my use case.

Fully agree

The default virtual host with Alias (/ssp) is working. The example in the ssp documentation points to /usr/local/self-service-password but it’s located in /usr/share/self-service-password.

I couldn’t check group membership of a user but I managed to exclude the admin user (for LDAP):

$ldap_filter = "(&(objectClass=person)(uid={login})(!(uid=admin)))";

It seems not easy to check the group membership with openldap as you’ll need to change LDAP config to use memberof-overlay:

https://jupfaf.net/index.php?article22/openldap-with-memberof-overlay

The typical rewriting should be enough. Just create /etc/e-smith/templates-custom/etc/httpd/conf.d/default-virtualhost.inc/50ssp with following content:

#
# 50ssp
#
RewriteEngine On
RewriteCond %\{HTTPS\} !=on
RewriteRule ^/ssp(/.*)?$ https://%\{HTTP_HOST\}/ssp$1 [L,R=301]

Apply the config:

expand-template /etc/httpd/conf.d/default-virtualhost.inc
systemctl restart httpd
1 Like

Oops. :blush: Easy enough to fix, though.

For AD I needed to enter the admin user, ldapservice is not working. My config.inc.local.php:

<?php
$lang = "de";
$show_menu = true;
$keyphrase = "secret123";
$ad_mode = true;
$ldap_starttls = false;
$ldap_url = "ldap://ad.domain.local:389";
$ldap_binddn = "domain\admin";
$ldap_bindpw = "secret";
$ldap_base = "dc=ad,dc=domain,dc=local";
$ldap_login_attribute = "sAMAccountName";
$ldap_fullname_attribute = "cn";
$ldap_filter = "(&(objectClass=user)(sAMAccountName={login})(!(userAccountControl:1.2.840.113556.1.4.803:=2)))";
$use_questions = false;
$use_sms = false;
$use_tokens = false;
$who_change_password = "manager";

You need to disable strong auth for AD to work:

Put ldap server require strong auth = no to the global section in /var/lib/machines/nsdc/etc/samba/smb.conf and restart samba in the container with systemctl -M nsdc restart samba

EDIT:

You need to use a higher version of PHP if you want to use AD. So I had to install nethserver-rh-php71-php-fpm and put the following in the Directory statements in /etc/httpd/conf.d/self-service-password.conf

<Directory ...>
...
  <FilesMatch \.php$>
      SetHandler "proxy:fcgi://127.0.0.1:9001"
  </FilesMatch>
...
</Directory>

Hmmm, don’t much like that.

Don’t much like that either. Between these two points, if they can’t be addressed, the AD installation would be much less secure than the OpenLDAP installation:

  • It needs admin privileges to run, which give it the power to do other bad things
  • It stores the admin credentials, in clear text, in a directory that’s served to the public (which is not quite as bad as it sounds; the PHP should be parsed such that those credentials are never sent out, but still doesn’t sound like a good idea)
  • It weakens authentication for everyone using the server, whether they use this feature or not

Changed my template fragment to reflect the correct directory, and yes, it’s now working from the default virtual host. Silly me for not having noticed that myself.

Can we get any input from the devs on this? Specifically, is updating the password in either OpenLDAP or AD all that needs to be done? @dev_team?

I think this could be solved with installing a certificate in the samba container…