What Is FreeIPA?
FreeIPA is an identity management platform for Linux environments. It combines central users, groups, hosts, Kerberos authentication, certificates, client enrollment and policies in one management layer. If you are coming from local accounts, manually maintained SSH access or isolated LDAP setups, FreeIPA gives you a shared identity core.
LDAP answers which objects exist: users, groups, hosts and services. Kerberos answers how users and services authenticate. SSSD is the bridge on the Linux client: it makes central users appear in `id`, `getent`, PAM and NSS even though they are not local entries in `/etc/passwd`. HBAC later controls who may access which host. sudo controls what a user may run with privileges there.
Component JobLDAP / 389-DS Store identities, groups, hosts and directory dataKerberos KDC Authenticate with tickets instead of repeatedly sending passwordsSSSD Connect the Linux client to FreeIPA, use NSS/PAM and cache dataDogtag CA Internal certificate authority for FreeIPA certificatesFreeIPA Management layer combining LDAP, Kerberos, CA, DNS options and policies
The Lab
We build a small reproducible lab with one FreeIPA server and one Linux client. The domain and realm are intentionally generic. Do not use a production DNS zone or a real customer domain for your own tests.
Lab domain: example.testRealm: EXAMPLE.TESTipa01.example.test FreeIPA server, CA, LDAP, Kerberos, Web UIclient01.example.test Linux client enrolled into the IPA domainExternal DNS:ipa01.example.test -> server IPclient01.example.test -> client IPserver IP -> ipa01.example.testclient IP -> client01.example.test
This lab installs FreeIPA without integrated DNS. That is realistic in many enterprise environments because DNS already exists separately. Integrated FreeIPA DNS is still valid and often easier for a first lab, especially when the whole lab zone is delegated to FreeIPA.
Requirements and Platform Choice
FreeIPA is not a tiny daemon. It combines Directory Server, Kerberos, HTTPD, Dogtag CA, SSSD-adjacent client integration and a management API. For a lab, 2 vCPU, 4 GB RAM and 20 GB disk are comfortable. Production sizing depends on users, groups, hosts, certificate usage, replication and the operating model.
Upstream names Fedora and Red Hat Enterprise Linux as supported platforms. RHEL provides vendor support and an enterprise lifecycle. Fedora provides very recent FreeIPA versions but has a shorter lifecycle and requires more upgrade discipline. Rocky Linux and AlmaLinux are Enterprise Linux compatible distributions with suitable packages, but their support model must be evaluated separately. CentOS Stream sits ahead of RHEL in the development flow and should not be treated as identical to RHEL.
Red Hat Identity Management is Red Hat’s supported enterprise variant of this IdM technology for RHEL environments. If FreeIPA should move beyond a lab and run with vendor support, lifecycle, security advisory handling and enterprise operations, Red Hat IdM should be evaluated as the target platform.
Fedora: very recent FreeIPA packages, good for labs and early features.
RHEL: preferred when vendor support, lifecycle and enterprise operations matter.
Rocky Linux / AlmaLinux: technically compatible Enterprise Linux variants; evaluate support and package status separately.
CentOS Stream: closer to the next RHEL than to a classic stable downstream; assess deliberately for production.
Prepare the Server
Set a static hostname first. FreeIPA and Kerberos rely on stable names. A dynamic DHCP hostname or an FQDN pointing to localhost is a common source of installation and authentication failures.
sudo hostnamectl set-hostname ipa01.example.testhostname -f
Check forward and reverse DNS. The FQDN must point to the real server address, and the PTR record should return exactly this FQDN. If you use `/etc/hosts` in a lab, the FreeIPA FQDN must not be placed on the localhost line.
hostnamectl statushostname -fdig +short ipa01.example.test Adig +short -x <SERVER-IP>getent hosts ipa01.example.test
127.0.0.1 localhost localhost.localdomain::1 localhost localhost.localdomain<SERVER-IP> ipa01.example.test ipa01
Install Packages
Package names differ between Fedora and RHEL-compatible platforms. Fedora uses `freeipa-server`; RHEL uses `ipa-server`. Do not install the DNS package here because this lab uses external DNS.
sudo dnf upgrade --refreshsudo dnf install freeipa-server bind-utils chrony firewalld
sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-rpmssudo subscription-manager repos --enable=rhel-9-for-x86_64-appstream-rpmssudo dnf updatesudo dnf install ipa-server bind-utils chrony firewalld
sudo dnf updatesudo dnf install ipa-server bind-utils chrony firewalld
Check Time and Firewall
Kerberos only tolerates limited clock skew. Make sure chronyd is running and the server has a reliable time source. Time is not a side issue here; it is part of authentication.
sudo systemctl enable --now chronydtimedatectlchronyc trackingchronyc sources -v
Open the FreeIPA services on the server. Without integrated DNS, the firewalld service `freeipa-4` is enough; port 53 is only required if the FreeIPA server provides DNS itself.
sudo systemctl enable --now firewalldsudo firewall-cmd --permanent --add-service=freeipa-4sudo firewall-cmd --reloadsudo firewall-cmd --list-services
Install the FreeIPA Server
For the first build, the interactive installer is the better path. It asks for domain, realm, hostname, Directory Manager password, IPA admin password and CA options. The realm is usually uppercase, for example `EXAMPLE.TEST`.
sudo umask 0022sudo ipa-server-install
For later repetition, the same installation can be described non-interactively. In real automation, do not put clear text passwords into shell history or Git.
sudo ipa-server-install \--realm=EXAMPLE.TEST \--domain=example.test \--hostname=ipa01.example.test \--ds-password='<DIRECTORY-MANAGER-PASSWORD>' \--admin-password='<IPA-ADMIN-PASSWORD>' \--unattended
Validate the Installation
Do not rely only on the installer success message. Check services, Kerberos and the IPA API. `kinit admin` obtains a Kerberos ticket for the administrative IPA user; `klist` shows whether that ticket exists.
sudo ipactl statuskinit adminklistipa user-findipa config-show
Then open the Web UI at `https://ipa01.example.test/ipa/ui/` and log in as `admin`. The UI contains Users, Groups, Hosts, HBAC, sudo and Certificates. For this first lab, Users, Groups and Hosts are enough.
Create the First User and Group
A FreeIPA user is a central directory object. It is not local on every server, but after client enrollment it can become visible on Linux systems. A group collects users for later permissions, roles or access models.
Important: a password set by an administrator is an initial password. FreeIPA asks the user to change it during the first Kerberos login. That is intentional and should be tested once in the lab.
kinit adminipa user-add max.mustermann \--first=Max \--last=Mustermann \--email=max.mustermann@example.testipa passwd max.mustermannipa group-add linux-users --desc='Linux users'ipa group-add-member linux-users --users=max.mustermannipa group-show linux-users
Prepare the Client
The client also needs a stable FQDN, working DNS, correct time and network access to the FreeIPA server. If discovery through DNS SRV records is not configured, we pass server, domain and realm explicitly to the client installer.
sudo hostnamectl set-hostname client01.example.testhostname -fdig +short ipa01.example.test Adig +short client01.example.test Adig +short -x <CLIENT-IP>sudo systemctl enable --now chronydchronyc tracking
Install Client Packages
Install `ipa-client` on the client. This package installs the client tooling and dependencies such as SSSD. `oddjob-mkhomedir` is useful so that a home directory can be created during the first login.
sudo dnf upgrade --refreshsudo dnf install freeipa-client bind-utils chrony oddjob-mkhomedir
sudo dnf updatesudo dnf install ipa-client bind-utils chrony oddjob-mkhomedir
Enroll the Client
During enrollment, the host is registered in FreeIPA. The installer configures Kerberos, SSSD, CA trust, NSS/PAM integration and the host keytab. After that, the client is a member of the IPA domain.
sudo ipa-client-install \--domain=example.test \--server=ipa01.example.test \--realm=EXAMPLE.TEST \--mkhomedir
Test the Client
The central user should now be visible on the client. `id` and `getent` test Linux name resolution through NSS/SSSD. `kinit` tests Kerberos. `ipa host-show` shows that the client exists as a host object in FreeIPA.
If the user password was set by an administrator, change it once as the user first. Then request a fresh Kerberos ticket with the new password.
kinit max.mustermann# Enter the initial password set by the administrator.# If FreeIPA asks for a change, set the new user password.kdestroykinit max.mustermannklist
id max.mustermanngetent passwd max.mustermannkinit max.mustermannklistsystemctl status sssd --no-pageripa host-show client01.example.test
The login test is where FreeIPA becomes tangible: the user logs into a Linux host even though that account was not created locally on the host.
ssh max.mustermann@client01.example.testpwdidklist
Understand SSSD
SSSD connects the Linux client to FreeIPA. NSS answers questions such as: Which UID does this user have? PAM participates in login. Kerberos handles authentication. The IPA provider in SSSD talks to FreeIPA and caches identities and, depending on configuration, credentials.
That explains why `id max.mustermann` works even though `max.mustermann` is not in `/etc/passwd`. The client asks SSSD, and SSSD asks FreeIPA or uses its cache. This cache helps during short network problems, but it is not a replacement for proper high availability.
Kerberos in This Lab
Kerberos prevents services from repeatedly seeing passwords. A user authenticates to the KDC and receives a Ticket Granting Ticket. Service tickets can then be derived from it. `kinit` requests a ticket, `klist` displays it.
User|| password or credentialvKerberos KDC|| Ticket Granting Ticket (TGT)vClient|| service ticketvService
Can I Simply Change the OS Later?
A FreeIPA server should not be treated like a stateless web server. FreeIPA stores directory state, Kerberos data, CA state, host and service principals, server roles, certificates and replication relationships. It does not merely remember a distribution name, but many components are coupled to hostname, roles, certificates, topology and platform packages.
For normal package updates within a compatible platform, follow the distribution update path. For OS major upgrades or platform changes, replica replacement is often the cleaner enterprise pattern. Red Hat explicitly documents that in-place upgrades of RHEL IdM servers are not supported for RHEL server migrations.
Existing FreeIPA replica-> add new replica on target platform-> wait for replication-> transfer and verify roles-> run health checks-> cleanly remove old replica
If a server name must be reused, remove the old server cleanly from the topology first, wait for replication, verify that no old roles or segments remain, and only then install the new replica. Reinstalling the same hostname and hoping FreeIPA overwrites the old state correctly is risky.
What Comes After This Lab?
A single FreeIPA server is good for learning, but it is not enterprise high availability. In later Tech articles we will cover FreeIPA replicas and multi-site design, HBAC and sudo, declarative management with Ansible/AWX, Keycloak integration, backup/restore, monitoring and PKI design.
Continue chronologically with FreeIPA in Large Environments: Architecture, High Availability, HBAC, sudo and Keycloak. That article covers the step from the first lab to a reliable enterprise architecture.
The most important next step is not immediate automation. Build the lab manually first and understand users, groups, hosts, Kerberos, SSSD and enrollment. Automation is much easier to validate afterwards because you know which directory objects are created and changed.
Professional Support
Discuss Identity & Access
If FreeIPA should become more than a lab and serve as a central identity platform for Linux environments, ForgeOne supports architecture, implementation, migration, operations and clean handover.
