Scope π
The IPA in FreeIPA stands for Identity, Policy, and Authentication. Obviously I use these services, albeit in minimal extent. Also of note, FreeIPA provides DNS and certificate services which may continue to be useful even in an environment devoid of enrolled systems. This post will focus on my FreeIPA deployment as it pertains to the former set of features.
Source of Constraint π
FreeIPA is the primary constraint that ties me to the Red Hat ecosystem. It provides single sign-on and DNS services, and since I deployed my FreeIPA instance in 2015, I’ve had SSHd configured on each server to accept only GSSAPI.
While the freeipa-client is available on most Linux distributions, it is not available in FreeBSD. Manual configuration is possible, but it may be better in my case to simply stop relying on FreeIPA entirely.
Original Problem π
In 2015, as I was building my network the proliferation of new servers presented an immediate manageability issue. How does one manage login credentials on n servers? SSH keys are the obvious answer, however, good sense dictates SSH keys be rotated periodically, which can be a hassle if done manually. My younger self wasn’t oblivious to this fact, but stopped thinking at that. Clearly SSH Keys wouldn’t work.
Simultaneously, I was working with Active Directory in my associate’s program. What a perfect solution, if only Linux had such a thing. A quick internet search later, and I was hooked on FreeIPA. Suddenly I could avoid the responsibility of rotating SSH keys manually. Perfect.
What Changed π
The sunsetting of CentOS 8 carried a message, loud and clear, for anyone who had gotten complacent: diversify. Deploying multiple operating systems protects a network from sudden, unilateral “shifts in focus,” certainly. Perhaps more importantly, running a heterogeneous system reduces the risk that a valid attack against one system will be valid against all deployed systems.
The ultimate benefit of diversification for a didactic network, however, is the resultant change in mindset from what works for one distribution to what works for a POSIX-compliant system.
No matter the cited benefit, I now have a FreeBSD system playing a vital role in my network and it will not be enrolled in my FreeIPA domain without significant effort.
What was Always Wrong π
Mismanagement π
My operation has but one user, and while it’s been nice to have that user provisioned on every server, there’s not always good cause to do so. I have no good reason to have a home folder on my PXE server, for example. Plus, maintaining my single user account across all systems means I’m a member of the libvirt/kvm, tty, dialout, and wireshark groups even on systems that have no relevance to these groups, or even have them defined. For the last six years, I’ve effectively been logging in to anything and everything I do with the same credential - that of a domain administrator. This must stop.
A Faulty Assumption π
From my associate’s studies, I know that Active Directory checks two sets of credentials on login. First, it checks a machine password that identifies the host being logged into. Then, it checks the user’s password, and (on a match), it grants a login token. In both cases, Active Directory uses a login mechanism called Kerberos. And since the raison d’Γͺtre of Kerberos is to authenticate trusted nodes on an untrusted network, this two-phase check happens in FreeIPA as well, right?
Nullius in verba. I accepted my reasoning as fact for 5 years before, on a
whim, I typed kinit
into my MacBook, a device certainly not enrolled in my
domain. To my horror, it proceeded to ask for my username and password, and
received a kerberos ticket from my domain, allowing me to login to every system
in my network.
I had thought that by requiring every server to only accept Kerberos login, I would be restricting login at all from unauthorized devices. Instead, an attacker on my network would face no greater challenge than if I’d left password authentication on.
Containment π
As I have yet to deploy a meaningful separation of service and management networks, the ability to jump from any server to any other server could prove devastating if an attacker were to compromise an enrolled system. While one might expect FreeIPA’s Host-Based Access Control settings to be useful in this regard, there is no obvious setting to restrict which system a user can login from - only which classes of users are allowed to login to which classes of servers and via which services.
A firewall rule can be written to only accept SSH connections from a specific set of appointed jump servers to improve containment. On public-facing servers, however, unenrollment is wise.
Conclusion π
As I examine my deployed servers, I find that the number of systems which have a legitimate need to be enrolled is at most one. One user on one server does not merit the maintenance of a FreeIPA domain. Over the previous few months, I’ve transitioned my network to use SSH keys.
As part of an ongoing effort to express my servers in terms of Ansible roles, I now have the ability to push updates to the authorized_keys file on all of my systems in one command. And I’ve written a simple Bash script to automate the process of generating a new SSH key and overwriting the old key in Ansible’s template.
Going forward I will also configure my systems to accept SSH only from my jump server, implementing a rudiamentary form of containment.