Password Policies

Overview

Password policies in FreeIPA enforce security requirements for user passwords including complexity, length, lifetime, and reuse constraints. These policies balance security needs against usability, preventing weak passwords while avoiding overly restrictive requirements that encourage poor password practices. Password policy enforcement occurs during password changes through passwd command and integrates with Kerberos ticket policies, account lockout mechanisms, and pwquality library for strength checking.

IPA supports a global password policy applying to all users and group-specific policies targeting members of designated groups. Each user is subject to exactly one policy: if the user belongs to groups with password policies, the highest-priority group policy applies; otherwise, the global policy applies. Group policies completely replace the global policy rather than augmenting it, enabling distinct security requirements for different organizational roles.

Password policy evaluation occurs during password changes, validating new passwords against applicable policy constraints. Violations result in rejection with error messages indicating which requirements were not met. Policies integrate with account lockout (consecutive failure limits), grace periods (authentication allowance after expiration), and password history (preventing immediate reuse), creating comprehensive password security controls.

Global vs Group Policies

The global password policy serves as the default for all users not covered by group-specific policies. Configured through pwpolicy-mod without specifying a group, the global policy typically enforces baseline security requirements suitable for standard users. Organizations often use moderate global policies with stricter group policies for privileged accounts.

Group password policies target members of specific groups, enabling role-based password requirements. For example, administrators might require longer passwords, more frequent changes, and stricter complexity than standard users. Group policies must specify a priority (unique integer) determining which policy applies when users belong to multiple groups with policies.

Priority values determine policy precedence: lower numeric values indicate higher priority. When a user belongs to multiple groups with password policies, IPA applies the policy with the lowest priority number. This deterministic selection ensures consistent policy application regardless of group membership order.

Group policies are automatically deleted when their associated group is removed, maintaining consistency between group structure and policy configuration. Before deleting groups with password policies, verify affected users have appropriate policy coverage through other groups or the global policy.

Password Strength Requirements

Minimum Length (--minlength): Shortest acceptable password, typically 8-14 characters. Longer passwords generally increase security but may reduce usability. Modern guidance favors longer passphrases over complex shorter passwords.

Character Classes (--minclasses): Number of different character types (uppercase, lowercase, digits, special characters) required. Values 2-4 are common. Higher values increase complexity but can lead to predictable patterns (Password1!).

Character Credits (--dcredit, --ucredit, --lcredit, --ocredit): Adjust how character types contribute to length requirements:

• 0 (default): Character type ignored in length calculation
• Positive value: Each character of this type can reduce effective length requirement
• Negative value: Minimum count of this character type required

Dictionary Check (--dictcheck): Rejects passwords matching dictionary words. Prevents common word passwords but may reject legitimate passphrases.

Username Check (--usercheck): Prevents passwords containing the username. Blocks obvious weak passwords (username as password or trivial variations).

Repeat Limits (--maxrepeat): Maximum consecutive identical characters (aaa). Prevents weak patterns like “aaabbb”.

Sequence Limits (--maxsequence): Maximum monotonic character sequences (abc, 123). Blocks keyboard patterns and simple sequences.

Password Lifetime and Expiration

Maximum Lifetime (--maxlife): Days until password expires and must be changed. Common values 60-180 days. Shorter lifetimes increase security at the cost of user friction. Modern security guidance questions aggressive rotation except for compromised credentials.

Minimum Lifetime (--minlife): Hours before password can be changed after setting. Prevents users from quickly cycling through history to reuse old passwords. Typical values 1-24 hours.

Grace Period (--gracelimit): Number of LDAP authentications allowed after expiration before account becomes unusable. Provides transition period for users to change expired passwords without being locked out:

• -1 (default): No expiration enforcement (legacy compatibility, unlimited grace logins)
• 0: No grace, account locks immediately on expiration
• Positive: Number of additional logins allowed

Grace periods reduce support burden from sudden lockouts but slightly weaken expiration enforcement. Balance depends on organizational support capacity and security requirements.

Important: Per-user grace login attempts are tracked in the passwordGraceUserTime attribute, which is not replicated between IPA servers. In multi-server deployments, users may have different remaining grace login counts depending on which server they authenticate against. This is by design to avoid replication overhead on every authentication.

Password History

Password history (--history) prevents reusing recent passwords, enforcing periodic password diversity. The history value specifies how many previous passwords are remembered and prohibited. Common values 3-10 depending on change frequency and security requirements.

History combined with minimum lifetime prevents users from quickly cycling passwords to return to favorites. For example, with history=5 and minlife=24h, users must set 5 new passwords over 5 days before potentially reusing an old password.

Excessive history values with frequent changes create password memorization challenges, potentially leading to insecure practices like written passwords or predictable patterns. Balance history depth with realistic user capabilities.

Account Lockout Configuration

Maximum Failures (--maxfail): Consecutive authentication failures before account lockout. Common values 3-10. Lower values improve security against brute force but increase risk of accidental lockouts.

Failure Interval (--failinterval): Seconds after which failure count resets. Enables recovery from temporary failure spikes (mistyped passwords). Typical values 300-3600 seconds (5-60 minutes).

Lockout Time (--lockouttime): Seconds account remains locked after exceeding failure threshold:

• Positive value: Automatic unlock after specified time
• 0 or not set: Manual unlock required (administrator intervention)

Account lockout protects against password guessing attacks but creates denial-of-service risk where attackers deliberately lock legitimate accounts. Monitor lockout events and establish efficient unlock procedures.

pwquality Integration

The pwquality library provides advanced password strength checking beyond basic length and character class requirements. pwquality options (credits, dict check, user check, repeats, sequences) take precedence over or complement standard policy values.

When using pwquality options, minimum length must be ≥6 characters (pwquality requirement). pwquality evaluation occurs after basic policy checks, providing layered password validation.

Credit system enables flexible complexity requirements: positive credits reduce effective length requirement when strong characters are used, while negative credits mandate minimum character type counts. This flexibility enables policies that encourage rather than strictly require complexity.

Best Practices

Avoid excessive complexity: Overly complex requirements (many character classes, frequent changes, long history) lead to insecure compensating behaviors like password patterns or writing passwords down.

