Overview

Part 1 built the FreeIPA server. Part 2 starts where day-to-day Linux operations begin: a client is enrolled into FreeIPA, resolves central users and groups, obtains Kerberos tickets and allows SSH logins with central identities.

The lab used Fedora 44, FreeIPA 4.13.3, SSSD 2.13.1, SELinux Enforcing, working forward and reverse DNS and separate server/client VMs. The time-skew failure test remained inconclusive; Kerberos clock skew is therefore described as a documented requirement, not as a failure mode proven in this lab.

Identity Series: Current Position

This article is Part 2 of the Identity series with FreeIPA and Keycloak. Part 1 covers installing the first FreeIPA server. This part documents the practical client path: ipa-client-install, SSSD, NSS, PAM, Kerberos, SSH, cache and recovery.

https://ipa01.example.test/ipa/ui/

The test starts at the FreeIPA web UI. The screenshot shows only the isolated lab environment, not production credentials.

https://ipa01.example.test/ipa/ui/

After login, FreeIPA administration is reachable. This confirms the server side for the client checks.

Lab Setup

The lab used ipa01.example.test as the FreeIPA server and client01.example.test as the enrolled Linux client. All screenshots and commands come from this isolated test environment.

bash
Server:        ipa01.example.test
Client:        client01.example.test
Domain:        example.test
Realm:         EXAMPLE.TEST
Distribution:  Fedora 44
FreeIPA:       4.13.3
SSSD:          2.13.1
SELinux:       Enforcing
https://ipa01.example.test/ipa/ui/#/e/user/search

The central user testuser exists in FreeIPA and is later resolved on the Linux client through SSSD/NSS.

https://ipa01.example.test/ipa/ui/#/e/group/details/lab-users

The lab-users group proves central group management and the POSIX group resolution later visible on the client.

What Client Enrollment Changes

ipa-client-install is more than package setup. The client is registered as a FreeIPA host, receives a host identity, Kerberos configuration, SSSD domain configuration and integration into NSS and PAM. Linux then asks SSSD for users and groups from the central identity source instead of relying only on local accounts.

  • NSS resolves central users and groups for Linux tools such as id, getent or ls.

  • PAM uses SSSD for login, password checks and optional home directory creation on first login.

  • Kerberos issues tickets for users and services in the realm.

  • SSSD caches identities and, after successful login, authentication data for defined offline scenarios.

Prerequisites

Before enrollment, name resolution, time and package basics must be correct. The client FQDN, reachable FreeIPA DNS records and synchronized time are especially important.

bash
hostnamectl
getent hosts ipa01.example.test
dig +short ipa01.example.test
dig +short -x <client-ip>
timedatectl
chronyc tracking
getenforce

Install the FreeIPA Client

On Fedora, install the FreeIPA client packages. SSSD, Kerberos tools and oddjob-mkhomedir are relevant so central users can log in cleanly and receive home directories.

bash
sudo dnf install -y freeipa-client sssd oddjob-mkhomedir krb5-workstation openssh-server

Enroll the Linux Client into FreeIPA

The lab used automated enrollment. The central interactive command looks like this; real passwords do not belong in scripts, screenshots or articles.

bash
sudo ipa-client-install \
  --domain=example.test \
  --realm=EXAMPLE.TEST \
  --server=ipa01.example.test \
  --mkhomedir \
  --enable-dns-updates

Verify Enrollment on the FreeIPA Server

After enrollment, the client must be visible as a FreeIPA host. This is the fastest server-side check that the host identity exists.

bash
ipa host-show client01.example.test
https://ipa01.example.test/ipa/ui/#/e/host/search

client01.example.test is registered as a FreeIPA host. This is the visible server-side proof of completed enrollment.

SSSD: The Bridge Between Linux and FreeIPA

SSSD is the central bridge between Linux and FreeIPA. It talks to the identity source, exposes NSS and PAM data, handles Kerberos-related behavior and manages the local cache. systemctl and sssctl are the most important first operational tools.

bash
systemctl status sssd
sssctl domain-status example.test
sssctl user-checks testuser
bash
systemctl is-active sssd
sssctl domain-status example.test


active
Online status: Online


Active servers:
IPA: ipa01.example.test


Discovered IPA servers:
- ipa01.example.test

Resolve Users Through NSS

When NSS works through SSSD, standard Linux tools see the central user. This is what separates a working enrollment from merely installed client packages.

bash
id testuser
getent passwd testuser
bash
id testuser
getent passwd testuser


uid=376600003(testuser) gid=376600003(testuser) groups=376600003(testuser),376600004(lab-users),376600005(linux-admins)
testuser:*:376600003:376600003:Test User:/home/testuser:/bin/sh
bash
getent passwd testuser


