FreeIPA password policies per group

How FreeIPA password policies per group fit your access model

One global password rule rarely fits everyone. Administrators with broad reach, service accounts that cannot easily rotate credentials, and general staff who log in many times a day each carry different risks and different operational costs. In FreeIPA, you can attach password policies to groups and give each policy a priority, so the rule that applies to a user depends on the groups that user belongs to. The policy is attached to a group, and priority decides which policy wins when a user matches more than one.

A password policy in FreeIPA controls the settings that shape how credentials behave: how long a password lasts before it must change, how long it must be, how many previous passwords are remembered so they cannot be reused, and how failed attempts trigger lockout. Teams usually need separate policies when a group has a different threat profile or a different tolerance for friction. Privileged administrators often justify stricter lifetimes and lockout thresholds, while service-related accounts may need settings that do not interrupt automated logins. Before you split policies, list which groups exist, which accounts belong to more than one of them, and which account types you cannot change interactively.

Treat this as a planning and testing exercise, not only a settings change. Overlapping group memberships can produce a result you did not intend, and a priority mistake can silently weaken or block access for a population. Build a test matrix with representative users from each group, confirm the effective policy for each one, and check how a password change or failed login behaves before you apply anything to production. Confirm the exact options and their behavior in the FreeIPA documentation for your release, and review the FreeIPA About page for the components involved in authentication, since password checks flow through the directory and Kerberos layers.

Which password settings to vary by group and when each fits

This table compares the password settings a FreeIPA group policy can shape, the audience each usually suits and the trade-off it brings. Read each row alongside the vendor documentation for your installed version, because option names and behavior are version-specific and should be confirmed before you set values.

Setting	Usually fits	Trade-off and what to confirm
Maximum password lifetime	Staff and contractors with routine password rotation requirements	Frequent expiry raises help desk load and can push users toward predictable passwords. Confirm how expiry interacts with Kerberos and SSSD clients in your version.
Minimum password lifetime	Admins and staff who must not cycle back to a known password immediately	Blocks quick rotation but can lock out a user who needs an urgent change. Confirm the unit and the exemption path for administrators.
Minimum length and character rules	Admins and privileged accounts, typically stricter than staff	Longer or more complex rules can conflict with passphrase guidance and with password-based service logins. Confirm which character classes the policy enforces and how existing passwords are handled.
Password history	Admins and privileged accounts where reuse is a review finding	A longer history stops reuse but increases the chance of frustrated changes. Confirm how many prior passwords are retained and whether history applies on administrator resets.
Failed-login lockout threshold	Staff and contractors exposed to remote or external login attempts	A low threshold protects against guessing but can lock out legitimate users and service retries. Confirm which login paths count toward failures.
Lockout reset and duration	Staff where self-service recovery is acceptable, and admins where manual unlock is preferred	Automatic reset reduces tickets but slows attacks less. Confirm whether lockout is time-based or requires an administrator unlock in your version.
Service accounts	Non-interactive accounts used by applications and automation	Rotation and lockout rules can break jobs that cannot be updated on schedule. Confirm whether service accounts should be exempted or moved to keytabs or other credentials, and document the reason.
Group priority	Any deployment where users belong to more than one group	When policies overlap, priority decides which settings apply. Confirm the tie-breaking rule and test a user who sits in several groups before go-live.

How to build group password policies in order

This sequence turns a single password rule for everyone into separate, tested policies for admins, service accounts and staff, each with a clear owner and a documented rollout.

