Binding Systems to the Directory¶
In Part 1 of this series, we installed a FreeIPA master server and discussed the core components that make up the platform. At this point, the identity infrastructure is in place, but it isn’t doing much yet.
To actually make use of FreeIPA, systems need to join the domain. This process is commonly referred to as directory binding, domain enrollment, or simply joining the realm.
When a system joins the FreeIPA domain, several things happen automatically:
- The host is registered in the LDAP directory
- A Kerberos principal is created for the system
- Certificates are issued by the FreeIPA Certificate Authority
- SSSD is configured for authentication
- PAM and NSS are configured for directory-based logins
Once complete, users stored in FreeIPA can log into the system using their centralized credentials.
How FreeIPA Authentication Works¶
Before diving into the commands, it helps to understand the authentication flow.
When a user logs into a FreeIPA-bound system:
- The system queries SSSD
- SSSD contacts the FreeIPA LDAP directory
- Authentication occurs using Kerberos
- Access rules such as HBAC policies are evaluated
- If allowed, the user session is created
SSSD also caches credentials locally, allowing logins to continue working even if the FreeIPA server becomes temporarily unreachable.
Preparing a System to Join FreeIPA¶
Before joining a system to the domain, ensure the following requirements are met:
1. DNS Must Work¶
The client must be able to resolve the FreeIPA servers.
Example:
dig ipa1.example.com
host ipa1.example.com
If DNS does not work, enrollment will fail.
2. Time Synchronization Must Be Correct¶
Kerberos is extremely sensitive to clock drift.
Make sure the system is synchronized with NTP or Chrony:
timedatectl status
If necessary:
dnf install chrony
systemctl enable --now chronyd
3. Install Required Packages¶
On RHEL / CentOS / Rocky / Alma:
dnf install ipa-client
On Debian / Ubuntu:
apt install freeipa-client
Joining the Domain¶
Joining the domain is handled by the ipa-client-install tool.
Example:
ipa-client-install
--server=ipa1.example.com
--server=ipa2.example.com
--domain=example.com
--mkhomedir
Explanation of options:
| Option | Purpose |
|---|---|
--server |
Specifies the FreeIPA server |
--domain |
The identity domain |
--mkhomedir |
Automatically create home directories |
During the process you will be prompted for IPA admin credentials.
If successful, the system will be enrolled into the domain and configured for authentication.
Verifying Domain Enrollment¶
Once the installation finishes, verify that the system joined the domain.
Check Kerberos:
kinit admin
klist
You should see a Kerberos ticket.
Check user lookup:
id username
Example output:
uid=10001(username) gid=10001(username) groups=admins
Check SSSD status:
systemctl status sssd
Testing Login Access¶
Try switching to a FreeIPA user:
su - username
Or log in through SSH:
ssh username@client-host
If everything is configured correctly, the user should authenticate against FreeIPA.
Host-Based Access Control (HBAC)¶
By default, FreeIPA restricts login access using HBAC rules.
These rules control:
- Which users
- Can log into which hosts
- Using which services
Example rule logic:
| Component | Value |
|---|---|
| Users | developers |
| Hosts | webservers |
| Service | ssh |
This allows only the developers group to SSH into webservers.
HBAC rules can be managed through the WebUI or CLI.
Removing a Host from the Domain¶
If a system needs to be removed from the domain:
ipa-client-install --uninstall
You should also remove the host record from the server:
ipa host-del hostname.example.com
Next Steps¶
At this point we have:
- Installed FreeIPA
- Enrolled systems into the domain
- Verified authentication works
In the next part of the FreeIPA Master Class, we will cover:
- Managing users and groups
- Identity lifecycle management
- Password policies
- Access control rules
- Automating account provisioning