Prefer length over complexity: Modern guidance recommends longer passphrases (15+ characters) over shorter complex passwords. Length provides more entropy than complexity.

Use group policies for privileged accounts: Apply stricter requirements (longer passwords, more frequent changes) to administrators and privileged accounts while keeping reasonable requirements for standard users.

Set realistic maximum lifetime: While regular changes increase security, excessively frequent changes (30-60 days) reduce usability without proportionate security benefit. Consider 90-180 days unless compliance requires shorter.

Monitor lockout events: Track account lockouts to detect both security incidents (attack attempts) and operational issues (forgotten passwords, configuration problems).

Test policies before deployment: Validate new policies with test users before applying to production. Ensure requirements are achievable and clearly communicate changes to users.

Provide clear password guidance: Help users understand requirements and create strong, memorable passwords. Documentation and examples reduce support burden and improve compliance.

Coordinate with Kerberos ticket policies: Ensure password lifetime and grace periods align with Kerberos ticket policies. Misalignment creates confusing user experiences.

Use Cases

1. Implementing Stricter Policy for Administrators

IT organization needs to enforce stronger password requirements for administrators compared to standard users.

# Check current global policy
ipa pwpolicy-show
# Shows baseline requirements for all users

# Create admin group (if doesn't exist)
ipa group-add admins --desc="System Administrators"

# Add admin users to group
ipa group-add-member admins --users=alice,bob,charlie

# Create strict password policy for admins
ipa pwpolicy-add admins \
  --minlength=16 \
  --minclasses=4 \
  --maxlife=90 \
  --minlife=24 \
  --history=10 \
  --maxfail=5 \
  --priority=1

# Verify policy created
ipa pwpolicy-show admins
# Group password policy: admins
# Max lifetime (days): 90
# Min lifetime (hours): 24
# History size: 10
# Min character classes: 4
# Min length: 16
# Max failures: 5
# Priority: 1

# Check policy applied to admin user
ipa pwpolicy-show --user=alice
# Shows admins policy (priority 1 overrides global)

# Admin users now require:
# - 16+ character passwords
# - All 4 character classes (upper, lower, digits, special)
# - Change every 90 days
# - Cannot change for 24 hours after setting
# - Cannot reuse last 10 passwords

Result: Privileged accounts have stricter password requirements than standard users. Admins must use longer, more complex passwords with more frequent changes.

2. Adjusting Global Policy for Compliance

Organization must meet PCI-DSS compliance requiring specific password complexity and lifetime settings.

# PCI-DSS requirements:
# - Minimum 7 characters (8 recommended)
# - Complexity (letters and numbers)
# - Max 90-day lifetime
# - Cannot reuse last 4 passwords

# Modify global policy to meet compliance
ipa pwpolicy-mod \
  --minlength=8 \
  --minclasses=3 \
  --maxlife=90 \
  --history=4

# Verify changes
ipa pwpolicy-show
# Max lifetime (days): 90
# History size: 4
# Min character classes: 3
# Min length: 8

# Test password change with compliant password
passwd testuser
# New password: MyP@ssw0rd2024
# Password meets requirements - accepted

# Test with non-compliant password
passwd testuser
# New password: simple
# Error: Password is too short (minimum 8 characters)

# Document compliance
cat > /root/pci-compliance-pwpolicy.txt <<EOF
PCI-DSS Password Policy Implementation
======================================
Date: $(date)

Global password policy modified to meet PCI-DSS 3.2.1 requirements:
- Minimum 8 characters (8.2.3)
- Minimum 3 character classes (8.2.3)
- 90-day maximum lifetime (8.2.4)
- 4-password history (8.2.5)

Verified against PCI-DSS checklist.
EOF

Result: Global password policy meets regulatory compliance requirements. All users subject to compliant password standards.

3. Implementing Account Lockout for Brute Force Protection

Security team wants to prevent brute force password attacks by locking accounts after repeated failures.

# Configure account lockout globally
ipa pwpolicy-mod \
  --maxfail=6 \
  --failinterval=1800 \
  --lockouttime=3600

# Lockout policy:
# - 6 consecutive failures trigger lockout
# - Failure count resets after 1800 seconds (30 minutes)
# - Account locked for 3600 seconds (1 hour)

# Test lockout behavior
# Simulate 6 failed authentication attempts for user bob
for i in {1..6}; do
  echo "wrongpassword" | kinit bob
done

# 6th attempt triggers lockout
# kinit: Preauthentication failed while getting initial credentials

# Check user status
ipa user-status bob
# Account disabled: False
# Failed logins since last success: 6
# Time now: 2026-05-13T14:30:00Z
# Last successful authentication: 2026-05-12T10:15:00Z
# Last failed authentication: 2026-05-13T14:30:00Z

# Account automatically unlocks after 1 hour
# Or admin can manually unlock:
ipa user-unlock bob
# Unlocked account "bob"

# Monitor lockout events
grep "Account locked" /var/log/krb5kdc.log
# Identify brute force attack patterns

Result: Automated account lockout prevents brute force attacks. Accounts unlock automatically after timeout or admin intervention.

4. Creating Temporary Contractor Policy

Organization hires contractors who need different password requirements: shorter lifetime, simpler complexity, immediate expiration upon contract end.

# Create contractor group
ipa group-add contractors --desc="Temporary contractor accounts"

# Add contractor users
ipa group-add-member contractors --users=contractor1,contractor2,contractor3

# Create contractor password policy
ipa pwpolicy-add contractors \
  --minlength=10 \
  --minclasses=2 \
  --maxlife=30 \
  --minlife=1 \
  --history=3 \
  --priority=5

# Contractor policy:
# - 10 characters (shorter than admins)
# - 2 character classes (simpler)
# - 30-day lifetime (monthly expiration)
# - 1-hour min lifetime
# - 3-password history

# When contract ends, delete policy and group
# Expiration forces contractors to set new password monthly
# Upon departure, disable accounts immediately

# After contract completion:
ipa user-disable contractor1
ipa group-remove-member contractors --users=contractor1

# When all contractors gone:
ipa pwpolicy-del contractors
ipa group-del contractors

