Set Up a FreeIPA Server on AlmaLinux 8 (or CentOS 8) Without the Headache
If you’re looking to spin up an internal identity platform that feels like Kerberos‑powered LDAP, this walk‑through will get your FreeIPA Server running on AlmaLinux 8 or its long‑dead sibling CentOS 8 in under an hour. No fancy networking diagrams required—just a fresh VM and a few typed commands.
What You’ll Fix Today
You’ll learn how to:
- Enable the right repos and install the FreeIPA packages.
- Configure DNS and firewall rules so clients can find and talk to the server.
- Bootstrap the domain with sensible defaults, avoiding the “I’m in a room full of strangers” nightmare.
Prerequisites
| Item | Why it matters |
|---|---|
| Root or sudo privileges | FreeIPA will write system files and open ports. |
| Static IP address | Clients need to resolve the server by name, not just ARP. |
| DNS zone (or forwarders) | Without proper PTR/AAAA records, Kerberos tickets fail silently. |
If you’ve been playing with a fresh AlmaLinux 8 install that only knows how to pull updates from the default repo, you’re already halfway there.
Enable the FreeIPA Repository and Install Packages
dnf -y update dnf -y module enable php:7.4 # FreeIPA uses PHP 7.4 for its web UI dnf install -y freeipa-server bind-dyndb-ldap
Why this matters:
The php stream is a dependency of the IPA web console; without enabling it, the installation will abort mid‑step. Pulling in bind-dyndb-ldap lets FreeIPA act as a dynamic DNS backend out of the box.
Prepare the System for Kerberos
systemctl stop firewalld setenforce 0
During bootstrapping, FreeIPA will open ports 88 (Kerberos), 464 (Kpasswd), and 389/636 (LDAP). Temporarily disabling the firewall and SELinux makes the wizard’s life easier. We’ll turn them back on later.
I’ve seen a handful of people leave SELinux disabled permanently after an “Access denied” error when trying to join clients. That’s not ideal; we’ll re‑enable it cleanly at the end.
Bootstrap the Domain
ipa-server-install \ --realm=EXAMPLE.COM \ --domain=example.com \ --ds-password='StrongPassw0rd!' \ --admin-password='AdminStr0ng!' \ --setup-dns \ --no-ntp \ --forwarder=8.8.8.8
Walk through the prompts with sensible defaults:
1. Realm – All‑caps, like EXAMPLE.COM.
2. Domain – Your actual DNS domain; must match your zone.
3. DS password – Internal directory service root DN.
4. Admin password – The web UI’s admin.
The wizard will:
- Set up PostgreSQL for LDAP storage.
- Configure Kerberos KDC and PKINIT if you like smartcards.
- Spin up a bind9 server that feeds from the directory.
If you skip --setup-dns, FreeIPA won’t act as your authoritative DNS, meaning clients can’t resolve the server name unless you already have a separate BIND setup pointing to it.
Re‑enable Security Features
setenforce 1 systemctl start firewalld firewall-cmd --permanent --add-service=ldap firewall-cmd --permanent --add-service=ldaps firewall-cmd --permanent --add-service=kpasswd firewall-cmd --permanent --add-service=kerberos firewall-cmd --reload
Why this matters:
With SELinux back on, you’ll avoid random “Permission denied” errors when clients try to bind. The firewall rules open the exact ports FreeIPA needs; nothing more, nothing less.
Test Client Connectivity
On a workstation that should join the domain:
kinit admin@EXAMPLE.COM ipa user-find -x admin
If you see a list of users, Kerberos and LDAP are talking. If not, check journalctl -u ipa* on the server for clues—most errors show up there.
I once had a client that kept timing out because its system clock was off by 30 minutes. FreeIPA will reject tickets with a time skew > 5 minutes, so always sync NTP first.
Troubleshooting Quick‑Fixes
- “Could not bind to LDAP” – Verify the server’s DNS A/AAAA record and that ipa-server-install finished without errors.
- “Kerberos authentication failed” – Ensure both client and server clocks are in sync; check /etc/chrony.conf or /etc/systemd/timesyncd.conf.
- SELinux blocking services – Run sealert -a /var/log/audit/audit.log to see what’s being denied.
Wrap‑Up
You’ve just turned a plain AlmaLinux 8 box into a central identity hub that can manage users, host keys, and even DHCP leases if you extend it. FreeIPA isn’t a silver bullet for every environment, but in a lab or small office it’s surprisingly lightweight.
Give it a spin, play around with the web UI under https://<your‑ipa‑server>/, and watch your internal authentication problems shrink faster than a bad Wi‑Fi password.
