FreeIPA server installation prerequisites

FreeIPA server installation prerequisites: what to settle before the first install

Most failed FreeIPA installs and the outages that follow them trace back to host preparation, not to the installer itself. Before the first server or replica goes in, your team should settle the host name, reverse DNS, time source, network paths, crypto policy and security agent behavior on every machine that will carry an IPA role. This section is for teams about to install the first FreeIPA server, or to add replicas, on infrastructure they control. The installer assumes these conditions hold, and it rarely explains which one is missing when they do not.

The work covers the ports that must be open between servers and clients, time synchronization with chrony, the fully qualified host names and reverse DNS records that the Kerberos realm and certificates depend on, the system crypto policy, the default umask, and how fapolicyd may block installer components if it is enforcing. It also covers the packages needed when a server will run the DNS role or a trust to Active Directory. Teams that already run Kerberos, certificate or DNS services on the same hosts should record every existing setting before changing anything, because the installer may overwrite or conflict with them. Get outside help when hosts are in several datacenters, when existing DNS or AD forests overlap the planned IPA domain, or when the security baseline forbids the default settings.

Exact port lists, package names and version-specific steps must be confirmed against the FreeIPA release notes and the documentation for your operating system and its lifecycle before you build. Ask your vendor or partner for a written checklist that names the release, the OS version and every role each host will carry, and have your network and security teams verify it on a staging host first.

Which server role changes the prerequisites

This table compares the four host roles that change what you prepare before installing FreeIPA: first server, replica, server with integrated DNS, and server prepared for an Active Directory trust. Read each row as a question: which prerequisite moves, and does this role fit the site you are building. The main takeaway is that DNS and trust naming decisions are made before the first install, while replica count is a topology decision you should settle early.

Server role	Prerequisite that changes	When this role fits
First server	Establish the IPA DNS domain and Kerberos realm names before installation, since these are hard to change later. Confirm forward and reverse name resolution for the host.	The first host in a new realm. It also takes on certificate renewal and CRL publication by default, so plan its placement and backups from day one.
Additional replica	Confirm the first server is reachable and time is synchronized with chrony on both hosts. Open the same service ports and keep the host name and reverse DNS rules consistent across sites.	Adding redundancy within a datacenter. The recommendations advise two to three replicas per datacenter and no more than four replication agreements per replica.
Server with integrated DNS	Plan DNS delegation and the resolver settings on clients. The recommendations advise at least two DNS servers in each client's resolv.conf, and at least one replica per datacenter running DNS if used.	Sites where clients should resolve internal names through FreeIPA. Confirm with your network team who owns zone delegation before the install.
Server prepared for an Active Directory trust	Choose an IPA DNS domain that does not overlap with any domain in the AD forest. Install the Samba trust packages before the trust is established.	Environments that must share identities with Windows Active Directory. Naming mistakes here are costly, so settle the domain name with the AD owners first.
Server with PKI role	Plan certificate authority placement and keep at least one replica per datacenter running PKI, where PKI is used. Confirm storage and time sync for the CA host.	Organizations issuing internal certificates through the Dogtag CA integrated in FreeIPA. Confirm which replicas will hold the CA role.
Dedicated FreeIPA host	Keep the host free of other applications and confirm no competing services claim the ports FreeIPA needs. Review firewall rules for each role on that host.	Every role. The recommendations call for dedicated servers, so shared hosts should be a documented exception, not a default.

How to prepare each host in sequence

This sequence takes each planned FreeIPA server and client from a bare base OS to a state where the installer can run cleanly. Each step closes with a check, so problems surface on the host rather than halfway through an install.

