FreeIPA combines a directory, a KDC and a CA in one install

One install for identity, authentication and access control

FreeIPA is described as allowing Linux administrators to centrally manage the identity, authentication and access control aspects of Linux and UNIX systems, by providing command line and web based management tools that are simple to install and use.

The emphasis in the project description is on management and automation, and on being built on well known open source components and standard protocols. That combination is the whole reason the project exists. A Linux estate that wants single sign on needs a directory, a Kerberos KDC, a certificate authority and a DNS server, and each of those is a substantial project to deploy, configure and keep in step with the others. FreeIPA's contribution is to install and drive them as one system.

The benefits the project lists are the ones an administrator would recognise. All users access all machines with the same credentials and security settings. Users reach personal files transparently from any machine in an authenticated and secure way. An advanced grouping mechanism restricts network access to services and files to specific users. Security mechanisms are managed centrally, including passwords, SSH public keys, sudo rules, keytabs and access control rules. Selected administrative tasks can be delegated to other power users. And the whole thing integrates into Active Directory environments.

The audience is a Linux or UNIX administrator with a fleet to manage. The delegate administration point matters, because a directory service that only one person can operate is a single point of failure, and FreeIPA models delegated administration as a first class concept rather than an afterthought.

The components are upstream projects FreeIPA wires together

The components section is the clearest statement of the architecture, and it is a list of other people's projects.

The LDAP server is based on the 389 project. The KDC is based on the MIT Kerberos implementation. The PKI is based on the Dogtag project. The Samba libraries provide Active Directory integration. The DNS server is based on BIND, together with the Bind-DynDB-LDAP plugin, which is what lets DNS records be generated from the directory instead of being maintained by hand.

The Bind-DynDB-LDAP piece deserves a note, because it explains a design choice that would otherwise look strange. A directory that cannot publish its own records into DNS is a directory that requires someone to keep two systems in step manually. With the plugin, a host entry in the directory becomes a DNS record, and the two cannot drift.

That said, this composition is also the source of the operational characteristic that most affects a decision. FreeIPA is not a single program with a single upgrade path, it is a coordinated set of programs, and a change to one component can affect the behaviour of another. The 389 Directory, the MIT Kerberos libraries, the Dogtag CA and BIND all have their own release cadences, and FreeIPA's job is to hold a tested combination of them together.

The Python side of the project, which is the primary language, is where that coordination lives. The `ipalib/` directory holds the shared API, `ipaclient/` and `ipaserver/` hold the client and server sides of it, `ipapython/` is the Python layer, `ipasetup.py.in` is the installer, `ipasphinx/` builds the documentation, and `ipatests/` contains the test suite.

The command line and the web interface are the same API

FreeIPA is built on the idea of a single API that both the command line and the web interface call, and the repository layout shows that idea in its structure.

There is an `API.txt` at the top level, which is the machine readable description of the interface, and an `ACI.txt`, which is the access control instruction list that defines who may perform which operation. The `makeapi.in` and `makeaci.in` files in the root are the generators that produce them, which means the API and the permission model are derived artefacts checked into the tree rather than hand written documents that can drift.

The `ipaclient/` and `ipaserver/` split is the other half of the model. The client library knows how to talk to a server, and the server implements the operations, and both the `ipa` command line tool and the web interface are built on the same client calls. A consequence worth knowing before you start is that anything the web interface can do, the command line can do, and vice versa, so an administration task that seems to need the browser is usually a one line command, and an administrator who prefers the command line is not losing anything.

The repository also carries the pieces that a large Python project accumulates. There is a `pylintrc` and a `pylint_plugins.py` for linting, a `tox.ini` and a `.wheelconstraints.in` for the Python packaging and test environment, an `asn1/` directory and a `freeipa.spec.in` for RPM packaging, a `selinux/` directory for the security policy, `po/` for translations, and `daemons/` for the long running processes.

The `daemons/` directory is worth a second look, because the last push was on 2026-10-15 and the tree is still receiving work. The components are not frozen at the version they were assembled at.

Active Directory integration comes in two flavours

For an estate that is not entirely Linux, the integration story is the part that determines whether FreeIPA fits.

