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.

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

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.

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

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

Cheers.

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.

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...

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.

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.

As this thread still pops up in searches, I find it still worth to make my annotation on it.
In my case, it is a fedora 20 system authenticating against old fashion NIS (NIS/YP).
While in normal operation, declaring nis for passwords lookup in /etc/nsswitch.conf and the respective /etc/yp.conf to declare the server, at the moment the user password was about to expire he issued the paswd command, and got the feared "Authentication token manipulation error" - not even being asked to input his old password, much less the new.

The solution was to modify /etc/pam.d/system-ath to include nis as part of the password configurations, such as:
password sufficient pam_unix.so sha512 shadow nis nullok try_first_pass use_authtok

In this case, declaring nis just solved the issue (no need to restart/reboot anything).

In general, any misconfiguration of NIS/YP or a network outage can lead to this error.