What FreeIPA password quality checks catch that length rules miss
An identity team asked to show stronger password rules often finds that minimum length and required character classes are not enough. A password such as a common word with a capital letter and a digit can meet both tests and still be trivial to guess. FreeIPA password quality checks address this gap by passing each new password through the libpwquality library on the server, which applies rules that look at the content of the password rather than only its shape. Teams need these checks when their policy or assessor expects protection against predictable choices, not just formatting compliance.
The checks cover three broad families at a high level. Dictionary checks reject passwords built from words or common patterns found in a word list. User name and derived string checks reject passwords that contain or closely resemble the account name, the full name or other values taken from the user's record. Repeated and sequential character checks reject runs such as the same character many times in a row or simple ascending or descending sequences. The exact behavior depends on the FreeIPA version and on the libpwquality build installed on the server, so the rules you get on one deployment may differ from another.
Before relying on any of these checks, confirm with your own test servers which checks are active, which options can be set through the password policy and how errors are reported to users and to applications that set passwords over other paths. Ask your vendor or the project documentation for the libpwquality build on your platform, and test a set of known weak passwords against a non-production policy. Plan for the limits as well: these rules do not detect passwords that have appeared in breach data, and they do not stop a user from writing a password on paper or reusing it elsewhere.
Which libpwquality options fit which password risks
This table compares the libpwquality settings a FreeIPA team is likely to review, with the risk each one addresses, the trade-off it creates and what to confirm in the target FreeIPA version. Values are placeholders for your own password policy, not recommendations. Read each row as a question your policy owner must answer before rollout.
| Setting | Risk it addresses | Trade-off and limits | What to confirm in the target version |
|---|---|---|---|
| Minimum length | Short passwords that are quick to guess or brute force | Longer minimums push users toward predictable patterns or password reuse if they are not paired with other checks | Which minimum length FreeIPA enforces through its password policy and whether libpwquality is consulted for that check |
| Minimum character classes | Passwords that use only one character set | Class rules are easy to satisfy with predictable substitutions, so they add little on their own against common words | How many classes are counted, and whether the setting applies to new passwords, resets or both |
| Dictionary check | Common words and well-known passwords used as the base of a password | Depends on the dictionary files installed on the server, so coverage varies by distribution and does not catch every pattern | Which dictionary files exist on each replica and whether all replicas use the same configuration |
| User name check | Passwords that contain the account name or parts of it | Effective only for the names it can compare, so users with short or common names may still be affected by false matches | Whether the check runs against the login name, the full name or both, and how it treats case |
| Maximum repeated characters | Runs such as repeated letters or digits that weaken a password | Too low a value rejects legitimate passphrases, and it does not stop sequences or keyboard patterns | The exact meaning of the setting and whether it counts consecutive or total repeats |
| Maximum sequence or same-class run | Ordered sequences such as numeric or alphabetic runs | Blocks obvious patterns but not all predictable structures, and it can increase helpdesk tickets | Whether this option exists in your installed libpwquality version and how FreeIPA passes it through |
| Retry and error handling | Users who need clear feedback to choose a compliant password | Clear messages help users but may reveal policy details to attackers if the wording is too specific | How FreeIPA and SSSD surface the rejection reason on each client type |
How libpwquality checks run when a password is set or changed
The quality checks do not run at one fixed point. In FreeIPA, a password can be set in several ways: a user changes their own password, an administrator sets or resets one, or a user completes a password reset. Each path can reach the password policy through a different component, and the same policy object does not guarantee the same result on every path. Before you rely on libpwquality for any of these, confirm which code path applies to each method your help desk, self-service pages and provisioning tools use. FreeIPA stores password rules in the password policy object, which is attached to a group or applied globally. When the password is evaluated, the server passes the configured minimum length, character class counts and related settings to the quality library, which applies them and returns an accept or reject decision with a reason. The reason is what the user sees in most cases, but the wording depends on the client and the interface. Test the rejection message in each interface your users touch, because a generic error in one tool can hide which rule failed.
Some checks look only at the password string, such as length, character classes and repeated characters. Others depend on user attributes, such as the login name or the GECOS fields, so the same password can pass for one account and fail for another. That difference is expected behavior, not an inconsistency to fix, but it means your test cases need real account data and not just a sample password. Kerberos key material and LDAP binds may also follow different paths, so a password accepted for Kerberos login is not automatically checked the same way for an application that binds over LDAP. Ask your implementation team to document, for each path, whether the check runs, which attributes it uses and where a rejection is returned.
Setting up FreeIPA password quality checks step by step
This sequence takes a FreeIPA deployment from version and package checks through policy review, a written rule set, applied settings and tests on every replica, so that each password rule is confirmed to work before it is relied on.
Confirm server versions and libpwquality on each server
The administrator checks the FreeIPA server version on every server in the topology, then confirms that the libpwquality package and its command-line tools are installed on each one, using the package manager of your distribution. Record the version and package build per host in your change record. Check the release notes for your version before you rely on any behavior described in this guide, because FreeIPA changes between 4.x releases. This step is done when every server reports the same FreeIPA version and the libpwquality check returns a valid installed package on each host, so you know what you are testing against.
Review current global and group password policies
Run the FreeIPA password policy queries for the global policy and for every group policy, including the policy that applies to administrators and any service or application groups. Note the minimum length, character class settings, history, lockout and expiration values, and which groups each policy targets. Identify any user who falls into more than one policy and confirm which one applies. This step is done when you have a written export of the current policy state, so that later changes can be compared against a known baseline and any conflicts with existing rules are visible before you edit anything.
Write the intended password checks in advance
Before changing settings, the security or identity owner writes down each check you intend to enforce. For each one, state the rule, the policy it belongs to, the accounts it covers, and the test passwords that should be rejected and accepted. Cover dictionary checks, user name and login checks, repeated character limits and any other libpwquality options your environment needs. Include the limits you know apply, such as checks that depend on system dictionaries and checks that cannot cover every guessed password. Get sign-off from the people who own the policy. This step is done when the document lists every rule with its expected test results, because the tests in later steps are built from it.
Apply the settings through the FreeIPA password policy
An administrator with password policy rights applies the agreed settings through the FreeIPA password policy, either in the web UI or with the ipa command-line tools, changing one policy at a time. Where a libpwquality option is configured on the servers rather than through a policy field, the administrator changes it there with the same change record and records the file and key names. Save the changes and export the policy again. This step is done when the exported policy matches the written document from the previous step, with any gap documented and explained.
Test rejected passwords for each rule
Using a sample test account in a non-production group, the tester sets passwords through the FreeIPA web UI and the ipa command line, one per rule defined earlier. Each password that should fail must be rejected with a message that names the failed rule, and each password that should pass must be accepted. Record the input, the result and the message for each case. This step is done when every rule has at least one rejected test and one accepted test with matching results, so you have evidence that each check fires for the intended reason and not because of an unrelated setting.
Verify changes through the web UI and command line
The tester changes the password of a sample account through the web UI and through the command line, and confirms the same rules are applied on both paths. Then the tester runs a Kerberos login with kinit using the new password, and an LDAP bind with the same credentials, to confirm that the accepted password works across the authentication paths your users depend on. Record the outcome of each path. This step is done when the web UI, kinit and LDAP bind results agree, and any path that behaves differently is written up with the cause before the change is accepted.
Repeat tests on every replica
Because policy changes replicate across the topology, the tester runs the same sample password tests against each replica, not only the server where the change was made. Use the same test accounts and the same rejected and accepted passwords from the written list, and check that the libpwquality behavior on each host matches. Where a server-side libpwquality option was used, confirm the configuration file matches on every host. Log the results per server. This step is done when every replica produces identical results for every test case, which shows the policy is consistent across the topology and that no single server enforces a different rule set.
Document the final rule set and retest schedule
The identity owner records the final rule set, the policies and groups it applies to, the test evidence from each replica, and the known limits, including what the checks do not catch. Assign an owner for reviewing the rules after future FreeIPA upgrades and security releases, because version changes can alter how checks behave. Confirm with your own change process how often the tests are repeated and who approves it. This step is done when the document is stored with the change record and every rule has a named owner and a test that can be rerun.
Security and operational considerations for password quality rules
A password quality check is only as good as the way it is changed, applied and proven. The cards below cover the operational decisions that surround libpwquality rules in FreeIPA, from change control to evidence.
Control policy edits across replicas
FreeIPA password policies are stored in the directory and replicated between servers, so a change made on one server reaches the others through replication rather than through a separate deployment step. Record every change to the global and group password policies with the reason, the requester and the approver. After each edit, check on at least two servers that the setting has replicated, and confirm that the libpwquality settings on those servers match what the change record says. (Confirm with your own team how your environment applies these settings.)
Separate rules for service and host accounts
Service principals, keytab-based services and automation accounts often cannot follow interactive rules such as frequent resets or complex passphrases. Inventory these accounts first, then decide whether each one should be exempt, moved to a separate policy, or handled through key or certificate authentication instead. Document each exemption with an owner and a review date, so that a password rule change does not silently break a batch job or service login.
Govern administrator password resets
When an administrator sets or resets a password, the reset may follow different rules than a user changing their own password, depending on how your environment and policy are configured. Confirm which checks apply to administrator-set passwords in your version, then require a temporary password that the user must change at first login. Log who performed each reset and keep a process for resets on accounts that belong to privileged groups.
Keep evidence of the policy in force
Auditors and internal reviewers usually want proof of what the rule was on a given date, not only what it is today. Export the password policy and the libpwquality settings on a schedule, store the output with a timestamp, and keep it alongside the change records from policy edits. Compare exports over time so that unexpected drift between servers is visible. The exports show configuration, not that each password is strong, so pair them with the audit logs described in your operations plan.
Test lockout and MFA interactions
Stronger password rules can raise the number of failed attempts users make while changing passwords, and lockout settings then decide whether those attempts lock accounts. Review the lockout thresholds together with the password policy, and test a failed change, a lockout and an OTP-protected login in a non-production environment. Confirm how a locked account is unlocked and who may do it, because a rule change that produces lockouts can become a help desk load.
Verify rules after security releases
Security releases can change authentication checks, so a password rule that worked before an update may behave differently afterward. After each update, repeat a short test set on every replica: a rejected dictionary word, a rejected user name, an accepted passphrase and a password change through the web UI and the command line. Record the results against the release version so that the evidence shows the rule still applies after the change.
Choosing password check levels by user group
Employees who sign in to workstations and day-to-day applications are the largest group, and they are the most likely to choose weak, guessable passwords under pressure. The checks that matter most here are dictionary checks, checks against the user's own name and login, and limits on repeated or sequential characters. These catch the patterns that length and character-class rules miss, such as a season and year followed by a symbol. The trade-off is user friction: strict rules increase reset tickets and tempt staff to write passwords down or reuse them across systems.
- Dictionary checks: Reject common words and known weak passwords, which is the most useful addition to length and class rules.
- User name checks: Block passwords that contain the login name or parts of the full name.
- Repeat and sequence limits: Stop runs such as repeated characters or keyboard-style sequences.
- Reset workflow: Confirm how users change expired or rejected passwords and whether help desk time can absorb the change.
- Pairing with MFA: Confirm whether OTP or other second factors cover these users, since that changes how much weight the password rules must carry.
Confirm with the business owner which rule set the workforce will accept and how the help desk will support resets before the policy is applied.
Accounts that can change host policy, certificate settings or other administrators carry the highest impact if compromised. For these accounts, the password checks should be at least as strict as the standard workforce policy, and the checks that matter most are dictionary checks and denial of passwords reused from the same person's other accounts or derived from their username. Administrators usually accept stricter rules more readily, but the trade-off is that a long, complex password typed under pressure during an incident can slow recovery. Strong authentication such as OTP or a smart card is often the better control for these accounts, with passwords acting as a backup.
- Stricter dictionary coverage: Apply the same or broader word checks as the workforce policy.
- Separate admin accounts: Confirm that administrators use dedicated accounts, so user name checks are applied to those names.
- Break-glass accounts: Define how emergency accounts are stored, tested and rotated without weakening their checks.
- Second factor first: Decide which administrative actions require OTP or certificate authentication in addition to the password.
- Change control: Confirm who approves exceptions and how changes to the policy are logged.
Confirm with the security owner and the business owner which administrative actions justify stricter rules and how break-glass access will be tested.
Service accounts and automation identities often hold passwords that people never type. They are used by scripts, applications and backup jobs, and they are frequently stored in configuration files or secrets stores. For these accounts, the most useful control is usually not a human-facing complexity rule but a rotation and storage design, because a password that is long and random but stored in plain text is still exposed. Libpwquality checks still help when a person chooses or sets the password, but the trade-off is that strict interactive rules may push teams toward shared or unchanged passwords. Where possible, the better design is to replace passwords with keytabs, certificates or vault-issued credentials.
- Generated secrets: Use long machine-generated values rather than human-chosen ones where the application allows it.
- Storage location: Confirm where each secret lives and who can read it.
- Expiry and rotation: Agree how often each account is rotated and what breaks when it changes.
- Bind behavior: Check how applications handle password changes and expired passwords during LDAP binds.
- Ownership: Record a named owner for every service account so checks and exceptions have an accountable contact.
Confirm with the application owners which accounts can move to keytabs or certificates and which must keep a password, and document the exceptions before the policy is applied.
Contractors, partner staff and external collaborators present a mixed risk. They may be less familiar with your password standards, may use personal devices, and may leave the organization on short notice. The checks that matter most are user name checks, since these accounts often carry predictable names tied to their employer, and dictionary checks against common words and company names. The trade-off is that stricter rules may be hard to enforce across organizations that run their own identity systems, and the account lifecycle may be shorter than the password rules assume. Where partner access is federated or routed through a trust, the local FreeIPA password policy may not be the control that matters most.
- Company and name terms: Add the partner's or your organization's name to the checks if your deployment allows custom word lists.
- Account lifecycle: Confirm the expiry date of each external account and tie it to the contract end.
- Access scope: Limit external accounts to the host groups and services they need.
- Authentication path: Confirm whether these users sign in locally, through a trust or through an external identity provider.
- Support model: Decide who resets passwords for external users and how identity is verified before a reset.
Confirm with the sponsoring business owner and the contract owner who the external users are, how long they need access and whether the partner's own identity provider should carry the password rules.
Limits of libpwquality checks in FreeIPA and what to confirm
libpwquality rules run at password-change time and judge a candidate password against configured criteria. The cards below cover what those checks cannot see, so you can confirm each gap in vendor documentation or a test environment before you rely on the policy.
Breach corpora are not checked by default
A libpwquality check scores a candidate password against its own rules and dictionaries. It does not know whether a password already appears in a breach dataset. Checking real-world guessability against breach corpora needs a separate process that supplies that data, such as a screening service or a periodic offline audit. Confirm with the FreeIPA and libpwquality documentation whether your deployment has any such hook, and decide who owns the breach data and how often it is refreshed.
Dictionaries are only as good as their content
The dictionary check rejects words found in the dictionary files available on the server. A generic word list misses company names, product names, local place names and common regional patterns, while a large list may reject passwords users need. Confirm which dictionary paths the FreeIPA servers actually read, whether custom word lists can be added, and how a candidate password is tested in a lab before you change the default behavior.
User name checks depend on available attributes
The user name check compares the candidate password with the account name. It cannot test against attributes it does not receive, such as a full name, email prefix, or employee identifier, unless the check is given that data. Confirm which attributes FreeIPA passes to the check during a password change and during an administrative reset, and test a sample of accounts with names that include common variants.
Kerberos and LDAP clients may take different paths
A password set through the FreeIPA web UI or ipa command follows the server-side policy, but a client that binds over LDAP or changes a password through another interface may follow a different path. Some applications also store or present credentials in ways that bypass the check. Confirm, in a test environment, which entry points enforce the quality rules, including Kerberos password changes and LDAP modify operations, and document any path that does not.
Existing passwords are not re-evaluated
When you tighten libpwquality options, passwords already stored in the directory keep working even if they would now fail the new rules. The check runs when a password is set or changed, not on each login. Plan a rollout that forces change at a defined date or runs an offline review, and confirm with the vendor documentation how the new settings apply to existing accounts and service accounts.
Questions buyers ask about FreeIPA password quality checks
Can our own team configure FreeIPA password quality checks without a partner?
Yes, a team with FreeIPA administration experience can change password policy settings and test them in a lab, and many do. The harder part is deciding which rules to set, confirming how each Linux client and application handles a rejected password, and recording the decisions in a form your auditors can follow. A partner is useful when the team lacks time for policy review, cross-replica testing or documentation, not because the configuration itself is out of reach. Before deciding, list who owns the policy, who will test it and who will write the evidence.
What drives the effort of a password quality project?
The main drivers are the number of policy groups, how many FreeIPA servers and replicas must enforce the same rules, and how many client types and applications set or check passwords. Each application that changes passwords outside FreeIPA may need its own test. Documentation for auditors adds effort when controls must be traced from a written requirement to a configured setting and a test result. Ask the proposal to list these items separately so you can see which ones your environment makes larger.
What does our team need to provide for the work?
You need named policy owners who can approve rules on dictionary, user name and repeated character checks, a non-production FreeIPA environment with replicas that match production, and client machines or test accounts that represent your real login paths. Plan change windows for policy updates and for any server changes, and assign someone to confirm results on each replica. Without these inputs, the work tends to stall at the approval step, so agree on them in the proposal.
How long does a password quality project take?
The duration depends on the scope written into the proposal, including the number of policies, replicas, client types and applications to test, and how much documentation is required. DeployOpen does not publish durations for this work, so a timeline comes only from the written scope. Ask for the phases, the dependencies on your approvals and change windows, and the testing period for each replica before you compare proposals.
What should a quote for password quality checks include?
A useful quote lists the in-scope policies, the FreeIPA servers and replicas covered, the client and application types tested, and the test cases used to confirm each rule. It should name the deliverables, such as a configuration record, a test report and a short operations note, along with what you must provide and the change windows required. It should also state what is excluded, such as password rules in applications that do not read FreeIPA policy, and how changes after approval are handled. Fixed scope agreed in writing makes proposals easier to compare.
Do password quality checks alone satisfy a compliance requirement?
No. Configuring libpwquality checks in FreeIPA can help you meet a password requirement, but it does not by itself satisfy a compliance requirement. Independent auditors and certification bodies perform assessments and issue reports, and DeployOpen prepares systems, controls and evidence for those assessments without issuing any audit result. Ask your assessor which controls and evidence they expect, and map the configured checks to those requirements before the assessment begins.
What are the limits of libpwquality checks in FreeIPA?
The checks cover dictionary words, user name similarity, repeated characters and the other options libpwquality exposes, so they do not measure every kind of weak password. They do not stop reuse across systems, and they do not apply to every login path if an application stores or validates its own passwords. Confirm with your FreeIPA version's documentation which options your deployment supports, and test each rule with real client and application flows before relying on it.
How DeployOpen scopes and delivers FreeIPA password policy work
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA password policy work. For libpwquality checks, we start from your current password rules, your directory layout and the applications that set or verify passwords, then agree the changes in writing before any server is touched.
How we scope
- Review current FreeIPA password policies, groups and the rules that apply to each user population.
- Confirm which password-setting paths exist, including client tools, self-service and any LDAP applications.
- Agree in writing which libpwquality options, dictionary and user name checks are in and out of scope.
How we build
- Apply quality settings in a non-production IdM environment that mirrors your replica topology and policies.
- Test rejected and accepted passwords for each policy group, including the cases that matter most to your users.
- Record each configuration key and value so changes can be reviewed and reproduced later.
How we hand over
- Deliver a written configuration record, a test matrix with expected results and the rollout order used.
- Document known limits, such as checks that cannot see every password reuse or breach pattern.
- Walk your team through the policy model so they can answer user questions and update rules themselves.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and re-testing after FreeIPA or libpwquality updates are available as a retainer.
- Ask any provider to confirm how they will test changes against your own environment before rollout.
