Infrastructure 2021 04 10 FreeIPA, server, client and certificate
Post
Cancel

FreeIPA, server, client and certificate

Let’s consider the following deployment topology :

  • ipa01.lab.epicfail.be
  • ipa02.lab.epicfail.be

Installation is performed on a CentOS 8 server (Stream, doesn’t actually matter). Make sure you have the right AppStream enabled.

dnf module list
[snip]
idm                  DL1 [e]       adtrust, The Red Hat Enterprise Linux Identity Management system module
                                    client,
                                    common
                                   [d], dns
                                   , server
idm                  client [d]    common [ RHEL IdM long term support client module
                                   d]
[snip]
# If not [e], enable the module idm:DL1 which is the idm server module.
dnf module enable idm:DL1

Then, start the installation process

dnf makecache && dnf update -y && dnf install ipa-server ipa-server-dns
firewall-cmd --add-service=freeipa-ldap
firewall-cmd --add-service=freeipa-ldaps
firewall-cmd --add-service=kerberos
firewall-cmd --add-service=dns
firewall-cmd --runtime-to-permanent
# Replace lab.epicfail.be and $dns-forwarder with values suited to your environment
ipa-server-install --setup-kra --setup-dns -n lab.epicfail.be \
	--forwarder=$dns-forwarder

On the other server, configure the DNS to use the already installed domain and run this

dnf makecache && dnf update -y && dnf install ipa-server ipa-server-dns
firewall-cmd --add-service=freeipa-ldap
firewall-cmd --add-service=freeipa-ldaps
firewall-cmd --add-service=kerberos
firewall-cmd --add-service=dns
firewall-cmd --runtime-to-permanent
# Replace $dns-forwarer with value suited to your environment
ipa-replica-install --setup-dns --setup-kra --forwarder $dns-forwarder 
ipa-ca-install

The roles installed are the domain role and CA role. All servers are CA server, DNS server and KRA server.

Optionally, create a user allowed to join new systems to the domain.

kinit admin
# This will prompt for a password, left at your discretion
ipa user-add joinuser --first=Join --last=User --password
# Privileges : Host Enrollment
# Permissions : Add Hosts, Read Hosts
# There should be some DNS permission as well
# A more permissive approach (my choice in the lab) is giving the DNS Admin
# This allows DNS auto-configuration / updates
# However there's a higher risk if the account is compromised (bad in prod)
ipa role-add --desc='Host Domain Join' 'Host Domain Join'
ipa role-privilege-add --privileges='Host Enrollment' 'Host Domain Join'
ipa role-privilege-add --privileges='DNS Admin' 'Host Domain Join'
ipa role-add-member 'Host Domain Join' --users=joinuser
kdestroy

Following a less permissive route should go like this

kinit admin
ipa user-add joinuser --first=Join --last=User --password
ipa role-add --desc='Host Domain Join' 'Host Domain Join'
ipa role-privilege-add --privileges='Host Enrollment' 'Host Domain Join'
# Find the target DN to use with this
# ipa user-show joinuser --all
ipa permission-add 'Read Host: joinuser' --target=uid=joinuser,cn=groups,cn=accounts,dc=lab,dc=epicfail,dc=be --right=read --right=search --right=compare --attrs='\*'
ipa privilege-add 'Read Host: joinuser'
ipa privilege-add-permission --permissions='Read Host: joinuser' 'Read Host: joinuser'
ipa privilege-add 'Add Hosts'
ipa privilege-add-permission --permissions='System: Add Hosts' 'Add Hosts'
ipa role-add --desc='Host Joining' 'Host Joining'
ipa role-add-privilege --privileges='Host Enrollment' 'Host Joining'
ipa role-add-privilege --privileges='Add Hosts' 'Host Joining'
ipa role-add-privilege --privileges='Read Host: joinuser' 'Host Joining'
ipa role-add-member 'Host Joining' --users=joinuser
kdestroy

