The Real Problem: When You Have Too Many Servers and Not Enough Order
Have you ever had to SSH into each server individually just to add a new user? Or dealt with the situation where an employee leaves but their accounts are still scattered across 15 different servers? This is an incredibly common problem for small teams as their infrastructure starts growing fast.
I ran into this exact situation when our company scaled from 3 to 12 servers in just 6 months. Managing users manually through /etc/passwd and copy-pasting SSH keys is a recipe for your first security incident.
FreeIPA was built to solve exactly this problem — an open-source Identity Management stack that bundles LDAP, Kerberos, DNS, and a Certificate Authority into a single package. Red Hat uses it as the foundation for IdM in RHEL, while Fedora is where it’s developed and where the latest features are tested first.
What Problems Does FreeIPA Solve?
Before diving into installation, it’s worth understanding what FreeIPA can — and more importantly, cannot — do:
- Centralized user management: Create or delete users in one place, with changes taking effect immediately across all domain-joined machines
- Single Sign-On (SSO): Log in once and access multiple services through Kerberos tickets
- Host-based access control (HBAC): Define which users can SSH into which servers
- Centralized sudo policies: Manage sudo permissions without editing
/etc/sudoerson every machine - Integrated DNS: Manage internal DNS for your domain
- Certificate management: Internal CA with automatic certificate issuance and revocation
FreeIPA is not the right choice for complex hybrid cloud environments — in that case, consider Keycloak or FreeIPA + AD Trust. It also doesn’t replace public IdPs like Okta if you need OAuth2/OIDC for web applications.
Installing FreeIPA Server
System Requirements
FreeIPA is fairly resource-hungry since it runs multiple services simultaneously. Minimum requirements:
- RAM: 2GB (4GB recommended for production)
- CPU: 2 cores
- Disk: 20GB+ (LDAP database grows with the number of objects)
- Hostname must be resolvable — this is the most commonly overlooked requirement
Preparing Hostname and DNS
FreeIPA is extremely sensitive to hostname and DNS configuration. Skipping this step will cause the installation to fail repeatedly:
# Set the hostname as a FQDN
hostnamectl set-hostname ipa.lab.internal
# Verify the hostname resolves correctly
hostname -f
# Output should be: ipa.lab.internal
# Add to /etc/hosts if no DNS server is available yet
echo "192.168.1.100 ipa.lab.internal ipa" >> /etc/hosts
# Verify
ping -c 1 ipa.lab.internalInstalling Packages
# Update the system first
dnf update -y
# Install FreeIPA server with DNS support
dnf install -y freeipa-server freeipa-server-dns
# Open the firewall for required services
firewall-cmd --permanent --add-service={freeipa-ldap,freeipa-ldaps,freeipa-replication,dns,kerberos,kpasswd,http,https,ntp}
firewall-cmd --reloadRunning the Installer
This is the most critical step. FreeIPA’s interactive installer is quite smart — it validates your hostname, checks forward and reverse DNS, then prompts for each parameter before starting the installation:
ipa-server-install \
--domain=lab.internal \
--realm=LAB.INTERNAL \
--ds-password=YourDirectoryPassword \
--admin-password=YourAdminPassword \
--setup-dns \
--forwarder=8.8.8.8 \
--forwarder=1.1.1.1 \
--auto-reverse \
--unattendedThis process takes about 5–10 minutes. It installs and configures: Directory Server (389-ds), Kerberos KDC, Apache httpd, DNS (BIND), NTP, and the Certificate Authority (Dogtag).
I usually add --unattended to skip the interactive prompts. For your first run, try removing that flag to see what the installer asks — it helps you understand which components are being configured.
Post-Installation Configuration
Getting a Kerberos Ticket and Starting Management
# Obtain a ticket for the admin account
kinit admin
# Enter the admin password you set during installation
# Verify the ticket
klist
# Access the web UI
# https://ipa.lab.internal/ipa/ui/FreeIPA’s web UI is fairly intuitive, but in practice the CLI is much faster when you need to work in bulk or script out onboarding workflows.
Creating Users and Groups
# Add a new user
ipa user-add trungnguyen \
--first=Trung \
--last=Nguyen \
[email protected] \
--shell=/bin/bash
# Set the password
ipa passwd trungnguyen
# Create a group for the devops team
ipa group-add devops --desc="DevOps Engineers"
# Add the user to the group
ipa group-add-member devops --users=trungnguyenConfiguring Host-Based Access Control (HBAC)
HBAC is my favorite feature in FreeIPA. Instead of logging into each server to adjust permissions, you define rules once in a central location and they take effect immediately across all enrolled machines:
# First, disable the default "allow_all" rule (too permissive)
ipa hbacrule-disable allow_all
# Create a rule: only devops can SSH into production servers
ipa hbacrule-add allow_devops_prod \
--desc="Allow devops team to access production servers"
# Add the SSH service to the rule
ipa hbacrule-add-service allow_devops_prod --hbacsvcs=sshd
# Add the devops group to the rule
ipa hbacrule-add-user allow_devops_prod --groups=devops
# Add the target host to the rule (after it has been enrolled)
ipa hbacrule-add-host allow_devops_prod --hosts=prod-web-01.lab.internalCentralized Sudo Policies
# Create a sudo rule for devops — allow running systemctl
ipa sudorule-add devops_systemctl_rule
# Add the allowed command
ipa sudocmd-add /usr/bin/systemctl
ipa sudorule-add-allow-command devops_systemctl_rule \
--sudocmds=/usr/bin/systemctl
# Apply to the devops group
ipa sudorule-add-user devops_systemctl_rule --groups=devops
# Apply to all hosts
ipa sudorule-add-host devops_systemctl_rule --hosts=ALLEnrolling Clients into the FreeIPA Domain
To use centralized authentication on other servers, you need to install the FreeIPA client on each of them:
# On the client machine (also running Fedora/RHEL)
dnf install -y freeipa-client
# Enroll into the domain
ipa-client-install \
--domain=lab.internal \
--server=ipa.lab.internal \
--realm=LAB.INTERNAL \
--principal=admin \
--password=YourAdminPassword \
--mkhomedir \
--unattended
# After enrollment, verify that the IPA user resolves correctly
id trungnguyen
# Output: uid=1234567890(trungnguyen) gid=1234567890(trungnguyen) groups=...Verification and Monitoring
Checking Running Services
# Get an overview of all FreeIPA service statuses
ipactl status
# Sample output:
# Directory Service: RUNNING
# krb5kdc Service: RUNNING
# kadmin Service: RUNNING
# named Service: RUNNING
# httpd Service: RUNNING
# ipa-custodia Service: RUNNING
# pki-tomcatd Service: RUNNING
# ipa-otpd Service: RUNNINGEnd-to-End Authentication Testing
# Test an HBAC rule before enforcing it for real
ipa hbactest \
--user=trungnguyen \
--host=prod-web-01.lab.internal \
--service=sshd
# Shows which rule matched and the resulting Allow/Deny decision
# Test Kerberos authentication
kinit trungnguyen
klist
# Test an LDAP query
ldapsearch -x -H ldap://ipa.lab.internal \
-b "dc=lab,dc=internal" \
-D "uid=admin,cn=users,cn=accounts,dc=lab,dc=internal" \
-W "(uid=trungnguyen)"Logs and Monitoring
# View Directory Server logs
journalctl -u dirsrv@LAB-INTERNAL -f
# Kerberos KDC logs
journalctl -u krb5kdc -f
# Apache logs (web UI + API)
journalctl -u httpd -f
# Check replication status (if replicas are configured)
ipa-replica-manage list
ipa-replica-manage statusBackup and Recovery
A hard lesson learned after a server crash with no backup in place: set up a nightly backup cronjob from day one — don’t wait for an incident to remind you.
# Full backup (files + data, typically ~500MB–1GB)
ipa-backup --gpg --gpg-keyring=/root/ipa-backup-key
# List available backups
ls -lh /var/lib/ipa/backup/
# Restore when needed
ipa-restore /var/lib/ipa/backup/ipa-full-2026-04-28-00-00-00Practical Notes from Production
After running FreeIPA in production for a while, here are a few things worth pinning down:
- Kerberos ticket expiry: By default, tickets expire after 24 hours. For long-running jobs, revisit the ticket policy or use a keytab instead
- Time sync is mandatory: Kerberos won’t tolerate clock skew greater than 5 minutes. Make sure all machines sync NTP to the IPA server
- Replicas for high availability: If the IPA server goes down, all authentication stops. Production environments need at least 2 replicas
- SELinux and FreeIPA: FreeIPA runs fine with SELinux in enforcing mode — it’s one of the few enterprise applications designed correctly for SELinux from the ground up
I’ve been using Fedora as my primary development machine for 2 years and I’m quite happy with the package update cadence. FreeIPA on Fedora typically runs a few months ahead of RHEL. Using it to lab new features before rolling them out to production RHEL is a solid workflow.
