You need a single source of truth for logins
You just provisioned a fresh Fedora Server instance to handle user logins for your small office. You type a username and password at the terminal, but the system asks you to create a local account. You repeat this on three different machines. The password drifts. The accounts multiply. You need a single place to manage users, groups, and SSH keys without touching every machine individually.
How FreeIPA actually works
FreeIPA solves this by combining three established Linux technologies into one managed stack. Kerberos handles the authentication handshake. LDAP stores the user database and group memberships. DNS and NTP keep the clocks and names synchronized across the network. Think of it as a central switchboard. Every machine on your network checks the switchboard before granting access. The switchboard remembers who is allowed in, what groups they belong to, and which SSH keys they are authorized to use. You only maintain the database on one server. The clients pull the configuration automatically.
The installation process sets up the database, generates the Kerberos keys, configures the web UI, and writes the initial DNS zones. You will run one interactive command. The command asks for your domain name, realm name, administrator password, and network details. It then handles the rest. You do not need to manually edit LDAP schemas or write Kerberos configuration files by hand. The installer generates them for you.
Reboot before you debug. Half the time the symptom is gone.
Prerequisites and hostname resolution
FreeIPA refuses to start if the server cannot resolve its own hostname. The installer checks forward DNS and reverse DNS before touching the database. If your machine is called auth.example.com, a DNS query for auth.example.com must return the server IP. A reverse lookup for that IP must return auth.example.com. The names must match exactly. Case sensitivity matters in the reverse lookup record.
Run a quick check before installing anything.
# Verify forward resolution matches the expected FQDN
hostname -f
# Verify reverse resolution matches the forward name
dig -x 192.168.1.50 +short
# Compare the two outputs. They must be identical.
If the outputs differ, fix your DNS zone files or /etc/hosts before proceeding. FreeIPA will abort with a clear error if the names do not match. You can also use dnf upgrade --refresh to pull the latest package metadata before installing, but the DNS requirement is the hard blocker.
Edit configuration files in /etc/. Files in /usr/lib/ ship with the package and will be overwritten on the next update. The installer respects this boundary and writes all runtime configuration to /etc/ipa/ and /etc/dirsrv/.
Running the installation wizard
Install the server package and launch the interactive setup. The command name is ipa-server-install. It replaces the older ipa-install wrapper and gives you direct control over the prompts.
# Pull the latest package metadata and install the server stack
sudo dnf upgrade --refresh
sudo dnf install freeipa-server -y
# Launch the interactive installer. It will pause for your input.
sudo ipa-server-install
The wizard asks for your domain name and realm name. The domain name is usually your DNS suffix. The realm name is typically the uppercase version of that suffix. You will then set the Directory Manager password and the IPA admin password. The Directory Manager password protects the underlying LDAP database. The IPA admin password protects the web UI and the ipa command line tool.
The installer will ask if you want to configure DNS. Say yes if this server will handle internal name resolution. Say no if you already run a separate BIND or Unbound server and plan to forward IPA DNS queries to it. The wizard will then ask for the reverse zone name. This must match your subnet. For a 192.168.1.0/24 network, the reverse zone is 1.168.192.in-addr.arpa.
# After the wizard finishes, check the service state immediately
sudo systemctl status ipa.service
# Review the last 50 lines of the installer log for warnings
sudo journalctl -xeu ipa.service --no-pager -n 50
The installer runs for several minutes. It compiles certificates, starts the Directory Server, configures Kerberos, and sets up the web UI. You will see a progress bar. Do not interrupt it. If it fails, read the log output before running it again. The installer is not idempotent. A second run will try to recreate certificates and may conflict with the first attempt.
Run journalctl -xe first. Read the actual error before guessing.
Verify the server is answering correctly
A successful installation leaves three core services running. The Directory Server stores the data. The Kerberos Key Distribution Center handles authentication tickets. The HTTP service serves the web UI and the REST API. Check each one individually.
# Confirm the LDAP directory is listening on port 389
sudo ss -tlnp | grep 389
# Confirm the Kerberos KDC is listening on port 88
sudo ss -tlnp | grep 88
# Query the server for the admin user to prove the database is reachable
ipa user-find admin
The ipa user-find command should return a table with the admin username, full name, and email address. If it returns nothing, the LDAP service is not answering or the client configuration is missing. The installer automatically configures the server as its own client, so the ipa command should work without extra setup.
Test a password change to verify Kerberos is functioning.
# Change the admin password to prove ticket granting works
ipa passwd admin
# You will be prompted for the current password and the new password twice.
If the password change succeeds, the authentication pipeline is complete. You can now join client machines using ipa-client-install. The client installer will pull the DNS records, fetch the Kerberos keys, and configure SSSD automatically.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and what the error looks like
DNS misconfiguration is the most frequent blocker. The installer checks reverse DNS strictly. If your reverse zone is missing or points to the wrong hostname, you will see this exact output:
Error: Reverse DNS lookup failed for 192.168.1.50. Expected auth.example.com, got nothing.
Fix the PTR record in your authoritative DNS server. Wait for propagation. Run the installer again. Do not force it past the check. Kerberos tickets will fail silently if forward and reverse names do not match.
SELinux denials appear when you move configuration files manually. FreeIPA ships with strict SELinux policies. If you copy a certificate or a keytab into /etc/ipa/ without preserving the security context, the Directory Server will refuse to start. Check the audit log for the exact denial.
# Search for recent SELinux denials related to the IPA services
sudo journalctl -t setroubleshoot | grep ipa
The output will include a one-line summary and a URL to a solution. Read the summary before disabling SELinux. Disabling SELinux breaks the entire security model and will cause the web UI to reject connections. Restore the correct context with restorecon -Rv /etc/ipa/ instead.
Hostname changes after installation break the Kerberos realm. The KDC binds to the FQDN during setup. If you rename the server later, the KDC will reject tickets. You must reinstall the server or run the reconfiguration wizard. Plan the hostname before you run ipa-server-install.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
When to use FreeIPA versus other identity stacks
Use FreeIPA when you want a fully managed Linux identity stack with a web UI, automated client enrollment, and integrated DNS and NTP. Use Active Directory when your organization already runs Windows servers and needs Group Policy, Exchange integration, and legacy NTLM fallback. Use Samba AD when you need Active Directory compatibility but want to run everything on Linux without Microsoft dependencies. Use local accounts when you only manage one or two machines and do not need centralized password rotation or SSH key distribution. Stay on the upstream Workstation if you only deviate from the defaults occasionally.