Result: Contractor accounts have appropriate password policy matching temporary employment status. Easy cleanup when contracts complete.

5. Troubleshooting Users Unable to Change Passwords

Users report password change failures with cryptic error messages. Administrator investigates policy conflicts.

# User alice reports: "Password does not meet complexity requirements"
# Check which policy applies to alice
ipa pwpolicy-show --user=alice
# Group password policy: engineering
# Min length: 14
# Min character classes: 4

# Alice's attempted password: SecurePass123
# Length: 13 characters (fails minlength=14)
# Classes: 3 (upper, lower, digits - fails minclasses=4)

# Provide feedback to alice
echo "Password requirements for engineering group:
- Minimum 14 characters
- Must include uppercase, lowercase, digits, AND special characters
- Example: SecureP@ssw0rd123! (15 chars, 4 classes)"

# User bob reports: "Password change too soon"
ipa pwpolicy-show --user=bob
# Min lifetime (hours): 24

# Bob changed password 12 hours ago, trying to change again
# Must wait 24 hours before next change

# Provide feedback
echo "Password cannot be changed within 24 hours of last change.
Wait until $(date -d '+12 hours')"

# User charlie reports password rejected but meets requirements
# Check for username in password
ipa pwpolicy-show | grep usercheck
# Username check: True

# Charlie's attempted password: Charlie2024!
# Contains username "Charlie" - rejected by usercheck

# Advise charlie to avoid username in password

Result: Policy enforcement issues diagnosed by checking applicable policy for each user. Users educated on specific requirements.

6. Disabling Password Expiration for Service Accounts

Service accounts used by automation need passwords that don’t expire, while human users must change passwords regularly.

# Create service account group
ipa group-add service-accounts --desc="Non-expiring service accounts"

# Add service accounts
ipa group-add-member service-accounts \
  --users=svc_backup,svc_monitoring,svc_integration

# Create policy with no expiration
ipa pwpolicy-add service-accounts \
  --maxlife=36500 \
  --minlife=0 \
  --history=0 \
  --priority=2

# Service account policy:
# - 36500 days (100 years) = effectively no expiration
# - No minimum lifetime (can change immediately)
# - No history (can reuse passwords)

# Note: This reduces security for these accounts
# Mitigation: Use strong passwords, limit account permissions,
# monitor authentication, rotate periodically via automation

# Alternative: Configure service accounts for Kerberos keytabs
# instead of passwords (more secure)

# Verify policy applied
ipa pwpolicy-show --user=svc_backup
# Group password policy: service-accounts
# Max lifetime (days): 36500 (no practical expiration)

Result: Service accounts exempt from password expiration requirements. Human users maintain regular password rotation.

7. Implementing Grace Period for Smooth Transitions

Organization wants to prevent sudden account lockouts when passwords expire, allowing users time to change passwords.

# Configure grace period globally
ipa pwpolicy-mod --gracelimit=3

# Grace period allows 3 additional LDAP authentications after expiration
# Users prompted to change password but not immediately locked out

# User password expires
# First login after expiration:
ssh alice@server
# Warning: Your password has expired. You have 3 grace logins remaining.
# Please change your password immediately.

# User can still login 3 more times
# On 4th attempt after expiration:
# Error: Password expired. Please contact administrator.

# Check grace login count
ldapsearch -x -b "uid=alice,cn=users,cn=accounts,dc=example,dc=com" \
  pwdGraceUseTime
# Shows grace logins used

# User changes password before exhausting grace logins
passwd
# Old password: (expired password)
# New password: (new compliant password)
# Password changed successfully

# Grace counter resets after password change

Result: Grace period prevents abrupt lockouts from password expiration. Users have transition period to change passwords without service disruption.

8. Preventing Password Cycling with History and Minimum Lifetime

Users attempting to quickly cycle through passwords to return to favorites. Policy prevents this behavior.

# Configure policy to prevent cycling
ipa pwpolicy-mod \
  --history=5 \
  --minlife=24

# History: Remember last 5 passwords
# Min lifetime: Cannot change for 24 hours

# User alice attempts to cycle passwords
# Day 1, 10:00 AM:
passwd alice
Old password: OldPassword123!
New password: TempPass1!
# Success

# Day 1, 10:05 AM (5 minutes later):
passwd alice
# Error: Password was last changed 0 days 0 hours 5 minutes ago.
# It cannot be changed for another 0 days 23 hours 55 minutes.

# Alice must wait 24 hours before next change

# Day 2, 10:01 AM:
passwd alice
New password: TempPass2!
# Success

# If alice continues changing daily, after 5 days:
# History contains: TempPass1!, TempPass2!, TempPass3!, TempPass4!, TempPass5!

# Day 6:
passwd alice
New password: OldPassword123!
# Error: Password has been used previously and cannot be reused.

# Alice cannot reuse OldPassword123! until it falls out of 5-password history
# Requires 5+ password changes, each 24 hours apart = minimum 5 days

Result: Combination of history and minimum lifetime prevents users from quickly cycling to old passwords. Enforces password diversity over time.

9. Adjusting Lockout Settings After Attack

Security incident reveals attackers attempting brute force against user accounts. Tightening lockout configuration.

# Current lockout settings (too permissive)
ipa pwpolicy-show
# Max failures: 10
# Failure interval: 3600 (1 hour)
# Lockout time: 0 (manual unlock only)

# Attack observed: 100+ failed login attempts per hour per account
# 10-failure threshold too high

# Tighten lockout policy
ipa pwpolicy-mod \
  --maxfail=5 \
  --failinterval=600 \
  --lockouttime=1800

# Updated policy:
# - Lock after 5 failures (reduced from 10)
# - Reset failure count after 10 minutes (reduced from 1 hour)
# - Auto-unlock after 30 minutes (changed from manual only)

# Auto-unlock reduces admin burden while maintaining security

# Monitor attack after policy change
tail -f /var/log/krb5kdc.log | grep "lockout"
# Should see accounts locking after 5 failures
# Attackers limited to 5 attempts per 10 minutes per account

