Password Management

Overview

Password management in FreeIPA balances user convenience with security requirements through flexible password change mechanisms and automatic policy enforcement. The passwd command provides both self-service password changes and administrative password resets, with built-in integration to password policies, OTP authentication, and Kerberos credential management. Every password change triggers automatic validation against applicable password policies, enforcing strength requirements, history constraints, and minimum change intervals.

Password operations in IPA distinguish between user-initiated changes and administrator-initiated resets. When users change their own passwords, they must provide their current password, preventing unauthorized password changes by someone with temporary session access. When administrators reset user passwords, IPA automatically marks the new password as requiring change on first use, ensuring only the user knows their final password even after helpdesk intervention.

IPA’s password system integrates tightly with Kerberos, LDAP, and optional OTP two-factor authentication. Password changes update both Kerberos keys and LDAP password attributes, maintaining synchronization across authentication mechanisms. For users configured with password+OTP authentication, password operations require OTP verification, preventing password changes without possession of the OTP token.

Self-Service Password Changes

Self-service password changes allow users to update their own passwords without administrator intervention. Users must authenticate with their current password, then provide a new password meeting applicable password policy requirements. This workflow prevents unauthorized password changes while enabling users to maintain their credentials independently.

Password changes validate against the user’s applicable password policy, enforcing minimum length, character complexity, password history, and strength requirements. If the new password fails policy validation, the change is rejected with error messages indicating which policy constraints were violated.

After successful password change, IPA updates the user’s Kerberos keys and LDAP password hash. Existing Kerberos tickets remain valid until expiration; users don’t need to re-authenticate immediately after password change unless they need fresh tickets.

Administrative Password Resets

Administrators with appropriate privileges can reset user passwords without knowing the user’s current password. This capability supports helpdesk workflows where users forget passwords or accounts need emergency access recovery. Administrative resets differ from self-service changes in requiring change on first use.

When an administrator sets a user’s password, IPA automatically marks it as expired, forcing password change on the user’s next authentication. This security measure ensures that even if the temporary password is intercepted or logged, it becomes invalid after the user’s first login. The user must change the password before accessing any IPA services.

Administrative password resets do not require the user’s current password, but do require the administrator to have the “Change User password” privilege, typically granted through the “User Administrator” or “Helpdesk” roles.

OTP Integration

Users configured with password+OTP authentication must provide an OTP value during password changes. The --otp option accepts the current OTP token value, verifying the user possesses their OTP device before allowing password modification. This additional factor prevents password changes by attackers who compromise passwords but don’t possess the physical OTP token.

OTP-protected password changes follow the same workflow as standard password changes but include OTP validation. Users enter their current password, current OTP value, and new password. IPA validates all three components before applying the password change.

Users without OTP configured should not use the --otp option; doing so causes authentication failure. OTP requirement is controlled through user authentication type configuration (user-mod --user-auth-type).

Password Policy Enforcement

All password changes automatically enforce applicable password policies. Password policies define:

• Minimum length: Shortest acceptable password
• Character classes: Required character type diversity (uppercase, lowercase, digits, special)
• Password history: Number of previous passwords remembered and prohibited
• Minimum lifetime: How soon after password change another change is permitted
• Maximum lifetime: How long until password expires and requires change
• Strength requirements: Complexity scoring thresholds

Password policies can be global (applying to all users) or group-specific (applying to members of designated groups). Group-specific policies override global policies, enabling different security requirements for different organizational roles.

If a password change violates policy, IPA returns an error describing the policy constraint that failed. Users must modify their new password to satisfy all applicable policy requirements.

Kerberos Integration

Password changes immediately update Kerberos principal keys. After password change, the user can obtain Kerberos tickets using the new password. Existing tickets issued with the old password remain valid until their natural expiration, following standard Kerberos credential lifecycle.

For users with active Kerberos sessions, password changes don’t disrupt current work. The user continues using existing tickets until they expire, then authenticates with the new password to obtain fresh tickets. This grace period prevents workflow interruption from password changes.

Password reset operations can optionally revoke existing Kerberos tickets by modifying the principal’s key version number (KVNO), immediately invalidating all previously issued tickets. This forceful revocation is rarely necessary but supports scenarios requiring immediate session termination.

