Published Jan. 20, 2025, 3:27 p.m. by dwest
If you’ve ever found yourself managing a growing number of servers, desktops, web applications, and other shared services, you’ve probably run into the pain of maintaining user accounts across all of them. This is where directory servers come in. A directory server is a system designed to manage user accounts across multiple devices and handle login access in a consistent way. Like the name suggests, a directory server keeps a database, or “directory,” of usernames, passwords, and other account details that can be used across many systems. It works a bit like a digital phone book or school directory that helps identify users and determine what they have access to. The goal is to create a single sign-on experience where one account can be used to log in to multiple systems.
Unlike a physical directory, a directory server stores much more information about the network. This includes users, groups, computers, services, and other resources. Directory servers are a core part of enterprise IT because they handle authentication, authorization, and access control. The most well-known example is Microsoft Active Directory, which most Windows-based businesses depend on. But there are also open-source alternatives for other environments, such as OpenLDAP, SMB-LDAP, and older solutions like NIS. These often use the LDAP protocol to manage identity information. Even Apple had their own option called Open Directory, which bundled together several open-source tools to manage Mac environments in a way similar to Active Directory.
In this blog series, we’re going to look at FreeIPA, an enterprise-grade directory service that is mainly focused on Linux. At its core, FreeIPA is an identity management system, but it also integrates several powerful tools to offer LDAP, Kerberos, DNS, and certificate authority services all in one package. Whether you’re managing a single service or a network spanning multiple sites, FreeIPA gives you a centralized and scalable way to control access across your environment.
FreeIPA is built from several open-source projects, each responsible for a specific function. In true open-source fashion, where each tool focuses on doing one thing well, these components work together to provide a full-featured identity management solution. The core components include:
The process for installing a FreeIPA Master significantly changes as newer versions are released and newer operating systems change their packaging structure. At the time of this writing, the FreeIPA Masters are first installed as a client. From there, they are upgraded to a FreeIPA Master and then a FreeIPA CA. These instructions are written with the expectation that you will be running them on CentOS-Stream, but should also work on RedHat Enterprise and other RHEL-based distro’s with minimal alterations.
This is probably one of the simplest steps you have to perform. Basically, you just need to install the client from you package manager or use a 3rd party provider. This part of the process is exactly the same whether you are setting up a FreeIPA master or just a client. FreeIPA will handle all the certificate generation and access control for you.
** Ubuntu/Debian apt-get install freeipa-client
Note: If it fails due to a pre-existing entry, you can either remove it manually or add the “–force-join” flag at the end.
This part if fairly simple since you are installing the “First Master” in the network. The “First Master” will become the CA and manage the CRL and CA renewals. While other replicas in the network can also be CA’s, the “First Master” is special. This can be changed to a different host at a later time.
Install the “freeipa-server” package dnf install freeipa-server
Now run the FreeIPA installer tool. Unless you plan on managing DNS with it, you will need to skip the DNS server setup. ipa-server-install
Note: For NTP servers, you can use either “pool.ntp.org” or “0.pool.ntp.org” if the current setup does not allow for access to the example internal ones. If there were no errors, then you should get a message saying “The ipa-server-install command was successful”
The method for adding a FreeIPA Replica has changed with the newer domain level. Before, you had to generate a replica file on an active IPA master and then transfer it over to the new host to perform the install. Now, you just need to join the host to the domain as a client and then upgrade it to a replica. This process is much easier than before, but only works with IPA Domain Levels 1 or greater.
In EL8, Redhat started using package modules for some software packages. In EL9, they scrapped it and went back to normal package repos. However, if you need to install FreeIPA on EL8, you will need to enable the idm:DL1 modules in your system.
You can enable it with the following command:
dnf module enable idm:DL1
Install the IPA client and server dnf install ipa-client freeipa-server
Bind the host to an IPA Master on the current domain ipa-client-install –server=$IPA_MASTER.example.com –domain=example.com –mkhomedir
Note: If it fails due to a pre-existing entry, you can either remove it manually or add the “–force-join” flag at the end.
Note: If you do not run –setup-ca, then you will not install the CA service on the system. If you would like to do this after the fact, then you can run ipa-ca-install. If there were no errors, then you should get a message saying “The ipa-replica-install command was successful”
Below is a list of common commands that you will often use when administering FreeIPA.
Check status of IPA services ipactl status
Stop, start and restart the FreeIPA services. The last one will allow for the system to start up even if one of the services (such as Tomcat) fails. ipactl stop ipactl start ipactl restart ipactl restart –ignore-service-failures
List replication status for the current host ipa-replica-manage list -v $(hostname) ; ipa-csreplica-manage list -v $(hostname)
List current replication agreements/segments
$ ipa topologysegment-find
Suffix name: domain
------------------
8 segments matched
------------------
Segment name: new_segment
Left node: server1.example.com
Right node: server2.example.com
Connectivity: both
Note: If you change the Suffix name to ‘ca’, it will list the CA replication agreements/segments
$ ipa topologysegment-add Suffix name: domain Left node: server1.example.com Right node: server2.example.com Segment name [server1.example.com-to-server2.example.com]: new_segment --------------------------- Added segment "new_segment" --------------------------- Segment name: new_segment Left node: server1.example.com Right node: server2.example.com Connectivity: both
$ ipa topologysegment-add Suffix name: ca Left node: server1.example.com Right node: server2.example.com Segment name [server1.example.com-to-server2.example.com]: new_segment --------------------------- Added segment "new_segment" --------------------------- Segment name: new_segment Left node: server1.example.com Right node: server2.example.com Connectivity: both
$ ipa topologysegment-show Suffix name: domain Segment name: new_segment Left node: server1.example.com Right node: server2.example.com Connectivity: both
Allow for depricated security protocols. This should only be used when upgrading a legacy system to current standards. ex. SSL 1.0, 1.1 update-crypto-policies –set LEGACY
Show the current domain level ipa domainlevel-get
Change the current domain level to ‘1’ ipa domainlevel-set 1
Note: This will update the domain level on ALL FreeIPA servers in the network at the same time. Also, you can not go backwards in level. Once you do this, there is no going home again. Enjoy ;)
Reinitialize the IPA Replica from another replica. Basically, it re-syncs everything from the upstream server to resolve any conflicts. ipa-replica-manage re-initialize –from $IPA_REPLICA.example.com –verbose
Manually renew the CA certificate. Normally, this should be automatic, but it is possible that something went wrong. ipa-cacert-manage renew
Display current global group policy
$ ipa pwpolicy-show Group: global_policy Max lifetime (days): 3650 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 600
$ ipa pwpolicy-mod --minlife=0 global_policy Group: global_policy Max lifetime (days): 3650 Min lifetime (hours): 0 History size: 0 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 600
Update the LDAP schema and configuration files. This is useful when updating the server packages and the auto-upgrade does not successfully run. ipa-server-upgrade
Update the local IPA cert database with local certificates from the server. This helps to ensure that all IPA server certificates are stored in IPA. ipa-certupdate
These instructions are written with the expectation that you will be running them on CentOS-Stream.
This is probably one of the simplest steps you have to perform. Basically, you just need to install the client and the install it to 1 or 2 masters. If the system is in the DMZ, make sure you bind it to the IPA masters in the DMZ. FreeIPA will handle all the certificate generation and access control for you.
** Ubuntu apt-get install freeipa-client
Note: If it fails due to a pre-existing entry, you can either remove it manually or add the “–force-join” flag at the end.
Before you can install a FreeIPA Master or Replica, you will need to enable the “DL1” module that can be found in the “AppStream” repository
$ dnf module list idm Updating Subscription Management repositories. Updating Subscription Management repositories. Last metadata expiration check: 0:16:51 ago on Sat 29 Dec 2018 09:52:44 AM EAT. Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs) Name Stream Profiles Summary idm DL1 adtrust, client, dns, server, default [d] The Red Hat Enterprise Linux Identity Management system module idm client [d] default [d] RHEL IdM long term support client module Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
You can see more info about which packages this provides by running the following: dnf module info idm:DL1
Install this module using YUM/DNF dnf install @idm:DL1
This part if fairly simple since you are installing the “First Master” in the network. The “First Master” will become the CA and manage the CRL and CA renewals. While other replicas in the network can also be CA’s, the “First Master” is special. This can be changed to a different host at a later time.
Install the “freeipa-server” package dnf install freeipa-server
Now run the FreeIPA installer tool. Unless you plan on managing DNS with it, you will need to skip the DNS server setup. ipa-server-install
Note: For NTP servers, you can use either “pool.ntp.org” or “0.pool.ntp.org” if the current setup does not allow for access to the example internal ones. If there were no errors, then you should get a message saying “The ipa-server-install command was successful”
The method for adding a FreeIPA Replica has changed with the newer domain level. Before, you had to generate a replica file on an active IPA master and then transfer it over to the new host to perform the install. Now, you just need to join the host to the domain as a client and then upgrade it to a replica. This process is much easier than before, but only works with IPA Domain Levels 1 or greater.
In EL8, Redhat started using package modules for some software packages. In EL9, they scrapped it and went back to normal package repos. However, if you need to install FreeIPA on EL8, you will need to enable the idm:DL1 modules in your system.
You can enable it with the following command:
dnf module enable idm:DL1
Install the IPA client and server dnf install ipa-client freeipa-server
Bind the host to an IPA Master on the current domain ipa-client-install –server=$IPA_MASTER.example.com –domain=example.com –mkhomedir
Note: If it fails due to a pre-existing entry, you can either remove it manually or add the “–force-join” flag at the end.
Note: If you do not run –setup-ca, then you will not install the CA service on the system. If you would like to do this after the fact, then you can run ipa-ca-install. If there were no errors, then you should get a message saying “The ipa-replica-install command was successful”
This is usually used if something went wrong during the install process or FreeIPA is acting weird. You will need to completely clean out all records for the replica and uninstall the the host.
Note: If something fails during the uninstall, you can add the “–force” flag at the end to force it to completion
Uninstall the FreeIPA Client ipa-client-install –uninstall
Remove IPA Replica from directory ipa-replica-manage del $REPLICA_NAME.example.com
Note: If this fails due to connectivity issues, then you can add the “–force” flag to forcefully remove it and the “–clean” flag to clean up any orphaned records
This is used if the current IPA environment has unrecoverable issues, such as the CA API not working correctly. This will not migrate any kerberos data since the new KDC will be issuing those tickets from now one. However, passwords will get migrated pre-hashed, so it will not generate Kerberos keys unless it can get a clear text entry. This just means that users will have to use the “Migration” service to update their passwords in the directory. The migration tool will need to be performed on the destination IPA server and will require logging in with an account on the source IPA server. You can run it with the following:
ipa migrate-ds \
--bind-dn="cn=Directory Manager" \
--user-container=cn=users,cn=accounts \
--group-container=cn=groups,cn=accounts \
--group-objectclass=posixgroup \
--user-ignore-attribute= {krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference,mepManagedEntry} \
--user-ignore-objectclass=mepOriginEntry \
--with-compat \
ldap://$OLD_MASTER.example.com
Note: This will probably fail on a few of the default accounts, such as “admin” and “root”, but that should be fine.
Failed user: admin: This entry already exists root: Kerberos principal root@example.COM already exists. Use 'ipa user-mod' to set it manually. Failed group: admins: This entry already exists. Check GID of the existing group. Use --group-overwrite-gid option to overwrite the GID editors: This entry already exists. Check GID of the existing group. Use --group-overwrite-gid option to overwrite the GID ---------- Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts.
Password migrations can be handled by each user at the following site: * https://$IPA_MASTER.galois.com/ipa/migration/
If you fail to do this before removing your “First Master” from the FreeIPA cluster, then you might be in for a world of hurt. While all FreeIPA replicas are considered masters, there is a special “First Master” that usually controls the certificate renewals and CRL. It is better to only have one IPA Master do this, otherwise you might get some conflicting records. It is also possible to do this after the fact, but it can be much more difficult or fail to do so..
/etc/pki/pki-tomcat/ca/CS.cfg
ca.crl.MasterCRL.enableCRLCache=true
ca.crl.MasterCRL.enableCRLUpdates=true
/etc/httpd/conf.d/ipa-pki-proxy.conf # Only enable this on servers that are not generating a CRL RewriteRule ^/ipa/crl/MasterCRL.bin https:///ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]
Most of this should be taken care of by Puppet, with the exception of manually adding the CIFS principal for your Samba server. It should allow users to login to their Samba share using their FreeIPA credentials. It might work with FreeNAS, but we do not have a currently working setup for it. Assuming you are installing this on a CentOS 7/8/Stream server, here are the steps for binding Samba to FreeIPA.
Install the required packages on the FreeIPA server and Samba server ** FreeIPA Server yum install freeipa-server-trust-ad ** Samba Server yum install samba samba-client samba-common sssd-libwbclient cifs-utils
On CentOS 8/Stream, you will need to enable the ‘adtrust’ stream. ex. dnf install idm:DL1/adtrust
Initialize CIFS support on each FreeIPA Server. This will automatically generate the SID’s for any existing user that does not have one assigned to them. It should already be done on existing IPA servers, but new ones will need to have this ran. ** FreeIPA Server
$ ipa-adtrust-install Enable trusted domains support in slapi-nis? [no]: yes Do you want to run the ipa-sidgen task? [no]: yes
Note: Running the ipa-sidgen task should only need to be done once
ipa-client-install --server=.example.com> --server=.example.com --mkhomedir
authconfig --enablesssdauth --enablemkhomedir --update
Add the CIFS principal for Samba on the FreeIPA server ipa service-add cifs/samba_server_name.example.com
Install the keytab on the Samba server
ipa-getkeytab -s
Make sure your Samba config file is setup. Here is a config example: /etc/samba/smb.conf
#
# smb.conf for hosts on internal subnets
#
# file maintained by puppet. local edits will be lost!
#
# ======================================================================
# Global Configuration
[global]
debug pid = yes
realm = example.COM
workgroup = example
domain master= yes
ldap group suffix = cn=groups,cn=accounts
ldap machine suffix = cn=computers,cn=accounts
ldap ssl = no
ldap suffix = dc=example,dc=com
ldap user suffix = cn=users,cn=accounts
log file = /var/log/samba/log.%m
max log size = 100000
follow symlinks = yes
wide links = yes
unix extensions = no
domain logons = Yes
registry shares = Yes
disable spoolss = Yes
dedicated keytab file = FILE:/etc/samba/samba.keytab
kerberos method = dedicated keytab
passdb backend = ipasam:ldaps://foresight.example.com ldaps://hindsight.example.com
security = USER
create krb5 conf = No
rpc_daemon:lsasd = fork
rpc_daemon:epmd = fork
rpc_server:tcpip = yes
rpc_server:netlogon = external
rpc_server:samr = external
rpc_server:lsasd = external
rpc_server:lsass = external
rpc_server:lsarpc = external
rpc_server:epmapper = external
ldapsam:trusted = yes
idmap config * : backend = tdb
ldap admin dn = cn=Directory Manager
# Shares
[some_directory_share]
comment = Example Share
path = /srv/some_directory
valid users = @admins
browseable = no
writeable = yes
read only = no
inherit acls = Yes
#
# EOF
#
If you are sharing the home directories on an SE Linux system, make sure you enable the boolean for it. ex. setsebool -P samba_enable_home_dirs on
Restart the Samba service systemctl restart smb
Test from a Samba Client to ensure that you can make a connection
kinit@example.COM smbclient -k -L samba_server_name.example.com smbclient -k //samba_server_name.example.com/some_directory_share
FreeIPA uses a self-signed certificate for its web interface by default. This is because it is the certificate signing authority for the network and considers itself to be trusted. However, most web browsers frown upon self-signed certificates because the signing authority is not known. When visiting a website with a self-signed certificate, your browser will throw up a big nasty error saying the Certificate Authority can not be trusted. Some browsers will even prevent you from accepting the risk and continuing to that website unprotected. This is because your web browser does not know about FreeIPA as a CA by default an will try to protect you by preventing access to it. One solution is to use a real certificate for the web interface. This is a little tricky and there seems to be issues when you mix HTTPS and LDAPS certificates with different signing authorities. The other option is to import the Certificate Authority as a trusted authority into your web browser, keychain, etc. This certificate can be downloaded using the following command:
openssl s_client -connect ipa.example.com:443 -showcerts < /dev/null > ipa.example.com_ca.crt
There are no comments.