How can I change passwords on a Linux NIS master?
As you've discovered, you cannot use passwd
as root on a NIS Client to change users' passwords on the NIS server. This is really common sense security.
Similarly you've discovered that yppasswd requires the root password (on the NIS server) before it will let you change a user's password. This is an additional bit of security predicated on the fact that you should be the NIS admin (root on the NIS server) to go about changing other people's passwords.
Unfortunately that bit of security isn't what you want, so yppasswd is getting in the way here.
I think this is actually a relatively new thing, or an OS-specific variant -- back in my Sun Admin days when I dealt with NIS regularly
yppasswd
just trusted you if you were root on the NIS server...
Because of your requirement (letting authorized admins make changes to NIS passwords) What I would suggest doing is writing a shell script (or language of your liking) that edits the NIS maps directly and rebuilds/pushes them.
You can do this with a little creative sed
work, and then grant your admins the ability to run that script using sudo
.
Ultimately though you probably want to consider moving away from NIS (LDAP is the new hotness for replacing NIS, pretty much a drop-in replacement, and WAY easier to manage).
Related videos on Youtube
asciiphil
Professional Linux and network administrator for more than a few years now. Currently wrangling RHEL derivatives, Fedora, and VMware, but still with a preference for Debian.
Updated on September 18, 2022Comments
-
asciiphil almost 2 years
This seems like it should be simple, but if it is, I must be missing something. I have a Linux NIS master from which I would like to be able to change users' passwords (in cases of forgotten passwords and similar things), but I can't.
Some details: I'm running Scientific Linux 6.4, with ypserv-2.19-26, ypbind-1.20.4-30, and yp-tools-2.9-12. NIS is configured to use
/etc/yp/passwd
for its passwd map (i.e. not the system passwd file). The system is a client of itself andypwhich
returns "localhost".Because unprivileged users should not be logging in to the NIS master, we have the following set in
/etc/nsswitch.conf
:passwd: files compat
and this at the end of
/etc/passwd
:+::::::/bin/false
In addition,
/etc/pam.d/passwd
contains the standard RHEL directives:password substack system-auth
/etc/pam.d/system-auth
is a symlink to/etc/pam.d/system-auth-ac
, which contains:password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so md5 shadow nis nullok try_first_pass use_authtok password required pam_deny.so
(As a side note, we're using md5 instead of sha512 because we have some Solaris clients that don't support sha512.)
If I run
passwd
as root, it prompts me for the new passwd, but then fails to change it:$ sudo passwd phil Changing password for user phil. New password: Retype new password: NIS password could not be changed. passwd: Authentication token manipulation error
The log file (
/var/log/secure
) is unhelpful:passwd: pam_unix(passwd:chauthtok): password not changed for phil on ypmaster.domain.tld
If, instead, I run
yppasswd
, I can change the password:$ sudo yppasswd phil Changing NIS account information for phil on ypmaster.domain.tld. Please enter root password: Changing NIS password for phil on ypmaster.domain.tld. Please enter new password: Please retype new password: The NIS password has been changed on ypmaster.domain.tld.
But that requires any sysadmin who needs to reset a password to know (or look up from our locked password safe) the system's root password, which is a scenario I'd like to avoid.
So how do I need to configure the master to allow us to change user passwords without having to type the system's root password every time?
-
EEAA almost 11 years+1 for LDAP recommendation. So much simpler than NIS.
-
asciiphil almost 11 yearsYeah, we just transitioned from a Solaris 10 master to the Scientific Linux master and this behavior was something of a surprise. I wrote a simple script that's handling everything for us, and LDAP's been on our horizon for a while but other projects have been taking priority.