Password Management
Set and reset user passwords with support for password policies and OTP authentication. Password changes trigger automatic policy validation and can require old password verification. Features include self-service password changes, administrative password resets, OTP integration for two-factor password changes, and automatic password expiration for initial administrator-set passwords requiring user change on first use.
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 passwdChange your own password with OTP authentication:
ipa passwd --otpChange your own password providing all values as arguments (less secure - visible in process list):
ipa passwd myuser NewPassword123! CurrentPassword456Administrative Password Resets
Reset another user’s password (prompts for new password):
ipa passwd jsmithReset a user’s password with OTP (if user has OTP configured):
ipa passwd jsmith --otpReset 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 itUser 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 passwordRoutine 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 changeBest 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 passwdTo reset your own password when password+OTP is set as authentication method:
ipa passwd --otpTo change another user’s password:
ipa passwd tuser1
Commands
Command Description
passwd Set a user’s password.
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