FreeIPA clients on Ubuntu and Debian

How FreeIPA clients on Ubuntu and Debian authenticate users

Enrolling an Ubuntu or Debian host in FreeIPA relies on three things on the client: SSSD to look up and authenticate identities, Kerberos to obtain and validate tickets, and DNS so the host can find the right FreeIPA servers. Whether those client packages and their versions are supported for your distribution is a question to confirm with the FreeIPA project and your own test results, not an assumption to carry into a rollout. If your estate mixes Ubuntu, Debian and RHEL hosts, the authentication design should be written once and then verified per distribution.

SSSD is the component that makes a Linux host a FreeIPA client. It answers identity lookups for users and groups, performs authentication against the Kerberos KDC, and keeps cached credentials so that a user who has logged in before can still sign in when the FreeIPA servers are unreachable, within the limits your cache settings allow. It can also serve SSH public keys from FreeIPA, so that sshd does not depend on per-host authorized_keys files. Each of these functions is a reason teams enable SSSD on their Ubuntu and Debian hosts, and each has settings that change the security outcome.

FreeIPA is an integrated stack: 389 Directory Server holds users, groups, hosts and policies, MIT Kerberos provides single sign-on, Dogtag issues certificates, and SSSD on the client consumes that data. Before you enroll hosts, confirm which FreeIPA server version your estate runs, which client packages your Ubuntu and Debian releases provide, and whether the enrollment and login paths you need (password, OTP, or certificate-based) work on those releases. Record the results in a test matrix that covers at least one host per distribution and release you run, so the rollout decision rests on evidence from your environment.

Which enrollment path fits your Ubuntu and Debian estate

The table compares three ways to enroll Ubuntu and Debian hosts in FreeIPA, from a hand-run install on one machine to pre-created hosts enrolled at scale. Read each row against your host count, your automation maturity and how much you trust the people holding enrollment credentials. The main takeaway is that the path matters less than what you verify afterward, since the same SSSD and Kerberos checks apply to every route.

Path	When it fits	What the operator must provide	What to verify afterward
Interactive enrollment on one host	Pilot machines, lab hosts and a small number of servers where an administrator can sit at the console	An FreeIPA administrator credential or enrollment account, the server name, realm and DNS domain, and the client packages for your release	Kerberos ticket issuance with a test user, SSSD service status, id output for a domain user and a login over SSH
Scripted enrollment with ipa-client-install and configuration management	Fleets managed by Ansible, Puppet, Salt or cloud-init, where installs should be repeatable and reviewed as code	Unattended install options with explicit server, realm and domain, a secured way to supply the enrollment secret, and a tested playbook or role for your Ubuntu and Debian releases	Idempotent rerun results, consistent sssd.conf and krb5.conf across hosts, host entries present in FreeIPA, and drift checks on a sample of hosts
Enrollment at scale with one-time passwords or PKINIT	Large fleets, rebuild-heavy environments and provisioning pipelines where no one should type a shared admin password	Pre-created host entries with one-time passwords or existing host certificates, a provisioning workflow that delivers them securely, and a plan for expiry and failed enrollments	Host principals and keytabs created once per host, certificate or OTP use logged, no leftover one-time credentials, and successful logins after reboot
Confirm before choosing	Every path depends on which client packages and SSSD versions your Ubuntu or Debian release supports with your FreeIPA server version	Written confirmation of supported packages, release names and server compatibility from the vendor documentation and your own test host	A pilot record showing the chosen path worked on each distribution release in your estate

Which identity functions to test on each non-RHEL client

A FreeIPA client is only ready for rollout when each identity function works on the exact Ubuntu or Debian release you run, not just on the reference platform. The six functions below cover login, directory lookups, policy, keys, host credentials and name resolution, and each one should be tested with a named user and host before any fleet-wide change.

Kerberos login and ticket acquisition

Confirm that a domain user can obtain a Kerberos ticket with kinit on a freshly enrolled host and that the ticket is usable for SSH and other services. Test with a password and with any MFA method you plan to require, since the PAM and Kerberos settings on Debian-family systems can differ from RHEL. Ask your distribution packager or the FreeIPA project which Kerberos and PAM package versions are validated, and check the FreeIPA release notes for your server version before assuming parity.