Examples

Self-Service Password Changes

Change your own password (prompts for current and new passwords):

ipa passwd

Change your own password with OTP authentication:

ipa passwd --otp

Change your own password providing all values as arguments (less secure - visible in process list):

ipa passwd myuser NewPassword123! CurrentPassword456

Administrative Password Resets

Reset another user’s password (prompts for new password):

ipa passwd jsmith

Reset a user’s password with OTP (if user has OTP configured):

ipa passwd jsmith --otp

Reset password providing new password as argument:

ipa passwd jsmith TempPassword789!

Common Workflows

Helpdesk password reset workflow:

# Helpdesk resets user password to temporary value
ipa passwd jsmith
# Enter temporary password when prompted
# User logs in, forced to change password immediately
# User sets their own password, only they know it

User forgotten password recovery:

# User contacts helpdesk
# Helpdesk verifies identity (out-of-band)
# Helpdesk resets password
ipa passwd jsmith
# Communicates temporary password securely (phone, secure message)
# User logs in and is forced to change password

Routine password change:

# User decides to change password proactively
ipa passwd
# Current Password: [enter current password]
# New Password: [enter new password meeting policy]
# Enter New Password again to verify: [re-enter new password]

Emergency access recovery:

# Administrator needs to recover locked account
# Reset password to known value
ipa passwd emergency_user
# User authenticates with temporary password
# Forced immediate password change

Use Cases

Helpdesk User Password Reset

Scenario: User forgets password and contacts helpdesk for reset.

Solution:

# Helpdesk operator (with User Administrator role) resets password
ipa passwd jsmith

# IPA prompts for new temporary password
# New password: Temp123456!

# Password automatically marked as expired
# User notified of temporary password via secure channel

# User authenticates with temporary password
kinit jsmith
# Kerberos prompts for password change
# Old password: Temp123456!
# New password: [user chooses permanent password]

# Temporary password now invalid, only user knows final password

Bulk Password Reset for Security Incident

Scenario: Credential dump compromises multiple user passwords.

Solution:

# Create list of compromised accounts
cat > compromised-users.txt <<EOF
alice
bob
charlie
diana
EOF

# Reset all compromised passwords
while read username; do
    echo "Resetting password for $username"
    ipa passwd "$username" --password="TempReset$(date +%s)!"

    # Notify user via email/Slack of password reset
    # (external notification system)
done < compromised-users.txt

# All users forced to change password on next login
# Compromised passwords immediately invalid

OTP-Protected Administrative Password Change

Scenario: High-security admin needs to change password with OTP verification.

Solution:

# Admin user has OTP token configured
# Change password with OTP verification
ipa passwd --otp

# Current Password: [current password]
# OTP: [6-digit code from token]
# New Password: [new password]
# Verify Password: [new password]

# Password changed only if OTP valid
# Prevents password change if OTP token stolen without password

Scheduled Password Rotation Policy Enforcement

Scenario: Compliance requires quarterly password changes for all administrators.

Solution:

# Set password policy with 90-day maximum lifetime
ipa pwpolicy-mod admins --maxlife=90

# After 90 days, admin passwords automatically expire
# Users forced to change password on next authentication

# Monitor upcoming expirations
ipa pwpolicy-show admins | grep "Max lifetime"

# Remind users before expiration (external monitoring)
# Users change passwords before expiration:
ipa passwd
# (self-service password change)

New Employee Onboarding with Temporary Password

Scenario: HR creates accounts for new employees with temporary initial passwords.

Solution:

# Create user account with random temporary password
ipa user-add newemployee \
    --first=New \
    --last=Employee \
    --email=new.employee@example.com \
    --random

# IPA generates and displays random password: xK9mP2qR7w

# HR securely provides temporary password to employee
# (printed on sealed envelope, SMS, secure portal, etc.)

# Employee's first login forces password change
kinit newemployee
# Password expired. You must change it now.
# Enter new password: [employee chooses password]

# Temporary password invalid after first login

Password Reset After Account Lockout

Scenario: User account locked due to failed login attempts, password forgotten.

Solution:

# User locked after exceeding password failure threshold
# Check lockout status
ipa user-status jsmith

# Unlock user and reset password
ipa user-unlock jsmith
ipa passwd jsmith

