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.
Then, start the installation process
On the other server, configure the DNS to use the already installed domain and run this
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.
Following a less permissive route should go like this
From the client, initially check the certificate served from any FreeIPA server :
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
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.
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 :
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
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
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.