From the client, initially check the certificate served from any FreeIPA server :

# This should fail successfully
# The certificate will be displayed, but the certificate won't be validated
echo | openssl s_client -connect ipa01.lab.epicfail.be:443 -brief

The previous step should indicate that the certificate was not successfully validated as the CA (Certificate Authority) is not known and recognized by the system.

Installing the package will depend on the distribution in use but it should not differ vastly from this

# Debian-like
apt update && apt install freeipa-client
# CentOS 7
yum install freeipa-client
# CentOS 8
dnf module enable idm:client
dnf install ipa-client

The next step will be to join your client to the domain. To do so, change your resolving DNS to the IP address of the newly generated domain and then run the following command, reviewing the parameters during each steps. The domain should be autodiscovered thanks to DNS.

# When requested, provide the credentials for any account allowed to enroll new systems into the
# domain.
ipa-client-install

Interestingly, the certificate will now be successfully validated. Here are some interesting insights on what happened during client installation.

  • A folder was created at /etc/ipa containing an interesting file, the CA certificate and domain informations.
  • /etc/sssd/ now contains the domain configuration (under [domain/home.epicfail.be]).
  • /etc/ssh/sshd_config was modified and some settings appended :
PubkeyAuthentication yes
KerberosAuthentication no
GSSAPIAuthentication yes
UsePAM yes
ChallengeResponseAuthentication yes
# This part is responsible for validating SSH keys configured in FreeIPA itself
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

Specifically, this part might cause some issues with some tools. I personally encountered one with Katello/Foreman (RedHat Satellite Upstream), causing some processes to unexplicably fail. It was due to the AuthorizedKeysCommand directive.

In FreeIPA, it’s very important to notice that a certificate will be linked to a service account, prefixed here with HTTP, and said service account needs to have an existing host coming by the same name. So here’s the important part if you want to create everything from the CLI

# Presumably, this won't work as hostname1.lab.epicfail.be shouldn't exist by then
ipa service-add HTTP/hostname1.lab.epicfail.be
# This will work
ipa host-add --force hostname1.lab.epicfail.be
ipa service-add HTTP/hostname1.lab.epicfail.be

Accesses are then granted to systems to the service account, which is allowed to have certificates generated to it. Hence, if you want to create a certificate with a SubjectAlternateName, it will require a service-account even though the certificate will not be linked to this service account.

Here’s a nice one-liner I came by while trying to replicate this process, aggremented by some commands giving some insight

yum install ipa-client
ipa-client-install 
# Using admin for lab's sake, use any user with the least privilege to create a server 
# certificate and an IPA service user
# This command generates a kerberos ticket for user
kinit admin 
# Checks for the ticket to be properly generated
klist
ipa service-add HTTP/$(hostname)
# If you want to add some SubjectAlternateName on the certificate, repeat the previous step with 
# other names
ipa service-add-host --hosts=ipa01.lab.epicfail.be --hosts=ipa02.lab.epicfail.be \
                     --hosts=$(hostname) HTTP/$(hostname)
# If you want to add the SubkectAlternateName, repeat by replacing the HTTP/$(hostname) with the 
# other names. Add a -D entry per SUbjectAlternateName in the following command
ipa-getcert request -r -f /etc/pki/tls/certs/$(hostname).crt \ 
   -k /etc/pki/tls/private/$(hostname).key -N CN=$(hostname) -D $(hostname) \ 
   -K HTTP/$(hostname)
# Checks for certificate status and parameters
ipa-getcert list
# Destroy kerberos ticket
kdestroy
# Check certificate file, displays the full certificate
openssl x509 -in /etc/pki/tls/certs/$(hostname).crt -noout -text

This certificate is now valid inside of the domain. With the file identified earlier (/etc/ipa/ca.crt) it would be possible to install the CA in a browser to browse to applications using one of the domain certificate.

Trending Tags

Trending Tags