Inventory the groups that need different rules
Start by listing every user and service group in the FreeIPA deployment and marking which ones truly need different password lifetimes, lengths, history or lockout settings. Typical candidates are administrators, service accounts, helpdesk staff and general staff, but the list should come from your own directory, not from a template. The security lead and the directory owner sign off on the list. The output is a short table of group name, member count, and the reason each group differs. Check: every group in the table exists in FreeIPA and its membership matches what the owners expect.
Map each group to its owner and authentication path
For each group, record who owns it, and how its members authenticate: password at the web UI or SSH, OTP tokens on top of a password, or a Kerberos keytab for non-interactive service accounts. This matters because a password lifetime or lockout setting does not apply the same way to a keytab-based account as it does to an interactive user. Confirm the path with the application owners rather than assuming it. The output is a mapping sheet that names each group owner. Check: each group has one named owner and one documented authentication path.
Define the global baseline policy
Set the global password policy in FreeIPA first. This is the fallback that applies to any user who is not in a more specific group policy, so it should be the strictest rule that every staff member can meet without workarounds. Record each value (minimum length, maximum lifetime, history count, lockout threshold and reset window) in the change record with its reason. The global policy is the reference point for every group override that follows. Check: displaying the global policy in the admin tools returns the same values as the change record.
Create group policies with distinct priorities
Create one password policy per group that needs a different rule, and attach each to its group. Each policy has a priority value, and when a user belongs to more than one group with a policy, the lowest-numbered priority wins. Assign priorities deliberately so that a narrow group, such as administrators, is not silently overridden by a broader group. Write down the priority order and the expected winner for any user who belongs to two policy groups. Check: no two policies share a priority that could produce an ambiguous result for a shared member.
Confirm effective policy with test accounts
Create one non-production test account per group, add it to that group only, and confirm the effective password policy it receives. Then add the same account to a second policy group and confirm the priority rule resolves to the expected winner. Try a password change that should fail under the new policy, such as one that is too short or reuses a recent password, and check that it is rejected. The output is a test log with account, group, expected value and observed value. Check: every test account shows the policy you intended, and no test account receives the global baseline by mistake.
Verify service accounts still authenticate
Before rollout, test each service account and keytab-based integration against the new policies, not just interactive logins. Confirm that Kerberos ticket requests still succeed, that keytabs were not invalidated by a password change, and that any application relying on a password-based bind still connects. Expiry and lockout settings that suit people can break scheduled jobs, so record which service accounts were tested and the result for each. Check: every service account in the mapping sheet completes its normal authentication from the test environment without a password error.
Roll out with a documented change record
Apply the tested policies to production in a planned window, with the change record listing every policy name, its priority, its members, the test results and a rollback step. Notify the owners from step two so that users know when password rules change and what they must do. After the change, confirm the effective policy for one live account in each group and check the directory logs for unexpected lockouts. Keep the change record with the test log so that an auditor or a later administrator can see what was set, why and when. Check: the change record is filed, and the post-change checks match the test results.

Policy design for admins, service accounts and staff

Administrative accounts carry the most risk in a FreeIPA deployment, because they can change policies, enroll hosts and reach certificate and DNS management. Design their password policy as the strictest in the directory, with a longer minimum length, a password history that stops quick reuse, and a lockout threshold that slows online guessing without locking out an administrator during an incident. Keep the stricter policy on a dedicated group so it does not spill onto staff.

Separate accounts: Give each administrator a privileged account used only for administration, and a standard account for email and browsing.
Stricter lifetime: Set a shorter maximum password lifetime for the admin group than for staff, and confirm how expiry interacts with Kerberos ticket issuance in your version.
History and reuse: Use password history to block recycled passwords across rotations.
Lockout planning: Pick lockout thresholds that stop guessing while leaving a documented break-glass path for the admin team.
Priority handling: Confirm which policy wins when a user belongs to several groups, using the policy priority settings.

Before enforcing, check the effective policy for a sample admin account and confirm the lockout recovery steps with your identity team.

Risks of overlapping policies and lockouts

Group password policies are easy to add and hard to reason about once several apply to the same person. The risks below come from policy overlap, from rules written for humans being applied to service accounts, and from changes nobody can trace later.

Overlapping groups with unclear priority

A user in three groups can inherit three policies, and FreeIPA resolves the conflict by policy priority, not by which setting is strictest. Lower-priority values are not the result you expect when a new group is added later. Before go-live, list every policy, its priority and its members, then test a user from each intersection with ipa pwpolicy-show for the account in question. Keep one policy per audience so a reader can answer which rule applies to a given account in one step.

Lockout rules that catch service accounts

A lockout threshold written for staff will also lock automated jobs that retry with a stale password after a rotation. A failed cron job or integration can then block an account used by several systems at once. Place service accounts in their own group with a lockout policy designed for non-interactive use, and confirm which hosts and services authenticate with each account before applying a stricter threshold.

Lifetime rules that break scripts

A maximum password lifetime that forces a change on an account used by scripts or batch tasks stops those tasks on the day of expiry. The failure looks like an outage, not a policy event. Exempt non-interactive accounts from forced expiry only through a documented exception, pair them with a rotation process in your secrets tooling, and set an owner and a review date for each exception.

History rules that conflict with password managers

Strict password history combined with generated passwords can push staff to reuse patterns or store passwords in less controlled places. Users who cannot pick a new value that satisfies history and complexity at the same time often write them down. Test the history and complexity settings with the password manager your staff use, and document the expected behavior in the helpdesk runbook.

Lockout as a denial-of-service path

