"passwd: Authentication token manipulation error"

Neowulf · 09-30-2004, 02:10 AM

Hi all,

I've been combing the forums for the past hour and I can't seem to find a solution to this issue which has been plaguing me since I installed the OS.

I'm currently running Enterprise Linux ES 3.0.

I create accounts without issue, but when clients first log in and attempt to change their passwords (using passwd), they recieve the following errors:

[foo@linux]$ passwd
Changing password for user foo.
Changing password for foo
(current) UNIX password:
New password:
Retype new password:
Password has been already used. Choose another.
Password has been already used. Choose another.
Password has been already used. Choose another.
passwd: Authentication token manipulation error

This occurs with *every* user I create. I can go back and manually set their password via root, but this isn't a decent log term solution.

The permissions on my /etc/passwd file:
-rw-rw-r-- 1 root wheel 1812 Sep 30 15:50 /etc/passwd

The permissions on my /etc/shadow file:
-r-------- 1 root root 1443 Sep 30 16:00 shadow

Any suggestions on this would be greatly appreciated.

SciYro · 09-30-2004, 02:16 AM

i get the same error, i assume its because the user cant write to the files were the passwords are stored

Neowulf · 09-30-2004, 02:20 AM

Yes, the thought had crossed my mind - but it seems pretty dumb to me to allow users free access to write directly to the passwd file.

I thought that passwd provided a mechanism for users to change their passwords without giving them direct write access to the file.

Thanks for the thought though.

SciYro · 09-30-2004, 02:33 AM

no, a user would have to write to the given file for it to take effect, you could however setup some sort of daemon or whatever to handle password change request ....... theres probably some sort of program if you look

btw.. if it might become a problem, then ill assume your constantly adding new users, so your probably using some sort of server with your computer, maybe check in on other ways to handle users if this is the case

Neowulf · 09-30-2004, 02:37 AM

Thanks for the advice, I'll look into it.

Cheers.

scuzzman · 09-30-2004, 07:43 AM

Does a user have write access to /etc/passwd or /etc/shadow?
One would think they'd not have access to either. If they did, what would keep them from:

cat /dev/null > /etc/shadow

There might be a file somewhere (*shrug*) that makes the passwords expire that could be misconfigured.

Neowulf · 10-03-2004, 08:03 PM

Hey all,

Well after hunting the internet without luck for about a week, I finally decided to do things the old fashioned way... through trial and error.

I eventually worked out this:

When you edit the /etc/pam.d/system-auth file and modify the following line, you'll break the users ability to modify their own passwords...

Code:

password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow remember=5

Once I removed the "remember =5" part from the end of the line, users were able to set their own passwords again.

This of course means that users are able to set their passwords to the ones they used previously (which blows... ), but it appears to be the *only* way I can make this work.

I just thought I'd post this up to hopefully save some time for some other poor smoe

If anyone has any ideas how I can get password history working "correctly" I'd love to hear it.

**UPDATE**

After some further research, I finally have the answer to this issue. I found that you have to manually create the /etc/security/opasswd file to store the old passwords.

If you fail to create the file when enabling password history, the feature breaks.

I've created the file now and everything works fine.
Hope this helps.

Wollongong · 06-21-2009, 07:23 PM

Long after the original message, I know, but ..

The same error message can occur if likewise-open has been installed, to
allow authentication via a remote authentication server.

In this case, you can no longer change any local users, presumably if the AD server doesn't permit changes from clients. I assume this is a bug in likewise-open, because you should still be able to change the local user's passwords.

Even if you leave the AD domain, using "sudo domainjoin-cli leave", and
reboot, you still get the error. The problem is cleared if you
remove the package 'likewise-open' and reboot.