Fix domain, realm and host names
Decide the IPA DNS domain, the Kerberos realm and the fully qualified name of every server before touching any host. Confirm that the IPA domain does not overlap with any Active Directory domain if a trust is planned, since the trust documentation requires non-overlapping DNS domains. Record the names in one reviewed document that the whole team signs off. Done means every planned server name is written down, unique, and matches the hostname each machine will report. Verify with hostnamectl status on each host, and confirm exact naming rules in the current FreeIPA install guide and your OS documentation.
Set static addresses and forward and reverse DNS
Assign static IP addresses to every FreeIPA server and give each one matching forward and reverse DNS records in the zone your team controls. The deployment recommendations call for at least two DNS servers in each client's resolver configuration, so plan those addresses now. Make sure the reverse record of each server points back to its fully qualified name. Verify from each host with dig +short for the forward name and dig -x for the address, and check that both return the same name. Confirm record requirements against the current FreeIPA DNS documentation before install.
Configure chrony against agreed time sources
Point every server and client at the time sources your organization has agreed, using chrony. Kerberos is sensitive to clock skew, so this step is a prerequisite for authentication working at all, not a tuning exercise. Use the same sources on all hosts and confirm that servers that will act as NTP sources for clients are configured as intended. Verify with chronyc tracking and chronyc sources, checking that the system clock is synchronized and the selected source is one you approved. Confirm the exact configuration keys in your OS chrony documentation.
Open required ports between servers and clients
Open the network ports that FreeIPA servers, replicas and enrolled clients need to reach each other, including DNS, Kerberos, LDAP, HTTPS and any NTP traffic you run through the servers. Apply the rules to host firewalls and to any network firewalls between sites, and write down which source may reach which destination. Verify from a client and from a peer server with a port check tool such as nc -zv against each port, and confirm the port list and protocols in the current FreeIPA and OS documentation before you open anything.
Review crypto policy and umask on the base OS
Check the system-wide crypto policy and the default umask on the base operating system before install, and align them with the policy your security team has approved. Changing crypto policy after install can affect Kerberos, Dogtag and TLS behavior, so the decision belongs here. Record the current values on every host so they can be compared later. Verify with update-crypto-policies --show and by reviewing the umask in the system profile files your distribution uses. Confirm the supported policy names and any interaction with FreeIPA in the current documentation.
Decide fapolicyd handling before install
Decide, before running the installer, whether fapolicyd will be enabled on FreeIPA servers and enrolled hosts, and how its rules will allow the FreeIPA binaries and data paths. Enabling a restrictive policy after install can block services that the installer has already placed, so this is a design decision with a documented outcome. Write the chosen mode and the exceptions on the host build record. Verify with systemctl status fapolicyd and by confirming the mode in its configuration file, and check the current FreeIPA guidance on fapolicyd before you proceed.
Install DNS and trust packages for chosen roles only
Install the DNS server packages only on the servers that your design assigns the DNS role, and the Active Directory trust packages only on servers that will hold the trust role. Keep every other server limited to the core identity packages. The deployment recommendations advise dedicated servers without other applications, so do not add unrelated services at this point. Verify with rpm -q or your package manager's query command for each package and compare the output with the role table in your build record. Confirm the package names for your distribution in its FreeIPA packaging documentation.
Run a final resolution and time check
Run one last check across every host before the installer starts. Confirm that each server resolves its own name and its peers forward and backward, that each client resolves the FreeIPA servers through its configured resolvers, and that chrony reports synchronized time on all hosts. Keep the output with the change record so the install team can compare it if the installer fails. The step is complete when every host passes the same checks without manual exceptions. Confirm the exact checks and expected output in the current FreeIPA installation documentation.

Why host names, reverse DNS and time sync break installs

Most failed FreeIPA server installs trace back to identity basics: the host name, the DNS records that point back to it, the resolvers clients use, and the clock. These cards cover the pitfalls we see most often and what to verify on each host before the installer runs.

Host name must match the planned realm

The server's fully qualified host name should sit inside the DNS domain you plan to use for the IPA domain, and that domain should match the Kerberos realm you intend to run. A host name chosen in a hurry, or copied from a template, often lands in a different domain than the realm. The installer then builds service principals and certificates for names clients never use. Check the output of hostnamectl and the hostname -f result on every planned server, and confirm the realm name with the team that owns naming before you start.

Missing or mismatched reverse DNS

Forward and reverse lookups must agree. If the server's address resolves to a name that differs from its host name, Kerberos service principals and certificate names can fail to match what clients request. The symptom is often a Kerberos or certificate error that appears only after install, not a clear DNS message. Check that each server has a PTR record for its address pointing to the exact fully qualified host name, and that the forward A or AAAA record points back to the same address. Do this for every replica as well as the first server.

Clients with fewer than two DNS servers

FreeIPA's deployment recommendations advise at least two DNS servers in each client's resolv.conf. A client that lists only one resolver loses name resolution, and therefore Kerberos and LDAP lookups, whenever that one server is down or unreachable. The failure can look like a login problem rather than a DNS problem. Before enrolling clients, check /etc/resolv.conf (or the NetworkManager or systemd-resolved source that generates it) on a sample of hosts and confirm that at least two resolvers answer for the IPA domain.

Clocks that drift or use unreachable sources