# New Password: TempUnlock123!

# User authenticates with temporary password
# Forced to change password immediately
# Account unlocked and accessible with new user-chosen password

Self-Service Password Change Before Expiration

Scenario: User receives expiration warning and proactively changes password.

Solution:

# User sees warning: "Password expires in 5 days"
# Change password before expiration
ipa passwd

# Current Password: [current password]
# New Password: [new strong password]
# Verify Password: [repeat new password]

# Password updated, expiration timer resets
# No service interruption from expiration

Emergency Admin Password Reset for Critical Service

Scenario: Service account password needed urgently for disaster recovery.

Solution:

# Service account password unknown/lost
# Admin resets to known temporary value
ipa passwd backup-service --password="EmergencyBackup2024!"

# Use temporary password for immediate recovery
# service uses temporary credentials

# After emergency resolved, change to proper password
ipa passwd backup-service
# (generate strong random password, store in vault)

# Or better: use keytab instead of password for service accounts
ipa-getkeytab -s ipa.example.com -p backup-service -k /etc/backup.keytab

Security Considerations

Password command-line arguments visible in process list: Providing passwords as command-line arguments (ipa passwd user newpass oldpass) exposes them in process listings visible to other users. Always use interactive prompts for production password changes.

Administrative password resets create temporary password window: Between admin reset and user’s first login, the temporary password could be intercepted. Use secure channels for temporary password transmission and set short expiration windows.

Existing Kerberos tickets remain valid after password change: Changing password doesn’t invalidate active Kerberos tickets. Compromised tickets can be used until expiration even after password changed. For immediate revocation, disable the user account.

Password policy violations may reveal policy details: Failed password change error messages describe policy requirements. This information disclosure helps users comply but could help attackers craft dictionary attacks targeting minimum requirements.

OTP requirement bypass via administrative reset: Admins can reset passwords for OTP-protected users without providing OTP, potentially bypassing two-factor protection. This is intentional for account recovery but represents a privilege escalation path.

Password changes logged but not passwords themselves: IPA logs password change events but not the actual passwords. However, command-line history, shell logs, or system monitoring could capture passwords if provided as arguments.

Temporary passwords transmitted out-of-band security: Helpdesk scenarios require transmitting temporary passwords to users. Email, SMS, and verbal communication are all potentially insecure. Use encrypted channels or secure password delivery portals.

Password history can be circumvented with rapid changes: Password history prevents immediate reuse, but users could cycle through old passwords rapidly if minimum lifetime not configured. Combine history with minimum lifetime policies.

Force change on first login depends on client compliance: IPA marks passwords as expired, but clients must enforce immediate change. Non-IPA-aware applications might accept expired passwords without forcing change.

No password strength estimation feedback: IPA validates against policy requirements but doesn’t provide strength estimation during password creation. Users might choose minimum-compliance passwords with low entropy.

Shared account password reset affects all users: Resetting password for shared account (service account, admin account) impacts all users of that account. Coordinate password changes or use keytabs for service accounts.

Password synchronization lag across replicas: In multi-master IPA deployments, password changes may take seconds to replicate. User might successfully authenticate to one server with new password but fail on another server still using old password.

Administrative reset audit trail: Password resets by admins are logged, but reviewing requires specific audit procedures. Regularly audit administrative password resets for compliance and abuse detection.

Troubleshooting

Password change fails with “Constraint violation”:

# New password violates password policy
# Check which policy applies to user
ipa pwpolicy-show

# Common violations:
# - Password too short (min length)
# - Insufficient character diversity (character classes)
# - Password in history (recently used)
# - Password change too soon (min lifetime)

# View detailed policy requirements
ipa pwpolicy-show --all

# Choose password meeting all requirements
ipa passwd

“Current password required” error during administrative reset:

# Attempting to change your own password without current password
# Use self-service password change with current password
ipa passwd

# For administrative reset of OTHER users:
ipa passwd username
# (doesn't require current password)

# Verify you have reset privileges
ipa role-show "User Administrator" --all | grep member

Password change succeeds but authentication still fails:

# Password may not have replicated to all IPA servers
# Wait 30 seconds for replication
sleep 30

# Test authentication again
kinit username

