Installing FreeIPA: From the First Server to an Enrolled Linux Client

Goal of this article

This article makes technical topic practical from an operations perspective: you understand the value, the key decisions and the validation points that must be correct before production use.

The concrete lab baseline for this series is Fedora Linux 44 with ipa01.example.test, client01.example.test and the EXAMPLE.TEST realm. This keeps the FreeIPA examples consistent across installation, clients, policies, sudo, keytabs, updates, backup, recovery and high availability.

Prerequisites

Plan DNS, time, hostnames, realm, administrator accounts and client access before installation. FreeIPA and Red Hat IdM are sensitive to broken name resolution and clock drift.

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 Job
• LDAP / 389-DS Store identities, groups, hosts and directory data
• Kerberos KDC Authenticate with tickets instead of repeatedly sending passwords
• SSSD Connect the Linux client to FreeIPA, use NSS/PAM and cache data
• Dogtag CA Internal certificate authority for FreeIPA certificates
• FreeIPA 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.test
• Realm: EXAMPLE.TEST
• ipa01.example.test FreeIPA server, CA, LDAP, Kerberos, Web UI
• client01.example.test Linux client enrolled into the IPA domain
• External DNS:
• ipa01.example.test -> server IP
• client01.example.test -> client IP
• server IP -> ipa01.example.test
• client 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.

This guide uses one consistent Fedora lab throughout: ipa01.example.test as the FreeIPA server and client01.example.test as the enrolled Linux client. Upstream names Fedora and Red Hat Enterprise Linux as supported platforms. Fedora provides recent FreeIPA packages and is well suited for reproducible labs and technical validation. For long-term enterprise operations with vendor support, lifecycle and security advisory handling, evaluate Red Hat Identity Management on RHEL separately.

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: the platform used in this lab, with recent FreeIPA packages and a consistent server/client setup.

• Red Hat IdM on RHEL: evaluate when vendor support, lifecycle and enterprise operations matter.

• Other distributions: not part of this lab; validate package status, support model and client behavior separately before production use.

• Platform changes: do not mix them into this installation run; plan them as a separate migration or replica scenario.

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.test
hostname -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 status
hostname -f
dig +short ipa01.example.test A
dig +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

In this Fedora lab, the FreeIPA server packages are installed directly from the Fedora repositories. Do not install the DNS package here because this lab uses external DNS and both server and client are based on Fedora.

sudo dnf upgrade --refresh
sudo dnf install freeipa-server bind-utils chrony firewalld

sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-rpms
sudo subscription-manager repos --enable=rhel-9-for-x86_64-appstream-rpms
sudo dnf update
sudo dnf install ipa-server bind-utils chrony firewalld

sudo dnf update
sudo 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 chronyd
timedatectl
chronyc tracking
chronyc 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 firewalld
sudo firewall-cmd --permanent --add-service=freeipa-4
sudo firewall-cmd --reload
sudo 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 0022
sudo 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 status
kinit admin
klist
ipa user-find
ipa 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.

ipa01.example.test/ipa/ui/

ipa01.example.test/ipa/ui/#/e/user/search

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 admin
ipa user-add max.mustermann \
  --first=Max \
  --last=Mustermann \
  --email=max.mustermann@example.test
ipa passwd max.mustermann

ipa group-add linux-users --desc='Linux users'
ipa group-add-member linux-users --users=max.mustermann
ipa group-show linux-users

ipa01.example.test/ipa/ui/#/e/user/search

ipa01.example.test/ipa/ui/#/e/group/details/lab-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.test
hostname -f
dig +short ipa01.example.test A
dig +short client01.example.test A
dig +short -x <CLIENT-IP>
sudo systemctl enable --now chronyd
chronyc 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 --refresh
sudo dnf install freeipa-client bind-utils chrony oddjob-mkhomedir

sudo dnf update
sudo 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.
kdestroy
kinit max.mustermann
klist

id max.mustermann
getent passwd max.mustermann
kinit max.mustermann
klist
systemctl status sssd --no-pager
ipa 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.test
pwd
id
klist

ipa01.example.test/ipa/ui/#/e/host/search

client01.example.test

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 credential
• Kerberos KDC
• | Ticket Granting Ticket (TGT)
• Client
• | service ticket
• Service

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 inside the Fedora lab, follow the Fedora update path and then re-check FreeIPA, Kerberos, SSSD and client login. OS major upgrades or a target platform change should not be mixed into the same installation run; treat them as a separate migration or replica replacement scenario.

• 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

Operations and validation

A successful installation alone is not enough for production operations. Validate services, logs, networking, login, updates, backup and recovery so that the state is repeatable and understandable for other administrators.

Production checklist

• Goal, scope and ownership are documented.
• DNS, TLS, networking, accounts and permissions are validated.
• The installation or change is verified with UI and CLI signals.
• Backup, monitoring, updates and rollback are planned before production use.
• Licensing, support paths and professional services are planned for operations.

Technical Acceptance

Installation is complete only when server, realm, web UI, Kerberos and the first client are technically proven. A reachable web UI alone is not sufficient acceptance.

Do Not Skip This

• Do not use a production customer domain for labs.

• Validate DNS and time before installation, not only after failures.

• Treat the first client as mandatory evidence.

• Think about admin access, recovery access and backup path from part 1 onward.