Kerberos rejects authentication when client and server clocks differ too much, so time synchronization is part of the install, not an afterthought. Problems appear when chrony is missing, when the configured time sources cannot be reached from the server's network segment, or when a virtual machine's clock is not corrected by its host. Check chronyc tracking and chronyc sources on each server, and confirm the time sources the server uses are reachable from inside your network. Ask your network team which internal source your environment provides.

Host name changes after install

Renaming a FreeIPA server after install is not a simple edit. The host name is baked into the server's directory entries, Kerberos principals, certificates and replication agreements, so changing the name in the operating system leaves the deployment in an inconsistent state. The safer rule is to settle the host name, reverse DNS entry and domain before running the installer. If a server must be renamed, plan that as a topology change with its own procedure and test it outside production first. Confirm the rename path with the FreeIPA documentation for your release before you touch a live server.

Crypto policy, umask and fapolicyd can block a working install

Host-level controls can make an otherwise correct FreeIPA install fail, and the failure often looks like a FreeIPA bug. The system crypto policy, the default umask and application allowlisting such as fapolicyd all act on the installer and the services it starts before FreeIPA writes its first file. The crypto policy governs which TLS versions, ciphers and Kerberos encryption types the host accepts, so a stricter setting can break the handshakes that the 389 Directory Server, the Dogtag certificate system and the KDC need during setup. A restrictive umask changes the permissions on files such as keytabs, configuration and certificate material, which can leave a service unable to read what it needs. fapolicyd can block execution of binaries, scripts or Python modules that the installer unpacks or runs from non-standard paths, and it can deny the services that the installer starts.

Make the troubleshooting sequence explicit before you run the installer. Record the current crypto policy, the umask in effect for the account running the install, and the fapolicyd state and rule set, so you can compare them later. After a failed attempt, review the installer log and the audit log for denials before changing anything, because a denial shows the exact binary and path that was blocked. Treat any change to the crypto policy, the umask or fapolicyd rules as a decision: write down what was relaxed, why, for how long, and who approved it, and restore the control once the install is verified. Do not disable fapolicyd or set the crypto policy to a weaker profile just to get past one error.

Confirm the current behavior and recommended settings for your OS release before you plan the change window. Defaults, supported crypto profiles and fapolicyd integration with the FreeIPA packages differ between releases, so check the vendor documentation for your distribution and the FreeIPA installation guidance that matches your version. Ask your platform team to confirm whether the hardening baseline you must meet permits any exception, and keep the result of that check with the installation record.

Packages to plan for DNS and AD trust roles

A plain FreeIPA server runs the directory, Kerberos KDC, certificate authority and web UI without integrated DNS or trust components. The base install pulls in the IdM server packages, but the role still needs decisions made before the first run, because the realm and domain names cannot be changed later without a rebuild. Planning here is mostly about the domain you choose and how clients will find the server.

Realm and domain naming: Pick the Kerberos realm and DNS domain now. Confirm they do not overlap with any domain you may later trust.
External DNS dependency: If DNS will be run elsewhere, plan the SRV and A records clients need to locate the servers.
Dedicated host: Keep the server free of other applications so its resources and change windows stay predictable.
Package source: Use the package set from the installer documentation for your chosen OS, not a list copied from another distribution.
Support boundary: Confirm with your distribution vendor whether the IdM server package is supported on that release.

Before installation, check that the chosen package set, realm and domain names match the design your replicas and clients will use.",

Security considerations at the preparation stage

Four decisions are made during preparation and are expensive to reverse once FreeIPA holds users, hosts and keys. Record each one in the preparation document before any server is built, so the install team and the security reviewers work from the same boundaries.

Dedicated servers only

FreeIPA servers should run no other applications. The directory, Kerberos KDC and Dogtag CA share a trust position, so a compromise of a web app or build tool on the same host exposes the stores that issue tickets and certificates. Record which hosts are reserved for IdM, who holds root on them, and which roles (CA, DNS, trust controller) each will carry. Confirm with your platform team that virtualization or container hosts do not share hypervisor-level administrators with unrelated workloads.

Trust boundary between servers and clients

Enrolled clients trust the IPA domain for logins, sudo rules and host keys, while servers hold the master copy of that trust. Decide which machines are full servers, which are enrolled clients, and which networks may reach each. Write down who may enroll hosts, who may approve host certificates, and whether client-side admins can change policy. A client compromise should not become a path to administrative API access on the servers.

DNS and Kerberos network paths