# If still failing, check which IPA server authenticating against
klist -v

# Verify password change replicated
# On each IPA server:
ipa user-show username | grep "Password"

# Force replication sync
ipa-replica-manage force-sync --from=ipa1.example.com

OTP option fails with “Authentication failed”:

# User may not have OTP configured
ipa user-show username --all | grep "User authentication types"

# If user doesn't have password+otp auth type:
# Don't use --otp flag
ipa passwd username

# If user should have OTP but doesn't:
# Add OTP token first
ipa otptoken-add --owner=username --type=totp

Cannot reset password - “Insufficient access”:

# Verify you have password reset privileges
ipa user-show $USER --all | grep memberof

# Check if member of appropriate role
ipa role-show "User Administrator"
ipa role-show "Helpdesk"

# Add user to role with password reset privilege
ipa role-add-member "Helpdesk" --users=adminuser

User password reset but still cannot login:

# Account may be disabled
ipa user-show username | grep Disabled

# If disabled, enable account
ipa user-enable username

# Account may be locked
ipa user-status username

# If locked, unlock
ipa user-unlock username

# Reset password again after enabling/unlocking
ipa passwd username

“Password is too soon to change” error:

# Password policy minimum lifetime not yet elapsed
ipa pwpolicy-show | grep "Min lifetime"

# Must wait minimum lifetime period before changing again
# Check when last changed
ipa user-show username --all | grep "Password"

# Override requires admin privileges
# Admin can reset despite minimum lifetime
ipa passwd username

Password change works but Kerberos tickets not obtained:

# Kerberos KDC may be unreachable
ping ipa.example.com

# Check Kerberos configuration
cat /etc/krb5.conf | grep -A5 realms

# Test Kerberos connectivity
kinit username
# Check detailed error messages

# If password change succeeded but kinit fails:
# May be network/firewall issue, not password issue

Administrative reset doesn’t force password change on first login:

# Verify password marked as expired
ipa user-show username --all | grep "Password"

# Should show password expiration in past
# If not expired, manually expire
ipa user-mod username --password-expiration="19700101000000Z"

# User's next login will force password change

Password reset for OTP user without OTP fails:

# User has OTP configured, must provide OTP
ipa passwd username --otp

# If admin resetting and doesn't have user's OTP:
# OTP not required for administrative reset
ipa passwd username
# (without --otp flag)

# Admin reset bypasses OTP requirement for account recovery

User reports password change didn’t work:

# Verify password change succeeded
ipa user-show username --all | grep "Last password change"

# Check if user typing password correctly
# Common issues:
# - Caps Lock enabled
# - Different keyboard layout
# - Copying/pasting with extra characters

# Reset to known simple password for testing
ipa passwd username --password="Test123!"

# Have user test with simple password
# Then change to strong password

“Password cannot be reused” error:

# New password in password history
# Check password history length
ipa pwpolicy-show | grep "Password history"

# User must choose password not in history
# Cannot reuse last N passwords

# Wait until password falls out of history window
# Or choose completely different password

Password change via web UI succeeds but CLI fails:

# Web UI and CLI may contact different IPA servers
# Replication lag between servers

# Wait for replication (typically < 30 seconds)
sleep 30

# Retry CLI password change/authentication

# Force replication sync if urgent
ipa-replica-manage force-sync

Temporary password works multiple times (not expiring):

# Password expiration may not be enforced by client
# Verify IPA password expiration set
ipa user-show username --all | grep "Password expiration"

# Manually expire password
ipa user-mod username --password-expiration="19700101000000Z"

# Ensure client supports password expiration enforcement
# SSSD should handle automatic expiration

Cannot change password - “Password is expired”:

# User's current password expired
# Most clients support password change during authentication

# If using kinit:
kinit username
# Password expired. You must change it now.
# Enter new password:

# If web UI login:
# Should prompt for password change automatically

# If neither works, admin must reset
ipa passwd username

Best Practices

Password Security

Never share passwords: Each user should know only their own password. Even administrators resetting passwords should use temporary passwords that users immediately change.

Use strong passwords: Even if policy doesn’t enforce it, users should choose passwords with high entropy, avoiding dictionary words, personal information, and common patterns.

Avoid password reuse: Don’t reuse passwords across different systems or accounts. Each account should have a unique password.

