Why FreeIPA upgrades and support become a standing job
A FreeIPA domain is not install-once infrastructure. It authenticates Linux hosts, users and services, so every FreeIPA release and every operating system under each server becomes a recurring maintenance item. Many teams handle routine work in-house, but the question to settle before go-live is who will carry it: who has the time, the change windows and the skills to upgrade identity servers without breaking logins. Make that decision early, because the first urgent security release is a poor time to find out nobody owns it.
The most visible trigger is a stabilization release. FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and it hardened authentication checks across the API. Start by recording the FreeIPA version on every server, then read the 4.13.4 release notes against your own deployment. A version gap on a domain controller is a security exposure, not just a version number, so the upgrade plan should state how quickly each class of server will be moved.
Other triggers are less predictable. An operating system can reach end of life on a replica server, which forces a rebuild or an in-place upgrade of that host. An aging replica may need replacing when its hardware or OS is no longer suitable. Certificate renewal checks matter too, because the first server handles certificate renewal and CRL publication by default, so an expired or misconfigured CA component can stop certificate issuance across the domain. Confirm the renewal and CRL state on that server as part of every maintenance cycle.
The main cost of this work is staff labor, since FreeIPA is licensed under GPL-3.0-or-later and is a community project with no paid edition. Expect one-time effort for the initial upgrade plan, lab rehearsal and backup testing, then recurring effort for each release, OS lifecycle event and certificate check. Ask any partner for a written scope that lists replica count, operating systems in use, the upgrade order, backup verification with ipa-backup, rollback steps and how urgent security releases are handled. Those items drive the quote more than the software does.
What FreeIPA upgrade and support work includes
These six work packages keep a FreeIPA domain patched, upgraded and recoverable after go-live. Each one ends in a written record the client keeps, so the next change starts from documented facts about the topology.
Release tracking and security patch assessment
This work tracks FreeIPA stabilization releases and security fixes, then assesses which ones apply to your topology. The 4.13.4 stabilization release, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, so the assessment starts with whether your servers expose those paths. The client receives a written patch assessment with a recommended action, a target window and rollback notes for each release.
Staged replica upgrades with rollback points
Upgrades run one replica at a time, with a verified backup and a rollback point taken before each change. Replication health, Kerberos logins and certificate issuance are checked on each replica before the next one starts, so a fault stays contained to a single server. The deliverables are a written upgrade plan, a change record for each replica and a validation report.
OS lifecycle planning for servers
FreeIPA servers run on operating systems with their own support end dates, so a FreeIPA upgrade cannot be planned apart from them. This work maps each server's OS version, support horizon and package sources, then sequences OS upgrades so that no two replicas holding the same role are offline together. The client receives a lifecycle calendar and a dependency map that names the roles each server holds.
Replica replacement and role moves
Retiring an old replica means moving its roles first, including CA services, DNS, NTP and the replication agreements it holds. The deployment recommendations limit each replica to no more than four replication agreements and expect at least one replica per datacenter running PKI or DNS if those services are used, so the replacement must keep those counts intact. The client receives a role-move plan, topology diagrams before and after the change, and a decommissioning record.
Certificate renewal and CRL checks
The first server handles certificate renewal and CRL publication by default, so its health decides whether certificates keep renewing. This work checks renewal status for CA and host certificates, confirms that CRL publication is current, and verifies that the renewal role sits on a server with working backups. The client receives a certificate inventory with expiry dates, a CRL check record and a renewal runbook.
Backup checks and post-go-live support
Backups created with ipa-backup are only useful once a restore has been tested. Test restores run in an isolated environment, because restoring an outdated backup into an active replica topology can break replication. Post-go-live support, delivered as included hours or a retainer, covers upgrades, incident response and runbook upkeep; confirm the hours and response expectations in the written scope before work starts.
What drives FreeIPA upgrade effort and cost
This table lists the factors that change how much work a FreeIPA upgrade takes and what support costs after go-live. Read each row as a question to answer about your own environment before you request a quote. The main takeaway is that topology, integrations and the first server's roles often matter more to effort than the version number alone.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Replica count and datacenter spread | Each replica must be upgraded, checked and kept in replication order. Deployment guidance of two to three replicas per datacenter and no more than four replication agreements per replica sets the baseline. | Keep the topology within the documented limits, and record the agreement map before any upgrade window. |
| Integrations (AD trusts, RADIUS OTP proxying, DNS and NTP roles) | Trust components, OTP proxy settings and DNS or NTP roles each need their own regression checks after every upgrade. | List each integration and its owner, and test them in the same order each cycle. |
| Customizations to plug-ins or scripts | Custom plug-ins, schema changes and API scripts may break on a new release and must be reviewed and retested before the upgrade. | Keep customizations documented, minimal and version-controlled, and retire any that no longer serve a purpose. |
| First server's renewal and CRL role | By default the first server handles certificate renewal and CRL publication, so its upgrade and any handover affect certificate operations. | Confirm which server holds the role before each window and plan a controlled handover if that server is being replaced. |
| Environments (test, staging, production) | Each environment needs its own upgrade run, validation and sign-off, so more environments mean more repeated work. | Use a test topology that mirrors production's replica count and integrations, and reuse the same runbook in each stage. |
| Operating system versions in use | Each OS release has its own lifecycle, package set and supported FreeIPA versions, so mixed versions across replicas add test paths. | Standardize the OS release across replicas where possible and confirm supported combinations with the vendor before planning. |
| Compliance evidence requirements | Assessors may ask for change records, backup test results, upgrade logs and proof of certificate checks, which adds documentation work to each cycle. | Agree the evidence list with your auditor early and generate it as part of each upgrade, not after it. |
How a FreeIPA upgrade moves from assessment to handover
The sequence runs from a topology inventory to a signed handover, and each phase produces a record your team can audit and operate from. Changes reach production one replica at a time, with checks after each server and a verified certificate state before the work closes.
Inventory topology, versions and operating systems
The engagement starts with an inventory of every IdM server and replica: the installed FreeIPA and 389 Directory Server package versions, the replication agreements between servers, which servers run the CA, DNS or NTP, the operating system release on each host, and which server is the first server. DeployOpen collects this with your platform team and records it in a topology register. The step is done when every server appears in the register, each replication agreement is listed, and your team has confirmed which host holds the certificate renewal and CRL role. No production change starts until the register is signed off.
Assess the target 4.x release and CVE fixes
Compare your installed version with the target 4.x release in the official release notes. Review configuration changes, altered or removed options, and operating system dependencies. Stabilization releases can also carry security fixes: the 4.13.4 release, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials. Confirm the target release against vendor advisories and with your own security owner. The output is a written assessment that lists each release note item, the CVEs addressed, and every item that needs a decision before the change window.
Rehearse the upgrade in a test environment
Restore a current backup into an isolated test topology that mirrors the production replica layout, then run the upgrade exactly as the change plan will. FreeIPA provides ipa-backup and ipa-restore, with full backups and online data-only backups. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so the test copy must come from a backup taken from the current production topology and must stay isolated from it. Record the commands, the package sequence, every error and the state of each replica afterward. The step is done when the test upgrade completes and login, certificate issuance and replication checks pass.
Write the change plan and replica order
Turn the rehearsal into a change plan that names each replica, the upgrade order, a rollback point for each step, and the approver for each step. Upgrade one replica at a time so the rest of the topology keeps serving logins and replicating. Keep the first server's role in view: by default it handles certificate renewal and CRL publication, so the plan must state where that role sits before the first server is touched and when it moves. Confirm the transfer method for your release with the vendor documentation before the window. The output is a signed plan that your operators can execute without the vendor present.
Upgrade production replicas with health checks
Upgrade each replica in the agreed order, and run the same health checks after each one before the next server starts. Checks cover replication status between servers, Kerberos ticket issuance from the upgraded host, client authentication through SSSD, DNS answers from any server that runs DNS, and certificate operations on the CA host. If a check fails, the rollback point in the plan applies and the change stops until the operations lead decides how to proceed. Take a fresh backup immediately before each change window. The step is done when each replica reports healthy, every check result is logged with a timestamp, and the operations lead signs off on the next step.
Verify certificates, CRL and renewal settings
After the last replica is upgraded, verify the PKI state. Check the CA certificate chain, the expiry dates of the CA and service certificates, CRL publication on the server that holds the renewal role, and the certificate serial number settings in use. FreeIPA 4.13.0 introduced random certificate serial numbers by default, so existing certificate profiles and any downstream systems that depend on serial numbers should be reviewed. Request and revoke a test certificate, and confirm that a client can retrieve the published CRL. The output is a certificate and CRL verification record with dates and results, filed with the change record.
Plan OS lifecycle changes and replica replacement
Map each server's operating system end-of-support date against the FreeIPA release line you run, because an operating system change can force a FreeIPA change. Confirm each vendor's published end-of-support date rather than relying on memory. Where a replica runs an operating system that will leave support, plan its replacement: deploy a new replica on a supported system, add it to the topology, confirm replication and any CA or DNS role, then remove the old replica and clean up its agreements. The recommendations advise two to three replicas per datacenter and no more than four replication agreements per replica, so each swap must keep those limits. The output is a dated replacement plan per server.
Hand over the runbook and support terms
Close with a handover that gives your team what it needs to run the platform. DeployOpen delivers a runbook covering the topology, the backup and restore procedure, the health checks, the certificate renewal checks, the upgrade procedure used in this engagement, and escalation contacts. Support terms are agreed in writing: either a one-time handover or a retainer covering upgrades, security releases and continuous testing, with the response commitments stated in the agreement. The step is done when your operators run a recovery exercise from the runbook, sign it off, and accept the support terms in writing.
What goes wrong in FreeIPA upgrades and how to prevent it
FreeIPA upgrades and support mostly fail at the edges: backups, replica order, certificate renewal, client DNS and shared servers. Each card below names one failure mode the vendor documentation calls out and the prevention step to build into your change plan before work starts.
Restoring an outdated backup
Restoring a backup that is older than the current replica topology can break replication between servers that already hold newer data. Treat backups as part of the upgrade plan: take a fresh backup before each change, confirm it is recent enough for the restore scenario you have in mind, and rehearse ipa-restore on a non-production copy. Ask your partner to document which backup type (full or data-only) each runbook uses.
Upgrading several replicas at once
Upgrading more than one replica in the same window removes the healthy copies you would use to recover if an upgrade goes wrong. Upgrade one replica at a time, confirm replication and services are healthy on that server, and only then move to the next. Set a go or no-go check between each step so a failed server does not become the reference for the rest of the topology.
Certificate renewal on the first server
By default, the first server in a FreeIPA deployment handles certificate renewal and CRL publication. A change that disturbs that server can stop renewals or leave the CRL stale, and the problem may not appear until certificates approach expiry. Before and after each change, check the renewal state, CA health and CRL publication on that server, and record the results in the change ticket.
Clients with one DNS server
Clients that list fewer than two DNS servers in resolv.conf lose name resolution and failover when their only DNS server is taken down for maintenance. The deployment recommendations call for at least two DNS servers in each client's configuration. Audit resolv.conf or the managed network settings on a sample of hosts in each site before the window opens, and confirm that failover works by stopping one DNS server in a test host group.
Shared servers and change windows
Running other applications on FreeIPA servers adds dependencies that change windows do not account for, such as package updates, database changes or memory pressure from unrelated services. The deployment recommendations call for dedicated servers without other applications. Ask for an inventory of what runs on each IdM host, separate shared workloads where possible, and include those workloads in the rollback plan for every upgrade.
Which FreeIPA upgrade tasks stay in-house and which go to a partner
This table compares eight FreeIPA upgrade and support tasks by who usually owns them and which skills each one requires. Read it as a starting split: many teams keep monitoring and day-to-day administration in-house and send the staged replica upgrade and the certificate and replication checks to a partner. Where the line falls depends on how much Linux identity experience the team already has.
| Task | Usual owner | Skills needed |
|---|---|---|
| Release monitoring and patch triage | In-house | Reading FreeIPA release notes, judging CVE exposure for your topology |
| Test upgrades | Partner or in-house, depending on lab maturity | Lab copy of your replica topology, staged upgrade runbooks |
| Production replica upgrades | Partner for first cycles, then in-house | One replica at a time, replication checks between each step |
| OS upgrades, kernel and package changes | In-house (server owners) | Linux administration, change windows, checking FreeIPA support for the new OS |
| Certificate renewal checks and Dogtag operations | Partner-led checks, in-house follow-up | Dogtag CA operations, renewal tracking on the first server, CRL publication |
| Backup and restore testing | Partner or in-house with partner review | ipa-backup and ipa-restore, restore steps that do not break active replication |
| Client-side SSSD and DNS checks | In-house | SSSD configuration, resolv.conf settings, DNS server reachability from clients |
| On-call support after go-live | In-house, with optional retainer | Incident response across 389 Directory Server, Kerberos, DNS and SSSD |
What FreeIPA support costs after go-live
The recurring cost of FreeIPA is labor and infrastructure. The project is licensed under GPL-3.0-or-later and has no paid edition of its own, so no license fee renews each year. What you pay for is the server capacity that runs the identity service in your own cloud accounts or data centers, including the recommended two to three replicas in each datacenter and any PKI or DNS replicas you run. Those hosts also need monitoring, storage and network capacity, and finance will see them as a line item at each budget cycle.
Most of the ongoing spend is internal time. Someone has to follow FreeIPA release announcements, decide when a stabilization release such as 4.13.4, dated July 9, 2026, moves into your environment, and schedule upgrades one replica at a time so the topology stays healthy. Periodic operating system lifecycle work runs alongside this. Replicas must stay on an OS version that its vendor still supports, so OS upgrades need the same change control as the identity service. Confirm the support window for your OS version and plan the replacement of old hosts before it closes.
Certificate and backup checks form a recurring routine that is easy to neglect. The first server handles certificate renewal and CRL publication by default, so confirm renewal dates and CRL publication on a fixed schedule. Test that backups restore into a lab, because restoring an outdated backup into an active replica topology can break replication. A retainer or bought support hours is the only recurring line that goes to an outside party, and it is optional. If you buy it, ask the partner to state in writing which replicas and integrations the price covers, such as CA and DNS roles, any Active Directory trust, OTP or RADIUS proxying, and the migration sources in scope.
Ask for response expectations written into the scope document, including who is contacted, during which hours, and what counts as urgent. Vague language about availability gives you nothing to measure. Ask also what happens when a security release arrives between scheduled cycles. A fix such as the two CVEs addressed in 4.13.4 may need to move quickly, so the quote should state who evaluates the advisory, who applies it to a test replica first, whether that work is included or billed as additional hours, and how each change is recorded as evidence for your assessors. Agree on the replica upgrade order before the first incident so that the response follows a written checklist.
How FreeIPA upgrades differ by starting point
A deployment several 4.x releases behind usually cannot move to the current stabilization line in one step without reading each release note in between. The plan becomes a sequence of upgrades, each proven on a copy before the next one starts, and the security fixes in later releases are part of that sequence rather than a separate task.
- Release path: map the installed version to the current 4.x line and list every release note between them, including security fixes.
- Test copy: build an isolated copy of the topology from a recent full backup and rehearse each step there. Restoring an outdated backup into an active replica topology can break replication, so never restore into production.
- Windows: plan one maintenance window per step, with a defined rollback decision for each.
- Client inventory: record the SSSD and operating system versions on enrolled hosts, since older clients may need changes before or after the server moves.
- Client supplies: the installed version of every server, a recent full backup, the change calendar and a named approver for each window.
Confirm the exact upgrade path against the release notes for your installed version before the plan is written, because the steps depend on where your deployment starts.
FreeIPA 4.13.0 introduced the first beta of a new web UI. A deployment that adopted that beta for daily administration needs a different plan than one that never used it: the goal is to move administrators and scripts onto the standard release without losing access or changing behavior that other systems depend on. The 4.13.0 release also introduced DNS over TLS between clients and IdM DNS servers, LDAP system accounts and random certificate serial numbers by default, so the upgrade check must cover those changes too.
- Version target: plan for the 4.13.4 stabilization release, dated July 9, 2026, which fixed two CVEs including LDAP access control flaws and hardened authentication checks across the API.
- Admin access: test every administrator role in the standard interface before the beta is switched off for them.
- Scripts: review any automation that calls the API or the ipa command, and confirm each call still returns the same results.
- Certificate serials: check whether any downstream system expects sequential serial numbers, since random serials are the default.
- DNS over TLS: confirm which clients are configured for it and which are not.
Client supplies: a list of users who use the beta web UI, the scripts and integrations that touch the API, and the named owners who will sign off on the test results.
A FreeIPA domain with a cross-forest trust to Active Directory has two sides to verify after every upgrade. The Linux side is the IPA servers, SSSD clients and policies. The Windows side depends on Samba components that handle the trust, and on ID mapping that decides how AD users appear on Linux hosts. Upgrades can change either side, so the trust must be checked on purpose rather than assumed to work.
- Trust state: confirm the trust reports as healthy on every server that handles it, before and after each step.
- Namespace: confirm the IPA DNS domain still does not overlap with any domain in the AD forest, since the trust depends on that separation.
- Sign-in tests: log in as AD users from several Linux hosts, covering both login and sudo or HBAC paths that reference AD groups.
- ID views: verify that mapped UIDs and GIDs for AD users are unchanged after the upgrade.
- Samba components: confirm the installed versions match what the upgraded FreeIPA release expects, and review the release notes for any trust-related change.
Client supplies: an AD forest administrator who can run trust tests, test accounts in AD, the list of AD groups used in HBAC or sudo rules, and a change approver on the Windows side.
When the operating system on the IPA servers approaches the end of vendor support, the FreeIPA plan has to be sequenced with the OS plan. Upgrading the OS in place and replacing replicas are both options, and the choice depends on how many replicas each datacenter runs, how much the team can change in one window and whether the OS vendor still supplies patches during the transition. The end-of-life dates themselves come from the OS vendor, so confirm them directly rather than relying on this page.
- Inventory: record the OS and its vendor support end date for every IPA server and every client that runs SSSD.
- Replica count: keep the deployment recommendation in view, which advises at least two to three replicas in each datacenter, so that one server can be upgraded or replaced while the others serve logins.
- Role handover: the first server handles certificate renewal and CRL publication by default, so confirm where those roles sit before retiring that server.
- Order: decide whether to upgrade the OS first, then FreeIPA, or to join new replicas on a supported OS and retire the old ones.
- Backups: take and test a full backup before each server change.
Client supplies: the OS inventory, the vendor support dates and any support contracts they hold, the change calendar for each datacenter, and the people who own certificate operations during the window.
In an air-gapped deployment, the FreeIPA servers cannot reach package repositories or release sources directly. Security releases must be brought in from outside through an approved transfer process, staged on an intake system and tested on a copy before they reach production. Each step adds time and approvals, so the security response plan has to be written before the first incident rather than during one.
- Intake: define how packages and release notes enter the isolated network, who handles the media and where the staged copy is kept.
- Integrity: verify each package against the checksums or signatures the vendor publishes, using the method the vendor documents, and record the result.
- Triage: track upstream release notes for security fixes, such as the two CVEs fixed in the 4.13.4 stabilization release, and decide which fixes need an expedited path.
- Test copy: rehearse each update on an isolated copy built from a recent backup before it touches the production topology.
- Backups: confirm that backup files moved out of the network follow the same transfer controls.
Client supplies: the approved transfer procedure and media rules, an intake host inside the isolated network, the security approval workflow with named approvers, and the maintenance windows that the change board accepts.
What your team needs to provide before FreeIPA upgrades start
Before any FreeIPA upgrade starts, your team must give DeployOpen administrative access to every replica and to the first server, and confirm that a current ipa-backup exists along with a restore path someone has tested. The first server matters most. FreeIPA's backup documentation notes that it handles certificate renewal and CRL publication by default, and restoring an outdated backup into an active replica topology can break replication. Ask whether your latest backup is a full backup or an online data-only backup, because the restore steps differ. Also confirm who holds the administrative credentials for the directory and the admin account, since the upgrade work depends on them and they should be available during the window.
Provide a test environment whose replica count matches production. A single test server will not show how replication behaves during a rolling upgrade, and the FreeIPA deployment recommendations describe topologies of two to three replicas per datacenter with no more than four replication agreements per replica. Your maintenance window policy should state how long each replica may be out of service, which change freeze dates apply, and who can stop the work. Agree on whether upgrades proceed one replica at a time with a verification pause between each. Write these window rules into the change record before the schedule is fixed, so that a delay on one server does not turn into an unplanned outage across the topology.
List every integration and customization that depends on FreeIPA. This includes SSSD client settings, sudo and HBAC rules, certificate profiles, automember rules, ID views, Active Directory trusts, OTP or RADIUS proxying, and scripts that call the ipa command or its JSON-RPC interface. Each item needs a test case in the upgrade plan. Confirm DNS and NTP ownership in writing. FreeIPA can run its own BIND DNS and NTP services, but many organizations run these elsewhere, and a DNS or time change made during an upgrade can look like a FreeIPA fault. Finally, provide the operating system support calendar for each server, because the OS lifecycle determines which upgrade paths are open and when they close.
Some decisions can only be made inside your organization. Name an owner for certificate decisions, including whether the first server renews certificates during the work and who approves any change to CA or certificate profile settings. Name a separate approver for production changes. Decide which replica is replaced and when, and whether OS upgrades happen in the same window as FreeIPA upgrades or separately. DeployOpen can recommend an order, but your business owner accepts the operational risk. Also settle how security releases are handled. The 4.13.4 release fixed two CVEs, including LDAP access control flaws, so confirm whether your team can approve security fixes on a shorter timetable than planned feature work.
How much effort, time and input do FreeIPA upgrades need?
How much does a FreeIPA upgrade cost and what drives it?
A FreeIPA upgrade has no license fee, because the project is licensed under GPL-3.0-or-later with no paid edition. The cost is the labor to plan, test, execute and verify the upgrade, plus any staging infrastructure you need. The main cost drivers are the number of replicas, how many datacenters they span, whether the integrated CA and DNS services are in use, whether an Active Directory trust or RADIUS proxy depends on the topology, and how much custom integration must be retested. Ask for a written quote that lists each server or site in scope, the test environments included, the rollback plan, and which activities are one-time and which recur, such as ongoing support or a retainer.
How long does a FreeIPA upgrade take across several replicas?
Duration depends mostly on two things: replica count and test coverage. Replicas are upgraded one at a time so that the topology keeps serving authentication, so more replicas and more datacenters mean more sequenced steps and checks between them. The FreeIPA deployment recommendations advise at least two to three replicas in each datacenter, and a larger topology takes longer to validate. Test coverage matters just as much: the more clients, Kerberos services, certificate workflows and integrations you can check in a staging copy before production, the fewer surprises appear during the change window. Ask for the proposed sequence, the validation checklist and the change windows assumed in the written scope.
What inputs does our team need to provide before an upgrade?
Your team provides the facts that the upgrade plan depends on. Typical inputs include an inventory of every FreeIPA server with its current version and operating system release, the replica agreement layout, the locations of CA and DNS roles, and a list of clients and integrations such as Active Directory trusts, OTP or RADIUS flows and DNS settings on client hosts. You also need recent backups that have been checked, access to the cloud accounts, data centers or air-gapped networks where the servers run, a staging environment if one is in scope, named approvers for change windows, and an owner who can accept the rollback decision. Confirm these items in the written scope so that gaps are found before work starts.
Can our internal team upgrade FreeIPA without outside help?
Some internal teams can upgrade FreeIPA alone, especially when the topology is small, they maintain a staging copy and they follow a documented runbook. The harder parts are usually the ones that touch identity for every host: the first server's role in certificate renewal and CRL publication, the replication sequence across sites, and DNS and client behavior during the change. Before deciding, check whether your team has recently tested a restore, understands how the CA and DNS services fail, and has people available to watch replication during each step. A useful test is whether someone outside the team can review your runbook and rollback plan before the window. Ask any outside provider to state which parts they would perform and which parts would stay with your staff.
How are FreeIPA security releases like 4.13.4 handled?
Security releases are handled as a planned change, with the urgency set by exposure. FreeIPA 4.13.4 is a stabilization release dated July 9, 2026, which fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and it hardened authentication checks across the API. The first step is to confirm which versions your deployment runs and whether those flaws apply to your configuration. The next steps are to test the release in staging, schedule the replica-by-replica rollout, and verify authentication, certificate issuance and replication after each change. Ask the provider how security releases are triaged, how quickly a patch can be scheduled under your scope, and whether that work is covered by a retainer or billed as a one-time change.
Does FreeIPA support cover certificate renewal checks and backups?
Coverage of certificate renewal and backups depends on the signed scope, so confirm it in writing. Technically, the first server handles certificate renewal and CRL publication by default, so checks should confirm which server holds that role, that renewals are working and that certificate expiry dates are being tracked. For backups, FreeIPA provides ipa-backup and ipa-restore, with full or online data-only backups, and the backup documentation warns that restoring an outdated backup into an active replica topology can break replication. A support scope should therefore include scheduled backup verification, restore tests in a non-production environment and a documented procedure for each replica. Ask which of these checks are included in a one-time upgrade and which run under an ongoing agreement.
What does a FreeIPA support retainer cover compared with a one-time upgrade?
A one-time upgrade is a fixed-scope engagement in which the scope, deliverables and timeline are agreed in writing before work starts. It ends when the agreed deliverables are complete. A retainer is an ongoing arrangement for support, upgrades and continuous testing, so its cost recurs and its scope is defined by the agreement rather than by a single change. In practice, a retainer may cover monitoring follow-up, handling security releases as they arrive, periodic certificate and backup checks, and planned upgrades within agreed limits. Ask the provider to list the included activities, the response expectations, what is excluded, how additional work is priced and how the agreement is reviewed over time.
How DeployOpen works on this
DeployOpen plans, implements and supports FreeIPA on servers you control, whether in your cloud accounts, data centers or air-gapped networks. Upgrades and support are scoped in writing before work starts, so you know which replicas, operating systems, certificates and runbooks are covered and who does what.
How we scope
- Inventory every IdM server, its operating system release, replica agreements and the datacenter it sits in
- Record which services run on each server, including the CA, DNS and any NTP role, before choosing an upgrade order
- Confirm the target FreeIPA release and whether it is a stabilization release or a change that needs more testing
- Agree in writing whether upgrades, certificate renewal checks and post go-live support are fixed-scope or a retainer
How we build
- Take and verify a full backup of the topology and test restore into an isolated environment before any change
- Upgrade replicas one at a time, starting with replicas that do not hold the first server role, and check replication after each step
- Validate clients enrolled with SSSD, Kerberos ticket issuance and certificate renewal before moving to the next server
- Test in a staging topology that mirrors your replica count and DNS layout, and record the results for your change board
How we hand over
- Deliver an upgrade runbook covering order of operations, rollback points and the checks passed at each stage
- Document the replica topology, the current first server, CA and DNS placement, and the backup schedule as built
- Provide a certificate and CRL renewal checklist your team can repeat on a set schedule
- Walk your operations staff through the runbook and confirm who owns each recurring task after handover
How we support
- Track FreeIPA stabilization releases and security fixes, then scope which of them apply to your deployment
- Plan OS lifecycle changes for IdM servers and replace aging replicas through a documented, tested sequence
- Run periodic checks on certificate expiry, backup freshness and replication health under an agreed retainer
- Confirm support hours, response expectations and escalation paths in the written scope before go-live