User and group lookups through SSSD

Run getent passwd and getent group for both local and IdM accounts, including nested groups and users in other domains if you use trusts. Verify that sssd starts cleanly, that the nsswitch.conf entries resolve through SSSD, and that home directories are created as expected. Ubuntu and Debian ship their own SSSD packaging and default configuration, so check the file paths and service names against your release before you copy RHEL runbooks.

Sudo and HBAC policy enforcement

Test one allowed and one denied login for each host-based access control rule, and one sudo command that is permitted and one that is refused. Policy outcomes depend on the PAM stack and the SSSD sudo provider, so a rule that works on RHEL can fail silently on a Debian-family host. Ask the vendor or your packager whether the sudo and PAM integration is supported on your release, and record the result for each rule.

SSH public key retrieval

Confirm that SSSD returns a stored user public key to sshd through the AuthorizedKeysCommand path, and that a key removed in IdM stops working on the host. Check that sshd_config on your release includes the IdM-provided lookup and that no stale authorized_keys files override the central result. Verify host key retrieval for known hosts as well, since a mismatch here causes login prompts that look like authentication failures.

Host keytab and certificate behavior

Check that the host keytab is created at enrollment, that ipa-getkeytab or the enrollment flow can renew it, and that host certificates are issued and renewed by the certmonger service on the client. Test a host certificate renewal before the first expiry date you plan to rely on. Ask the packager which certmonger and NSS or OpenSSL integration is supported, because certificate paths and tracking helpers vary between Debian-family releases.

DNS over TLS to IdM DNS servers

FreeIPA 4.13.0 introduced DNS over TLS between clients and IdM DNS servers, so test it only on releases and client packages where you have confirmed the feature works end to end. Verify that name resolution succeeds through the encrypted path, that fallback behavior matches your policy, and that the resolver configuration survives reboot. Read the 4.13.0 release notes and confirm the client-side resolver support for your distribution before you enable it fleet-wide.

What the support position for Ubuntu and Debian clients means for you

The first thing to settle is that three different statements are often mixed together: a client that enrolls successfully, a client the FreeIPA project supports, and a client your operating system vendor or distribution will support. An Ubuntu or Debian machine can join a realm, obtain a Kerberos ticket and resolve users through SSSD without any of the other two being true. The supplied FreeIPA documentation describes the server platform and the upstream project, including the components a deployment combines: 389 Directory Server, MIT Kerberos, Dogtag, SSSD on clients, and optional DNS and NTP. It does not, on its own, give a support statement for Ubuntu or Debian clients against a given server version, so do not treat a working test enrollment as evidence of support.

Ask for the written support position for each exact client OS release you plan to run, paired with the exact FreeIPA server version you will operate. Confirm it against the current FreeIPA release notes and distribution documentation, and get the answer in writing from whoever will carry the risk: the distribution vendor, a commercial support provider, or your own platform team if you maintain the packages. Pay attention to whether the statement covers the client packages, the SSSD version shipped with that release, and the PAM and sudo integration, since those are where enrollment and login behavior typically differ. Also confirm whether the statement changes after a server upgrade.

For comparison, read the RHEL client statement covered in the client version compatibility topic. FreeIPA is developed alongside Red Hat's platform, so RHEL clients are the reference point most teams start from, but the same wording may not carry over to Ubuntu or Debian. Record the gap explicitly in your risk register. If a client falls outside the written support position, plan for it as a known exception with an owner, a patch path and a test before any server upgrade, rather than discovering it during a production login failure.

How to enroll an Ubuntu or Debian client in FreeIPA step by step

This sequence takes one pilot Ubuntu or Debian host from name resolution and time checks through a working FreeIPA enrollment, with a verified Kerberos ticket, SSH login and sudo rule before any wider rollout.