# Document incident response
echo "$(date): Tightened account lockout policy in response to brute force attack.
Max failures reduced from 10 to 5.
Failure interval reduced from 3600s to 600s (10 min).
Lockout time changed from manual to 1800s (30 min auto-unlock).
" >> /var/log/security-incidents.log

Result: Tightened lockout policy limits attacker attempts while enabling automatic recovery. Brute force attack mitigated.

10. Managing Multiple Group Policies with Priority

Organization has multiple groups with password policies. Understanding and managing priority to ensure correct policy application.

# List all password policies
ipa pwpolicy-find
# Shows multiple group policies

# Groups and their priorities:
# admins: priority=1 (highest)
# engineering: priority=5
# contractors: priority=10
# service-accounts: priority=20 (lowest)

# User alice belongs to both admins and engineering
ipa user-show alice | grep "Member of groups"
# Member of groups: admins, engineering

# Check which policy applies
ipa pwpolicy-show --user=alice
# Group password policy: admins
# (Priority 1 beats priority 5)

# Alice subject to strict admin policy, not engineering policy

# User bob belongs to engineering and contractors
ipa user-show bob | grep "Member of groups"
# Member of groups: engineering, contractors

# Check bob's policy
ipa pwpolicy-show --user=bob
# Group password policy: engineering
# (Priority 5 beats priority 10)

# Modify priority to change precedence
# Make contractor policy stricter than engineering
ipa pwpolicy-mod contractors --priority=3

# Now bob gets contractor policy (priority 3 beats 5)
ipa pwpolicy-show --user=bob
# Group password policy: contractors

# Document priority scheme
cat > /root/pwpolicy-priority-scheme.txt <<EOF
Password Policy Priority Scheme
================================

Priority values (lower number = higher priority):
1  = admins (strictest)
3  = contractors (moderate)
5  = engineering (standard)
20 = service-accounts (most permissive)

When users belong to multiple groups with policies,
the policy with the LOWEST priority number applies.

Global policy applies only to users in NO groups with policies.
EOF

Result: Understanding priority system enables correct policy application for users with multiple group memberships. Administrators can adjust precedence by modifying priority values.

Security Considerations

Overly Complex Requirements Drive Insecure Practices

Password policies requiring excessive complexity (long length + many character classes + frequent changes + deep history) paradoxically reduce security by encouraging users to write passwords down, use predictable patterns (Password1!, Password2!, etc.), or choose similar passwords across systems. Research shows overly complex policies lead to “Password1!” style patterns where users meet technical requirements through minimal effort. Balance security and usability: prefer longer passphrases (15+ characters) over shorter complex passwords, and avoid changing passwords more frequently than every 90 days unless compromise is suspected.

Account Lockout as Denial-of-Service Vector

Account lockout policies protect against brute force attacks but create denial-of-service vulnerabilities where attackers intentionally lock legitimate accounts by submitting incorrect passwords. An attacker who knows usernames (often discoverable via email addresses, LDAP enumeration, or social engineering) can lock accounts without needing valid credentials. This disrupts operations and creates helpdesk burden. Mitigation: set maxfail high enough to tolerate legitimate typos (5-6 failures), implement failure interval reset (failinterval) to allow recovery, use automatic unlock (lockouttime) to reduce manual intervention, and monitor for suspicious lockout patterns indicating targeted DoS attacks.

Password History Stored as Hashes

Password history is maintained by storing hashes of previous passwords in user LDAP entries. While these are hashed, they still represent a persistent record of password patterns. If LDAP is compromised and hashes extracted, attackers gain multiple hash attempts per user (current password + history) rather than single password hash. Excessive history (15-20 passwords) increases attacker opportunity without proportional security benefit. Limit history to 3-10 passwords depending on change frequency. For extremely sensitive environments, consider alternative authentication methods (certificates, passkeys) that don’t rely on password rotation.

Grace Period Extends Compromised Credential Validity

Grace periods (--gracelimit) allow continued authentication after password expiration, creating a window where compromised credentials remain valid beyond intended expiration. If an attacker compromises a password one day before expiration and the policy allows 5 grace logins, the attacker has the expiration day plus 5 additional logins to abuse the credential. This extends the attack window. For high-security environments, disable grace periods (--gracelimit=0) and accept the operational burden of immediate lockouts, or use very small grace limits (1-2 logins) to minimize exposure while allowing users to reach password change interfaces.

Minimum Lifetime Creates Recovery Window

Minimum lifetime (--minlife) prevents password changes for a specified period, intended to prevent password cycling through history. However, this also prevents users from changing compromised passwords immediately. If a user’s password is compromised 1 hour into a 24-hour minimum lifetime, they cannot change it for 23 more hours, giving attackers extended access. For suspected compromises, administrators must bypass minimum lifetime by using ipa user-mod --password (admin-initiated password reset) which ignores minimum lifetime. Document emergency password change procedures for security incident response.

Service Account Password Policy Weakening

Exempting service accounts from password expiration (maxlife=36500 days) and history (history=0) eliminates key password security controls. Service account passwords, if compromised, remain valid indefinitely without forced rotation. Service accounts often have elevated privileges, making compromise high-impact. Mitigation: use Kerberos keytabs instead of passwords for service accounts where possible (keytabs can be centrally managed and rotated). If passwords necessary, implement compensating controls: strong password requirements, least-privilege permissions, extensive audit logging, and periodic manual rotation via automation.

Dictionary and Username Checks Performance Impact

Enabling dictionary checking (--dictcheck=true) and username checking (--usercheck=true) adds computational overhead to password changes. For large dictionaries or high password-change volume, this can slow operations. More significantly, the effectiveness depends on dictionary quality: small dictionaries miss many weak passwords; comprehensive dictionaries may reject legitimate passphrases. Username checking prevents only the most obvious weak passwords (username itself or with numbers); determined users work around it (partial username, reversed username). These checks provide marginal security benefit at usability and performance cost. Consider whether they address actual password weaknesses in your environment.

Priority System Complexity with Multiple Groups