Account lockout can be triggered on purpose by anyone who knows a username. An attacker who repeats failed logins can lock out a privileged user during an incident. Use a lockout threshold and duration that protect administrators without making their accounts easy to disable, and pair lockout with monitoring of failed authentications so bursts are visible. Confirm the lockout behavior with a non-production account first.

Policy changes without an audit trail

A policy edited by an administrator with broad rights can weaken controls with no record of who changed the setting or why. Limit who may modify password policies, keep changes in your change process, and review the directory's audit output for policy objects on a regular schedule. Ask your auditor which evidence they expect for the policy change history before the assessment starts.

How password policy interacts with OTP and Kerberos settings

A group password policy alone does not define the assurance level of an account. Once a user also has an OTP token, the lifetime, length, history and lockout values in a policy govern only the password factor, so an administrator should decide what the second factor is meant to prove before adjusting those values. FreeIPA supports two-factor authentication with HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including software tokens and hardware tokens such as YubiKeys, and it can proxy OTP checks to an existing RADIUS server, according to the FreeIPA OTP design page. Confirm in your version which accounts actually require an OTP check and whether that requirement is enforced for each access path, such as SSH, the web UI or service logins, before you treat a stricter password rule as the control that matters.

Lockout and password lifetime mean different things once MFA is in place. A failed password attempt followed by a missing or wrong token is still a failed authentication, but the lockout threshold you set for a privileged group may need to be reviewed against how often legitimate users mistype a token or lose a device. Password expiration also deserves a separate decision for accounts whose password is only one of two factors, since frequent forced changes can push staff toward weaker passwords without changing what an attacker who holds a stolen token can do. Test the policy with a real enrollment and a deliberate failed login for each group, and record the observed lockout behavior so the setting is justified in writing.

The Kerberos settings that MFA depends on must be checked alongside the password policy, not after it. OTP-backed logins are issued through the MIT Kerberos KDC, so ticket lifetimes, pre-authentication requirements and the options that carry authentication indicators determine whether an OTP check is actually enforced for a Kerberos ticket. Review these values for each group that relies on OTP, and confirm with the FreeIPA documentation for your release how the Kerberos and OTP settings interact before you rely on them. Document the result in your access review, since an auditor will ask how the password factor, the token factor and the Kerberos ticket policy combine for each privileged group.

What to confirm in your environment before rollout

Group password policies only behave as designed on the release, topology and applications you actually run. The cards below list what to verify in your own test realm, and where to check with the vendor, before any policy reaches production users or administrators.

Installed release and policy behavior

Confirm the exact FreeIPA release on every server and whether the password policy behavior you need is documented for that version. Recent 4.x releases have included security fixes that changed authentication checks, so a policy tested on one release may not match another. Check the release notes for your version, then reproduce the lockout and expiry cases in a test realm. Do not assume behavior carried over from an older install.

Replicas holding policy data

Count the replicas that will serve authentication for each group and confirm that a policy change has reached all of them. Policies are stored in the directory and replicate between servers, so a user may hit a server that has not yet received a new setting. Check the replication status after each change, and test a login against each site before you rely on the new lifetime or lockout value.

Password versus Kerberos or certificate apps

Inventory which applications accept a typed password, which use Kerberos tickets and which use certificates or OTP. Group password policies govern only the password path, so a service that uses keytabs or certificates will not follow the same expiry or history rules. List each application, its authentication method and its owner, and decide with the owner which accounts the policy should cover.

Compliance values and sign-off

Ask your compliance lead which control requirements set minimum length, maximum age, history or lockout values, and who approves the chosen settings. Use the control IDs and titles from your framework rather than a generic password rule. DeployOpen prepares evidence of the configured values, but independent auditors decide whether the controls are met. Record the approver and the date in your change log.

Backup and restore of policy data

Read the backup documentation for your release and confirm how policy objects are captured by full and data-only backups. Restoring an outdated backup into a live replica topology can break replication, so restore into a separate test realm first. Verify that a restored server returns the same group policies and priorities before any restore is used in production.

Priority and group membership overlap

Map which users belong to more than one group that carries a policy, and check which policy wins under your priority numbering. Overlapping memberships can produce a policy that nobody intended, especially for administrators who are also staff. Test a sample account from each overlapping set, and document the resulting setting before enforcing it.

Questions buyers ask about FreeIPA password policies per group

What drives the cost of setting up per-group password policies in FreeIPA?

The cost is driven by how many distinct policies you need, how well your groups already reflect real roles, and how much existing configuration must be reviewed. Creating a policy in FreeIPA is quick once the requirements are written down, so most of the effort goes into agreeing the requirements with security, compliance and application owners. A partner quote should separate the design workshop, the configuration and testing work, the documentation of the resulting policy model, and any follow-on support. Ask for each component to be priced and for a list of the groups and policy priorities it covers.

