When working with mixed authentication environments (local users + MS-AD via Kerberos/LDAP), administrators often encounter this specific challenge. The standard passwd command behaves differently for root versus regular users, particularly when PAM modules are configured for AD integration.

The issue stems from how PAM modules are stacked in /etc/pam.d/common-password:

password [success=3 default=ignore] pam_krb5.so minimum_uid=1000
password [success=2 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512
password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass
password requisite pam_deny.so
password required pam_permit.so

Here are three reliable methods to change local user passwords as root:

Method 1: Using chpasswd

echo "service1:newpassword" | chpasswd

Method 2: Direct Shadow File Modification (Advanced)

# Generate SHA512 password hash
mkpasswd -m sha-512 "newpassword"

# Edit shadow file manually (use vipw or similar tools)
service1:$6$salt$hashedpassword:18047:0:99999:7:::

Method 3: Temporary PAM Configuration Change

# Create temporary PAM configuration
cp /etc/pam.d/common-password /etc/pam.d/common-password.bak
sed -i 's/use_authtok try_first_pass//' /etc/pam.d/common-password

# Change password
passwd service1

# Restore original configuration
mv /etc/pam.d/common-password.bak /etc/pam.d/common-password

For a more maintainable solution, modify your PAM configuration to handle local users differently:

# /etc/pam.d/common-password modification
password [success=3 default=ignore] pam_krb5.so minimum_uid=1000
password [success=2 default=ignore] pam_unix.so obscure sha512
password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass
password requisite pam_deny.so
password required pam_permit.so

When implementing these solutions:

• Always verify password complexity requirements
• Consider using pwgen for secure password generation
• Audit password changes in your system logs

When managing a mixed authentication environment with Microsoft Active Directory (Kerberos+LDAP) and local system accounts, administrators often encounter the "Authentication token manipulation error" when attempting to change local user passwords as root. Here's why this happens and how to fix it.

The issue stems from how PAM modules are configured in /etc/pam.d/common-password. The current configuration prioritizes Kerberos authentication even for local users. Here's the problematic flow:

# Current problematic PAM flow for password changes:
1. pam_krb5.so attempts first (fails for local users)
2. System doesn't properly fall back to pam_unix.so
3. Error propagates to pam_deny.so

To properly handle local users while maintaining AD integration, modify /etc/pam.d/common-password:

# /etc/pam.d/common-password - Modified version
password    [success=2 user_unknown=ignore default=die] pam_krb5.so minimum_uid=1000
password    [success=1 default=ignore]      pam_unix.so obscure use_authtok try_first_pass sha512
password    requisite                       pam_deny.so
password    required                        pam_permit.so
password    optional                        pam_gnome_keyring.so

The modified configuration:

• Changes the success jump count to properly handle fallthrough
• Uses user_unknown=ignore for Kerberos module to skip local users
• Simplifies the stack by removing redundant LDAP module (already handled by Kerberos)

If you prefer not to modify PAM configurations, consider these approaches:

# Method 1: Use chpasswd
echo "service1:newpassword" | chpasswd

# Method 2: Directly modify shadow file (requires caution)
sudo vipw -s
# Edit the encrypted password hash for the target user

After making changes, verify with:

# Test password change for local user
sudo passwd service1
# Should now prompt for UNIX password instead of Kerberos

# Verify authentication stack
pamtester passwd service1 authenticate
# Should show successful local authentication

The modified configuration still preserves AD authentication for domain users (UID ≥ 1000):

# For AD users (UID ≥ 1000):
1. Kerberos authentication attempted first
2. Falls back to LDAP if needed
3. Local authentication never attempted

# For local users (UID < 1000):
1. Skips Kerberos entirely
2. Uses standard UNIX authentication

If issues persist:

# Check PAM debugging
tail -f /var/log/auth.log

# Verify user UID
id service1
# Should show UID < 1000 for local users

# Test PAM stack directly
pamtester passwd service1 chauthtok