When a FreeIPA deployment must run in FIPS mode
FreeIPA can run on FIPS-enabled hosts, but the host must be placed in FIPS mode before IdM is installed on it. If your organization is a public sector body, or operates under procurement rules or regulated workloads that call for FIPS 140 operation, make this decision at the planning stage, not after the first server is running. The FIPS setting belongs to the operating system, so it is a host-level property that every IdM server and replica inherits from its base image.
Before you commit, confirm two things in writing. First, ask your operating system vendor how FIPS mode is enabled on the release you plan to use, which packages and cryptographic modules are involved, and whether the vendor's documentation covers the host setup you intend. Second, check the FreeIPA documentation for the release you plan to deploy to see which FIPS requirements it describes. Your procurement or compliance team should also state whether it needs FIPS operation, a validated cryptographic module, or both, since these are different requirements and different sources answer them.
Treat the FIPS choice as a fixed input to the design. Every server you add later, including replicas, must meet the same host requirement, so a single non-FIPS build can undermine the whole topology. Record the host image, operating system release and FIPS verification output as part of your deployment evidence, and confirm the configuration with your auditor or assessor before go-live, since DeployOpen prepares these controls and evidence but does not issue the assessment.
Which FIPS deployment path fits each situation
This table compares the deployment paths for FreeIPA in FIPS mode, from new servers to existing non-FIPS deployments and features that do not qualify. Read each row against your current topology and ask whether any server must change. Conversion of an existing deployment is not covered by this guidance, so confirm it with the vendor before any change.
| Path | When it fits | What it requires | Main trade-off |
|---|---|---|---|
| New IdM servers on FIPS-enabled hosts | New deployments where FIPS mode is a policy requirement from the start | FIPS mode enabled on each host before installation, and every planned server built this way | Restricted Kerberos encryption types, so clients and services must support them |
| FIPS replicas added to a non-FIPS topology | Existing deployments that want a FIPS server added to a running environment | Confirmation from the vendor that this mixed layout is supported, since this guidance does not cover it | A mixed topology can leave the deployment outside FIPS scope and adds change risk |
| Existing non-FIPS deployment kept as is | Production systems that work today and have no approved conversion path | A documented scope, an inventory of encryption types in use, and a change freeze on the platform | The deployment cannot claim FIPS operation, so assessors need a clear boundary |
| Features such as RADIUS proxying | Two-factor authentication that relies on an existing RADIUS server | Confirmation from the vendor on whether the feature qualifies before it is counted in scope | The feature does not qualify under this guidance, so it needs a separate design or another method |
| Clients with older encryption type support | Estates where some hosts or services may not support the restricted types | An inventory of client, keytab and service encryption types gathered before installation | Clients that cannot negotiate the restricted types fail to authenticate |
Setup sequence for a FIPS-enabled FreeIPA install
This sequence makes FIPS mode a precondition for every FreeIPA server, so the first server and each replica start from a verified cryptographic baseline and the Kerberos encryption types are settled before any directory data exists.
Confirm the host OS supports FIPS mode
The platform engineer checks the operating system vendor's documentation for FIPS-validated cryptographic modules and confirms that the exact release planned for each server supports FIPS mode and the FreeIPA packages you intend to install. Ask the vendor which module certificate covers your release and whether your FreeIPA version is supported on it. Confirm the exact enablement and verification commands in that vendor documentation rather than relying on memory. The step is complete when every planned server has a written OS release that the vendor documents as supporting FIPS mode.
Enable FIPS on every server before installing
The platform engineer enables FIPS mode on each planned server, including the host that will become the first server, while no IdM packages are present. This is done through the OS vendor's documented procedure, followed by a reboot, because the kernel setting must be active before cryptographic libraries load. Confirm the change with the vendor documentation for the enablement command. The step is complete when each host has been rebooted and nothing from FreeIPA has been installed yet.
Verify the kernel FIPS flag on each host
On every server, the platform engineer checks the kernel FIPS flag by reading the file /proc/sys/crypto/fips_enabled and expects the value 1. They also confirm that the crypto policy reports a FIPS policy, using the command the OS vendor documents for that purpose. Record the output with the hostname and date in your change record. Any host that returns 0 or lacks the policy must be fixed and rebooted before it proceeds. The step is complete when the check passes on all servers and the output is recorded.
Plan Kerberos encryption types and test clients
Before installation, the identity team lists the Kerberos encryption types that FIPS-mode servers will offer and checks which are still accepted by the FIPS policy on the OS release. They then test representative Linux clients, Windows or other Kerberos consumers, and any applications with keytabs, to confirm they can obtain tickets with the restricted types. Confirm the supported encryption types for your FreeIPA release in the FreeIPA documentation before you test. The step is complete when a written compatibility matrix shows which clients and services work and which need a fix before cutover.
Install the first server in FIPS mode
The platform engineer installs the first FreeIPA server only after the FIPS checks pass, using the install procedure in the FreeIPA documentation for your version. The installer runs on a host that is already in FIPS mode, so the realm, the certificate authority and the Kerberos keys are created under FIPS policy from the start. Confirm the installer options and any required flags in the FreeIPA installation documentation. The step is complete when the server answers Kerberos requests and the server reports FIPS status matching the host check.
Verify the first server before adding replicas
Before any replica is created, the identity team confirms that the first server issues Kerberos tickets with the planned encryption types, that its certificate authority is healthy, and that the FIPS flag remains 1 after the installation. They also run the client compatibility tests from the earlier matrix against this server. Confirm the health commands in the FreeIPA documentation for your version. The step is complete when these tests pass and the results are saved with the change record.
Install each replica only after FIPS confirmation
For each replica, the platform engineer repeats the enablement, reboot and kernel flag checks on that host, then installs the replica from the verified first server using the replica procedure in the FreeIPA documentation. A replica whose host is not confirmed in FIPS mode is not installed, because it would hold directory and key material under a different cryptographic policy. Confirm the replica installation and promotion commands in the vendor and FreeIPA documentation. The step is complete when the replica shows FIPS status, replication with the topology is healthy and the earlier Kerberos tests pass against it.
How FIPS planning differs for new, existing and mixed estates
With no existing deployment, FIPS mode is a design input made before the first server is installed. Decisions made at this stage are costly to reverse, so they belong in a written design that a reviewer can check.
- Host baseline: Confirm that every server, replica and client image boots with FIPS enabled before FreeIPA packages are installed, and record the operating system settings in the build.
- Encryption types: Confirm with the vendor documentation which Kerberos encryption types are restricted in FIPS mode, then check that every client, service and application you run can use the remaining types.
- Replica plan: Decide how many replicas each site needs and confirm that every replica, including ones added later, will run in FIPS mode. The FreeIPA deployment recommendations describe replica counts that apply to any design.
- Feature review: List the features you need, such as RADIUS proxying, and confirm in writing whether each one qualifies in FIPS mode before the design is approved.
Before the first install, check each decision against a written test plan that covers logins, replication and certificate issuance on a non-production build.
An existing non-FIPS deployment under review is not converted to FIPS mode by this guidance. Changing the mode of a running topology is a rebuild decision, not an in-place change, unless a confirmed procedure from the vendor says otherwise. Get that position confirmed in writing before any planning work begins.
- Written position: Ask your FreeIPA provider or internal platform owner to confirm in writing that in-place conversion is not supported for your version and topology, and file the confirmation with the review.
- Inventory: Record every server, replica, client, service keytab and integration, including applications that depend on specific Kerberos encryption types.
- Gap assessment: Compare current encryption types and features against the FIPS restrictions and mark each item that would fail or need change.
- Rebuild options: Evaluate a new FIPS-enabled deployment and a migration path, and test restore procedures on separate hosts first. The backup and restore documentation warns that restoring an outdated backup into an active topology can break replication.
- Do not attempt: Do not toggle FIPS settings on live servers, edit cryptographic configuration by hand, or restore an old backup into a production topology to test a conversion.
Check that the written confirmation names the exact version and topology that were reviewed.
A mixed estate is where FIPS-enabled clients authenticate against non-FIPS servers, or the reverse. Authentication results depend on the encryption types negotiated, so failures can look like password, DNS or network problems and take longer to diagnose.
- Boundary map: Identify which clients are FIPS-enabled, which servers they contact, and which services hold keytabs, so the boundary is visible before testing begins.
- Negotiation tests: Test Kerberos logins from each client type against each replica, and record the encryption types in use for each combination.
- Application impact: Check applications, jump hosts and scripts that use LDAP binds or older cryptography, and confirm they work from FIPS-enabled clients.
- Enrollment gate: Block enrollment of new non-FIPS clients into a FIPS-designated realm until the owner accepts the risk in writing and the test results are on file.
- Do not attempt: Do not run replicas with different FIPS states in one topology as a workaround unless the vendor documents that configuration as supported.
Confirm which client and server combinations were tested, and keep the results with the change record.
Security considerations for FIPS-enabled identity servers
A FIPS-enabled FreeIPA deployment inherits every weakness of its servers, so the controls around the first server, replicas, backups, patching, authentication paths and directory access matter as much as the cryptographic mode itself. Each card below names one area and the operational check that confirms it is working. None of them is a compliance claim on its own.
Protect the first server
By default the first FreeIPA server handles certificate renewal and CRL publication. In a FIPS deployment, that role concentrates the most sensitive operations in one host. Confirm which server holds these roles, restrict administrative access to it, and record where the CA signing material and key backups are stored. Review the role assignment after any topology change so renewal does not silently depend on a server you have decommissioned.
Keep replicas on one baseline
Every replica must run in FIPS mode with the same restricted Kerberos encryption types, or clients may negotiate differently depending on which server answers. Before adding a replica, compare its kernel FIPS flag, crypto policy and FreeIPA package version against the existing servers. Run the same check after patching so a single host does not drift out of the baseline.
Restore only current backups
FreeIPA backups let you restore data, but restoring an outdated backup into an active replica topology can break replication. Treat each restore as a topology event: confirm the backup is recent, plan which servers will be brought back first, and verify replication status afterward. Test restores on an isolated copy so the procedure is known before an incident forces it.
Patch on security releases
FreeIPA 4.13.4 fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials. Track stabilization and security releases for your version, schedule updates in a defined order across replicas, and confirm the fixed package is installed on every server. Record the verification step so auditors can see that fixes reached the whole topology.
Review OTP and RADIUS paths
OTP tokens and RADIUS proxying are features that do not qualify for FIPS mode, so any login that depends on them needs a separate decision. List every service that uses OTP or proxies to a RADIUS server, confirm whether it runs on a FIPS host, and document the compensating control or the removal plan. Test each path after changes to Kerberos settings, since OTP authentication depends on them.
Limit access to the KDC and LDAP
The KDC and the LDAP directory hold the credentials and policies for the whole realm, so access to them should be narrower than access to ordinary application hosts. Review which administrators can reach the servers, which hosts can bind to LDAP, and whether anonymous or unauthenticated reads are blocked. Confirm these settings on every replica and retest them after each security release.
What FreeIPA FIPS mode projects cost and what they need from your team
Can I convert an existing FreeIPA deployment to FIPS mode later?
Our guidance on this topic is that FIPS mode should be enabled on the hosts before FreeIPA is installed, and existing deployments should not be converted in place. The work that follows from that position is a planned rebuild or migration, not a switch. Plan for a new FIPS-enabled topology, then move identities, policies, certificates and services across with a tested cutover. Confirm the approach against the current FreeIPA documentation and your own environment before committing a change window, because the cost of a migration depends on how much state you carry over. Ask any partner to state in writing whether they propose conversion or rebuild, and why.
What drives the cost of a FreeIPA FIPS project?
The main drivers are the number of FreeIPA servers and replicas, the size and variety of the client inventory, the number of services that authenticate through Kerberos, and whether external trusts such as Active Directory are in scope. Each replica adds build, replication validation and backup work. Each client platform adds enrollment and Kerberos testing. Applications that depend on RADIUS, legacy LDAP binds or older ciphers add compatibility work that is hard to estimate until they are inventoried. Ask for a quote that lists these items separately, so you can see which assumptions move the price.
How many replicas and clients will affect the effort?
Effort grows with the number of replicas because each one must run in FIPS mode and must be validated in the replication topology. The DNS and certificate authority roles also need placement decisions per site. On the client side, effort depends on distributions, the number of hosts per distribution, and whether enrollment is automated. Ask the partner how they will test a representative sample of each client type, and what they will do with hosts that cannot negotiate the restricted Kerberos encryption types.
What does my team need to provide for a FIPS engagement?
The work needs root access on the target OS images or a supported build pipeline, scheduled change windows, a current inventory of hosts and the services that authenticate against FreeIPA, and named owners for each service. Your team should also supply the existing identity data, policy exports and certificate lists that will be carried forward. Without service owners, Kerberos and LDAP testing stalls because nobody can confirm expected behavior. Agree the access model, approval path and rollback responsibilities in writing before the first change.
Can our internal team run a FIPS FreeIPA deployment alone?
An internal team can do it if it has direct experience with FreeIPA installation, Kerberos, the Dogtag certificate authority, SSSD on clients and FIPS-enabled operating systems, and if it has time for testing and rollback planning. The gaps usually appear in client compatibility and in features that do not qualify for FIPS mode, such as RADIUS, where the team must decide on alternatives. Compare the internal estimate against a fixed-scope quote, and count the recurring work after go-live, including patching, backups and security releases.
How long does a FreeIPA FIPS project take?
Duration depends on scope rather than on a fixed template. A single-site deployment with few clients is shorter than a multi-site topology with external trusts and many client platforms. The longest phases are usually the client inventory, the compatibility testing and the change windows that your organization requires. Ask for a timeline in the written scope that ties each phase to a deliverable and a named dependency. No duration should be accepted without a stated list of assumptions.
Does DeployOpen issue FIPS certification for my FreeIPA environment?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask the partner which evidence they will produce, such as configuration records, test results and runbooks, and confirm with your assessor which of those items they will accept before the project starts.
Limits to confirm in your environment before you commit
FIPS mode changes which cryptographic modules, Kerberos encryption types and features your FreeIPA deployment can rely on. The items below are the points where the answer depends on your operating system build, your clients and your existing directory, so confirm each one in writing before you fix the design.
FIPS-validated modules in use
Ask which FIPS-validated cryptographic modules the operating system and the FreeIPA packages in your target build actually load for TLS, Kerberos, LDAP and certificate operations. Ask whether the validation covers the exact module versions you will install, not only the operating system family. Confirm with your operating system vendor and your FreeIPA packaging contact, and have your compliance lead record the answer as evidence for the cryptography controls you are mapping.
Permitted Kerberos encryption types
FIPS mode restricts the Kerberos encryption types the KDC will issue. Test each client and service that authenticates with Kerberos, including SSSD clients, Samba file servers and any application using GSSAPI, to confirm it negotiates an allowed type. Ask the FreeIPA maintainers or your vendor which types remain available in your release, and plan a keytab regeneration path for services that still hold older keys.
Non-qualifying features like RADIUS
Identify any feature that depends on a non-qualifying component, such as OTP checks proxied to an existing RADIUS server. Ask your identity team whether those users, VPNs or network devices can be moved to supported authentication paths. Ask the RADIUS vendor and your security assessor whether the proxy traffic falls inside the boundary you intend to certify.
Conversion of existing servers
Ask the FreeIPA maintainers and your platform vendor whether an existing deployment can be switched into FIPS mode after installation. Plan on the assumption that FIPS mode is set before installation and that every replica must match. If you have a running topology, ask for the supported path to build a new FIPS deployment and migrate data into it, and ask who owns the cutover plan and rollback.
Cross-realm and Active Directory trusts
Trusts with Active Directory and other Kerberos realms depend on the encryption types and cryptographic options that both sides negotiate. Ask your Active Directory team which encryption types their domain controllers accept under their own policy, and test a trust in a non-production realm before you rely on it. Ask FreeIPA support which trust configurations are documented for FIPS-enabled servers.
Supported version and operating system pairs
Confirm which FreeIPA release and operating system combination your vendor supports with FIPS mode enabled, and whether security fixes for that pair arrive on the same schedule as the rest of the platform. Ask for the support matrix in writing, and confirm how the pair will be kept current during your planned operating life so that the FIPS posture does not drift during an upgrade.
How DeployOpen scopes and delivers FreeIPA FIPS work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA deployments on FIPS-enabled hosts. Each engagement starts from a written scope that sets out which hosts, replicas and services are in FIPS mode and what evidence you receive at the end.
How we scope
- Inventory every FreeIPA server, replica and client that must run in FIPS mode before any installation starts.
- Confirm which clients, services and integrations depend on encryption types that FIPS mode restricts.
- Agree in writing whether any feature in scope, such as RADIUS proxying, falls outside what FIPS mode supports.
How we build
- Enable FIPS on the operating system hosts before running the FreeIPA installer, and record the host state.
- Build every replica in FIPS mode so the topology stays consistent, and test Kerberos logins with the restricted encryption types.
- Verify client enrollment and SSSD authentication against the FIPS-configured servers before the build is accepted.
How we hand over
- Document the FIPS configuration of each host, the Kerberos settings in effect and the list of unsupported features.
- Provide the test results for authentication, replication and certificate issuance on the FIPS hosts.
- Record the runbook for adding a replica or client later, so new members of the topology also meet the FIPS requirement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer work can cover re-testing after FreeIPA security releases and changes to host FIPS settings.
- Ask any provider, including DeployOpen, to confirm how they will handle new replicas and any scope changes in writing.
