How FreeIPA automember rules decide group membership
Group-based HBAC and sudo rules are only as accurate as the group membership behind them, and manual membership drifts as people change roles and new hosts appear. Automember rules fix this by placing users and hosts into groups automatically when their attributes match a rule, so access policy follows the directory instead of an administrator's memory. Teams need them once the number of users or hosts makes hand-maintained groups unreliable, or once HR-driven attributes such as department or host role already exist and should drive access.
FreeIPA is an integrated identity service that combines 389 Directory Server for the LDAP data store, MIT Kerberos for single sign-on, the Dogtag certificate system and SSSD on client machines. Automember rules operate in the directory layer, which means they feed the group objects that HBAC rules, sudo rules and other policies reference. A rule does not grant access by itself. It changes who belongs to a group, and the access granted to that group is defined elsewhere. Read the membership change and the policy change as one decision during review.
Before you enable a rule, confirm its exact syntax, the attributes it can match and how it behaves on existing entries against the documentation for your FreeIPA version, because rule handling has changed across the 4.x releases. Test the rule against a small set of accounts, then check which HBAC and sudo rules would apply to the new members. Pay particular attention to default groups and to broad attribute matches, since a rule that matches more entries than intended can give an unexpected user or host access that an allow-all rule or a sudo rule already permits.
Which automember rule fits which population
User automember rules place accounts into groups based on directory attributes such as department, job title, location or employee type. The decision is which attribute reliably reflects the access the person should have, and whether group membership alone should grant that access. In most deployments the group feeds HBAC rules, sudo rules or group-based password policies, so a wrong match becomes a wrong permission.
- Attribute source: Confirm where the attribute is populated, such as an HR feed, a provisioning job or manual entry, and how often it changes.
- Value consistency: Check that department names or job titles use one spelling and format across all records, since automember rules match exact values.
- Leavers and movers: Confirm how a changed attribute removes a user from the old group, because rules add members but the old membership may remain.
- Service and test accounts: Identify non-person accounts that might match a broad pattern and inherit access they should not have.
- Downstream rules: List every HBAC, sudo and policy rule that references the target group before enabling the automember rule.
Before enabling a user rule, export the current membership of the target group and compare it with the expected population from the source system.
Host automember rules place enrolled machines into host groups based on hostname patterns or host attributes such as a location or role field. The decision is whether naming conventions are stable enough to drive access. Hosts often gain access rights through host-based access control, so a host group that matches too broadly can open login paths on servers that were never meant to be included.
- Naming discipline: Confirm that hostnames follow a documented convention and that exceptions, renamed machines and decommissioned names are known.
- Enrollment timing: Check whether a host can be enrolled before its role is set, since an empty or default attribute may place it into the wrong group.
- Pattern scope: Test regular expressions against a full list of current hostnames, including development, staging and temporary machines.
- Host attributes: If a rule depends on a host attribute, confirm who sets it and whether a client can change it.
- Dependent access rules: Review which HBAC and sudo rules apply to the host group and whether a newly matched host could reach them.
Test the rule with the host list from your inventory system, and confirm that no machine appears in the group without an owner.
Default placement covers entries that match no specific rule, typically new users or hosts that arrive without complete attributes. The decision is whether a default group should exist at all, and if so, what it grants. A default group that carries access is the most common cause of accidental permissions, because it applies to every unmatched entry.
- Default group purpose: Decide whether the group is only a holding area for review or whether it should carry no access at all.
- Access grants: Confirm that no HBAC, sudo or policy rule references the default group unless that access is intended for every new entry.
- Incomplete records: Identify which attributes are often missing at creation, such as department or location, and whether the provisioning process fills them.
- Review queue: Assign an owner who checks the default group on a regular schedule and moves entries to their correct groups.
- Rule ordering: Test a set of sample entries with missing and partial attributes to see which group each one lands in.
Before relying on defaults, ask who receives the alert or report when entries accumulate in the default group, because unreviewed entries are where unintended access tends to remain.
Automember options and when each fits
This table compares the four ways a FreeIPA team can decide group membership: automember inclusion rules, exclusion conditions, default groups and manual membership. Read each row for its trade-off and the point where it should be checked against the FreeIPA release you run. The main takeaway is that automember is predictable only when its rules are narrow, tested and reviewed against the access rules that depend on those groups.
| Option | Trade-off | When it fits | Verify in your release |
|---|---|---|---|
| Attribute-based automember inclusion rule | Predictable when the attribute is controlled at source, but a broad filter can pull in accounts nobody intended | Stable populations such as a department or host class that HR or provisioning already keeps accurate | Confirm the rule syntax and which attributes can be matched in your FreeIPA version |
| Automember exclusion condition | Carves out exceptions without editing the inclusion rule, but adds a second logic path to review | Removing service accounts, test hosts or contractors from a group that otherwise matches | Confirm how exclusions are evaluated and whether they apply to rebuilt membership |
| Default group | Simple and easy to audit, but every new user or host inherits it, so it must never carry powerful access | Baseline membership such as a general staff group used only as a label for policy | Confirm which default groups exist on a fresh install and any changes in your release |
| Manually managed membership | Explicit and reviewable, but it depends on administrators remembering to add and remove people | Privileged groups, small exception lists and groups that need an approval step before use | Confirm delegation options such as member managers for your administrators |
| Rebuilding membership for existing entries | Brings older accounts and hosts into line, but can change access for many entries in one run | After a rule is added or corrected, to apply it to records created before the rule existed | Test on a copy or in a lab first and confirm the rebuild command and its scope for your version |
| Combining automember with HBAC or sudo rules | Makes access follow attributes automatically, so a wrong rule grants access without a separate approval | Access that must track role changes, provided each rule is tested with access tests before enforcement | Confirm the effect of group changes on existing HBAC and sudo rules in your environment |
Setting up automember rules in order
This sequence takes automember rules from an attribute inventory to verified group membership in production, so that every user and host lands in the groups you intended and no group quietly carries access it should not have.
Inventory the attributes that will drive grouping
Start by listing the attributes your directory already holds for users and hosts, such as department, job role, location, host class or operating system, and confirm where each value comes from, whether an HR export, an enrollment process or a manual field. Your identity team and the owners of the source systems do this work, and you know it is done when each proposed grouping attribute has a named source, a known set of values and a named owner who can answer questions about it. Attributes with inconsistent or free-text values should be flagged now, because rules will match them literally.
Define target groups and the rules that depend on them
For each group the rules will fill, write down which HBAC rules, sudo rules or other policies reference it, and what each of those policies allows. Decide which groups are user groups and which are host groups, and whether any group must stay manual. The output is a short table mapping each target group to its dependent policies and its owner. You are done when every target group has at least one named dependent policy, and any group that would grant access to no one or to everyone has been reviewed and either removed or justified.
Write the rules in a test environment
Create the automember rules in a non-production FreeIPA deployment that mirrors your production schema and sample data, using a realistic but non-sensitive set of users and hosts. Define the rule type for users or hosts, the attribute condition and the target group for each rule, keeping one rule per target group where possible so that changes are easy to trace. Record each rule in version-controlled text, such as an Ansible playbook or a scripted set of commands, so the same rules can be reproduced later. You know this step is complete when the rules load without errors and each rule is listed against the expected group.
Rebuild membership in the test environment
Run the automember rebuild for the affected user and host scopes in the test environment, so that existing entries are evaluated against the new rules and not only newly created ones. Rebuilding applies to entries that already exist, which is why it matters for an existing deployment. Check the result by reviewing the resulting group lists for each target group and comparing them with the sample data. Look for entries that landed in a group they should not be in, and for entries that should have matched but did not. The step is done when every group list matches the expectation you wrote down in step two.
Test the access effect of each group
Confirm what the group membership actually changes before anything reaches production. Use the access-testing tools available in your FreeIPA version, such as hbactest for HBAC rules, and check sudo rule matches for representative users and hosts. Compare the outcome with the policy you intended in step two. Pay particular attention to rules that could match more users than planned, and to any group that now grants access through a catch-all condition. This check is complete when each dependent policy returns the expected result for a set of test cases, and those cases are saved for future review.
Review the rules and approve the change
Have someone other than the author review the rule definitions, the rebuild output and the access test results. The reviewer should confirm that each condition is specific, that no rule matches an empty or missing attribute, and that the change record names the rules, the scope and the rollback approach. Approval is recorded when the reviewer has signed off on the change record, and the record is stored alongside the version-controlled rule definitions.
Apply the rules and verify production membership
Apply the reviewed rules to production during the change window your organization uses, rebuild membership for the same scope, and repeat the group list review on production data. Confirm that group counts and sample memberships match the test results, and that dependent HBAC and sudo policies behave as they did in testing. Keep a copy of the previous group membership and rule definitions so you can reverse the change if needed. The step is complete when production group lists match the approved test results and the change record is closed.
Monitor membership after the change
Schedule periodic reviews of automember group lists, especially after changes to the source attributes, new hires, new host classes or a migration. Watch for drift, such as entries whose source attribute changed but whose group did not, and for new entries that match a broad rule. Record each review and its findings. The review is effective when someone is accountable for it, the frequency is written down in your operations procedures, and findings lead to rule changes that go back through the same test and approval steps.
Rebuilding membership without surprises
Automember rules act on entries when they are added. Users and hosts that already exist in FreeIPA keep their current groups until you rebuild membership for them, which you do with the automember rebuild operation for users, hosts or both. The rebuild evaluates every matching existing entry against the rules, so a rule that looked harmless when written can add a large population to a group in one step. The risk is highest when the target group already appears in an HBAC rule, a sudo rule or a host group. For example, in an illustrative setup, a rule that maps a job title attribute to a group named sysadmins would quietly give every existing employee with that title login rights on production hosts. Before rebuilding, list the access rules that reference each target group, and confirm the exact rebuild options available on your FreeIPA version in the product documentation.
Take a backup before any rebuild. The ipa-backup tool offers full backups and online data-only backups, and a full backup is the safer choice before a change that touches many entries. Keep the backup off the server, record which server produced it, and note the time. The backup documentation also warns that the first server handles certificate renewal and CRL publication by default, and that restoring an outdated backup into an active replica topology can break replication. A backup is therefore for recovering a known state with a planned procedure, not for undoing a bad rebuild on a live multi-server deployment. Read the FreeIPA backup and restore page and confirm the restore steps for your topology before you rely on them.
Review the membership before and after the change. Export the member lists of every target group, and the member lists of the groups that feed your access rules, to files you can diff. Run the rebuild in a narrow scope first, such as a single known account, then widen it. After each step, compare the new lists with the saved ones and ask an access owner to confirm every added name should have the access attached to that group. Test the effect on real login paths in a non-production environment before applying the rule to production. Keep the before and after exports with the change record, because they are the evidence an auditor or incident responder will ask for when someone asks why an account gained access on a given date.
How automember rules grant access by accident
Automember rules run without a person reviewing each membership, so a group that was meant for reporting or ownership can quietly become an access path. The five cards below cover the points where a rule, a source attribute or a downstream policy can widen who gets in. Each one ends with a check you can run before and after a rule goes live.
Broad attribute matches
A rule keyed on a common value such as a department code, a location or an empty field can match far more accounts than its name suggests. Test the rule's condition against the full user and host population, not only the accounts you expect. Export the resulting membership and review it for accounts that should not be there, such as contractors, service accounts or former staff whose attributes were never cleared.
Groups referenced by broad HBAC rules
Automember adds members to a group, but access comes from the HBAC rules that name that group. If a rule grants access to a group that now receives automatic members, anyone matching the attribute gains login rights on the hosts in that rule. Before you add an automember rule, list every HBAC rule that references the target group and confirm each one still reflects the intended audience. Use ipa hbactest to check representative users against those hosts.
Source attributes changed by non-admins
Automember rules trust the attributes they read. If a user or helpdesk role can edit a field such as a title, department or host description, that person can add someone to a group by changing one value. Review which delegated roles can modify the attributes your rules depend on, and restrict write access to those fields. Record who changed a source attribute, because the membership change will appear without a separate approval step.
Membership flowing into sudo rights
A group that is added to a sudo rule grants command rights to every member on every host in that rule's scope. An automember match therefore reaches sudo as well as login, and the effect is easy to miss because the sudo rule itself was reviewed months earlier. For each group used by an automember rule, list the sudo rules that reference it and confirm the commands and host scope are still correct for the people now arriving automatically.
Rules left after reorganization
When a team is split, merged or renamed, the automember rules written for the old structure often keep running. Users still match the old condition, so they keep joining groups that tie to current access, while new staff may never match at all. Schedule a review after each reorganization that lists every rule, its target group and the policies that reference that group. Remove rules whose owner no longer exists and document who approved each remaining rule.
Questions teams ask before automating FreeIPA groups
How much effort does setting up automember rules take?
Effort depends mainly on how clean your directory attributes are, how many groups need automatic membership, and how many HBAC and sudo rules depend on those groups. A small set of rules keyed to one or two reliable attributes, such as a department code, is a short exercise. Rules that must read several inconsistent fields, or that feed access policy across many systems, take longer because each rule needs review, a rebuild test and a check of every access rule that references the target group. Ask any provider to break the work into attribute analysis, rule design, testing and cutover so you can see where the time goes.
Can our in-house team build automember rules without a partner?
Yes, if your team already administers FreeIPA and understands how automember rules interact with groups, HBAC and sudo. The core work is the same whether you or a partner does it: review attributes, write inclusive and exclusive conditions, rebuild membership in a test environment and verify results before production. A partner adds value mainly when you want an independent review of rules that touch access, or when your team lacks time for testing. Decide based on who will own the rules after handover and who will review changes to them.
What do we need to provide before the work starts?
You need named owners of the directory data, usually the people who maintain HR feeds, identity sources or manual user records, because automember rules are only as good as those attributes. You also need a test FreeIPA environment that mirrors production group and access policy, a change window for applying rules and rebuilding membership, and a list of the HBAC and sudo rules that reference the target groups. Confirm who approves changes to rules that affect access before the engagement begins.
How long does validation take for a large directory?
Validation time grows with the number of users and hosts, the number of rules and the number of access policies that depend on the resulting groups. A directory with a few thousand entries and a handful of rules can be checked quickly, while a larger estate with many rules and cross-team dependencies needs staged rollouts, comparison of expected and actual membership, and sign-off from each group owner. Ask for the validation steps and the criteria that must pass before production cutover, rather than a single number.
What is the main risk of an automember rule?
The main risk is that a rule places someone in a group that already grants access, such as a group referenced by an HBAC rule or a sudo rule. A broad condition, a missing exclusion or a bad attribute value can add users or hosts to that group without any manual approval. Before enabling a rule, list every access policy that references the target group, then run test cases that show who will be added and whether they should have that access. Keep those test cases so the same check repeats after future changes.
What should a quote for automember work include?
A written quote should list the groups in scope, the attributes each rule uses, the number of rules, the HBAC and sudo rules that depend on those groups, the test environment, the validation steps and the handover material. It should also state what is one-time work, such as rule design and testing, and what recurs, such as reviewing rules when HR data changes or when FreeIPA is upgraded. Ask whether the scope covers rebuilding membership and documenting rules for your auditors, and what happens if validation finds data problems that need fixing in source systems.
Does automember membership check whether a user should have access?
No. An automember rule adds members to a group based on attributes it can read, but it does not decide whether those members should have access. Access comes from the HBAC rules, sudo rules and other policies that reference the group. Engineers should therefore review the access policy separately and confirm with the FreeIPA About page overview of how FreeIPA components fit together before assuming a group change alone controls login.
How DeployOpen scopes automember rule work
DeployOpen puts automember work into a written scope before any rule is written. The scope starts with an inventory of where user and host attributes come from, such as HR exports, directory sources, enrollment tooling and naming conventions on hosts, because an automember rule is only as reliable as the attribute it matches. We also list which groups already exist, which of them feed HBAC rules, sudo rules or member managers, and which ones are only labels. That mapping is the decision point: each automember group is tied to the access rule it will influence, and the scope records who approves that link. DeployOpen implements and supports self-hosted platforms in your own infrastructure, so the work is done against your FreeIPA deployment and your data sources, and a quote follows from the scope written this way.
Next, rules are built and tested in a non-production FreeIPA that mirrors the production schema and group structure. The test plan covers the expected members of each group, the users and hosts that should not match, and the effect on existing HBAC and sudo rules, which should be confirmed with ipa hbactest and a review of the resulting group membership. Rebuild behavior, default group assignment and the handling of existing members are checked before anything reaches production. The scope should also state which environment will hold the rules, who may change them later, and how the test evidence will be kept. Confirm with your own platform team whether a second FreeIPA environment is available for this purpose and what it costs to keep it running.
The handover covers the rule set itself, a description of each rule and its intended members, the group-to-access mapping, the test cases with expected results, and the operating steps for adding attributes or rebuilding membership. Ask for these documents to be listed in the written scope with named owners and delivery dates. Recurring work after handover, such as reviewing rules when HR sources change or when new access rules are added, is usually a separate retainer and should be priced on its own line in the quote so that one-time build effort and ongoing support are not mixed together.
