Why sudo and HBAC rules need a separate migration from LDAP
If your LDAP directory holds sudoers entries and access rules, plan for those to move by hand. The `ipa migrate-ds` command carries users and groups, but it does not carry sudo and HBAC rules. The FreeIPA migration how-to states that these rules need manual migration through LDIF, so the export, mapping and testing work sits outside the directory migration itself. Teams that assume the user migration covers access policy often discover the gap only after cutover, when hosts that depended on sudo or login restrictions behave differently in FreeIPA than they did in LDAP.
The effort depends on three things you can measure before any work starts. The first is the rule count: a list of sudoers entries and access rules, exported from each directory server, tells you how much mapping is required. The second is host group structure: rules that apply to many hosts through shared groups are easier to map once, while rules tied to individual hosts multiply the testing. The third is how much the current rules rely on LDAP-specific attributes, such as custom object classes or attribute names that have no direct FreeIPA equivalent. Each of these needs a documented answer from your own directory before you request a quote, because a fixed-scope agreement depends on knowing what is in scope.
Start by asking your team or partner to inventory the sudo and HBAC objects in the directory, record which hosts each one targets, and flag any attribute that does not appear in the FreeIPA documentation for sudo and HBAC rules. Confirm the exact sudo and HBAC object classes in your own schema, since your directory may extend the standard ones. This inventory tells you which rules can be mapped directly, which need redesign, and which should be retired, and it sets the baseline for the per-host-group testing described in the rest of this page.
Which LDAP access objects map to FreeIPA sudo and HBAC rules
This table compares the LDAP access objects you are likely to export with their closest FreeIPA counterparts, along with the review each one needs. Treat every mapping as a candidate until someone has checked it against the source directory and tested it on a copy. The main takeaway is that the group and host structures move most reliably when they are rebuilt first, and the sudo and HBAC rules follow only after those objects exist.
| LDAP object | FreeIPA target | Migration notes |
|---|---|---|
| sudoRole entries | IPA sudo rule (sudorule) | Each sudoRole becomes a rule only after manual review of sudoUser, sudoHost, sudoCommand and sudoOption values. Options such as NOPASSWD or runAsUser need matching settings in the rule. Export the entries to LDIF and convert them by hand, because migrate-ds does not carry them. |
| sudoCommand values | IPA sudo command or command group | Commands must exist as sudo commands in FreeIPA before the rule references them. Wildcards and argument patterns in LDAP may not behave the same way, so confirm each command string on a test client. |
| sudoUser and sudoHost values pointing at groups | IPA user groups, host groups and netgroups | Map each referenced group to an existing FreeIPA group first. Nested or netgroup-style references need flattening or a deliberate rebuild, and any name that no longer exists in FreeIPA must be resolved before the rule is loaded. |
| Host groups and netgroups (ipaHostGroup, nisNetgroup) | IPA host groups | Host membership must be rebuilt from the enrolled host inventory. Confirm which hostnames are FQDNs in FreeIPA, since short names in LDAP can point at the wrong machine after cutover. |
| Access control objects such as host-based or service-based access (orgPerson access attributes, pam_access files) | IPA HBAC rules (hbacrule) with service and host groups | There is no one-to-one attribute copy. Rebuild each policy as a rule that names users or groups, hosts or host groups, and services such as sshd or login, then review the intent with the policy owner. Do not assume an LDAP allow list covers the same services. |
| Rules that allow everyone or use a default-deny fallback | IPA HBAC rule with allow-all or a narrowed rule set | FreeIPA evaluates HBAC rules as allow rules, so a source that relies on explicit denials needs redesign. Test the logins that should fail as well as those that should succeed, using hbactest. |
| Nested or conditional access logic in custom attributes or scripts | No direct equivalent (manual design) | Custom schema, shell scripts and PAM modules are outside migrate-ds and outside the LDIF mapping. Document each one, decide whether it is still needed, and rebuild the behavior in FreeIPA or on the host with a named owner. |
| Cutover per host group | Host group membership and rule enablement | Enable new rules for one host group at a time, check the affected logins, then widen the scope. Keep the old LDAP policy available until each group passes its tests, since rollback is simpler while both sources exist. |
Documented paths for moving rules into FreeIPA
FreeIPA offers no single command that moves every LDAP object. Users and groups have one documented path, sudo and HBAC rules need a manual route, and FreeIPA-to-FreeIPA moves use a separate tool. Knowing which path covers which object decides how much of the rule migration is left to your team.
User and group migration with migrate-ds
The ipa migrate-ds command moves users and groups from an LDAP server into FreeIPA, and it excludes Kerberos attributes that FreeIPA regenerates. It does not carry sudo rules or HBAC rules, so those need their own plan. Confirm the exact options for your release in the FreeIPA documentation before you run it on a copy of the directory.
Manual sudo and HBAC export through LDIF
The FreeIPA migration how-to states that sudo and HBAC rules need manual migration through LDIF. Export the rule objects from your source directory, then map each attribute to its FreeIPA sudo or HBAC equivalent. Expect group membership, host references and command lists to need the most attention, because those references may not exist under the same names in FreeIPA.
Testing rules with hbactest
Rules imported by hand can look correct and still deny or allow the wrong logins. Use the HBAC test capability before cutover to simulate a user, host and service combination and check the result against the source directory. Record each test case with its expected outcome so that the same set can be rerun after every change.
FreeIPA to FreeIPA moves with ipa-migrate
The ipa-migrate tool moves users, groups, sudo and HBAC rules, hosts, services and policies between two FreeIPA deployments over LDAP. It fits consolidation or rebuild projects, not migrations from OpenLDAP or Red Hat Directory Server. Confirm which objects it carries against your release and plan the manual follow-ups it does not cover.
Gaps that stay manual
Whatever the tools skip becomes a manual task, so inventory it before the first run. Typical gaps include policies that reference host groups that were never created in FreeIPA, and sudo options that depend on the source system's configuration. Record each gap with an owner and a decision, such as recreate, retire or accept, so nothing is lost at cutover.
Cutover in host group batches
Moving rules for all hosts at once makes failures hard to isolate. Group hosts by the policies that govern them, move one host group at a time, and keep the source rules in place until that group's logins and sudo behavior are verified. Ask your implementation partner to confirm the batch plan and rollback steps in writing before work starts.
How the LDIF export and mapping work step by step
Start by exporting every sudo and HBAC entry from the source LDAP directory as LDIF, because migrate-ds does not carry these objects into FreeIPA. The FreeIPA migration how-to states that sudo and HBAC rules need manual migration through LDIF, so this export is the working inventory for the whole project. Use a search filter that captures the sudo object class and the access-control entries your source uses, and keep the output in version control so each review pass can be compared against the last. Before mapping anything, open the file and list every object class and attribute present. Flag anything FreeIPA does not expect, such as vendor-specific schema extensions, custom attributes used by in-house scripts, or entries that describe groups rather than rules. Confirm the exact object classes your source directory uses against the FreeIPA sudo and HBAC schema in your own test installation, because naming differs between directory servers and this page does not assume a specific mapping.
Next, map each source rule to a FreeIPA sudo rule or HBAC rule and record three scopes for each: the hosts, the users or groups, and the commands or services. Each source entry should become one row in a mapping sheet with its original distinguished name, the target rule name, and the FreeIPA host group, user group and command group it will reference. Before import, consolidate duplicate and overlapping rules. Two entries that grant the same command to the same people on the same hosts should become one rule, and a broad rule that already covers a narrow one should be checked for whether the narrow one still adds anything. Consolidation reduces the number of rules an administrator must reason about during cutover and makes hbactest results easier to read. Then verify host group membership against the FreeIPA host inventory, not against the names in the LDIF. Hosts that were decommissioned, renamed or never enrolled will silently fail to match, so a rule can appear correct on paper while applying to no machine at all. Ask the platform team to confirm enrollment status for every host named in the mapping sheet.
How to cut over HBAC and sudo policy one host group at a time
This sequence moves sudo rules and HBAC policies from LDAP into FreeIPA in controlled stages, so each host group is tested, run in parallel and switched over before the LDAP rules are retired.
Inventory LDAP sudo and access rules
Export the sudo rule objects, access control entries and the host or host group membership they depend on from the existing LDAP directory, using LDIF. Record which hosts each rule applies to, which users and groups it names, and which commands or options it sets. The owner of each rule should confirm it is still needed. The step is done when every rule has a row in an inventory that lists its scope, its targets and its owner.
Group hosts into cutover sets
Arrange the inventoried hosts into host groups that match how they are administered, such as one application tier, one data center or one team's servers. Keep each set small enough that a rollback affects one owner's systems. Mark any host that carries rules from more than one set, because those hosts need an agreed order of changes. The output is a numbered list of host groups with the rules each one needs.
Map rules to FreeIPA sudo and HBAC objects
Translate each LDAP rule into a FreeIPA sudo rule or HBAC rule, with the matching user groups, host groups and service lists. Where a single LDAP entry covers several concerns, split it into separate FreeIPA rules so each one can be tested and removed alone. Note any attribute with no direct equivalent and decide how to handle it before import. Check the result against the inventory row by row. The step is complete when every LDAP rule has a mapped FreeIPA counterpart or a recorded reason for dropping it.
Import into a test FreeIPA deployment
Load the mapped sudo and HBAC rules into a test FreeIPA deployment that holds a copy of the users and groups, not production data. Confirm that the rules appear with the expected scope, that referenced groups resolve, and that no rule is left in an enabled state that targets production hosts. The output is a test realm where each mapped rule can be listed and traced back to its LDAP source.
Verify with hbactest and sudo checks
Run hbactest against representative user and host pairs from each cutover set, covering both allowed and denied cases, and record the service name used for each check. On enrolled test clients, confirm sudo behavior with the commands and users in the inventory, including denials. Compare results with the expected outcome from the LDAP rules. The step is done when every tested pair matches the LDAP behavior, and any mismatch has been fixed in the mapping and retested.
Run a parallel period for one host group
Enable the FreeIPA rules for the first host group while the LDAP rules remain in place for the same hosts, then confirm that access and sudo results agree. Watch authentication and sudo logs on those clients for unexpected denials. The length of the parallel period is set by your change process and risk owner, not by a fixed figure, so confirm it with them before starting. The step closes when the agreed period ends with no unexplained differences, and the owner signs off.
Cut over remaining groups and retire LDAP rules
Repeat the enable, compare and sign-off pattern for each remaining host group, then disable the LDAP rules for those hosts. Once every group has moved, remove the LDAP sudo and access entries, keeping an LDIF export and a dated record of the change for audit and rollback. Confirm with the owners that no host still depends on an LDAP rule. The output is a FreeIPA-only policy set with a retained archive of the original LDAP rules.
What drives the effort of a sudo and HBAC migration
This table lists the factors that change how much work a sudo and HBAC migration takes, and whether each one raises or lowers cost. Use it to see which parts of your LDAP policy estate will need the most mapping, review and testing, and what to ask for in a written quote.
| Driver | Effect on effort | What to ask for in a quote |
|---|---|---|
| Number of sudo rules | Raises cost: each rule needs mapping to a FreeIPA sudo rule, review and a test case | Count of sudo rules exported from LDAP, with a note on how many are still in use |
| Number of host groups and user groups | Raises cost: every host group needs its own HBAC or sudo scope and cutover step | List of host groups and user groups, with the hosts in each |
| Custom LDAP attributes and object classes | Raises cost: nonstandard attributes must be read, mapped or dropped by hand | Inventory of custom schema and attributes used by policy objects |
| Overlapping or conflicting rules | Raises cost: deciding which rule wins takes analysis and stakeholder sign-off | Plan for resolving overlaps and who approves each decision |
| Number of distinct server environments | Raises cost: each environment (production, staging, lab) needs its own test and cutover | Environment list with host counts and the change window each one allows |
| Depth of testing and change control | Raises cost: hbactest runs, sudo checks on sample hosts and sign-off add time | Test scope, evidence format and the approvals your change process requires |
| Rules that stay in LDAP or move by hand | Lowers cost when few exist; raises it when many need manual LDIF work | Confirmation of which objects are carried by migrate-ds and which need manual handling |
What usually goes wrong when access rules move from LDAP
Access rules are easy to copy and hard to verify. The risks below share one cause: the rules that come across may not mean the same thing on the new platform, on the hosts you actually run, or under the policies you expect. Each card names one failure and the check that catches it before users notice.
Rules that silently allow more
A sudo or HBAC rule that reads correctly in LDAP can grant more on FreeIPA when a wildcard, an empty host list or a missing user category is interpreted differently. The result is access that works but was never approved. Before cutover, compare each legacy rule with its FreeIPA counterpart and record who gains access, on which hosts, and with which commands. Confirm that every rule has an explicit owner and purpose.
Host groups that miss the fleet
Host groups built from an old inventory often omit servers added since, or include hosts that were retired and reused under the same name. Rules then cover the wrong machines or leave new ones unprotected. Generate host group membership from your current configuration management or asset source, not from the LDAP export, and reconcile the counts with what is enrolled in FreeIPA before any rule is activated.
Command paths that differ
A sudo rule that names /usr/bin/systemctl will not match a host where the binary lives at /bin/systemctl or where a distribution ships a different path. Commands that match on one distribution can silently fail on another, leaving administrators locked out of the very task the rule was meant to allow. Inventory the command paths on each OS family in your fleet and test each rule on a representative host of every family.
HBAC left at allow-all
HBAC is enforced only when rules are defined and the default is changed. If the imported environment still carries the allow-all rule, every enrolled user can log in to every host, whatever the legacy policy said. Check the status of the default allow-all rule after import, disable it only after the replacement rules are tested, and confirm with a non-administrator account that a denied login is actually denied.
Cutover before hbactest passes
Running hbactest is the quickest way to see whether a given user, host and service combination will be permitted, but it only helps if the results are reviewed before go-live. Moving a host group to FreeIPA while tests still fail, or while cases are untested, turns a policy error into a login outage. Make a passing hbactest run for every host group, service and user population a precondition of cutover, and keep the test cases in version control.
Questions teams ask before migrating sudo and HBAC rules
How much effort does migrating sudo and HBAC rules to FreeIPA take?
The effort depends mostly on how many rules exist, how many of them are still in use, and how much they depend on each other. Sudo and HBAC rules are not carried by the user and group migration tool, so each rule set has to be exported as LDIF, mapped by hand to FreeIPA sudo rules and HBAC rules, and tested. Teams with a small number of host groups and a clear rule owner for each usually finish faster than teams that inherited years of overlapping rules. Ask any partner to break the work into rule inventory, mapping, host group design, testing and cutover, and to state which of those steps assume a specific number of rules or hosts.
Can our internal team migrate sudo and HBAC rules without a partner?
Yes, a team with FreeIPA administration experience and read access to the LDAP directory can do this work in-house. The skills that matter most are reading the existing LDAP schema for sudoers and access control objects, understanding how FreeIPA groups map to host groups and user groups, and running hbactest against real login scenarios. Teams without that experience often underestimate the rule review, because the largest risk is not the export itself but deciding which old rules should still exist. A partner is most useful when the internal team lacks time, or when the migration must be documented for an assessment.
What must our team provide before the migration starts?
Three inputs carry most of the work. First, read access to the source LDAP directory, so the sudo and access control objects can be exported as LDIF and reviewed. Second, named owners for each rule set or host group, who can confirm whether a rule is still needed and who may approve changes. Third, test hosts that resemble production, with test accounts in each affected group, so login and sudo behavior can be checked before cutover. Also ask for a current list of which hosts consume which rules, because the mapping cannot be verified without it.
How long should a parallel run last, and what sets its length?
Plan the parallel run around the host groups and the change cycle of your organization, not around a fixed number of days. The LDAP source and the FreeIPA policy can both be active while hosts are moved group by group, and each group should run long enough to cover the login and sudo paths its users actually take, including batch jobs and scheduled tasks that run at unusual times. Factors that lengthen the run include shared service accounts, hosts with many local exceptions, and change freezes. Confirm the exit criteria in writing before starting, and agree who signs off on each host group.
Does migrate-ds move sudo and HBAC rules into FreeIPA?
No. According to the FreeIPA migration how-to, ipa migrate-ds migrates users and groups from other LDAP servers, while sudo and HBAC rules need manual migration through LDIF. This is why the rules are a separate workstream in the migration plan. Your team should still run migrate-ds for identities first, then handle the rules, so that the group membership referenced by each rule exists in FreeIPA before the rule is created. Check the migration how-to for the exact options and any attributes it ignores.
What does a fixed-scope engagement cover for this work?
A fixed-scope engagement covers the work agreed in writing before it starts: the inventory of LDAP sudo and access control objects, the mapping to FreeIPA sudo rules and HBAC rules, the host group design, hbactest test cases, the cutover plan per host group, and the documentation of decisions. Scope, deliverables and timelines are set out in that written agreement. Items commonly left out of scope include changes to source systems outside the directory, and decisions that belong to your rule owners. Ask for the deliverables and the acceptance tests to be listed by name, and for any assumption about host count or rule count to be stated, so the quote can be checked against them.
Where to confirm the import behavior in the FreeIPA documentation
Before you import a single sudo rule or HBAC policy, confirm the import path in the FreeIPA documentation for your own release. The FreeIPA migration how-to states that users and groups can be moved with ipa migrate-ds, but that sudo and HBAC rules need manual migration through LDIF. That single statement sets the plan for this topic: migrate-ds will not carry the access policies, so you will export them from the source directory, rewrite them as FreeIPA objects, and load them yourself. Read the how-to alongside the FreeIPA migration how-to so you know exactly which attributes and object classes fall outside the tool's scope before you design the mapping.
Next, read the FreeIPA to FreeIPA migration design page to confirm what ipa-migrate covers. That page describes moving sudo and HBAC rules between two FreeIPA deployments, which is a different source than an LDAP directory. Do not assume the two tools share the same behavior for your data. If your source is OpenLDAP or another directory rather than an existing FreeIPA realm, the design page tells you what the FreeIPA-to-FreeIPA path can and cannot do for you, and the manual LDIF route remains your working method.
Finally, check release-specific command options in the documentation for the FreeIPA version you run, and test them on a copy of the server before any production change. Options, defaults and supported attributes can shift between 4.x releases, so the flags in an older blog post or a previous project may not match your server. Record the exact version of ipa and the client tools you tested with, and confirm the options with ipa help on that host. Treat any command you cannot match to the documentation for your release as unverified.
How DeployOpen scopes and delivers an LDAP to FreeIPA rule migration
A sudo and HBAC migration is only as reliable as the scope agreed before work starts and the checks run before each host group moves. The cards below follow the order DeployOpen works in, from a written fixed scope through inventory, mapping, verification and cutover.
Fixed scope agreed in writing
Before work starts, scope, deliverables and timelines are agreed in writing. For this migration the written scope should name the LDAP sources in use, the sudo and access rules in play, the host groups that will move, and the test hosts used for verification. Ask for the list of excluded items too, such as rules that will stay in LDAP or be retired. A quote follows from that written scope, so unclear scope is the first thing to resolve.
Inventory and mapping review
Each sudoers entry and HBAC rule in the LDIF export is listed with its source object, its targets, and its intended FreeIPA equivalent. Reviewers check for rules that reference users, groups or hosts that no longer exist, and for wildcard commands or host patterns that FreeIPA will evaluate differently. The output is a mapping sheet the client signs off before any object is created in FreeIPA.
hbactest and sudo verification
Each mapped HBAC rule is tested with hbactest against representative user, host and service combinations taken from the inventory, including denied cases. Sudo rules are checked on test hosts with sudo -l run as the target users, so the team can see the effective commands before a rule reaches production. Results are recorded per rule so a failed case can be traced to one object.
Pilot cutover support
A single host group is cut over first, with the old LDAP rules still in place as a fallback until the pilot passes. DeployOpen supports the cutover steps, the observed login and sudo results, and the rollback decision for that group. The client decides when to widen the cutover to the next group, so each group moves on its own evidence.
Optional retainer after go-live
Once the last host group is live, some teams keep a retainer for changes to rules, new host groups and FreeIPA upgrades that touch the policy model. A retainer covers ongoing support for the migrated rules and the verification steps used to check them. It is priced separately from the fixed-scope migration, so ask for its scope, response expectations and what it excludes in writing.
