Passwd: Authentication Token Manipulation Error Passwd: Password Unchanged

The error “passwd: authentication token manipulation error” usually appears when a Unix or Linux system cannot update a user’s password, while “passwd: password unchanged” means the password was not changed. These messages can be frustrating, especially when you believe the new password is valid, but they often point to account locks, expired credentials, PAM configuration problems, file permission issues, or network-based authentication systems such as LDAP or Active Directory.

Introduction

The passwd command is used on Unix-like systems to change or manage user passwords. When it fails, the system may return messages such as:

• passwd: authentication token manipulation error
• passwd: password unchanged

These messages are common enough that many system administrators see them during routine password management. Still, they can have different causes depending on the operating system, authentication backend, account status, and PAM configuration But it adds up..

Understanding the difference between these two messages actually matters more than it seems. “Authentication token manipulation error” usually means the system tried to change the password but failed at a lower authentication or system level. “Password unchanged” usually means the password update did not happen, either because the new password matched the old one or because the system rejected the update.

What “passwd: authentication token manipulation error” Means

The phrase authentication token manipulation error is a generic error returned by the passwd utility when it cannot successfully modify the user’s authentication credentials Simple, but easy to overlook..

In simple terms, the system did not complete the password update.

This can happen even when:

• The old password is correct.
• The new password meets the policy requirements.
• The user is allowed to change their

Why the “authentication token manipulation error” Shows Up

When the passwd utility finishes its internal checks, it hands the new credentials over to the kernel via the authentication token. If any component in that chain refuses to cooperate, the kernel returns EPERM (Operation not permitted), which the passwd wrapper translates into the generic authentication token manipulation error. The most frequent triggers are:

1. Account lockout – a locked user (e.g., usermod -l <user> -U <user> or a failed‑login lock) is denied any credential change. The lock is recorded in /etc/shadow with a ! or * at the beginning of the password field.
2. Expired password – the chage database marks the account as expired (expired flag). Even if the user supplies the current password, the system refuses to write a new one until the expiration is cleared (chage -E).
3. PAM module rejection – modules such as pam_pwquality, pam_unix, or pam_tally2 can abort the operation. To give you an idea, pam_pwquality may deem the new password too weak, or pam_tally2 may have reached a maximum failed‑login threshold, causing the whole PAM stack to return a failure.
4. File‑system permission problems – /etc/shadow must be writable by root. If the file’s mode is reduced (e.g., chmod 644 /etc/shadow) or the filesystem is mounted read‑only, the kernel cannot update the password entry, leading to the same error.
5. Security‑module interference – SELinux or AppArmor policies that deny the passwd process the write attribute on the shadow file will surface as a token manipulation failure. Checking audit logs (ausearch -m avc -ts recent) often reveals the denial.
6. Corrupted shadow database – a malformed line in /etc/shadow (missing colon, stray characters) prevents the kernel from parsing the entry, causing the update routine to abort.

In network‑centric environments, the same symptom can arise when the local PAM stack forwards the request to an external directory service (LDAP, AD, SSSD). A failed bind, missing write permission on the remote entry, or a schema violation can all surface as a token manipulation error Simple as that..

When “passwd: password unchanged” Is Reported

The opposite message indicates that the passwd command completed its internal validation but did not actually modify the password field. Typical reasons include:

• Password reuse – the new string matches the previous password, and the password‑history module (pam_pwhistory) rejects the change.
• Policy mismatch – the new password does not satisfy the complexity rules enforced by pam_pwquality (length, character classes, dictionary checks).
• Account expiration – an account marked as expired cannot have its password altered until the expiration date is removed.
• Shadow file lock – another process (e.g., a backup script that has the file opened with O_RDONLY) holds an exclusive lock on /etc/shadow, preventing passwd from writing the new entry.
• User’s UID range – on systems with UID‑range restrictions (e.g., useradd -U), a non‑privileged user may be denied the write operation, resulting in a silent failure.

Systematic Troubleshooting

1. Verify account status

   sudo chage -l 
   

   Look for “Account expires” or “Password last change”. If the account is locked or expired, resolve the condition first (usermod -U <user> or chage -E) Small thing, real impact..

2. Inspect /etc/shadow permissions

   ls -l /etc/shadow
   

   The file should be owned by root:root with mode 640 (or 600). If it is not, correct it with chmod 640 /etc/shadow and ensure the filesystem is writable.

3. Review PAM configuration

   • Open /etc/pam.d/passwd and confirm that pam_pwquality.so (or the relevant module) is present.
   • Temporarily comment out restrictive modules to see if the change succeeds, then re‑enable them with adjusted parameters.

4. Examine system logs

   sudo journalctl -u shadow.service   # systemd‑based logs
   sudo grep passwd /var/log/auth.log   # traditional logs
   

   Look for entries that indicate “authentication failure”, “PAM: authentication error”, or “permission denied”.

5. Check for SELinux/AppArmor denials

   sudo ausearch -m avc -ts recent | grep passwd
   sudo aa-status   # AppArmor status
   

   If a denial appears, adjust the policy (setsebool, audit2allow, or AppArmor profile edit) and retry It's one of those things that adds up..

6. Test with a minimal command

   sudo passwd -l    # lock the account (just to see the error)
   sudo passwd       # attempt change again
   

   If the error disappears, the previous failure was likely due to a transient lock or a PAM rule that only applies after a certain state.

7. Network authentication checks (if applicable)

   • Verify LDAP/AD connectivity: ldapsearch -x -D "cn=admin,dc=example,dc=com" -w secret
   • Ensure the user’s UID/GID mapping on the server matches the one stored in the directory service.
   • Confirm that the remote directory allows write operations on the password attribute (e.g., pwdLastSet in AD).

Practical Example

A sysadmin receives passwd: authentication token manipulation error after attempting to change a password for a service account. Investigation reveals:

• The account’s password field begins with !*, indicating it is locked.
• /etc/shadow permissions are 600, owned by root.
• SELinux is enforcing, and the audit log shows type=AVC ... denied { write } for pid=1234 comm="passwd".

Resolution steps:

1. reach the account: sudo usermod -U serviceuser.
2. Restore correct SELinux context: sudo restorecon -v /etc/shadow.
3. Retry the password change; it succeeds.

Conclusion

The messages “passwd: authentication token manipulation error” and “passwd: password unchanged” are distinct symptoms of different failure points in the password‑change pipeline. The former signals a breakdown before the actual credential update — commonly caused by locked or expired accounts, PAM rejections, permission problems, security‑module denials, or corrupted shadow files. The latter indicates that the command reached the final write stage but was blocked by policy, history checks, or external locks.

By systematically checking account status, file permissions, PAM configuration, security‑module logs, and, when relevant, remote directory connectivity, administrators can pinpoint the root cause and restore normal password‑change functionality. Once the underlying issue is addressed, the passwd command will complete its task without further error messages Simple, but easy to overlook. And it works..