Password policy priority system (--priority) can create unexpected results when users belong to many groups with policies. Administrators may not realize which policy applies to specific users without explicit checking (pwpolicy-show --user=<username>). Policy changes (adjusting priorities, modifying requirements) may have unintended cascading effects on users in multiple groups. Misunderstanding priority (thinking higher numbers mean higher priority, when opposite is true) leads to configuration errors. Mitigation: document priority scheme clearly, limit number of group policies (3-5 maximum), test policy changes on test users in multiple groups, and provide tools/scripts for administrators to check effective policies.

Global Policy Modification Impacts All Unassigned Users

Modifying the global password policy (pwpolicy-mod without group parameter) immediately affects all users not covered by group-specific policies. A change intended for new users (e.g., increasing minimum length from 8 to 12) suddenly requires existing users to use longer passwords at next change, potentially creating surprise and support burden. Communicate global policy changes to all users in advance. Consider transition periods where new requirements apply only to password changes, not existing passwords. Test policy changes in development environments first.

Credit System Misunderstanding

The credit system (--dcredit, --ucredit, --lcredit, --ocredit) is frequently misunderstood. Positive values reduce effective length requirements (weakening security), while negative values enforce minimum character type counts (strengthening security). Administrators unfamiliar with this inverted logic may configure credits incorrectly, inadvertently weakening password policies. For example, --dcredit=2 allows passwords to be 2 characters shorter if they include digits—opposite of what many administrators expect. Mitigation: use negative values for mandatory character types (--dcredit=-1 requires at least one digit) or avoid credit system entirely, relying instead on minclasses for complexity.

Password Reuse Across Systems

Password policies in IPA control only IPA passwords. Users may reuse these passwords across other systems (personal email, other work applications, personal devices). If another system is compromised via password breach database or weak security, the reused password becomes known to attackers who then attempt it against IPA. IPA cannot prevent this reuse pattern. Mitigation: educate users on unique passwords per system, encourage password managers, and consider passwordless authentication methods (passkeys, certificates) that eliminate reusable credentials.

Lockout Time Automatic Unlock Risks

Automatic account unlock (--lockouttime=<seconds>) reduces administrative burden but allows attackers to resume brute force attempts after each lockout period. An attacker can launch 5 attempts (assuming maxfail=5), wait for auto-unlock, launch 5 more attempts, repeatedly. This distributed brute force evades lockout if automated. Over days/weeks, attackers can try thousands of passwords despite lockout policy. Mitigation: use manual unlock (lockouttime=0) for high-value accounts, implement rate limiting at network/firewall layer, monitor for repeated lockout patterns indicating persistent attacks, and consider geofencing or IP-based access controls for privileged accounts.

No Password Strength Meter Feedback

IPA password policy validation occurs after password submission, providing only accept/reject feedback. Users don’t receive real-time strength feedback during password creation (like browser password meters). This trial-and-error approach frustrates users and doesn’t educate them on creating strong passwords. Users may give up and use minimally compliant passwords meeting technical requirements without actual strength. Mitigation: provide password requirements documentation with examples of strong passwords, offer password generation tools, and consider enabling pwquality warnings (if supported) that provide feedback beyond binary accept/reject.

Troubleshooting

Password Change Fails with “Constraint violation”

Symptoms: User attempts password change, receives generic “Constraint violation” error without specific details.

Diagnosis:

# User reports password change failure
# Check which policy applies
ipa pwpolicy-show --user=alice
# Group password policy: engineering
# Min length: 12
# Min character classes: 3
# Min lifetime (hours): 24
# History size: 5

# Test user's password against policy
# Password attempted: MyPassword
# Analysis:
# - Length: 10 chars (fails minlength=12)
# - Classes: 2 (upper, lower - fails minclasses=3)

# Check when password was last changed
ipa user-show alice --all | grep "krbLastPwdChange"
# Last change: 2026-05-13 10:00:00Z (2 hours ago)
# Min lifetime: 24 hours - cannot change yet!

# Multiple constraint violations possible

Resolution: “Constraint violation” indicates policy failure but not specifics. Common causes: (1) Password too short (check minlength). (2) Insufficient character classes (check minclasses). (3) Password changed too recently (check minlife). (4) Password in history (check history). (5) Username in password (usercheck=true). (6) Dictionary word (dictcheck=true). Determine applicable policy with pwpolicy-show --user=<username>, verify password meets all requirements, and check last password change time.

Account Locked, User Cannot Authenticate

Symptoms: User reports “Account locked” or “Access denied” errors after multiple failed login attempts.

Diagnosis:

# Check user lockout status
ipa user-status alice
# Account disabled: False
# Failed logins: 6
# Last failed authentication: 2026-05-13T14:30:00Z
# Time now: 2026-05-13T14:35:00Z

# Check lockout policy
ipa pwpolicy-show --user=alice
# Max failures: 5
# Failure interval: 1800 seconds (30 min)
# Lockout time: 3600 seconds (60 min)

# Alice exceeded 5 failures within 30-minute window
# Account locked for 60 minutes from last failure
# Auto-unlock time: 15:30:00Z (60 min after 14:30:00Z)

Resolution: Account locked due to exceeding maxfail within failinterval. Options: (1) Wait for automatic unlock if lockouttime > 0 (60 minutes in this example). (2) Manual unlock: ipa user-unlock alice. (3) If legitimate user forgot password: unlock and reset password via admin. (4) If attack detected: investigate source, keep locked, review access logs.

User Cannot Change Password Due to Minimum Lifetime

Symptoms: User changed password but needs to change again immediately (typo, compromised, etc.), receives “too soon” error.

Diagnosis:

# Check policy minimum lifetime
ipa pwpolicy-show --user=bob
# Min lifetime (hours): 24

# Check when password was last changed
ipa user-show bob --all | grep "krbLastPwdChange"
# Last change: 2026-05-13 10:00:00Z
# Current time: 2026-05-13 14:00:00Z
# Elapsed: 4 hours (minimum is 24 hours)

# User must wait 20 more hours before changing again

Resolution: Minimum lifetime prevents immediate password changes. For legitimate immediate change needs (compromise, typo): (1) Admin-initiated reset bypasses minimum lifetime: ipa user-mod bob --password. (2) Temporarily reduce minimum lifetime: ipa pwpolicy-mod <group> --minlife=0, user changes password, restore original value. (3) For emergencies, disable account and create temporary alternative access.