How long does a per-group password policy rollout usually take?

No duration can be stated here without a written scope, so treat any figure you hear with caution. The main drivers are the number of policy tiers, the size and state of your existing user and group structure, whether any service accounts depend on current password behavior, and how many approval rounds security and compliance teams require. A small directory with three clearly separated groups moves much faster than one where staff, contractors and service accounts share groups. Ask the vendor to break the timeline into design, test, cutover and monitoring phases.

What does the client team need to provide for this work?

You need a named owner for the identity directory, someone who can approve password rules for each population, and access to a non-production FreeIPA environment that resembles production. Security or compliance staff should provide the written password requirements their policies already cite, and application owners should list any system that authenticates with passwords rather than Kerberos tickets or keys. Plan for time from your team to review group membership, because policy priority depends on which groups users belong to. Confirm these inputs in the written scope so the work does not stall waiting for them.

Can an internal team set up per-group password policies without a partner?

Yes, a team with FreeIPA administration experience can configure password policies with the ipa pwpolicy commands and the web UI, provided it has tested in a lab first. The difficult part is rarely the command syntax. It is deciding the policy priorities, confirming how overlapping group memberships resolve, and documenting the result so auditors can follow it. A partner adds value when the team lacks time, when policy requirements are contested, or when evidence must be assembled for an assessment. Whichever route you choose, ask for a written record of the policy design and test results.

How do we test password policies without locking out users?

Test each policy against a set of test accounts in a staging FreeIPA deployment before any change reaches production. Confirm that lifetime, minimum length, history and lockout values behave as designed for each group, and check that a user who belongs to more than one group receives the expected policy. Verify that service accounts and automated logins that rely on passwords still work, because a lifetime that expires silently can break jobs. Schedule production changes outside peak hours, keep an administrator session open, and have a documented rollback that restores the previous policy values.

Can we change password policies after rollout, and what does that require?

Yes, policies can be changed after rollout, but each change affects the users in the affected groups, so it needs the same review as the original design. Record the current values, the reason for the change, and the test evidence before editing, and make the change through a controlled process rather than ad hoc edits. Changing a priority or group membership can alter which policy applies to a user, so check the effective result for representative accounts. Ask any partner to include a change procedure and a short review in the support agreement.

How do per-group password policies relate to MFA and compliance evidence?

Password policies control how passwords are created, changed and locked out, while multi-factor authentication adds a second factor, so the two should be designed together rather than treated as substitutes. FreeIPA supports OTP tokens and can proxy checks to a RADIUS server, which you should document alongside the password rules for each population. For compliance, DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue any audit report or certification. Ask your assessor which control requirements they expect to see evidenced, then keep exported policy settings and test records as evidence.

Is an open-source FreeIPA policy setup covered by a license fee?

FreeIPA is licensed under GPL-3.0-or-later and is a community project with no paid edition of its own, so there is no software license fee to budget. Costs come from the infrastructure you run it on, the staff time to design and operate policies, and any services you buy for implementation or support. Ask any vendor to state which parts of the quote are software-free labor and which are third-party products or subscriptions, and confirm that any operating system or platform subscription you use is priced separately.

How DeployOpen scopes and delivers FreeIPA password policy work

DeployOpen plans, implements, documents and supports FreeIPA inside your own infrastructure, including the group password policies that set lifetimes, lengths, history and lockout for each population. Engagements are fixed-scope, with the written scope agreed before work starts.

How we scope

Inventory the user groups, service accounts and admin roles that need different password rules.
Record the priority order, lifetime, minimum length, history and lockout values for each policy in writing.
Confirm which identity assurance and audit requirements the policies must support, and who signs off.

How we build

Create group password policies on a non-production FreeIPA deployment and check which policy applies to each user.
Test password changes, expiry warnings, lockout and history behavior with sample accounts for each group.
Review service accounts separately so rotation settings do not break the applications that depend on them.

How we hand over

Deliver a written policy register with group, priority, settings and the owner responsible for each change.
Document the test cases used to confirm each policy, so they can be repeated after later changes.
Walk your administrators through adding users to groups and checking which policy takes effect.

How we support

Review policy changes and group membership changes before they reach production, under a retainer if you want ongoing help.
Check policies again after FreeIPA upgrades or security releases, and confirm that behavior has not shifted.
Keep the policy register current as teams, roles and compliance requirements change over time.