Change compromised passwords immediately: If a password may have been exposed, change it immediately rather than waiting for policy-driven expiration.

Enable OTP for privileged accounts: Accounts with elevated privileges should use password+OTP authentication to provide additional security against password compromise.

Administrative Operations

Use temporary passwords for resets: When resetting passwords, use random temporary passwords, not predictable patterns. The user will change it immediately anyway.

Communicate temporary passwords securely: Don’t email or message temporary passwords through insecure channels. Use phone calls, in-person communication, or secure messaging.

Document reset reasons: Maintain records of why passwords were reset, especially for privileged accounts. This aids security audits.

Limit reset privileges: Grant password reset capabilities only to appropriate personnel (helpdesk, user administrators). Not all administrators need this privilege.

Policy Coordination

Align policies with security requirements: Set password policies based on actual security needs, not arbitrary complexity requirements that encourage poor password practices.

Consider user experience: Overly restrictive policies lead to password writing, reuse, or predictable patterns (Password1!, Password2!). Balance security and usability.

Use group-specific policies: Apply stricter policies to privileged accounts (administrators, DBAs) while using more lenient policies for standard users.

Educate users about policies: Clearly communicate password requirements so users understand what constitutes a valid password.

OTP Integration

Test OTP password changes: Before deploying OTP widely, verify password change workflows function correctly with OTP authentication.

Provide OTP recovery procedures: Ensure users know how to reset passwords if OTP devices are lost or broken. This typically requires administrative intervention.

Document OTP requirements: Clearly indicate which accounts require OTP and how password changes differ for OTP-protected accounts.

Operational Practices

Monitor failed password changes: Track failed password change attempts. Patterns may indicate users struggling with policy requirements or potential attacks.

Plan for policy changes: When modifying password policies, communicate changes to users in advance. Surprising policy changes cause frustration.

Test policy changes: Before applying new password policies to all users, test with a small group to ensure requirements are achievable.

Provide password guidance: Offer guidance on creating strong, memorable passwords that satisfy policy requirements (passphrases, password managers).

Security Monitoring

Audit administrative resets: Review logs of administrative password resets, especially for privileged accounts. Unusual patterns warrant investigation.

Track password change frequency: Users changing passwords very frequently or very rarely may indicate issues (account compromise or policy non-compliance).

Investigate failed OTP validations: Failed OTP during password changes may indicate OTP device issues or attempted unauthorized access.

Monitor policy violations: Repeated policy violation errors from users may indicate policy is too restrictive or users need additional guidance.

Integration with Other IPA Components

Password Policies

Password policies (pwpolicy-* commands) define the constraints enforced during password changes. Global and group-specific policies determine what passwords are acceptable.

User Authentication Types

User authentication type (user-mod --user-auth-type) determines whether OTP is required for password changes. Users configured for password+OTP must provide OTP values.

OTP Tokens

OTP tokens (otptoken-* commands) provide the second factor for OTP-protected password changes. Users must have configured OTP tokens to use password+OTP authentication.

Kerberos

Password changes update Kerberos principal keys, enabling Kerberos ticket acquisition with new passwords. Kerberos ticket lifetime and renewal policies interact with password change timing.

LDAP

Passwords are stored in LDAP as hashed values. Password changes update LDAP password attributes alongside Kerberos keys, maintaining synchronization.

Roles and Privileges

The “Change User password” privilege controls who can reset other users’ passwords. This privilege is typically granted through “User Administrator” or “Helpdesk” roles.

User Lifecycle

Password expiration integrates with user lifecycle management. Initial administrator-set passwords expire immediately, forcing user-initiated change. Regular expiration follows password policy maximum lifetime settings.

EXAMPLES

To reset your own password:

ipa passwd

To reset your own password when password+OTP is set as authentication method:

ipa passwd --otp

To change another user’s password:

ipa passwd tuser1

Commands

passwd

Usage: ipa [global-options] passwd [USER] PASSWORD [CURRENT-PASSWORD] [options]

Set a user’s password.

Arguments

Argument Required Description

---

USER no User name

PASSWORD yes New Password

CURRENT-PASSWORD no Current Password

Options

Option	Description
--otp OTP	The OTP if the user has a token configured