Confirm DNS resolution and resolver settings
The engineer on the pilot host checks that the IPA domain, the IPA server host name and the realm's SRV records resolve, and that /etc/resolv.conf lists at least two DNS servers that can answer for the IPA domain. FreeIPA's deployment recommendations advise at least two DNS servers in each client's resolv.conf. Run getent hosts on the IPA server name and dig -t SRV _kerberos._tcp.<domain> to confirm. The step is done when both lookups return the expected IPA server address and SRV records point to the right servers.
Confirm time synchronization
Kerberos rejects tickets when clocks drift too far apart, so confirm that the host syncs time against a source the IPA servers also use. On Ubuntu and Debian, check timedatectl status for a synchronized clock and that the time service in use is active. Ask your platform team which NTP sources the FreeIPA servers use and align the client to them. The step is done when the host reports the system clock as synchronized and its time offset from the IPA server is negligible.
Install the client packages
Install the FreeIPA client and SSSD packages from the distribution archive that matches your release, along with the Kerberos client tools and the PAM and NSS modules that SSSD depends on. Confirm the package names and supported release combinations in the FreeIPA client documentation for your distribution before you start, because support for non-RHEL clients is a separate question from the packages themselves. The step is done when the installed client version is recorded and ipa-client-install is available on the path.
Run ipa-client-install with explicit options
Run ipa-client-install with --domain, --server and --realm set explicitly, so the installer does not guess from DNS. Use --mkhomedir if local home directories should be created at first login, and decide now whether the host should update DNS records. The installer asks for an enrollment credential unless you supply one, so use an account with enrollment rights or a pre-created one-time password, and avoid sharing the admin password. The step is done when the installer ends with a success message and the host appears under Hosts in the FreeIPA web UI.
Verify identity lookups with id and getent
Check that SSSD resolves directory users and groups through the normal name service path. Run id <test user> for a known IPA user and getent passwd <test user> and getent group <test group> to confirm the NSS entries. Compare the UID and GID with the values shown in the FreeIPA user record. The step is done when the lookups return the same identity and group memberships the FreeIPA server holds. If the lookup fails, check sssd service status and its logs before changing anything else.
Obtain and inspect a Kerberos ticket
Log in as the test user with kinit <test user> and then run klist to confirm a ticket-granting ticket for the IPA realm exists. Note the principal, the realm and the expiry time. This confirms that the host can reach the KDC and that the user's password and Kerberos keys work on this client. The step is done when klist lists a valid ticket issued by the realm. If kinit reports that the KDC cannot be found, return to the DNS step.
Test SSH login and a sudo rule
Open a new SSH session from a workstation as the test user to this host, using a Kerberos ticket or a key that the policy allows. Then run sudo -l to confirm the sudo rules that the test user should receive from FreeIPA are present. Also check that the access control rule for this host allows the login, since host-based access control applies to SSH. Ask the policy owner which rules the test user should match. The step is done when the login succeeds, the expected sudo rules appear and a user outside the rule is refused.
Review SSSD and PAM configuration
Review /etc/sssd/sssd.conf, the NSS entry in /etc/nsswitch.conf and the PAM files under /etc/pam.d/ that the installer changed. Confirm that the SSSD domain points to the expected IPA server and realm, that the cache and offline settings match your standard, and that no leftover LDAP settings from earlier configurations remain. Save a copy of the final configuration as the baseline for this release. The step is done when the configuration matches the reviewed baseline and the pilot host passes the earlier checks after a reboot.

Choosing an enrollment approach by estate size and change pattern

A small estate, often a few dozen Ubuntu or Debian hosts, can usually be enrolled by an administrator running ipa-client-install directly on each machine. The administrator who holds the enrollment rights is also the person who checks the result, so the process stays simple and the cost is mostly the time spent on each host. Templating is light: a short written runbook with the exact options, the expected DNS and NTP settings, and the group membership each host type needs.

