Ansible Playbooks for Setting up FreeIPA
The code for this project is located on my Github: ansible-freeipa-easysetup
Background
Setting up FreeIPA can be tedious and a chore. There are official FreeIPA Ansible Roles that you can leverage, and I decided to base a project around them to get you up and running with a baseline configuration that only requires editing a few configuration variables.
FreeIPA (Identity, Policy, and Audit) is an open-source identity management solution designed for Linux and Unix systems. It provides centralized authentication, access control, and auditing capabilities, making it easier to manage user identities, roles, and permissions across a network of systems. FreeIPA combines several technologies, such as LDAP (Lightweight Directory Access Protocol), Kerberos, DNS, and a certificate authority, to create an integrated identity and security management platform.
FreeIPA is an open-source alternative to Microsoft’s Active Directory that’s tailored specifically for Linux and Unix environments. It simplifies the management of users, groups, hosts, and access policies through a unified web interface, command-line tools, and robust APIs.
Usecase
Currently, my main use case is providing centralized ssh access to a slew of servers I may deploy and destroy for development, or some that I may have up in production.
- Avoid creating local admin users on every server
- Create service accounts for automation to use across servers with RBAC or HBAC
- Manager user groups
- Passwordless ssh authentication
- Support SSO sign-in for applications that support it
- Create Certificate authority to self-sign TLS certificates and distribute them
- Run your own DNS server to add private local domains
If you’re on-prem, you can run FreeIPA in a VM, same as if you’re in the cloud or hybrid environment.
Notes
FreeIPA has a robust web UI and API. Ideally, you’d want to restrict management access of FreeIPA to a private network. For example, on-prem FreeIPA can run in a VM with only a local private IP address. Clients on the same network can join the domain with no special configuration. For hybrid environments, you can use a VPN so that clients in the cloud can still join the domain.
DNS is important when dealing with FreeIPA, the basis of a FreeIPA cluster is the Realm (IPA1.EXAMPLE.NET) and primary DNS domain name (ipa1.example.net). You can join clients from separate domains to a single Realm.
Luckily, you do not need to purchase a domain name. You can instead use a valid local network domain. Technically, any TLD can be used locally if you run your own DNS, but the better question is should you?
You want to avoid conflicts, and for most of modern history, enterprises and home networks have used domains that ended in .local, .lan, .home, etc. However, according to ICANN such a free-for-all can lead to unintended side-effects and conflicts, such as what has been documented regarding using .local
Because of this, ICANN has proposed using .internal for use in private networks. For that reason, I would suggest using .internal if you’re not going to purchase a dedicated commercial TLD.
You will be running our own DNS server that comes with FreeIPA, and can set private domains there.
The GitLab project ReadMe with thorough documentation on the Ansible playbooks used, but a few minor points I wanted to elaborate on.
You will also be adding the FreeIPA Server (and any Replicas) domain to the /etc/hosts of all clients. This is for two reasons:
- The clients need to connect to the FreeIPA server before it can have its DNS resolver settings updated
- You still want to be able to use FreeIPA in case of total DNS server failure.
As I have mentioned in the ReadMe, when running your own DNS FreeIPA uses BIND9, and the recommended security configuration is to only allow recursion from IP addresses explicitly set in a trusted_network ACL configuration. For this, you will want to plan out IP addresses of clients so that you can whitelist CIDR ranges.
The playbooks are based around the official FreeIPA Ansible Role. I use JSON files to define Groups and Users that will be added to said Groups. Refer to the official documentation on Users and Groups to flesh out configuration depending upon your needs.
Conclusion
The project should be a good starting point for setting up FreeIPA. You will want to tune and customize it to your needs, but it should be a good starting point.