testuser:*:376600003:376600003:Test User:/home/testuser:/bin/sh

Groups and POSIX Attributes

FreeIPA centrally manages POSIX attributes such as UID, GID, login shell and group membership. The client resolves these values through SSSD; local duplicates with identical names should be avoided.

bash
getent group lab-users
id testuser

Kerberos Login

Kerberos confirms that the user can authenticate in the realm. kinit obtains a ticket and klist shows the result. The lab successfully proved ticket issuance for testuser.

bash
kinit testuser
klist
bash
kinit testuser
klist


Password for testuser@EXAMPLE.TEST:
Ticket cache: KCM:1001
Default principal: testuser@EXAMPLE.TEST


Valid starting       Expires              Service principal
09/19/2026 13:54:16  09/20/2026 13:28:19  krbtgt/EXAMPLE.TEST@EXAMPLE.TEST

klist shows the Kerberos ticket in the EXAMPLE.TEST realm. This proves ticket issuance in the lab.

PAM, Home Directory and SSH

Linux login runs through PAM. With oddjob-mkhomedir or equivalent PAM integration, the home directory is created at first login. SSH therefore uses the same central user as local login.

bash
ssh testuser@client01.example.test
pwd
id
bash
ssh testuser@client01.example.test
pwd
id


testuser
/home/testuser
uid=376600003(testuser) gid=376600003(testuser) groups=376600003(testuser),376600004(lab-users),376600005(linux-admins)

The central user can log in through SSH; PAM, SSSD and home directory creation work together.

SSSD Cache and Offline Behavior

SSSD can cache known identities and, after a successful login, authentication data. That does not mean that a brand-new user who never logged in can always work offline. The lab checked cache behavior, offline authentication after prior login and recovery after service and DNS disruption.

bash
sssctl user-checks testuser
sudo systemctl stop sssd
sudo systemctl start sssd
sssctl domain-status example.test

DNS Failure, SSSD Failure and Recovery

The lab controlled DNS and SSSD failure conditions and then restored them. Expected behavior: DNS problems affect new resolution and server contact, while the SSSD cache only provides limited local continuity. After DNS or SSSD recovery, id, getent, kinit and SSH must work again.

bash
getent hosts ipa01.example.test
id testuser
kinit testuser
ssh testuser@client01.example.test
sssctl domain-status example.test

Troubleshooting

ipa-client-install does not find the server

Check
Check dig, getent hosts and SRV records
Typical Cause
DNS or search domain is wrong

id testuser returns nothing

Check
Check systemctl status sssd and sssctl domain-status
Typical Cause
SSSD domain inactive or FreeIPA unreachable

kinit fails

Check
Check realm, password, time and KDC reachability
Typical Cause
Kerberos configuration, clock or credentials

SSH login does not work

Check
Check PAM, sshd_config, HBAC and logs
Typical Cause
PAM/HBAC/SSHD blocks login

Home directory is missing

Check
Check oddjobd and PAM mkhomedir
Typical Cause
Home directory creation is not active

Result Check

Client enrollment

Check
Host client01.example.test visible in FreeIPA
Expected Result
Host is centrally registered
Status
PASS

SSSD

Check
sssctl domain-status example.test
Expected Result
Domain is reachable and usable
Status
PASS

NSS

Check
id/getent for testuser
Expected Result
Central identity resolves
Status
PASS

Kerberos

Check
kinit and klist
Expected Result
Ticket in realm EXAMPLE.TEST exists
Status
PASS

PAM/SSH

Check
SSH login with testuser
Expected Result
Central user can log in
Status
PASS

Cache/recovery

Check
SSSD/DNS disruption and return
Expected Result
Resolution and login work again after recovery
Status
PASS

Security and Operational Aspects

For production, the lab commands alone are not enough. Clean DNS zones, time sources, SELinux, restrictive administrator rights, documented enrollment processes, logging, FreeIPA server backups and a clear client re-enrollment process matter.

Kerberos is time-sensitive. The MIT Kerberos documentation describes clock skew as a security boundary. This specific failure mode was not reliably reproduced in this lab and is therefore not counted as lab proof.

Limits of This Lab

  • Fedora 44 was tested as both server and client platform; this was not a cross-distribution matrix.

  • No FreeIPA replica or HA topology was tested.

  • HBAC, sudo rules, password policies and lifecycle workflows follow in later lab parts.

  • The time-skew failure case remained inconclusive and is not claimed as PASS.

What Comes Next in the Identity Series

The next practical step is central identity lifecycle: creating, activating and disabling users, maintaining groups, testing password and expiration behavior and proving those states on an enrolled Linux client. That follow-up article is not published yet and is therefore not linked here.