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

Source: https://forgeone.solutions/en/tech/install-freeipa
Language: en
Published: 2026-08-30
Updated: 2026-10-22

Install FreeIPA on Fedora 44: server, realm, DNS/time baseline, web UI, first client and technical acceptance as the start of the identity series.

## 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](https://forgeone.solutions/en/products/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.

```bash
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.

```bash
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.

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

```bash
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
```

```bash
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.

```bash
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.

```bash
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\`.

```bash
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.

```bash
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.

```bash
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.

[![FreeIPA login view in the isolated ipa01.example.test lab](https://forgeone.solutions/media/01-freeipa-login.png)](https://forgeone.solutions/media/01-freeipa-login.png)

[![Authenticated FreeIPA web UI with the user overview in the lab](https://forgeone.solutions/media/02-freeipa-authenticated.png)](https://forgeone.solutions/media/02-freeipa-authenticated.png)

## 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.

```bash
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
```

[![FreeIPA user list showing the lab user testuser](https://forgeone.solutions/media/03-freeipa-users-testuser.png)](https://forgeone.solutions/media/03-freeipa-users-testuser.png)

[![FreeIPA lab-users group with testuser as a member](https://forgeone.solutions/media/04b-freeipa-group-lab-users-membership.png)](https://forgeone.solutions/media/04b-freeipa-group-lab-users-membership.png)

## 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.

```bash
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.

```bash
sudo dnf upgrade --refresh
sudo dnf install freeipa-client bind-utils chrony oddjob-mkhomedir
```

```bash
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.

```bash
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.

```bash
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
```

```bash
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.

```bash
ssh max.mustermann@client01.example.test
pwd
id
klist
```

[![FreeIPA host overview with the enrolled client01.example.test](https://forgeone.solutions/media/05-freeipa-hosts-client01.png)](https://forgeone.solutions/media/05-freeipa-hosts-client01.png)

[![Terminal proof on the FreeIPA client showing whoami, id and klist for testuser](https://forgeone.solutions/media/06-client-terminal-login-klist.png)](https://forgeone.solutions/media/06-client-terminal-login-klist.png)

## 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](https://forgeone.solutions/en/tech/freeipa-enterprise-architecture-hbac-sudo-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.

## Sources and further documentation

For production work, also use the current vendor documentation, release notes, security advisories and internal operational standards. ForgeOne complements those sources with practical project experience from planning, implementation and operations.

### 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.

- [Discuss Identity & Access](https://forgeone.solutions/en/identity-management-idm)

## 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.

| Area | Check | Result |
| --- | --- | --- |
| Platform | Fedora Linux 44 documented as server and client baseline | PASS required |
| Hostname/DNS | ipa01.example.test and client01.example.test resolve correctly | PASS required |
| Time | NTP/chrony without relevant clock skew | PASS required |
| FreeIPA server | ipactl status shows running services | PASS required |
| Kerberos | kinit admin and klist work | PASS required |
| Web UI | FreeIPA UI login works | PASS required |
| Client | client enrollment successful and host visible | PASS required |

## 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.

## Hero image

[![freeipa logo.](https://forgeone.solutions/media/freeipa_logo.webp)](https://forgeone.solutions/media/freeipa_logo.webp)

## Author

Mathias Rumbold

## Category

- [Identity & Access](https://forgeone.solutions/en/tech/install-freeipa?category=identity-access)

## Tags

- [FreeIPA](https://forgeone.solutions/en/tech/install-freeipa?tags=freeipa)
- [Identity Management](https://forgeone.solutions/en/tech/install-freeipa?tags=identity-management)
- [Linux](https://forgeone.solutions/en/tech/install-freeipa?tags=linux)
- [Kerberos](https://forgeone.solutions/en/tech/install-freeipa?tags=kerberos)
- [Security](https://forgeone.solutions/en/tech/install-freeipa?tags=security)
- [Red Hat IdM](https://forgeone.solutions/en/tech/install-freeipa?tags=red-hat-idm)

## Identity Management mit FreeIPA und Keycloak

Die Beiträge bauen praktisch aufeinander auf: Fedora-44-basierter FreeIPA-Server, Linux-Clients, Identity-Lifecycle, Passwort-Richtlinien, HBAC, sudo-Regeln, Kerberos-Keytabs, Updates, Backup, Recovery und Hochverfügbarkeit.

1. [Installing FreeIPA: From the First Server to an Enrolled Linux Client (current part)](https://forgeone.solutions/en/tech/install-freeipa)
2. [Connect Linux Clients to FreeIPA: SSSD, Kerberos and Centralized Users](https://forgeone.solutions/en/tech/connect-linux-clients-freeipa-sssd-kerberos-centralized-users)
3. [Managing FreeIPA Users and Groups: Identity Lifecycle in Practice](https://forgeone.solutions/en/tech/managing-freeipa-users-groups-identity-lifecycle-practice)
4. [FreeIPA Password Policies in Practice: Expiration, Lockout and Authentication Behavior](https://forgeone.solutions/en/tech/freeipa-password-policies-expiration-lockout-practice)
5. [FreeIPA HBAC in Practice: Control SSH Access by User, Group and Host](https://forgeone.solutions/en/tech/freeipa-hbac-ssh-access-user-group-host-practice)
6. [FreeIPA sudo rules in practice: delegate commands without root passwords](https://forgeone.solutions/en/tech/freeipa-sudo-rules-command-delegation-practice)
7. [Kerberos service principals and keytabs with FreeIPA in practice](https://forgeone.solutions/en/tech/freeipa-kerberos-service-principals-keytabs-practice)
8. [Updating FreeIPA: package updates, replicas and client compatibility checks](https://forgeone.solutions/en/tech/freeipa-update-package-updates-replicas-client-compatibility)
9. [FreeIPA backup in practice: ipa-backup, certificates, LDAP and recovery windows](https://forgeone.solutions/en/tech/freeipa-backup-ipa-backup-certificates-ldap-recovery)
10. [FreeIPA disaster recovery: restore, replica rebuilds and emergency access testing](https://forgeone.solutions/en/tech/freeipa-disaster-recovery-restore-replica-rebuild-emergency-access)
11. [Running FreeIPA highly available: replication, CA roles, DNS and maintenance workflows](https://forgeone.solutions/en/tech/freeipa-high-availability-replication-ca-dns-maintenance)

## Further content

- [FreeIPA](https://forgeone.solutions/en/products/freeipa)