Can FreeIPA clients be upgraded in place to a new OS release?
Yes, for enrolled clients. Red Hat documents an in-place RHEL 8 to RHEL 9 path for IdM clients that uses the leapp utility, which handles the configuration changes on the machine, and the FreeIPA project notes that enrolled client machines do not need to be updated unless you want new features. That means a fleet of RHEL 8 clients can move to RHEL 9 without being removed from the domain and enrolled again. The main reading for the procedure is the Red Hat migration guide for Identity Management on RHEL 9, which should be read in full against your own leapp version before any machine is touched.
A client upgrade is a different job from a server upgrade. Clients hold a machine keytab, run SSSD, and depend on the directory and DNS services they reach, but they do not hold the certificate authority, replication topology or the directory data. Server upgrades are not done in place, so the RHEL 8 servers must be replaced by RHEL 9 replicas, as covered in the server migration section. Clients are the part of the fleet where in-place work is practical. Confirm with Red Hat which client configurations and SSSD settings the leapp run changes, and check that the target RHEL 9 release is one your identity servers already support.
What changes for clients and what each change requires
This table sets out each client-relevant change in an in-place upgrade or a FreeIPA release, with its effect on enrolled machines, the action the team takes and what to verify afterward. Read it row by row before scheduling a client upgrade, and treat any row without a confirmed requirement as an open item to check with the release notes and Red Hat documentation.
| Change | Impact on enrolled machines | Action the team takes | What to verify afterward |
|---|---|---|---|
| Leapp handling of IdM client configuration (RHEL 8 to 9) | Leapp handles the IdM client configuration changes during the in-place upgrade, so the machine keeps its enrollment without a new join | Run leapp on the enrolled client following Red Hat's guide for the RHEL 8 to 9 path, and confirm the client is in a supported state before starting | The machine still resolves its IdM identity, Kerberos ticket issuance works for a test account, and enrollment status reports as expected |
| SSSD configuration changes made by leapp | SSSD settings may be rewritten during the upgrade, which can change how users, sudo and SSH keys are looked up | Review the SSSD configuration files before and after the upgrade and compare them with the pre-upgrade copies | Confirm sssd starts cleanly, logins succeed for a domain user, and sudo and SSH key lookups return the expected results |
| Clients need no update unless new features are wanted | Enrolled clients keep working with upgraded servers without any client package change, so an upgrade is not forced by the server release alone | Decide per client group whether new client features are needed, and leave machines on their current packages where they are not | Record which clients stay on current packages and confirm they keep authenticating against the upgraded servers |
| DNS over TLS between clients and IdM DNS servers (introduced in FreeIPA 4.13.0) | This is a server-side feature that clients may use later, so enrolled machines are not changed by the server release alone | Confirm the client requirements in the FreeIPA 4.13.0 release notes and Red Hat documentation before enabling any client setting | Before enabling, check name resolution from a test client and confirm the resolver configuration on each machine matches the agreed plan |
Changes to the resolv.conf and DNS server list | Name resolution depends on at least two reachable DNS servers in each client's resolver configuration, so a changed list can break lookups | Verify the resolver setting on each client before and after the upgrade, and keep at least two DNS servers listed | Run forward and reverse lookups for IdM hosts and the Kerberos realm from each upgraded machine |
| Re-enrollment as the alternative path | Re-enrollment removes the old host entry and certificates, so the machine loses its existing identity state until the new join completes | Choose re-enrollment when in-place upgrade checks fail or the machine has drifted, and plan it per host with the replacement join | Confirm the host entry, host keytab, SSH host keys and access rules are present again and that users can log in |
| Client-side log and audit checks after upgrade | Authentication problems often appear first in SSSD and system logs rather than as an obvious failure | Collect SSSD and authentication logs for a window before and after the upgrade on a sample of machines | Check for new errors on Kerberos, SSSD and PAM after logins, sudo use and SSH key retrieval |
In-place upgrade or re-enrollment: which path fits which machine
Most enrolled RHEL 8 clients follow a common pattern: they were enrolled with the standard client tooling, use SSSD for identity lookups, and rely on the default PAM and sudo setup that the enrollment created. For these hosts, Red Hat's migration guide describes upgrading IdM clients in place from RHEL 8 to RHEL 9 with the leapp utility, which handles the configuration changes. The main advantage is that the host keeps its existing enrollment, its host principal and its keys, so users, SSH key lookups and access rules continue to work without a new enrollment step.
- Host identity stays intact: The machine keeps its Kerberos host keys and directory entry, so no new host object has to be created in FreeIPA.
- Configuration changes are handled by leapp: The utility applies the configuration changes it knows about, which removes manual edits from the standard path.
- Client upgrades are optional: The FreeIPA upgrade page notes that enrolled clients do not need to be updated unless you want new features, so this path is a choice rather than a server requirement.
- Rollback is a snapshot question: Confirm how you will restore the host if the upgrade fails, because in-place changes are not undone by re-enrolling.
- Confirm the baseline: Check the enrolled client version, SSSD version and any drop-in files against the steps in Red Hat's guide before you schedule the change.
Before you commit a fleet to this path, check that each host matches the standard enrollment pattern and that your test host upgrades cleanly with the same leapp steps.
Some clients carry local changes that leapp may not account for: hand-edited SSSD configuration, custom PAM stacks, sudo rules placed in local files, or scripts that depend on specific file paths. In this case the in-place path keeps the host identity but leaves more of the configuration to review after the upgrade. The trade-off is between preserving the enrollment and keys, and taking on the work of confirming that every local change still behaves as intended on the new release.
- Local SSSD edits survive, but may not behave the same: Review
sssd.confand any drop-ins, since option names and defaults can differ between releases. - PAM stacks need a diff: Compare
/etc/pam.dagainst the packaged defaults and confirm that each custom module still exists on RHEL 9. - Sudo rules need testing: Confirm which sudo rules come from FreeIPA and which come from local files, and test both sets after the upgrade.
- Re-enrollment removes local drift: A clean enrollment resets these files to the managed state, but any local customization must then be rebuilt by hand or through automation.
- Document the decision per host: Record which hosts were upgraded in place and which were re-enrolled, so later troubleshooting starts from a known baseline.
Confirm with your own change records which customizations are required for applications, and test each one on a non-production host before you decide between the two paths.
Some clients are kept only for a short period, are scheduled for decommissioning, or are being rebuilt on RHEL 9 anyway as part of a wider platform change. For these machines, the cost of carrying an in-place upgrade through may exceed the benefit of keeping the existing host identity. A clean enrollment on a freshly built RHEL 9 host avoids the upgrade steps entirely, and the trade-off moves to the work of creating a new host object, issuing new keys and updating any references to the old host name.
- Fresh keys replace inherited ones: Re-enrollment issues new host keys and a new host entry, which is cleaner when the old identity has no further use.
- Old host objects need cleanup: Plan how stale host entries, DNS records and host-based access rules for the retired machine will be removed.
- Application bindings may depend on the host name: Confirm whether any service, keytab or monitoring target refers to the existing host principal before you change it.
- Rebuilds reset local drift: A rebuild on RHEL 9 gives you a known starting point rather than a carried-forward configuration.
- Confirm the rebuild schedule: Ask whether the host will still be in service after the planned date, because that answer usually decides the path.
Before choosing this path, confirm the host's retirement date with its owner and check which keytabs and host references must move with it.
What to prepare on each client before the leapp run
Each enrolled client needs a recovery path, a documented configuration baseline, a healthy enrollment, and a proven rehearsal before leapp touches the OS. The four to six items below connect those steps, and each one produces an artifact you can review before the maintenance window opens.
Recovery path for each host
Take a full, verified backup of every client before the upgrade and confirm you can restore it to a known state. Record the backup location, the restore steps and who can run them. Snapshots from your hypervisor or cloud platform often serve as the fastest rollback, but confirm they capture the disk state at a consistent point. Test restoring at least one host so the procedure has been exercised, not just written down.
Inventory of local customizations
List every local change to SSSD, PAM, sudo, SSH and automation on each host. Include /etc/sssd/sssd.conf, files under /etc/pam.d/, /etc/sudoers.d/, /etc/ssh/sshd_config and any configuration management that writes them. The output is a diff-ready inventory that tells you which settings leapp will carry forward, which it may rewrite, and which you must reapply and test after the upgrade.
Enrollment and DNS health check
Confirm each host is enrolled, its Kerberos ticket and SSSD lookups work, and its DNS resolution succeeds. Check that /etc/resolv.conf lists at least two DNS servers, as FreeIPA recommends, and that both answer for IdM and client records. A host that fails this check before the upgrade will fail it after, and the failure is harder to attribute once the OS has changed.
Rehearsal on a test host
Build a test host from the same OS release, enrollment method, SSSD settings and PAM and sudo files as the production client, then run the leapp upgrade on it first. Log in with a domain user, test sudo, SSH key retrieval and any automation that depends on the host. The output is a pass or fail record per check, which becomes the acceptance list for production.
Named rollback decision owner
Assign one person to decide, during the window, whether a failed host is fixed in place, restored from backup or re-enrolled. Document the criteria in advance, such as login failure for a privileged account or failed sudo, and the time limit before the decision is made. The output is a written owner, a decision threshold and a contact path that the change board has approved.
The in-place upgrade sequence for an enrolled client
This sequence moves an enrolled FreeIPA client to a new OS release while keeping its identity, host record and keytab, and it ends with a checked, documented result for each host.
Confirm enrollment and server reachability
The engineer on the host confirms it is still enrolled and can reach its IdM servers before anything changes. Check the client's realm and domain settings, confirm that DNS resolves the IdM servers listed for the client, and confirm that Kerberos can obtain a ticket for a test account. The step is done when a ticket is issued, the host record appears in the IdM web UI or CLI, and the team has noted which IdM server the client used. A host that fails here should not enter the upgrade queue.
Back up and snapshot the host
The platform or systems team takes a full snapshot of the client, or a verified system backup, and records the current SSSD, Kerberos and PAM configuration files and the host keytab in a location outside the host. Store the copy under change control with the host name and date. The step is done when the snapshot restore has been confirmed to start, or when the backup has been listed and its files checked, and the rollback owner has written down how to revert. Ask your backup vendor or internal team to confirm the restore procedure for your environment.
Run the leapp preupgrade assessment
The engineer installs the leapp utility and runs its preupgrade assessment, which produces a report of inhibitors, warnings and informational items. Confirm the exact command syntax and package names against the RHEL 9 documentation for migrating to Identity Management, because command details can change between releases. The step is done when the report is saved and every inhibitor is either resolved or formally accepted by the change owner. Do not proceed to the upgrade while any inhibitor is open.
Resolve reported blockers and warnings
The engineer works through the assessment report, fixing inhibitors such as unsupported packages, third-party repositories, or configuration that leapp cannot migrate, and reviewing each warning for its effect on SSSD, Kerberos or sudo. Re-run the assessment after each change until no inhibitors remain. The step is done when a clean assessment report is saved with the change record. If a blocker involves an IdM-specific component, escalate to the team that owns the IdM server design before continuing.
Run the upgrade and reboot the host
The engineer runs the leapp upgrade on the host from a console or out-of-band session, not only over an SSH session that would be lost if the network changes, then reboots into the new OS release when leapp instructs. Keep the rollback point available until verification is complete. The step is done when the host boots into RHEL 9 and the operating system release reports the expected version. If the host does not boot, the rollback owner restores from the snapshot taken earlier.
Review SSSD and related configuration after reboot
After the reboot, the engineer compares the current SSSD configuration, Kerberos configuration and PAM and nsswitch settings with the copies saved before the upgrade. Confirm that the sssd service is running, that its domain configuration still points at the same IdM servers, and that any changes made by the upgrade are expected. Check the SSSD and related files for settings your team needs to review, and confirm the exact configuration keys against the RHEL 9 documentation. The step is done when the differences are reviewed, documented and accepted or corrected.
Verify login, access rules and key lookup
The team tests Kerberos login with a test account, confirms that HBAC rules allow and deny access as intended, confirms sudo rules apply to the expected users and groups, and checks that SSH public keys stored in IdM are returned during login. Record each result in the change record. The step is done when all four checks pass on the upgraded host. Any failure is a no-go for this host, and the team should decide between a fix and a rollback before the next host starts.
Apply the go or no-go check before the next host
Before any other enrolled client is upgraded, the change owner reviews the results for the completed host, including the assessment report, configuration review and verification tests. The owner records a go or no-go decision with a named approver. A go allows the next host in the batch to start. A no-go keeps the batch on hold until the cause is fixed or the host is rolled back. The step is done when the decision and the approver are recorded for that host.
What makes a client upgrade take longer
This table lists the factors that change how much work an in-place client upgrade takes, why each one adds effort, and what to do about it before the first host is touched. Count these items for your fleet first, then use the table to decide which clients can follow a standard path and which need individual planning.
| Driver | Why it adds work | How to reduce it |
|---|---|---|
| Number of clients | Every enrolled host needs a leapp run, reboot, and post-upgrade check, so effort grows with host count even when each run is routine. | Count enrolled hosts by OS release and group them into waves so the same runbook covers each batch. |
| Clients sharing a configuration profile | One profile change or one failure can affect every host that uses it, so a single problem spreads quickly across a group. | Group hosts by profile, upgrade one host per profile first, and confirm each profile passes before widening the wave. |
| SSSD and PAM customizations | Hand-edited sssd.conf and PAM stacks may not match what leapp expects, and local changes can be overwritten or conflict with new defaults. | Inventory every local change to SSSD and PAM files and record which ones are intentional and still needed. |
| Custom sudo rules and HBAC dependencies | Login and privilege behavior depends on these rules, so each host must be tested for who can log in and what they can run after the upgrade. | List the HBAC and sudo rules that apply to each host group and write a login and sudo test for each one. |
| Third-party agents and packages | Agents such as monitoring, backup, or security tools may lack packages for the target release or may need reinstalling after the upgrade. | Confirm vendor support for the target OS release for each agent before scheduling the host, and document reinstall steps. |
| Number of distinct client configurations | Each unique combination of OS release, SSSD settings, and installed software is a separate test case, so variety multiplies testing. | Reduce the number of configurations where possible and keep a short list of the ones you must support during the upgrade. |
| Availability of a test host | Without a host that mirrors production, problems appear first on live systems, and rollback options are limited. | Keep at least one test host per configuration profile, enrolled to the same IdM servers as production. |
| Change windows and approvals | Each wave needs a window, notice to owners, and sign-off, so calendar limits can stretch the schedule more than technical work does. | Ask change management for standard approval for the runbook and plan waves around existing windows and freeze periods. |
How SSSD configuration changes after the upgrade and what to check
The leapp path does more than replace packages. Leapp handles the IdM client configuration changes that the RHEL 9 release requires, so the SSSD configuration on an upgraded client is not the same file set it was on RHEL 8. Treat the result as a change to review, not as a host that is untouched. Before the upgrade, capture the state of /etc/sssd/sssd.conf, /etc/krb5.conf, the files under /etc/krb5.conf.d/ and /etc/sssd/conf.d/, /etc/ipa/default.conf, and the PAM and nsswitch files. Store the copies outside the host so you can diff them after leapp finishes. Confirm the exact key names, default values and file locations for your RHEL 9 minor release against the Red Hat migration guide, because the keys that leapp rewrites and the ones it leaves alone are release specific.
Compare four areas. First, the domain section: the ID provider, the authentication provider, the access provider, the domain name, and any ldap_ or krb5_ overrides you set by hand. Second, cache behavior: entry cache timeouts, and whether offline login (cache_credentials) is still enabled and behaves as your policy expects. Third, local overrides: ipa_* settings, override_homedir and override_shell values, ID views, and any drop-in files that leapp may have left in place or regenerated. Fourth, anything you edited outside the IdM tooling, since a rewrite can silently drop a manual change. Keep a short list of the keys you depend on and mark each one as unchanged, changed on purpose, or changed unexpectedly.
Verify behavior, not just file contents. On a test host first, obtain a Kerberos ticket with kinit, confirm it with klist, and check that the ticket renews. Log in over SSH with a key from the directory and confirm that ipa key retrieval through SSSD still returns the expected key. Test a user that your HBAC rules allow and one they should not reach, and confirm that both results match the pre-upgrade baseline. Run sudo -l for a user covered by sudo rules. Repeat the login test with the network to the IdM servers blocked, if you rely on offline login. Only after these checks pass should you move the rest of the fleet, and keep the pre-upgrade files available so that a rollback or a re-enrollment decision can be made with evidence.
Questions teams ask before upgrading FreeIPA clients
What drives the cost of upgrading FreeIPA clients in place?
The main cost is the labor to plan, test and carry out the upgrade, and that labor scales with how many hosts you have, how varied their roles are and how many of them run custom SSSD or PAM settings. Most of the effort is one-time: building the runbook, testing on representative hosts and fixing what the test exposes. Recurring costs are smaller and come from the next OS cycle or from ongoing support if you buy a retainer. When you request a quote, ask for the scope by host group, what testing is included, how rollback is handled and which items are one-time versus recurring.
How long does an in-place client upgrade take?
Duration depends on the number of host groups, the complexity of each host's configuration and how many change windows your organization can use. Pace is usually set by testing and by approvals, not by the upgrade tool itself. Hosts that share a role can often move in batches, while database, application or identity-dependent hosts need their own windows. Ask any provider for a timeline built from your host inventory and your change calendar, and confirm the assumptions behind it.
What does our internal team need to provide?
Your team needs administrative access to the test and production hosts, a named owner for each host group and access to the FreeIPA server to check enrollment state. You also need test hosts that match production in OS version, SSSD configuration and application logins, plus change windows that cover rollback. Someone must be able to approve the SSSD configuration changes that come out of testing. Confirm these inputs before the schedule is agreed, because missing access or owners are a common cause of delay.
Can our team upgrade FreeIPA clients without a partner?
A team with Linux administration experience and a clear inventory can do this alone, especially for a small number of standard hosts. The Red Hat migration guide says IdM clients can be upgraded in place from RHEL 8 to RHEL 9 with the leapp utility, which handles the configuration changes. A partner helps most where hosts have custom SSSD or PAM configuration, where many host groups must be coordinated or where the team lacks time for testing. Decide based on your host variety and available staff, and ask a partner to show how the work will be scoped in writing.
Do the FreeIPA servers need to be upgraded first?
Server upgrades are a separate path with their own planning, and you should not treat them as a prerequisite that you complete in the same window as client work. The FreeIPA upgrade page says enrolled client machines do not need to be updated unless you want new features. Plan the server path first if your clients depend on features only the new server release provides, and confirm compatibility between your server and client versions before the client window. Check the server upgrade topics in this section for the steps that apply to your topology.
What should we check in SSSD after the upgrade?
Confirm that the host still joins the realm, that Kerberos tickets are issued for test users and that SSH and sudo logins behave as before. Review the SSSD configuration, since leapp handles the standard changes but custom options in sssd.conf still need review. Verify that offline login and home directory settings match your policy. Record the results for each host group so you can compare them with the pre-upgrade baseline and roll back a group if a check fails.
When is re-enrollment cleaner than an in-place upgrade?
Re-enrollment is usually cleaner when a host has heavily customized or inconsistent configuration, when it was built from an old image, or when you are also changing its hostname, domain or role. It also suits hosts that can be rebuilt quickly and whose data is easy to restore. In-place upgrades fit hosts with stable configuration that you can test and roll back. Make the choice per host group, and confirm with your test results and your rebuild process before you commit to either path.
How DeployOpen scopes and delivers a client upgrade
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA client upgrades. Engagements are fixed-scope, so the written scope sets what gets upgraded, tested and handed over before any work starts.
How we scope
- Inventory enrolled clients by OS release, SSSD version and the services each host relies on for login
- Agree in writing which hosts move in place and which are re-enrolled, with the reasons for each
- Define the test hosts, rollback points and acceptance checks that the written scope will cover
- Confirm which parts of the upgrade need your team, your change window and your approvals
How we build
- Run the leapp in-place upgrade on pilot clients first, then on the agreed production groups
- Review SSSD and related configuration after the OS change and correct drift against your baseline
- Verify Kerberos login, SSH key lookup, sudo and host access rules on each upgraded machine
- Record each step, result and exception in the test evidence delivered with the engagement
How we hand over
- Deliver a runbook covering the upgrade sequence, checks, rollback steps and known exceptions
- Walk your operations team through the procedure so they can repeat it on the remaining hosts
- Provide a list of hosts still on the old release, with the planned path for each one
- Document configuration changes so your team can review them against your own policies
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the handover
- Retainers can cover later FreeIPA client updates and the next OS release on your schedule
- Ask any provider to confirm response times, scope boundaries and who performs the work in writing
- Quotes follow from the written scope, so a clear inventory of hosts makes the quote easier to compare