Kerberos ticket exchange and DNS lookups are the traffic clients cannot function without, and both depend on name resolution being correct. Map every path that carries these requests, including client to server, server to server replication, and any forwarders. Note which paths cross zones, firewalls or tenant boundaries. Confirm that the forward and reverse records your team plans to publish match the host names you will use, because mismatches are hard to repair after clients are enrolled.

Installer credentials and admin access

The installer sets the Directory Manager password, the IPA admin password and certificate authority keys during build, and these values often pass through shell history, automation logs or chat. Decide where each secret is generated, who may read it, and how it is stored after install. Record which admin accounts exist before the first server is built, the approval path for using them, and how build-time access is removed afterwards. Ask your auditors which evidence they expect for this step.

Plan replicas and DNS locations before the first host is built

Decide the replica layout and DNS placement before you prepare any host, because the host names, reverse zones, firewall rules and time sources all follow from that layout. A FreeIPA server is not a generic Linux box you can rename later without cost. Each server is a named member of a replication topology, and the names you choose become part of the realm, the DNS zones and the certificates. Work out how many servers each datacenter needs, which of them will run the Dogtag CA or DNS if you use them, and which network segments each one sits on before you touch a kickstart file or a cloud template.

The FreeIPA deployment recommendations advise at least two to three replicas in each datacenter, no more than four replication agreements per replica, at least one replica per datacenter running PKI or DNS if used, and dedicated servers without other applications. Read those rules together. They determine how many hosts you build, where the replication links run, and which sites need their own DNS service. Clients also depend on the layout: the same recommendations call for at least two DNS servers in each client's resolv.conf, so the resolver order you plan for each site must point to servers that actually exist in that site and that you have already named and addressed.

Server placement and sizing belong to the replication and topology work, so use that work as the source for the final numbers rather than treating this section as the decision itself. Confirm the current recommendations on the FreeIPA deployment recommendations page before you fix the layout, since guidance on topology can change between releases. Write down the server names, IP addresses, DNS entries, reverse zones and resolver lists for every site in one reviewed plan. Hosts built from that plan avoid renames, and the prerequisites in the rest of this page can then be checked against a fixed design.

Limits to confirm in your environment

Several prerequisites depend on facts about your network, operating system and change process that no general guide can settle. Confirm each item below with the party named on the card before you fix the server design, because a wrong assumption here usually surfaces as a failed installation or a broken replication topology.

Required ports for your roles

The ports FreeIPA needs depend on which roles each server takes: client enrollment, the web UI, replication between servers, Kerberos, LDAP, DNS, and certificate services if the CA is installed. Your firewall model, whether host-based, network-based or cloud security groups, decides how those ports are opened and who must approve the change. Ask the FreeIPA documentation for the current port list for your planned roles, then have your network team map each port to a source and destination. Confirm every port in both directions before the first install attempt.

Supported OS releases and lifecycle

FreeIPA server support follows the operating system you run it on, and the lifecycle of that OS sets how long your servers can receive fixes without a rebuild. Confirm with your OS vendor which releases carry the FreeIPA server packages you intend to use, how long each release receives updates, and which upgrade path leads to the next one. Client support on other distributions can differ from server support, so check each client OS separately with the vendor's own documentation.

Time sources inside your network

Kerberos rejects authentication when clocks drift beyond its tolerance, so every FreeIPA server and client needs a reliable time source. Find out which NTP servers your network team provides, whether they are reachable from every planned server and site, and whether they are stratum-accurate and monitored. Plan chrony configuration on each host against those sources, and confirm that virtual machine hosts do not introduce time drift that the guests inherit. Ask your network team for the names and addresses before you set server lines in chrony.conf.

AD forest and planned IPA domain overlap

If you plan a trust with Active Directory, the IPA DNS domain must not overlap with any domain in the AD forest. Check every domain and subdomain your AD forest uses, including those created by mergers or old naming decisions, against the DNS domain you plan for IPA. The Windows directory team should confirm this list in writing, because a late discovery forces a rename of a domain that already holds users and hosts. Confirm the trust type and forest policy with them too before you finalize DNS naming.

Change control for policy adjustments

Some hardening steps, such as fapolicyd rules, crypto policy changes and umask settings, can block services or logins if they conflict with what FreeIPA and its dependencies expect. Confirm with your own security team whether they require a formal change record, a test window or a documented exception for each setting you intend to change. Ask who approves a policy exception, who reverts it during an outage, and whether the approval covers every server role. Record the answers before the build, because changing them during an incident is slower and riskier.

