You provisioned a fresh Fedora Server instance to centralize user accounts and SSH keys. You run the install command, the wizard asks for a realm name, and then it hangs on certificate generation. Or worse, it finishes but the web UI refuses to load on port 443. Identity management sounds simple until the underlying services fight over ports or DNS refuses to resolve the server itself.
What is actually happening under the hood
FreeIPA is not a single daemon. It is a coordinated stack of LDAP, Kerberos, DNS, NTP, and a web administration interface. The installer does not just drop binaries. It generates a Certificate Authority, configures Kerberos realms, writes DNS zones, and adjusts firewall rules. Think of it like setting up a small government agency. You need a registry office, a passport authority, a mail system, and a set of rules for who gets in. The installer builds all of that in one transaction. If one piece fails, the whole transaction rolls back. That is why the process takes time and why it demands a fully qualified domain name before it starts.
The underlying components are mature, independent projects. 389 Directory Server handles the user database. MIT Kerberos provides authentication tickets. BIND or dnsmasq handles name resolution. Dogtag PKI manages certificates. The ipa-server-install script orchestrates them. It writes configuration files, starts services, and registers the server as its own first client. You are not just installing software. You are bootstrapping a trust domain.
Run journalctl -xeu ipa.service before you assume the install failed. The explanatory flag shows you exactly which sub-component aborted.
Prerequisites that the installer will not forgive
The installer will refuse to proceed if your system does not meet basic network and hostname requirements. These are not suggestions. They are hard checks built into the bootstrap script.
Your server must have a static IP address. DHCP leases change. Identity servers cannot change addresses without breaking every client that trusts them. Configure a static address in NetworkManager or your network configuration tool before you begin.
Your hostname must be a fully qualified domain name. server01 will fail. ipa.example.com will pass. The installer uses the FQDN to generate Kerberos realms, DNS zones, and certificate subjects. If your /etc/hostname file contains a short name, edit it now. Run hostnamectl set-hostname ipa.example.com to apply it immediately.
DNS must resolve the server both forward and backward. The installer will query the system resolver for your FQDN and expect an A record. It will then perform a reverse lookup on the IP address and expect a PTR record pointing back to the FQDN. If you do not have an existing DNS infrastructure, you can let FreeIPA create one during installation. The ipa-server-dns package handles this.
Time synchronization must be accurate. Kerberos tickets expire based on strict time windows. A clock drift of more than five minutes will cause authentication to fail across the entire domain. Fedora ships with chronyd enabled by default. Verify it is running before you start the installer.
Set the hostname and verify DNS resolution before you touch the package manager. A botched bootstrap leaves you with half-configured services and a locked database.
Running the installation and configuration
Here is how to pull the packages and launch the interactive setup wizard.
sudo dnf install -y ipa-server ipa-server-dns
# ipa-server provides the core LDAP, Kerberos, and web UI components
# ipa-server-dns adds BIND integration so FreeIPA can manage your zone
# -y skips the package confirmation prompt since we want a clean install
The package manager will pull in dozens of dependencies. This includes 389 Directory Server, SSSD, Dogtag PKI, and various Python libraries. Wait for the transaction to complete. Do not interrupt it. The post-install scripts configure SELinux policies and set up systemd units.
Here is how to launch the configuration wizard.
sudo ipa-server-install
# The script runs as root to modify system files and start services
# It will prompt for realm name, admin password, and DNS options
# Press Enter to accept defaults where appropriate, but verify each prompt
The wizard will ask for your realm name. By convention, this matches your DNS domain in uppercase. If your domain is example.com, enter EXAMPLE.COM. It will ask for the admin password. This password protects the admin user in the LDAP directory and the web UI. Choose a strong password. The wizard will then ask if you want to configure DNS. Answer yes if you are setting up a new domain or want FreeIPA to manage your existing one.
The script will then generate certificates, start services, and configure firewalld. This takes several minutes. Watch the terminal output. If it stops at Configuring certificate server (pki-tomcatd), it is usually waiting for entropy or performing a heavy cryptographic operation. Let it run.
Here is how to check whether the installation completed successfully.
sudo systemctl status ipa.service
# Shows the aggregated state of all FreeIPA sub-services
# Look for "active (exited)" or "active (running)" depending on the unit
# If any component is failed, the wizard will have printed a rollback message
If the wizard succeeded, it will print a summary with the admin password, the web UI URL, and instructions for joining clients. Save that output. You will need it later.
Reboot the server once after installation. Some kernel modules and network bindings only fully initialize on a clean boot.
Verify the stack is healthy
Do not assume the server is ready because the installer printed a success message. Verify each layer independently.
Here is how to test Kerberos authentication against the local server.
kinit admin
# Requests a Kerberos ticket for the admin principal
# You will be prompted for the password you set during installation
# A successful run produces no output and returns to the prompt
Here is how to confirm the ticket is valid and query the directory.
klist
# Displays your current Kerberos ticket cache
# Look for a valid start and end time matching your realm
ipa user-find admin
# Queries the LDAP directory using the IPA CLI
# Should return the admin user's full name, email, and UID
Here is how to check that the web administration interface is reachable.
curl -kI https://localhost/ipa/ui
# -k skips certificate verification for local testing
# -I requests only the HTTP headers
# Look for HTTP/2 200 or HTTP/1.1 200 OK in the response
The web UI uses a self-signed certificate by default. Browsers will warn you about it. That is expected. You can replace it with a trusted CA certificate later, but the self-signed cert works for internal administration.
Run klist and ipa user-find before you join your first client. A broken ticket cache means every client will fail authentication silently.
Common pitfalls and what the error looks like
The installer and runtime will refuse to proceed if prerequisites are misconfigured. You will see specific error messages. Recognize them early.
The ipa-server-install command will refuse to proceed and print DNS resolution failed for ipa.example.com. The reverse lookup does not match the forward lookup. Fix your /etc/resolv.conf or your upstream DNS server before retrying. The installer will not create a working realm if the server cannot find itself.
If you see [FAILED] Failed to start dirsrv@EXAMPLE-COM.service during boot, your 389 Directory Server database is corrupted or the SELinux context is wrong. Run restorecon -Rv /var/lib/dirsrv/ to reset the contexts. Check /var/log/dirsrv/slapd-EXAMPLE-COM/errors for the actual database error. Never edit files in /usr/lib/dirsrv/. Those ship with the package. Apply overrides in /etc/dirsrv/.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. FreeIPA expects enforcing mode. If you see audit: type=1400 audit(1690000000.000:123): avc: denied { read } for pid=1234 comm="httpd", the web server is trying to access a file with the wrong label. Run semanage fcontext and restorecon to fix it. Disabling SELinux breaks the trust model FreeIPA relies on.
Firewall rules must be applied after every manual change. If you open a port for a custom service, run firewall-cmd --reload. Otherwise the runtime config and the persistent config diverge. FreeIPA opens ports 389, 636, 88, 464, 88, 443, 53, and 123 by default. Do not close them manually. Use firewall-cmd --list-all to verify.
Trust the package manager and the installer scripts. Manual file edits drift, snapshots stay.
When to use FreeIPA versus other identity tools
Use FreeIPA when you need a self-hosted, Linux-native identity provider with built-in DNS, PKI, and a web UI. Use Samba Active Directory when you must interoperate with Windows domain controllers and legacy AD clients. Use a simple OpenLDAP server when you only need a directory database and want to manage Kerberos and DNS separately. Use a cloud IAM service like AWS IAM Identity Center or Azure AD when you are running workloads in the cloud and do not want to maintain on-premises infrastructure. Stay on local FreeIPA if you require full control over certificates, audit logs, and network traffic.
Snapshot the system before the upgrade. Future-you will thank you.