Who runs enrollment: one named administrator, with enrollment rights granted to that person only and removed afterward.
What must be templated: the runbook, the install options, and the post-enrollment checks such as id and an SSH login test.
How drift is detected: periodic manual review of the host list in the FreeIPA web UI against the inventory, plus a short checklist after any change.
Pilot results to hold: one or two enrolled hosts of each Ubuntu or Debian release in use, with login, sudo, and host-based access tested.
Watch for: host names that are reused after rebuilds, which leave stale host entries behind.

Before choosing this approach, confirm that the number of hosts and rebuild frequency will not grow faster than one person can track by hand.

Security risks on enrolled Ubuntu and Debian hosts

Enrolling an Ubuntu or Debian host gives it a host identity, Kerberos keys and a cache of directory data, and each of those becomes a target if the host is compromised. The cards below name the controls and checks that keep enrolled hosts from becoming a path into the wider FreeIPA realm. Confirm each item against your own host build and your server patch level before rollout.

Protect host keytabs and enrollment credentials

A host keytab holds the Kerberos keys that let a machine authenticate as its host principal, and the enrollment password or one-time password used to create that principal can add hosts to your realm if it leaks. Restrict read access to /etc/krb5.keytab to root, remove enrollment passwords from build scripts and configuration management once enrollment completes, and confirm that golden images do not carry a keytab from another host. Check file ownership and permissions on every enrolled host during acceptance testing.

Control what SSSD caches

SSSD can cache user credentials so people can log in when the IPA servers are unreachable, which is useful on laptops and remote servers but widens the exposure of a stolen disk or a compromised host. Decide per host group whether offline login is allowed, set cache lifetimes that match your policy, and test that a cached login behaves as you expect when the network is down. Ask your security team to sign off on the caching design before it reaches laptops.

Enforce HBAC and sudo on local administrators

Host-based access control and sudo rules only apply to hosts that enforce them, and local administrators on Ubuntu and Debian can still create local accounts, edit local sudoers files or change PAM settings if they have root. Keep HBAC and sudo rules in FreeIPA as the source of truth, restrict who holds root on each host, and review local sudoers.d drop-ins and PAM configuration on a schedule. Verify with test accounts that denied users stay denied on each host group.

Keep client and server on supported patch levels

The FreeIPA 4.13.4 release notes describe fixes for two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, along with hardened authentication checks across the API. Patch the FreeIPA servers first, then confirm the client packages and SSSD on Ubuntu and Debian hosts are at versions your support position covers. Record the server version and client package versions in your inventory so you can show which hosts were exposed and when they were updated.

Verify the DNS path to IPA servers

Clients locate the IPA domain, KDC and LDAP servers through DNS, so a host that resolves the IPA names to an untrusted address can be steered toward a fake server. Check that each enrolled host's resolv.conf points to your IdM DNS servers, that the SRV records for the realm resolve to your servers, and that DNS over TLS is configured where your FreeIPA version supports it. Include a resolution test in your acceptance checklist and repeat it after network changes.

Testing FreeIPA clients on Ubuntu and Debian before rollout