Password Rejected Despite Meeting Visible Requirements

Symptoms: Password meets stated length/complexity requirements but is still rejected.

Diagnosis:

# User reports: "SecurePass789" rejected
# Length: 13 characters ✓
# Classes: 3 (upper, lower, digits) ✓

# Check for hidden requirements
ipa pwpolicy-show --user=charlie
# Min length: 10 ✓
# Min classes: 3 ✓
# Username check: True ← ISSUE
# Dictionary check: True ← POSSIBLE ISSUE

# "SecurePass789" contains "secure" (dictionary word)
# OR
# User's username is "charlie" - check if username in password
# Username "charlie" not in "SecurePass789", so usercheck not issue

# Dictionary check likely the problem

Resolution: Password rejected due to: (1) Dictionary check: Contains dictionary word (“secure”, “pass”). Use non-dictionary words or mispellings. (2) Username check: Contains username or username contains password. Avoid username in password. (3) Character repeats: Exceeds maxrepeat (e.g., “aaa”). Limit consecutive identical characters. (4) Sequences: Exceeds maxsequence (e.g., “abc”, “123”). Avoid sequential patterns. Check all pwquality-related settings, not just length and classes.

Group Policy Not Applied to User in Group

Symptoms: User is member of group with password policy, but global policy applies instead.

Diagnosis:

# User david in engineering group
ipa user-show david | grep "Member of groups"
# Member of groups: engineering, developers

# Engineering group has policy
ipa pwpolicy-show engineering
# Group password policy: engineering
# Min length: 12

# Check david's effective policy
ipa pwpolicy-show --user=david
# Group password policy: developers
# Min length: 8 (different!)

# David in BOTH engineering and developers
# Check priorities
ipa pwpolicy-show engineering | grep Priority
# Priority: 10

ipa pwpolicy-show developers | grep Priority
# Priority: 5

# Lower priority number wins: developers (5) beats engineering (10)
# David gets developers policy, not engineering

Resolution: User in multiple groups with policies receives policy with lowest priority number (highest precedence). To apply engineering policy to david: (1) Change priorities: ipa pwpolicy-mod developers --priority=15 (higher than engineering’s 10). (2) Remove david from developers group (if appropriate). (3) Create specific policy for users needing engineering policy with lower priority number.

Cannot Delete Group Password Policy

Symptoms: Attempting to delete group password policy fails with error.

Diagnosis:

# Try to delete policy
ipa pwpolicy-del contractors
# ipa: ERROR: <error message varies>

# Check if group still exists
ipa group-show contractors
# Group exists

# Policy tied to group - can only delete if group deleted first
# OR policy may be deleted automatically when group deleted

Resolution: Group password policies are tied to groups. To remove policy: (1) Delete the group: ipa group-del contractors (policy auto-deletes). (2) If group must remain but policy should be removed, this may not be possible—verify IPA version documentation. (3) Alternative: modify policy to match global policy effectively neutralizing it: ipa pwpolicy-mod contractors --minlength=8 --maxlife=90 ... (copy global policy values).

Global Policy Change Not Taking Effect

Symptoms: Modified global password policy, but users still experiencing old requirements.

Diagnosis:

# Modified global policy
ipa pwpolicy-mod --minlength=12
# Success

# But user eve can still set 8-character password
passwd eve
# New password: Pass1234 (8 characters)
# Success (should fail with minlength=12)

# Check if eve has group policy
ipa pwpolicy-show --user=eve
# Group password policy: staff
# Min length: 8

# Eve subject to group policy (staff), not global policy
# Global policy only applies to users in NO groups with policies

Resolution: Global policy changes don’t affect users covered by group policies. Users belong to groups with policies are subject to those group policies instead. To apply global policy change to all users: (1) Modify each group policy individually. (2) Remove group policies (users fall back to global). (3) Accept that group policy users have different requirements. Document which users are subject to group vs. global policies.

Password Expiration Causes Unexpected Lockouts

Symptoms: Users suddenly unable to authenticate with “password expired” errors without warning.

Diagnosis:

# User frank reports sudden lockout
# Check password expiration
ipa user-show frank --all | grep -E "(krbLastPwdChange|krbPasswordExpiration)"
# krbLastPwdChange: 2026-02-12 10:00:00Z
# krbPasswordExpiration: 2026-05-13 10:00:00Z

# Check policy
ipa pwpolicy-show --user=frank
# Max lifetime (days): 90
# Grace limit: 0 (no grace logins)

# Frank's password expired 90 days after last change
# No grace period - immediate lockout

# Current time: 2026-05-13 14:00:00Z
# Password expired at 10:00:00Z (4 hours ago)

Resolution: Password expiration without grace period causes immediate lockout. Options: (1) Configure grace period globally: ipa pwpolicy-mod --gracelimit=3 (allows 3 logins after expiration for user to change password). (2) Admin resets password: ipa user-mod frank --password. (3) Implement pre-expiration warnings via email notifications or login messages to give users advance notice. (4) Educate users on password expiration schedule.

Priority Conflict Between Policies

Symptoms: Two group policies have same priority, unclear which applies to users in both groups.

Diagnosis:

# Check all policies
ipa pwpolicy-find
# engineering: priority=10
# developers: priority=10 (SAME!)

# User george in both groups
ipa pwpolicy-show --user=george
# Which policy applies is undefined with equal priority
# May apply either policy non-deterministically

Resolution: Each group policy must have unique priority. Modify one policy’s priority: ipa pwpolicy-mod engineering --priority=11. After change, policy application becomes deterministic (developers priority=10 wins over engineering priority=11). Document priority scheme to avoid future conflicts. Priority values don’t need to be consecutive—use gaps (10, 20, 30) to allow insertions.

Account Locks Despite Correct Password

Symptoms: User certain password is correct, but account locks after several attempts.

Diagnosis:

# Check lockout status
ipa user-status helen
# Failed logins: 5
# Time of last failed auth: 2026-05-13T14:00:00Z

# Check policy
ipa pwpolicy-show --user=helen
# Max failures: 5

