As your home lab grows, managing everything becomes a little more complicated. What starts with a couple of Linux servers can quickly turn into an environment with multiple virtual machines, applications, users, and services that all need to communicate securely. At first, managing everything individually might not seem like a big deal. You create a user account on one server, configure SSH access on another, manage DNS somewhere else, and handle certificates whenever you need them.
But eventually, you reach a point where you start asking yourself whether there's a better way to manage all of this. That's exactly where I found myself while working on the management side of my infrastructure.
I wanted to establish a few foundational services before continuing to deploy more workloads. Centralized identity management, authentication, DNS, and an internal Certificate Authority were all near the top of that list. Rather than deploying and maintaining separate solutions for everything, I started looking for something that could bring these services together. That's when I came across FreeIPA.
After spending some time testing it, I realized it could solve several of the challenges I was trying to address. More importantly, it could give me a foundation to build on as the environment continues to grow. In this guide, we'll take a look at what FreeIPA is, why you might want to use it, and how to install it on Red Hat Enterprise Linux (RHEL).
What Is FreeIPA?
If you're familiar with Microsoft's Active Directory, you already have a good starting point for understanding FreeIPA. FreeIPA is an open-source identity management platform designed primarily for Linux and Unix environments. It provides centralized identity, authentication, access control, DNS, and certificate management.
Think of it as a central management system for your Linux infrastructure. Instead of maintaining separate user accounts and access configurations across every server, you can manage much of that information from one place.
For example, imagine you have ten Linux servers in your environment. Without centralized identity management, you might create and maintain local user accounts on each server. If someone needs access to another system, you have to configure that access separately. If permissions change, you may need to update multiple machines.
With FreeIPA, you can centrally manage user identities and groups, enroll Linux hosts, and define policies that determine who can access particular systems. You can also control sudo permissions, manage SSH public keys, maintain DNS records, and issue certificates through an internal Certificate Authority.
That's a lot of functionality in one platform. And while FreeIPA isn't a complete replacement for every feature of Active Directory, it provides many of the capabilities needed to manage a Linux-focused environment.
Understanding the Components Behind FreeIPA
One thing I appreciate about FreeIPA is that it brings together several established open-source technologies. Rather than developing every service from scratch, FreeIPA integrates these components into a platform that can be managed through a web interface, command-line tools, and APIs.
At the center of FreeIPA is 389 Directory Server, which stores identity information such as users, groups, and host records. This is the directory service that allows FreeIPA to maintain a centralized view of the identities in your environment. For authentication, FreeIPA uses MIT Kerberos. Kerberos provides a way for users and services to authenticate without repeatedly sending passwords across the network.
Certificate management is handled through the Dogtag Certificate System, which provides the internal Certificate Authority functionality. This allows FreeIPA to issue certificates for supported systems and services. For DNS, FreeIPA integrates with BIND, allowing you to manage internal DNS zones and records directly through the platform.
On client systems, SSSD helps Linux machines retrieve identity and authentication information from FreeIPA. Meanwhile, Certmonger can help request, track, and renew certificates. FreeIPA also provides a web interface, command-line utilities, and APIs for administration.
You don't need to become an expert in every one of these technologies before installing FreeIPA. However, understanding their roles will make the platform easier to work with later. For now, I'm focusing on getting the server installed and operational. We'll explore identity policies, authentication, and certificate management in more detail as the environment develops.
Choosing an Operating System for FreeIPA
Before installing FreeIPA, it's important to understand which operating systems are suitable for the server. FreeIPA server packages are primarily developed and maintained within the Fedora and RHEL ecosystem. Depending on the release and available packages, you can deploy FreeIPA on Fedora, Red Hat Enterprise Linux, CentOS Stream, Rocky Linux, or AlmaLinux.
This applies specifically to the FreeIPA server. The client side is more flexible and supports a broader range of Linux distributions. For this deployment, I'm using Red Hat Enterprise Linux (RHEL). One reason I like including RHEL in a home lab is that it provides hands-on experience with an operating system widely used in enterprise environments.
Red Hat also offers a Developer Subscription for Individuals, which provides access to no-cost, self-supported RHEL for up to 16 physical or virtual systems, subject to its subscription terms. If you're interested in developing Linux administration skills, it's worth exploring.
Preparing the RHEL Server
Before installing FreeIPA, there are a few things we need to configure. These steps aren't particularly complicated, but they're important because FreeIPA will eventually provide services that other systems depend on.
For this guide, we'll use ipa01.lab.example.com as the server's Fully Qualified Domain Name (FQDN). Our FreeIPA domain will be lab.example.com, and the Kerberos realm will be LAB.EXAMPLE.COM.
We'll assign the server the example IP address 192.168.10.10 on a /24 network, with 192.168.10.1 serving as the gateway and upstream DNS resolver. These are placeholder values, so make sure you replace them with addresses and names appropriate for your environment.
Configure a Static IP Address
The first thing I recommend is making sure your FreeIPA server has a predictable IP address. Since the server will be providing services such as DNS and authentication, you don't want its address changing unexpectedly.
You can accomplish this by configuring a static IP directly on the operating system or by creating a DHCP reservation on your network. On RHEL, you can check the current network configuration using:
- nmcli dev show
This displays information such as the current IP address, gateway, and DNS servers. If everything is already configured correctly, there's no reason to change it.
Otherwise, RHEL provides a convenient text-based network configuration interface:
- sudo nmtui
Select Edit a connection, choose the appropriate network connection, and configure the IPv4 settings. If you're assigning an address manually, make sure the IP address, subnet prefix, gateway, and DNS server match your network.
After applying the changes, verify the configuration:
- ip -4 addr
- ip route
Configure the Hostname and FQDN
Next, we need to establish the server's final hostname. For this example, we'll use:
- ipa01.lab.example.com
Here, ipa01 is the hostname, while lab.example.com is the DNS domain. Together, they form the Fully Qualified Domain Name (FQDN). Set the hostname with:
- sudo hostnamectl set-hostname ipa01.lab.example.com
Then verify it:
- hostnamectl
- hostname -f
The FQDN should be ipa01.lab.example.com. It's worth deciding on your naming convention before installation because changing the identity of an established FreeIPA server is not a simple operation.
Verify Hostname Resolution
This is one of those steps that's easy to overlook. Configuring a static IP and setting a hostname doesn't automatically guarantee that the server can resolve its own FQDN. Normally, we'd verify the forward and reverse DNS records before proceeding.
However, there's an interesting situation when FreeIPA itself is going to become the DNS server. If this is a new deployment and the DNS zone doesn't exist yet, the server may not have an authoritative DNS service available to resolve its own hostname.
One way to handle the initial local resolution is through /etc/hosts. Open the file:
- sudo nano /etc/hosts
Add an entry using your server's actual IP address and FQDN:
- 192.168.10.10 ipa01.lab.example.com ipa01
Make sure there aren't conflicting entries that associate the FreeIPA FQDN with another address, particularly a loopback address. Then verify local resolution:
- getent ahostsv4 ipa01.lab.example.com
The result should include the server's correct IPv4 address. You might wonder why we're using getent instead of dig. The difference is that getent uses the system's configured name-resolution mechanisms, which can include /etc/hosts. The dig command queries DNS directly.
Adding an entry to /etc/hosts does not create a DNS record. Once FreeIPA's integrated DNS is operational, we'll be able to verify actual forward and reverse DNS records.
Verify Time Synchronization
Accurate time is particularly important for FreeIPA because it uses Kerberos for authentication. Kerberos relies on time-sensitive authentication tickets. If clocks differ too much between systems, authentication can fail. Before installing FreeIPA, check the server's time synchronization:
- timedatectl
Look for the following values:
- System clock synchronized: yes
- NTP service: active
You can also inspect Chrony's synchronization status:
- chronyc tracking
A few useful indicators include the reference time source, stratum, system time offset, and leap status. Ideally, the server should have a valid time source, a small clock offset, and a leap status of Normal. If Chrony is installed but not running, enable it with:
- sudo systemctl enable --now chronyd
It's a small check, but one that can save you from troubleshooting authentication issues later.
Configure the Firewall
FreeIPA uses several network services, including Kerberos, LDAP, HTTPS, and DNS. We need to make sure the required traffic is allowed through the server's local firewall. First, check the firewall status:
- sudo firewall-cmd --state
If you're using firewalld, allow the predefined FreeIPA service group:
- sudo firewall-cmd --permanent --add-service=freeipa-4
Since we're also configuring integrated DNS, allow DNS traffic:
- sudo firewall-cmd --permanent --add-service=dns
Apply the changes:
- sudo firewall-cmd --reload
Then verify:
- sudo firewall-cmd --list-services
If your network uses additional firewalls or VLAN restrictions, you'll also need to account for those separately. The goal is to allow the traffic FreeIPA actually needs without unnecessarily exposing the server to unrelated networks.
Choose Your FreeIPA Domain and Kerberos Realm
Before proceeding, we need to make two important decisions: the FreeIPA domain and the Kerberos realm. They serve related but different purposes. The domain identifies the DNS namespace used by FreeIPA. The Kerberos realm identifies the authentication namespace used by Kerberos for users, hosts, and services.
For example:
- Domain: lab.example.com
- Realm: LAB.EXAMPLE.COM
In most FreeIPA deployments, the domain and realm names match, with the realm conventionally written in uppercase. These names become foundational parts of the deployment, so it's worth planning them carefully.
Installing FreeIPA on RHEL
With the server prepared, we can move on to the actual installation. There are two main stages. First, we'll install the required packages. Then we'll run the FreeIPA installer to configure the services.
Install the FreeIPA Packages
Before installing packages, make sure the system is updated and the appropriate RHEL repositories are available. Then install FreeIPA and its integrated DNS components:
- sudo dnf install -y ipa-server ipa-server-dns
The ipa-server package provides the FreeIPA server software, while ipa-server-dns adds the integrated DNS functionality. It's important to understand that this command only installs the required software. We haven't configured the FreeIPA environment yet.
Configure the FreeIPA Server
Now we can run the installer. Using the example values from earlier, the command looks like this:
sudo ipa-server-install \
--hostname=ipa01.lab.example.com \
--domain=lab.example.com \
--realm=LAB.EXAMPLE.COM \
--setup-dns \
--forwarder=192.168.10.1
Let's briefly go through what we're configuring.
- The --hostname option identifies the FreeIPA server using its FQDN, while --domain establishes the DNS domain FreeIPA will use.
- The --realm option defines the Kerberos authentication realm. Although the domain and realm are related, they serve different purposes. The domain identifies systems through DNS, while the realm provides the authentication namespace.
- By including --setup-dns, we're telling FreeIPA to configure its integrated DNS service.
- Finally, --forwarder specifies an upstream DNS resolver.
The DNS forwarder deserves a little explanation. FreeIPA can provide authoritative DNS for the zones it manages. However, it also needs a way to resolve names outside those zones. For example, if a client requests a domain that FreeIPA doesn't manage, the configured forwarder can handle that request. In this example, we're using 192.168.10.1 as the upstream DNS server.
Your environment might use a firewall, internal recursive resolver, or another suitable DNS server instead. The important thing is that the forwarder can resolve the domains your clients need.
What Happens When Your DNS Zone Already Exists?
Here's something worth understanding before you continue. During the installation, FreeIPA checks DNS to determine whether the zone you're trying to configure already exists.
This can become an issue if you're using a domain that already has authoritative DNS servers. For example, imagine you own example.com and already use it for a public website or email. If you try to configure FreeIPA as an authoritative DNS server for that same zone, the installer may detect the existing DNS infrastructure and refuse to continue.
That doesn't necessarily mean you can't use the domain internally. It means you need to understand the implications of managing the same DNS namespace in more than one place. If creating an overlapping zone is intentional, FreeIPA provides the following option:
- --allow-zone-overlap
You can include it in the installation command:
sudo ipa-server-install \
--hostname=ipa01.lab.example.com \
--domain=lab.example.com \
--realm=LAB.EXAMPLE.COM \
--setup-dns \
--allow-zone-overlap \
--forwarder=192.168.10.1
Only use this option when you understand why the zone overlaps.
Understanding Split DNS
When the same DNS domain is managed internally and publicly, you're working with a split-DNS design. For example, public DNS might contain records for your website and email, while internal FreeIPA DNS contains records for servers and services inside your network.
The important detail is that internal clients querying FreeIPA for a zone it manages will receive answers from FreeIPA's authoritative zone. They won't automatically receive records from the public version of that same zone.
So if your public DNS contains a record that internal clients also need, you'll need to make that record available through your internal DNS design. This is why I recommend thinking through your DNS namespace before installing FreeIPA.
You don't necessarily need a completely separate domain, but you should understand how internal and external DNS will coexist. Also, avoid pointing FreeIPA at an upstream resolver that sends queries for the same FreeIPA-managed zone back to FreeIPA. That can create DNS forwarding loops.
After starting the installer, FreeIPA will ask several questions to complete the configuration. Most of these are straightforward, but there are a few worth explaining.
Directory Manager Password
The first important password is the Directory Manager password. FreeIPA uses 389 Directory Server to maintain its directory information, and the Directory Manager account has administrative privileges over that directory. This password is not the same as your normal FreeIPA administrator password. Use a strong, unique password and store it securely.
IPA Administrator Password
Next, you'll configure the password for the FreeIPA admin account. This is the account you'll initially use to access the FreeIPA web interface and perform administrative tasks. Make sure you understand the distinction between these two passwords.
The Directory Manager password is associated with directory administration, while the IPA admin password is used for normal FreeIPA administration.
DNS Forwarders
If you're configuring integrated DNS, the installer may ask whether you want to configure DNS forwarders. Even if you've already specified a forwarder in the installation command, you may still encounter prompts related to DNS forwarding.
Review the displayed configuration and confirm that the correct DNS server is listed. The installer may also offer the opportunity to add additional forwarders. If you don't need another one, you can continue without adding anything.
Reverse DNS Zones
FreeIPA may also ask whether you want to search for missing reverse DNS zones. Reverse DNS provides the opposite mapping of a normal DNS record. A forward record maps a hostname to an IP address, while a reverse record maps an IP address back to a hostname. For example:
Forward DNS:
- ipa01.lab.example.com → 192.168.10.10
Reverse DNS:
- 192.168.10.10 → ipa01.lab.example.com
If a suitable reverse DNS zone doesn't already exist, the installer may offer to create one. For a typical /24 network such as 192.168.10.0/24, the reverse zone would be:
- 10.168.192.in-addr.arpa
Review the suggested zone carefully before accepting it. If another DNS server already manages reverse DNS for that network, you'll need to coordinate the configuration rather than create conflicting authoritative zones.
NetBIOS Domain Name
Depending on the installation options and components being configured, FreeIPA may ask for a NetBIOS domain name. This is primarily relevant to integration with Active Directory and Samba-related functionality.
NetBIOS domain names have a 15-character limit, so a longer domain name may be shortened. This doesn't change the actual FreeIPA DNS domain or Kerberos realm. If you don't plan to use Active Directory trust functionality immediately, you can generally accept an appropriate default.
NTP Configuration
The installer may ask whether you want to configure Chrony with a specific NTP server or pool. If you already have a working time synchronization configuration, you may choose to retain it. Alternatively, you can provide an internal NTP server if that's how your environment is designed. The important thing is that FreeIPA and its clients maintain synchronized clocks.
Review the Installation Summary
Before making changes, the installer presents a summary of the configuration. This is your opportunity to verify the server's hostname, IP address, domain, Kerberos realm, DNS settings, and other installation options.
Take a moment to review everything. Once you're satisfied, confirm the installation and allow FreeIPA to configure the required services. This process can take several minutes, depending on the system and the components being installed.
Accessing the FreeIPA Web Interface
Once the installation finishes successfully, we can access the FreeIPA management interface. One thing to keep in mind is that the computer you're using to access the interface needs to resolve the FreeIPA server's hostname. If FreeIPA is providing DNS for your internal domain, your client needs a DNS resolution path to that server.
You can accomplish this by configuring the client to use FreeIPA DNS directly or by configuring an existing internal DNS resolver to forward the appropriate zone to FreeIPA. For a simple test environment, pointing a client directly to the FreeIPA DNS server is often the easiest approach. Once name resolution is working, open a browser and navigate to:
- https://ipa01.lab.example.com
You should reach the FreeIPA login page. Use admin as the username and the IPA administrator password you created during installation. Remember, this is not the Directory Manager password. Because FreeIPA uses an internal Certificate Authority, your browser may initially warn that the HTTPS certificate isn't trusted.
That's expected if the FreeIPA CA hasn't been added to your client's trusted certificate authorities. Rather than ignoring certificate warnings indefinitely, the better long-term approach is to securely distribute and trust the appropriate CA certificate. Once you're logged in, you'll have access to FreeIPA's management interface.
What Can We Manage From Here?
Getting FreeIPA installed is only the beginning. The real value comes from connecting systems to it and using the services we've just deployed. For example, we can create users and groups, enroll Linux servers, and define access policies that control which users can log in to particular hosts.
We can also configure sudo rules centrally rather than managing those permissions separately on every machine. Kerberos provides the authentication foundation, while FreeIPA's Certificate Authority can help manage certificates for supported systems and services.
And with integrated DNS, we have a centralized place to maintain records for the infrastructure. These capabilities become especially useful as the number of servers grows. Instead of treating each Linux machine as an independent system, we can start managing the environment as a collection of connected resources with shared identity and security policies. That is the direction I'm working toward.
Final Thoughts
One of the things I've learned from building and rebuilding home lab environments is that getting services running is usually the easy part. Managing them consistently as the environment grows is where things start becoming more interesting. It's easy to deploy another virtual machine, create another local account, or manually configure another certificate. But doing that repeatedly doesn't necessarily lead to an environment that's easy to maintain.
That's why I'm taking the time to establish services like FreeIPA early in the process. Centralized identity, authentication, DNS, certificates, and access policies give us a stronger foundation for everything that comes afterward. At this point, we have FreeIPA installed on RHEL, integrated DNS configured, and access to the management interface. The next step is where things really start coming together.
We'll begin exploring FreeIPA's identity and policy management features, enroll Linux systems, configure access controls, and put some of these capabilities to work in a real environment. There's still a lot to explore, but that's part of the fun of building a home lab. You get to take these technologies, understand how they work, and figure out how they fit into the bigger picture. As always, stay geek, stay curious. I will see you on the next one.