The project states that FreeIPA can integrate into an Active Directory environment via cross-realm Kerberos trust or user synchronization. The benefits list also names the integration with Active Directory environments as one of the reasons to use it, and the components list credits the Samba libraries for it.

The two mechanisms are different in kind and the choice matters. A cross-realm Kerberos trust is a relationship between two authentication systems, so a user authenticating to a Linux host with a Windows account is authenticated by the Windows infrastructure, and the trust has to be configured on both sides. User synchronization is a copy of identities, so the Windows directory remains the source of truth for those accounts and FreeIPA holds a replicated view.

The difference in operational consequence is the usual one. A trust is a live relationship that breaks when domain trust settings change and needs Kerberos configuration on both sides. Synchronization is a copy that can go stale and needs a scheduled job and a conflict policy, but it survives more changes to the remote side because it does not depend on the remote side at request time.

For a mixed estate, this is the design decision with the largest blast radius, and the documentation on it is where a FreeIPA evaluation should spend its time. The project does not say which to choose, which is correct, since the right answer depends on the topology and on who controls the Active Directory.

The GitHub repository is a mirror and the issues live on Codeberg

A practical detail that will save a contributor some confusion: this repository is described as a mirror of FreeIPA, and the default branch is `master`.

The project description for the repository says it is a mirror, and the README points bug reports to a different location entirely, at codeberg.org/freeipa/freeipa/issues. The repository also contains a `.forgejo/` directory, and the presence of both `.forgejo/` and `.github/` is consistent with a project whose primary forge is elsewhere and which keeps a GitHub presence for visibility and for pull requests from contributors who work there.

So the question of where to file an issue has a concrete answer, and it is not the GitHub issue tracker for this repository. The README is explicit about it.

The same split applies to the developer workflow. Bug reports go to the issue tracker, general questions and discussion go to the freeipa-devel mailing list, and there is an IRC channel on irc.libera.chat for the `#freeipa` channel. The README also points at a freeipa-announce list for release announcements, bug fixes and security fixes, hosted by Red Hat, which is a sensible arrangement for a project with a long history of security maintenance.

Documentation has its own home as well. The most up to date documentation is at the documentation page on the project website, the quick start guide is the entry point for a first install, and the build instructions are on the build page with the `BUILD.txt` file in the source root for the details.

Building from source is an autoconf and RPM affair

The build story is the one that reveals the project's packaging heritage, and it is not a pip install.

The tree is a classic autotools project. There is `configure.ac`, an `autogen.sh`, `Makefile.am` with separate `Makefile.python.am` and `Makefile.pythonscripts.am` fragments for the different parts of the build, and `server.m4` for the server side. The version lives in `VERSION.m4`, and `freeipa.spec.in` is the RPM spec template, with `makerpms.sh` for producing the packages. The `pypi/` directory is there because parts of the Python code are also published to the Python package index.

`BUILD.txt` in the source root is the reference, and the build documentation is on the project website.

There is a `make-test` file at the root, and the test suite lives in `ipatests/`, with the test configuration in `tox.ini` and a `pylintrc` alongside. The `init/` and `install/` directories hold the parts of the installation that are not Python, and `util/` holds the command line tools.

For a reader deciding whether to use FreeIPA, the build system tells you something about the deployment model. A system that produces RPMs, generates a spec file, ships an SELinux policy directory and integrates with systemd unit conventions is a system that expects to be installed by a package manager on each server, and a system that expects to be operated by administrators who know what a KDC and a CA are. That is not a criticism. It is a description of the audience, and it is a different audience from a team that wants a container and a REST API.

Editorial conclusion

FreeIPA suits a Linux or UNIX estate that wants one identity system with Kerberos, certificates and DNS managed together rather than as five separate projects, and that has someone prepared to own a directory service. It is the wrong choice for an estate that is mostly Windows, and the wrong choice for a small team that needs only shared SSH keys. Check first what the documentation and the Quick Start Guide say about the version you will install, and confirm that the DNS and certificate pieces fit your existing infrastructure, since those are the components that conflict with whatever is already running.

Frequently asked questions

Official sources

1. freeipa/freeipa on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README