# User likely typing password incorrectly (CAPS LOCK, different keyboard layout, etc.)
# OR password was actually changed and user using old password

# Check password last change time
ipa user-show helen --all | grep "krbLastPwdChange"
# Last change: 2026-05-12 15:30:00Z

# Verify no recent admin password resets
ipa-audit | grep "user-mod.*helen.*password"
# Check if admin reset password without user knowledge

Resolution: Common causes: (1) User typing password incorrectly (CAPS LOCK, keyboard layout, typos). Have user try on different device. (2) Password was changed (expired, admin reset) and user not aware. Reset password: ipa user-mod helen --password. (3) Account compromised—attacker attempted passwords, causing lockout. Investigate access logs. (4) Clock skew between client/server causing authentication timing issues (rare). Unlock account: ipa user-unlock helen and assist user with correct password.

Cannot Set Very Long Password (>100 characters)

Symptoms: User attempting to set very long passphrase (150+ characters), password rejected.

Diagnosis:

# User attempts 150-character passphrase
passwd
# New password: (very long passphrase)
# Error: Password too long

# Check for maximum password length constraints
# IPA doesn't enforce maximum via policy, but underlying systems may

# Check Kerberos maximum password length
# Varies by Kerberos implementation
# MIT Kerberos: typically 256 characters
# But practical limits may be lower

Resolution: While IPA password policies define minimum length, maximum length is constrained by underlying systems (Kerberos, LDAP, pam_password). Practical maximum typically 100-256 characters depending on configuration. For passphrases needing >100 characters, this is rarely necessary—100-character passphrase provides enormous entropy. If truly needed, verify Kerberos and LDAP maximum password lengths, may require recompilation or configuration changes. For most use cases, recommend 20-50 character passphrases as sufficient.

pwpolicy-show Returns Different Values Than Expected

Symptoms: pwpolicy-show displays unexpected values after modification.

Diagnosis:

# Modified policy
ipa pwpolicy-mod engineering --minlength=14
# Success

# But pwpolicy-show shows old value
ipa pwpolicy-show engineering
# Min length: 12 (old value)

# Check LDAP replication
# May be reading from un-replicated replica

# Force specific server
ipa -s ipa01.example.com pwpolicy-show engineering
# Min length: 14 (correct value)

# Replication delay or issue

Resolution: Multi-master replication delay causes temporary inconsistency. Wait 30-60 seconds for replication to complete. Verify replication health: ipa topologysuffix-verify domain. Force sync if needed: ipa-replica-manage force-sync --from=ipa01. If values never synchronize, investigate LDAP replication conflicts.

Credits Configuration Causes Unexpected Behavior

Symptoms: Configured password credits, but passwords behave unexpectedly (too lenient or too strict).

Diagnosis:

# Configuration
ipa pwpolicy-show
# Min length: 10
# Digit credit: 2 (intended to require digits)

# BUT: positive credit REDUCES effective length requirement
# User can set 8-character password if it has digits
# Example: "Pass123!" (8 chars, has digits) - ACCEPTED
# Effective length: 10 - 2 (credit for digits) = 8

# This is opposite of intended behavior

# Correct configuration for required digits:
# Use NEGATIVE value: --dcredit=-1 (requires at least 1 digit)

Resolution: Credit system is often misunderstood. Positive values reduce length requirement (lenient). Negative values enforce minimum counts (strict). To require character types: use negative credits (--dcredit=-1, --ucredit=-1) or use minclasses instead. To avoid confusion, many organizations avoid credit system entirely, using only minlength and minclasses.

Password Policy Modification Requires Repeated Changes

Symptoms: Password policy modifications don’t seem to persist, requiring repeated execution.

Diagnosis:

# Modify policy
ipa pwpolicy-mod --minlength=12
# Success

# Later, check policy
ipa pwpolicy-show
# Min length: 8 (reverted?)

# Check if automation is overwriting configuration
crontab -l
# Check for scheduled policy reset scripts

# Check ipa-audit logs
ipa-audit | grep pwpolicy-mod | tail -20
# Shows repeated modifications from unexpected source

Resolution: Policy reverting indicates: (1) Automation script resetting policy (Ansible, Puppet, etc.). Find and update automation. (2) Multiple administrators making conflicting changes. Coordinate change management. (3) Configuration management system (Ansible, Puppet) enforcing state. Update configuration management templates. (4) Replication conflicts causing rollback. Fix replication issues. Implement change control for policy modifications.

User Belongs to No Groups With Policies But Still Gets Group Policy

Symptoms: User not in any groups with password policies, but receives group policy instead of global policy.

Diagnosis:

# User ivan not in any special groups
ipa user-show ivan | grep "Member of groups"
# Member of groups: ipausers (default group)

# Check ivan's effective policy
ipa pwpolicy-show --user=ivan
# Group password policy: ipausers
# Min length: 12 (not global policy!)

# Someone created policy for ipausers group (default group all users are in)
ipa pwpolicy-show ipausers
# Group password policy: ipausers
# Priority: 50

# This effectively makes ipausers policy the new "global" policy
# True global policy only applies to users NOT in ipausers (none)

Resolution: Password policy created for default group (ipausers) overrides true global policy for all users. If this was intentional, policy is working correctly. If unintentional: delete ipausers policy: ipa pwpolicy-del ipausers. After deletion, users fall back to actual global policy. Avoid creating policies for universal default groups unless intentionally replacing global policy.

Integration with Other IPA Components

User Management (user-*): Password policies apply during user password changes. User authentication type (password, password+OTP) interacts with policy enforcement.

Password Changes (passwd): Password policy validation occurs during passwd operations, rejecting passwords failing policy requirements.

Kerberos Policies (krbtpolicy-*): Kerberos ticket policies control ticket lifetime and renewal. Password expiration integrates with ticket acquisition.

Global Configuration (config-show/mod): Global password policy is stored in IPA configuration and serves as default for all users.

Group Management (group-*): Group password policies target specific groups. Policy applies to all group members. Group deletion automatically removes associated password policy.

EXAMPLES

Modify the global policy:

ipa pwpolicy-mod --minlength=10

Add a new group password policy:

ipa pwpolicy-add --maxlife=90 --minlife=1 --history=10 --minclasses=3 --minlength=8 --priority=10 localadmins

Display the global password policy:

ipa pwpolicy-show

Display a group password policy:

ipa pwpolicy-show localadmins

Display the policy that would be applied to a given user:

ipa pwpolicy-show --user=tuser1

Modify a group password policy:

ipa pwpolicy-mod --minclasses=2 localadmins

Commands

pwpolicy-add

Usage: ipa [global-options] pwpolicy-add GROUP [options]

Add a new group password policy.

Arguments

Argument	Required	Description
GROUP	yes	Manage password policy for specific group

Options

Option	Description
--maxlife MAXLIFE	Maximum password lifetime (in days)
--minlife MINLIFE	Minimum password lifetime (in hours)
--history HISTORY	Password history size
--minclasses MINCLASSES	Minimum number of character classes
--minlength MINLENGTH	Minimum length of password
--priority PRIORITY	Priority of the policy (higher number means lower priority
--maxfail MAXFAIL	Consecutive failures before lockout
--failinterval FAILINTERVAL	Period after which failure count will be reset (seconds)
--lockouttime LOCKOUTTIME	Period for which lockout is enforced (seconds)
--maxrepeat MAXREPEAT	Maximum number of same consecutive characters
--maxsequence MAXSEQUENCE	The max. length of monotonic character sequences (abcd)
--dictcheck DICTCHECK	Check if the password is a dictionary word
--usercheck USERCHECK	Check if the password contains the username
--dcredit DCREDIT	The max credit for digits in the password.
--ucredit UCREDIT	The max credit for uppercase characters in the password.
--lcredit LCREDIT	The max credit for lowercase characters in the password.
--ocredit OCREDIT	The max credit for other characters in the password.
--gracelimit GRACELIMIT	Number of LDAP authentications allowed after expiration
--setattr SETATTR	Set an attribute to a name/value pair. Format is attr=value.
--addattr ADDATTR	Add an attribute/value pair. Format is attr=value. The attribute
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.

pwpolicy-del

Usage: ipa [global-options] pwpolicy-del GROUP [options]

Delete a group password policy.

Arguments

Argument	Required	Description
GROUP	yes	Manage password policy for specific group

Options

Option	Description
--continue	Continuous mode: Don’t stop on errors.

pwpolicy-find

Usage: ipa [global-options] pwpolicy-find [CRITERIA] [options]

Search for group password policies.

Arguments

Argument Required Description

---

CRITERIA no A string searched in all relevant object attributes

Options

Option	Description
--group GROUP	Manage password policy for specific group
--maxlife MAXLIFE	Maximum password lifetime (in days)
--minlife MINLIFE	Minimum password lifetime (in hours)
--history HISTORY	Password history size
--minclasses MINCLASSES	Minimum number of character classes
--minlength MINLENGTH	Minimum length of password
--priority PRIORITY	Priority of the policy (higher number means lower priority
--maxfail MAXFAIL	Consecutive failures before lockout
--failinterval FAILINTERVAL	Period after which failure count will be reset (seconds)
--lockouttime LOCKOUTTIME	Period for which lockout is enforced (seconds)
--maxrepeat MAXREPEAT	Maximum number of same consecutive characters
--maxsequence MAXSEQUENCE	The max. length of monotonic character sequences (abcd)
--dictcheck DICTCHECK	Check if the password is a dictionary word
--usercheck USERCHECK	Check if the password contains the username
--dcredit DCREDIT	The max credit for digits in the password.
--ucredit UCREDIT	The max credit for uppercase characters in the password.
--lcredit LCREDIT	The max credit for lowercase characters in the password.
--ocredit OCREDIT	The max credit for other characters in the password.
--gracelimit GRACELIMIT	Number of LDAP authentications allowed after expiration
--timelimit TIMELIMIT	Time limit of search in seconds (0 is unlimited)
--sizelimit SIZELIMIT	Maximum number of entries returned (0 is unlimited)
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.
--pkey-only	Results should contain primary key attribute only (“group”)

pwpolicy-mod

Usage: ipa [global-options] pwpolicy-mod [GROUP] [options]

Modify a group password policy.

Arguments

Argument Required Description

---

GROUP no Manage password policy for specific group

Options

Option	Description
--maxlife MAXLIFE	Maximum password lifetime (in days)
--minlife MINLIFE	Minimum password lifetime (in hours)
--history HISTORY	Password history size
--minclasses MINCLASSES	Minimum number of character classes
--minlength MINLENGTH	Minimum length of password
--priority PRIORITY	Priority of the policy (higher number means lower priority
--maxfail MAXFAIL	Consecutive failures before lockout
--failinterval FAILINTERVAL	Period after which failure count will be reset (seconds)
--lockouttime LOCKOUTTIME	Period for which lockout is enforced (seconds)
--maxrepeat MAXREPEAT	Maximum number of same consecutive characters
--maxsequence MAXSEQUENCE	The max. length of monotonic character sequences (abcd)
--dictcheck DICTCHECK	Check if the password is a dictionary word
--usercheck USERCHECK	Check if the password contains the username
--dcredit DCREDIT	The max credit for digits in the password.
--ucredit UCREDIT	The max credit for uppercase characters in the password.
--lcredit LCREDIT	The max credit for lowercase characters in the password.
--ocredit OCREDIT	The max credit for other characters in the password.
--gracelimit GRACELIMIT	Number of LDAP authentications allowed after expiration
--setattr SETATTR	Set an attribute to a name/value pair. Format is attr=value.
--addattr ADDATTR	Add an attribute/value pair. Format is attr=value. The attribute
--delattr DELATTR	Delete an attribute/value pair. The option will be evaluated
--rights	Display the access rights of this entry (requires —all). See ipa man page for details.
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.

pwpolicy-show

Usage: ipa [global-options] pwpolicy-show [GROUP] [options]

Display information about password policy.

Arguments

Argument Required Description

---

GROUP no Manage password policy for specific group

Options

Option	Description
--rights	Display the access rights of this entry (requires —all). See ipa man page for details.
--user USER	Display effective policy for a specific user
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.