Questions teams ask before installing FreeIPA

What drives the cost of preparing hosts for FreeIPA?

The main cost driver is how many hosts, sites and naming decisions are involved, and how much of the preparation depends on people outside the platform team. Preparation covers host naming, forward and reverse DNS, time synchronization, firewall rules, crypto policy, umask and fapolicyd settings, and the packages for any DNS or Active Directory trust roles. Each item costs more when existing DNS zones, firewall policy or change control are unclear. Cost is largely one-time work, but drift in DNS records and time sources recurs as the environment changes. When you ask for a quote, ask which items are included, who performs the changes in your environment, and which decisions you must make before work begins.

How long does host preparation take before FreeIPA installation?

Duration depends on the state of your existing network and the number of approvals needed, more than on the FreeIPA software itself. The work takes longer when DNS records must be created or corrected, when firewall requests go through a separate team, or when hosts lack reliable time sources. Multi-site layouts add review of replication paths and DNS placement. No fixed duration applies to every environment, so ask a partner to state the assumptions behind any timeline, including lead times for change approvals and the number of hosts in scope.

What does preparation need from our own network, DNS and security teams?

Preparation needs decisions and changes from several teams at once. Typical inputs include:

DNS staff to confirm the IPA domain, which must not overlap with any Active Directory domain if you plan a trust, and to create forward and reverse records for each server.
Network staff to open the ports FreeIPA needs between servers and clients, and to confirm that time sources are reachable for chrony.
Security staff to review crypto policy, umask, fapolicyd rules and any FIPS requirements before they are applied.
Change approvers to sign off on the host list, firewall rules and the maintenance window.

Record who owns each item before the build starts, because gaps usually surface during installation.

Can our internal team prepare hosts for FreeIPA without a partner?

A team with Linux administration, DNS and firewall experience can prepare hosts without a partner, provided it has time and clear ownership. The risks are in the details: reverse DNS that does not match host names, chrony configured against unreliable sources, fapolicyd or umask defaults that block installation, and DNS roles planned after the fact. A partner adds value when the team lacks one of these skills or when deadlines are tight. Either way, write a checklist of prerequisites and test each host against it before running the installer.

What should we check before asking a partner for a FreeIPA quote?

Prepare the inputs a partner needs to scope the work, because the quote follows from the written scope. Gather the number of servers and clients, the planned sites and whether each runs a replica, the operating system for each host, whether you need integrated DNS, and whether an Active Directory trust is planned. Also list your DNS zones, firewall process, change control steps and any compliance obligations that affect host hardening. Confirm whether you expect the partner to make changes directly or to hand you a runbook. The clearer these answers, the fewer assumptions a quote has to carry.

How does preparation differ for a single server and a multi-site layout?

A single server needs one set of host name, DNS, time and firewall checks, and the decisions are mostly local. A multi-site layout repeats those checks in every site and adds decisions about where replicas run, which hosts carry DNS or certificate roles, and how sites reach each other. The project recommendations advise at least two to three replicas in each datacenter, no more than four replication agreements per replica, and at least two DNS servers in each client's resolv.conf, so plan each site's host list before preparing any of them. Ask a partner how they will verify the layout from each site, not just from the first one.

How DeployOpen scopes FreeIPA host preparation

DeployOpen plans, implements, hardens and documents FreeIPA on infrastructure you control, including the host preparation that comes before any server is installed. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory the planned server hosts, their DNS names, reverse DNS records and time sources before agreeing the written scope.
Confirm which ports, firewall zones and network paths must open between servers, clients and any Active Directory domain controllers.
Decide in writing whether DNS, PKI or AD trust roles are in scope, since each adds packages and host requirements.

How we build

Configure chrony on every planned server and check synchronization before the installer runs.
Set host names, reverse DNS and crypto policy to the agreed standard, and verify each result from every server.
Test umask and fapolicyd settings against the installer in a staging environment before changing production hosts.

How we hand over

Deliver a host preparation record listing each setting, its value, the check that confirmed it and its owner.
Provide the exact verification commands and expected outputs so your team can rerun the checks later.
Document the firewall rules, time sources and packages added for DNS or trust roles in your change records.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial build.
Re-run the host checks when new replicas, clients or network segments join the FreeIPA topology.
Confirm with your own team which health and audit checks will run after installation and who acts on the results.

FreeIPA server installation prerequisites