Linux NIS "Authentication token manipulation error"

[Steve Bonds]

Forum-dwellers:

I'm having an interesting time getting NIS password changes to work on RHEL 5.3. When I try to change one using "passwd" I get the error:

Changing password for user applic.
Changing password for applic
(current) UNIX password:
New UNIX password:
New UNIX password:
passwd: Authentication token manipulation error

(Yes, I'm sure that I'm entering the correct current password first since I know that this simple mistake can cause the same error message to appear, albeit earlier in the output.)

Here are the details of the PAM/NIS configuration:

1) NIS server IP/name added to /etc/hosts

2) /etc/yp.conf changed to

domain server

3) /etc/sysconfig/network changed

NISDOMAIN=

4) ypbind added to auto-start

# chkconfig --level 345 ypbind on

5) "compat" entries added to /etc/passwd and /etc/group

6) /etc/nsswitch changed to:

passwd: compat
shadow: files
group: compat

(I suspect that the "shadow" entry may be part of the problem-- more on that later.)

7) Add netgroups to /etc/security/access.conf

8) Change /etc/pam.d/system-auth

password sufficient pam_unix.so md5 shadow nis nullok try_first_pass use_authtok

-----

Some interesting tests I've run:

1) add "audit" to /etc/pam.d/system-auth line

This gives some more detail in /var/log/secure, but not enough to troubleshoot the problem. For example when changing the user "applic":

passwd: pam_unix(passwd:chauthtok): username [applic] obtained
passwd: pam_unix(passwd:chauthtok): username [applic] obtained
passwd: pam_unix(passwd:chauthtok): password not changed for applic on

2) Removing "md5 shadow" from the system-auth config allows the NIS password changes to work, but the local root account now has an old-style crypt() based password in the /etc/shadow file.

How can I set things up so that:
1) users in /etc/passwd keep an md5 shadow password
2) NIS users can change their passwords via NIS

Thanks for any help.

-- Steve Bonds

[Steven E. Protter]

Shalom Steve,

Note: HP-UX systems with trusted system won't NIS authenticate to RHEL NIS master.

The root account should not be handled via NIS. You need to be able to get on root with the system in single user mode.

if you exclude root from this configuration you may be okay using md5 shadow. shadow by itself is not so bad though.

SEP

[Steve Bonds]

>Note: HP-UX systems with trusted system won't
>NIS authenticate to RHEL NIS master.

Noted. In this case the NIS master is an HP-UX system, but I've seen no signs that there's a problem on that end.

>The root account should not be handled via
>NIS. You need to be able to get on
>root with the system in single user mode.

Agreed! In fact, that's really my question...

>if you exclude root from this configuration
>you may be okay using md5 shadow. shadow by
>itself is not so bad though.

How would I exclude root from the configuration? Ideally, I'd like to exclude all users who exist in /etc/passwd, but I'll settle for root if that's all I can get...

Thanks again,

-- Steve Bonds

[Stephen P. Schaefer]

On the RHEL client in /etc/nsswitch.conf, put

passwd: files nis

This will cause the system to prefer the local password and shadow files over the NIS server. If and only if the account does not appear in the files, then it will consult the NIS server. The root and utility accounts should be in the files; users will typically be in the NIS map; for 3rd party applications, it's your judgement call, depending on, among other things, whether the account should be available to every machine in the NIS domain and on whether the 3rd party application install procedure creates the account in the local passwd/shadow files.

[Steve Bonds]

> On the RHEL client in /etc/nsswitch.conf, put

> passwd: files nis

> This will cause the system to prefer the
> local password and shadow files over the NIS
> server. If and only if the account does not
> appear in the files, then it will consult
> the NIS server. The root and utility
> accounts should be in the files; users will
> typically be in the NIS map;

This is the config I'm using-- perhaps it's already working as expected. I will admit I have not yet done an actual simulated network outage to verify that the root account is still accessible...

[Steven E. Protter · Accepted solution]

Shalom Steve,

Nice first name.

Noted. In this case the NIS master is an HP-UX system, but I've seen no signs that there's a problem on that end.

This is the only way to go with NIS. HP-UX can't function with a Linux master if the master is using the default shadow password configuration.

This issue may be due to issues with Linux NIS. I'd be satisfied however calling it a day and pulling back the md5 option.

SEP

[Steve Bonds]

> Nice first name.

I agree!

> This issue may be due to issues with Linux
> NIS. I'd be satisfied however calling it a
> day and pulling back the md5 option.

That's pretty much where I'm ending up. I'll check that I can log in fine without a network, but otherwise I'll just stick with local crypt() style passwords while forced to use NIS. Clearly those will not be the weak link in system security! :-)

Thanks again for the help, everyone!

-- Steve