Build the pilot as a matrix before anyone touches production hosts. Each row is one combination of distribution, release, client package set, FreeIPA server version and host role, taken from what your estate actually runs. Include the server version exactly as installed, because a pilot result applies only to the combination it tested. For each combination, record the output of ipa-client-install (or your automation's equivalent), the resulting /etc/sssd/sssd.conf and /etc/krb5.conf, the time to first successful Kerberos ticket, and whether id resolves both a local and an IPA user. Store these records with the change ticket so the next reviewer can see what was tested.

Test each login path that matters to your users and services, not only SSH. Check console login, SSH with password and with Kerberos (GSSAPI) where you plan to allow it, graphical login on desktop hosts, sudo under the access rules you intend to enforce, and at least one service account that starts a long-running process. For each path, confirm that the access rules (HBAC and sudo) allow and deny as designed, and that a denied user fails cleanly. Failure tests matter as much as success tests. Stop the FreeIPA server or block its ports, then confirm which cached logins still work and which fail, and how long the host waits before failing. Change the DNS records or resolver settings on a test host and confirm that SRV lookups and the server name still resolve. Document every result, including the ones you consider acceptable.

Plan rollback before the first pilot host is enrolled. Confirm how you will unenroll the host, remove the keytab and any leftover SSSD cache, and restore the prior PAM and name service settings. Keep a snapshot or image of the host before enrollment, and check that the rollback procedure restores local login on a host you have deliberately broken. Once you have a tested matrix, treat it as valid only for the exact distribution release, client package versions, server version and configuration it covered. Repeat the matrix after any Ubuntu or Debian release upgrade, after a client package change, and after a FreeIPA server upgrade. Confirm the supported distribution and release list with the FreeIPA project and your vendor's documentation before you plan the matrix, since support for non-RHEL clients is a separate question from whether a combination works in your lab.

Limits to confirm in your environment before you commit

Ubuntu and Debian are not the platform FreeIPA's own client support statement is built around, so several limits depend on your exact releases, server version and login stack. Each card names an item to settle with the distribution, the FreeIPA project or your own test before you commit to a rollout.

Written client support position per release

Ask which Ubuntu and Debian releases are covered by a written support position for the FreeIPA client packages you plan to use, and who gives that position. Do not assume a release works because it installs. Record the answer for each release in your estate, including whether the packages come from the distribution archive or from another source. Confirm this with the distribution and your own enrollment test, since support wording can differ from what installs cleanly.

Client and server version compatibility

Check that each Ubuntu and Debian client release works with the FreeIPA server version in your estate, including the SSSD and Kerberos versions the client ships. Server upgrades can change what clients need, so plan client and server versions together. Confirm the pairing with the FreeIPA project's release notes and by enrolling a test host against a server running the same version you will operate.

PAM and AppArmor changes affecting login

Distribution updates to PAM stacks, SSSD integration and AppArmor profiles can change how SSH, sudo and console logins behave after enrollment or a routine upgrade. Test a full login path on each release, including a password change, a locked account and a sudo rule. Confirm the expected PAM and AppArmor configuration with the distribution's documentation and your own test, and keep a rollback path for hosts you cannot reach from the console.

SSSD cache settings and offline login

The SSSD cache settings on each host decide whether a user can log in while the FreeIPA servers are unreachable, and for how long cached credentials remain usable. Confirm the cache lifetime and offline behavior you want, and test a login with the network disconnected from the IPA servers. Weigh the security trade-off of caching credentials on laptops and remote hosts against the availability need, and confirm the exact settings in your SSSD version.

OTP and smart card login requirements

Decide whether OTP tokens or smart card login are required on these hosts, or whether password and Kerberos login is enough. Ubuntu and Debian login paths for OTP and smart cards may need extra packages and PAM settings that differ from RHEL-based clients. Confirm which methods your Ubuntu and Debian releases support in your own test before you write the requirement into a policy, and do not assume the RHEL behavior carries over.

Recovery for a lost keytab or certificate

Define the procedure for a host whose keytab or host certificate is lost, damaged or copied off the machine. Confirm with your own test how re-enrollment, certificate revocation and keytab removal work on the distribution release you run, and who is allowed to perform each step. Write the steps down and rehearse them on a test host, since a lost keytab can lock a host out of Kerberos login until the host is re-enrolled.

What buyers ask before enrolling Ubuntu and Debian clients

Are Ubuntu and Debian clients supported by FreeIPA?

Ubuntu and Debian machines can be enrolled through the SSSD client stack, but the FreeIPA project's client support statement centers on Red Hat Enterprise Linux and its derivatives, so non-RHEL support is a question to settle in writing before rollout. Confirm the exact client package versions your distribution ships, the FreeIPA server release you will run, and whether the vendor packaging of your chosen distribution matches the behavior you need for host enrollment, SSSD caching and SSH key handling. Ask your partner to document which of these points they have tested in your environment and which remain open.

How much effort does a pilot take, and what drives it?

Effort depends on how many distributions and release versions you run, how much of your current authentication is tied to local accounts or legacy LDAP, and how many access policies you need to reproduce. A pilot on a small set of machines is mostly test design: enrolling representative hosts, logging in as different user types, checking sudo and host-based access rules, and confirming home directory creation and SSH key lookup. Each additional distribution release, configuration management tool or existing LDAP client adds test cases. Ask for the effort split between enrollment testing, policy mapping and documentation.

What does the internal team need to provide?

Your team needs to supply access to a FreeIPA server or a test realm, DNS and NTP settings for the test network, a list of target distributions and versions, and named owners who can approve policy decisions such as who may log in to which hosts. Someone must also be able to change host firewall rules and DNS records during testing. Plan for a systems engineer who knows your current PAM, NSS and SSH configuration, because that knowledge shortens the cleanup of old settings. Confirm these responsibilities in the scope before work starts.

Can our own team do this without a partner?

Yes, an experienced Linux team can enroll Ubuntu and Debian clients using the documented client tools, and many do. The difficult part is rarely the first enrollment. It is confirming the behavior across your distributions, cleaning up previous LDAP and SSSD configuration, and deciding how enrollment will be repeated across a fleet without sharing administrator credentials. A partner adds value when you want that testing and rollout plan written down, or when your team lacks time to do it alongside production work.

How long does a pilot run, and what sets its length?

Pilot length is set by the number of distributions under test, the number of policy areas to verify, and how quickly your change process can approve and deploy test changes. Identity changes also need time for cross-checks, such as a login from a second host and a clean re-enrollment. Ask for a schedule with the agreed scope, including dependencies on your change windows and on any server work that must happen first. A duration should be stated in the written plan, not inferred from this page.

What recurring work follows enrollment?

After enrollment, recurring work includes keeping the SSSD and client packages current on each distribution release, reviewing host access rules as staff change, watching for FreeIPA server upgrades that affect clients, and checking that new hosts enroll with the intended policy. Teams also need a repeatable re-enrollment or removal procedure for rebuilt or retired machines. Ask whether the work will be done by your team, by a partner under a retainer, or split between them, and what each option covers.

How is a partner's fixed-scope quote built?

A fixed-scope quote is built from the written list of deliverables: the distributions and versions covered, the test cases, the number of representative hosts, the policy items to map, the documentation expected, and the handover. Each item that adds work, such as an additional distribution, a legacy LDAP cleanup or an automation pipeline, should appear as a separate line. DeployOpen does not publish a price list, so the quote follows from the written scope. Ask which items are one-time and which would be handled under a separate retainer.

What should we ask for in writing before work starts?

Ask for the exact distribution and release list, the FreeIPA server version and the client packages that will be tested, the test cases and pass criteria, the list of hosts and users involved, the access policies to be checked, and the responsibilities of each party. Also request the rollback plan, the documentation format, the handover contents and what happens when a finding requires a change outside the scope. A written scope protects both sides and makes the next quote comparable.

How DeployOpen scopes and tests FreeIPA client enrollment

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so Ubuntu and Debian client enrollment is scoped and tested against your estate before any production host is touched. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.

How we scope

We inventory your Ubuntu and Debian release versions, host types and SSSD configuration before agreeing any scope.
The written scope names the FreeIPA server versions, client packages and enrollment method (password, OTP or PKINIT) for each host group.
We record which client behaviors you need to confirm with your own environment, such as home directory creation and offline login rules.

How we build

We build a test enrollment path on lab hosts that match your target Ubuntu and Debian releases and FreeIPA server version.
We produce repeatable enrollment automation and SSSD configuration that you can review, version and rerun on new hosts.
We test SSH key lookup, sudo and HBAC access, DNS resolution and failed-server behavior before any production rollout.

How we hand over

You receive the written configuration, enrollment runbook and a record of the test results against the agreed scope.
The documentation lists the supported client packages, known gaps for non-RHEL clients and the checks each new host must pass.
We walk your operations team through troubleshooting SSSD logs, re-enrollment and removing old LDAP configuration.

How we support

Ongoing support, client upgrades and continuous testing are available as a retainer, scoped separately from the build.
A retainer can cover re-testing when FreeIPA servers or Ubuntu and Debian releases change under your estate.
Support requests are handled against the written scope, so you know which changes need a new quote before work begins.