Users change password remotely?

Feature
11

Yes, and getting trusted certs through Let’s Encrypt is easy as well–all of which is good. But all that does is prevent some one from getting usable data by sniffing on the wire. It doesn’t stop brute-forcing a password (though fail2ban would help here), and it doesn’t protect against any vulnerabilities in the server manager.

Likewise. VPN and SSH forwarding work around the issue by making a remote user effectively non-remote, but add a step that most of my users wouldn’t know how to do.

What about the groupware apps? Horde/Sogo/WebTop–does any of them have a “change password” function, and would it work for this?

12

Yes, and that works–I can log in as a user and change that user’s password. So if I do feel comfortable exposing the server manager to the Internet, that’s a way to do what I’m looking for.

13

It would be nice to have an isolated page for users to change their password. But then again, I would never want my authentication server exposing anything to the wan.

SOGo lacks the option to change the password afaik. Outlook might be able to handle the forced change and be of use there, haven’t tested that tho.

I have read that, for implementation reasons, passwords should be changed through server manager. I would expect this not to be the case for AD account provider being used for all authentication (nor single server implementations where only mail is used by users)

14

For apps it could depend on ldap bind parameters ( write permissions)…
Horde and Nextcloud have it if I recall correctly, but never tried.

For Nextcloud with Active Directory account provider:

  • Admin > LDAP/AD integration > Advanced > Directory Settings:
  • Enable LDAP password changes per user (checkbox)
  • Default password policy DN
15

Ah, hadn’t thought about Nextcloud–and I would be running that, too. I’ll have to test to make sure it works, but that’s a possibility. Though I’d still be concerned about the “implementation reasons” @planet_jeroen mentions.

16

Maybe @giacomo can shed some light on this, I am just parrotting him from here:

1 Like
17

I agree. But there are thousand of services which allow change of passwords throught the internet. Consequently, it’s still not the safest choice, but for me a safe enough one.

18

Indeed, which is what I’m wanting to do as well. But I expect most of them keep their overall administration interface much more locked down.

19

I don’t know if Cockpit implementation would change anything in this regard.
Otherwise, would something like this be a viable solution?

1 Like
20

Looks very nice, and the existing RPM is a bonus. Besides, I’m kind of Java-phobic. Would changing the password via the LDAP backend be the only thing that would be needed?

21

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!

22

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.

23

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
24

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
25

This would make a killer module on top of NS!

26

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…

27

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.

28

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
29

I agree.

30

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