FreeIPA client installation options: what each choice changes on a host
Before you roll out FreeIPA to a group of Linux machines, you need to decide which ipa-client-install options each host will receive, because those options decide what the install writes to the machine. The tool configures SSSD for identity lookups, Kerberos for ticket-based login, and the NSS and PAM stacks that let local logins consult FreeIPA. Per the FreeIPA About page, FreeIPA is built from 389 Directory Server, MIT Kerberos, the Dogtag certificate system, SSSD on clients, and optional ISC BIND DNS and NTP, so the client side touches the directory, Kerberos and name resolution at once. The options you choose control whether the host updates DNS records, whether it creates home directories at first login, how it sets NTP, and which server and realm it joins.
Teams usually need explicit options in a few situations: unattended installs where no one answers prompts, estates with more than one IPA domain or realm, and mixed fleets where some hosts sit in a different network zone or need different NTP sources. In those cases, pass the server, domain and realm explicitly rather than relying on DNS discovery, and write the same values into your provisioning templates so every host lands in the same place. The exact flag names and defaults depend on the client release, so confirm each option against the ipa-client-install man page for the exact version in your estate before you write automation around it. Ask your platform owner which client release the golden image uses, since that answer can change which options are available.
Before rollout, test the chosen options on a few representative hosts and check the results with getent passwd and klist against a test user, then review /etc/sssd/sssd.conf, /etc/krb5.conf and the PAM configuration the installer changed. Also record which options you did not set, because defaults can differ between releases and between DNS-discovered and explicitly configured installs. If the host already has LDAP or SSSD configuration from an earlier setup, plan the cleanup step as part of the same test, since leftover settings are a common source of login failures that look like directory problems.
Which ipa-client-install options fit which estate
This table compares the main ipa-client-install option areas by what each changes on a host, when it fits, and what happens if it is left at default. Use it to shortlist the options to confirm against the man page for your installed client version before writing an enrollment script.
| Option area | What it changes on the host | When it fits and the risk of default |
|---|---|---|
| Home directory creation | Decides whether a first login creates a local home directory for a directory-backed user, using the PAM and mkhomedir settings the installer manages. | Fits workstations and shared servers where users log in directly. Left at default without checking, users may log in with no home directory, or the host may create directories you did not plan for. |
| DNS updates and client DNS records | Controls whether the client registers its own address records with the IdM DNS server during enrollment, and whether resolver settings are changed. | Fits integrated DNS zones where hosts should self-register. Risk: stale or unexpected records if DHCP addresses change, and resolver changes that conflict with local DNS management. |
| Explicit domain, server and realm | Writes the domain, realm and IdM server into SSSD, Kerberos and LDAP client configuration so the host does not depend on discovery. | Fits estates with several domains, split DNS or hosts outside the main site. Risk: discovery picks a server or realm you did not intend, especially where DNS records are incomplete. |
| Unattended credentials | Supplies the enrollment principal, password or one-time password on the command line or from a file, so enrollment can run without a person typing. | Fits kickstart, cloud-init and configuration management runs. Risk: credentials stored in shell history, logs or images, and enrollment tokens that outlive their intended use. |
| NTP and time sources | Sets whether the installer configures time synchronization against IdM NTP servers or leaves the host's existing time service alone. | Fits estates where Kerberos depends on tight clock skew. Risk: a host with drifting time fails Kerberos authentication in ways that look like password or realm errors. |
| Cleanup of previous LDAP and SSSD configuration | Removes or replaces older LDAP client, SSSD, Kerberos and keytab state left by a previous enrollment or a manual setup. | Fits rebuilt hosts, hosts moved from another directory and images with leftover configuration. Risk: conflicting sssd.conf or keytab entries that cause intermittent logins or wrong identities. |
| What to confirm for your version | Exact flag names, defaults and which options each client package version supports. | Check the ipa-client-install man page shipped with your installed client, and test the chosen set on one host of each OS before rollout. |
Four estate types and the install choices each one needs
Most FreeIPA estates mix several kinds of machines, and each kind pushes the installer toward different choices. Decide these per estate type before the first rollout, not host by host, so the same options are applied consistently. The DNS and NTP settings in the deployment recommendations are the common thread across all four.
A small set of named servers
Long-lived servers with fixed names, usually managed by hand or a small team. Decide whether home directories are created on first login, since shared service accounts may not need them, and whether the installer should update DNS records for each host. Confirm that each client's resolv.conf lists at least two DNS servers that can answer for the IPA domain, as the deployment recommendations advise. Choose whether ipa-client-install sets NTP through the installer or whether the team keeps its own time configuration.
Laptops with local users
Laptops that move between networks and may have local accounts already in use. Decide early whether home directories are created locally on first domain login, and how existing local UIDs and LDAP or SSSD leftovers will be cleaned up before enrollment. Plan for machines that are often off the corporate network, so check that DNS and time still resolve when the device roams. Offline login behavior is a separate decision that affects this group most.
Hosts provisioned by kickstart or automation
Machines built from kickstart, images or configuration management, where enrollment runs without a person at the console. Fix the domain, server, realm and NTP values in the automation rather than relying on discovery, so every build resolves to the same servers. Remove any stale LDAP or SSSD configuration that golden images may carry. Decide whether DNS records are created during enrollment, because a rebuilt host with an old record can confuse later lookups.
Hosts in restricted networks
Hosts whose DNS or time sources are limited by segmentation, proxies or a data center policy. Confirm which IPA servers each host can reach for DNS and NTP before running the installer, because discovery and time sync will fail quietly if those paths are blocked. Decide whether the host should use IPA's DNS and time or reach an approved internal source, and record that choice in the install command. Test name resolution and time sync from the restricted segment itself, not from an admin workstation.
How DNS and NTP settings decide whether enrollment succeeds
Enrollment succeeds only if the host can find an IdM server through DNS and keeps its clock close enough to the KDC for Kerberos to accept its tickets. ipa-client-install discovers servers and the realm through DNS SRV records, so a client that resolves the wrong zone or cannot reach the SRV records fails before any credential is exchanged. The FreeIPA deployment recommendations advise listing at least two DNS servers in each client's resolv.conf, and that advice matters most during enrollment, when a single unreachable resolver can stop the install with an error that looks like a Kerberos or server problem. Before you run the install, check from the host itself that the SRV records for your domain resolve, that the search domain is correct, and that the resolvers answer for both the IPA zone and external names.
Teams should also confirm how the client reaches DNS. The FreeIPA 4.13.0 release notes introduced DNS over TLS between clients and IdM DNS servers. This is a new transport choice, not a default you can assume: confirm that your client operating systems, their resolver software and your IdM DNS servers all support it in your estate, and that your firewalls allow the TLS port between them. Treat it as a change to test on a non-production host, because a resolver that silently falls back or cannot validate the server certificate will break discovery in ways that are hard to diagnose from the enrollment log alone.
Time sync is the second dependency. Kerberos rejects tickets when client and KDC clocks drift too far apart, so the NTP settings you pass or configure during installation must point at the same time source the rest of your estate already uses. If your data center runs its own stratum sources or a corporate NTP pool, point the client and any IdM NTP servers there rather than introducing a second hierarchy. Agree the source with your infrastructure team first, then verify that the host's clock is synchronized before enrollment, since a skewed clock often surfaces as an authentication failure after the install appears to finish.
Setup sequence for FreeIPA client installation options
This sequence settles the domain, realm, server and DNS facts a client install depends on, proves them on one host, and only then turns the approved options into a repeatable script for the rest of the estate.
Confirm the IdM domain, realm and server names
The platform or identity lead records the IdM DNS domain, the Kerberos realm, the fully qualified names of every server clients will contact, and the names of the replicas they may fall back to. Realm and domain are often written in upper and lower case forms that must match, so record both exactly. Check the names against the server's own configuration rather than from memory or an old runbook. Done when a single written reference sheet lists these values and the server admin has signed off on it.
Verify DNS resolution from a test host
On a non-production host, the engineer confirms that the resolver configuration in resolv.conf points at the IdM DNS servers, and that forward lookups for each IdM server name, and reverse lookups for their addresses, return the expected results. Confirm that the host can resolve the SRV records that clients use to find the KDC and LDAP service. The FreeIPA deployment guidance calls for at least two DNS servers in each client's resolv.conf, so verify that the second entry also answers. Done when every lookup returns the recorded values from both DNS servers.
Decide DNS record and home directory behavior
The team decides whether the client install should create DNS records for the host, which network interfaces those records should cover, and whether home directories should be created on first login. Each choice is written down with its reason and the owner who approved it. Ask the platform owner to confirm whether home directories come from a shared file system or are local, since automatic creation on a host that mounts shared homes can cause conflicts. Done when each option has a recorded value and an approver.
Check time synchronization
The engineer confirms that the test host syncs time from an approved source and that its clock offset is small enough for Kerberos to accept tickets. Kerberos rejects requests when clocks drift too far apart, so a host that is out of sync will fail enrollment in ways that look like authentication errors. Confirm the expected NTP settings with the IdM team, especially if the client install is asked to configure NTP. Done when the time service reports synchronized and the offset matches the value agreed for the estate.
Run a test enrollment on one non-production host
Using the approved options typed by hand, an engineer runs the client installation on one disposable, non-production host with a named enrollment account or one-time password. The run is captured in a log so that every option and output can be reviewed later. Record the exact command and the version of the client packages. Do not use a production host for this step, because a failed attempt can leave behind LDAP and SSSD configuration that is hard to remove. Done when the installer finishes without errors and the log is saved with the team's records.
Verify Kerberos, SSSD and the host record
On the test host, the engineer requests a Kerberos ticket for a known test user and checks that the ticket is issued with the expected realm. Then the engineer runs an identity lookup for that user through SSSD and confirms the user's groups resolve. From the IdM side, the administrator confirms that a host record exists with the expected name, domain and enrollment state. Done when the ticket, the user lookup and the host record all match the reference sheet from the first step.
Script the approved options for the rest of the estate
Once the test host passes, the approved options are moved into a versioned install script or configuration management role, with the domain, realm, server names and DNS and home directory choices as parameters. The script must be run against a second test host before wider use, and its output compared with the first run. Confirm with the team who owns the script, where its logs are kept, and how it will be rerun on hosts that are already enrolled. Done when a second host produces the same results as the reference host and the script is stored under change control.
What to clean up before enrolling a host that ran LDAP or SSSD before
Clean up a host before running ipa-client-install, not after a failed attempt. Hosts moved from an older LDAP-based setup or from an earlier SSSD configuration often carry settings that conflict with a new FreeIPA enrollment: an old /etc/ldap.conf or /etc/openldap/ldap.conf pointing at a previous directory, an /etc/sssd/sssd.conf naming a different domain, and nsswitch.conf lines that still route lookups to a retired source. The installer rewrites many of these files, but it does not know which of your local edits you want to keep, so review them first. Check that nsswitch.conf lists sss only where you intend it, and note any custom PAM or sudo changes that were tuned for the old directory so you can reapply the ones you still need.
Next, clear cached data and leftover credentials. Stop SSSD, then remove its cache under /var/lib/sss/db/ and /var/lib/sss/mc/ so cached users and group IDs from the old realm do not survive into the new one. Review /etc/krb5.conf and any /etc/krb5.keytab or /etc/krb5.conf.d/ fragments from the previous setup, and remove keytabs that belong to a host principal you are about to replace. Confirm the host's DNS name and reverse record match what the new FreeIPA server expects, because enrollment depends on them. Keep a copy of the old files in a dated directory so you can restore a setting if a service fails after the cut-over.
Removing the host's entries on the FreeIPA server is a separate step, and it needs coordination. The old host object, its service principals and its certificates may be owned by a application team, a change board or another administrator, and deleting them can break services that still depend on them. Agree on who approves the removal and when it happens, then follow the full removal and rebuild procedure in the re-enrollment topic, Re-enrolling and uninstalling FreeIPA clients. Do not run the enrollment until the server-side record has been resolved, or the installer may reuse an old host entry with stale keys.
Security considerations when choosing enrollment options
Each ipa-client-install option decides who holds enrollment power, what secrets land on the client and what the server records afterward. The four cards below cover the controls your team must own before the first host joins, so the install choice does not quietly widen who can become a machine identity.
Admin passwords versus one-time passwords
Enrolling with an administrator password means that person's credential is typed, logged in shell history or pasted into automation, and it grants rights well beyond one host. A one-time password pre-created for a specific host limits the exposure to that enrollment. Decide who issues these passwords, how they are delivered to the installer, and who may revoke an unused host entry. Confirm with your team how automation stores them, since a password left in a playbook variable becomes a standing secret.
Protecting keytabs and host credentials
Enrollment writes a host keytab to the client, and that file lets the machine authenticate as its Kerberos principal. Anyone who reads it can impersonate the host to services in the realm. Set restrictive ownership and permissions on the keytab, keep backups of client disks encrypted, and make sure images or templates created from an enrolled machine do not carry its keytab. Plan how a compromised host is removed from the server so its principal and certificates stop working.
Creating home directories on shared hosts
The option that creates home directories on first login is convenient on multi-user servers, but it also creates local paths with ownership and permissions that the team must govern. On shared hosts, check that the directory mode, skeleton files and mount point match your policy, and that the automatically created home does not inherit a path an attacker can pre-seed. Test first logins under your access rules, and review which accounts are allowed to log in to each host before enabling it widely.
Logging and reviewing enrollment activity
Enrollment creates host entries, principals and certificate requests on the server, and those actions should appear in your review process. Export and retain the relevant server logs, compare the host list against your asset inventory on a schedule, and flag host entries that were created but never used. Ask who receives alerts for unexpected enrollments and how long logs are kept, because a reviewer cannot investigate a host that was enrolled months ago without them.
FreeIPA client installation options questions buyers ask before hiring help
How much effort does a fixed-scope FreeIPA enrollment design take?
Effort depends mostly on how many distinct host types you have, not on the raw host count. A design covering one image and one enrollment path is a small job. Effort rises when hosts differ in operating system, network zone, role, or whether they need home directory creation, custom SSSD settings, or special DNS handling. Cleanup of old LDAP and SSSD configuration adds work on every host that has been managed by hand. Ask any partner to show how the written scope counts host groups, enrollment methods, and cleanup cases, and to state which of those they assume. A quote follows from that written scope.
What drives the cost of a FreeIPA client enrollment project?
Four factors drive most of the cost. The first is estate size and variation: the number of distinct host builds matters more than the total count once automation is in place. The second is the state of DNS and NTP: if forward and reverse records, resolver settings, or time sources are inconsistent, the work moves into those systems before any client changes. The third is cleanup, because hosts with leftover LDAP, SSSD, or keytab files need an inventory and a repeatable reset. The fourth is testing: each distinct distribution and access path needs a verified login before rollout. One-time costs cover design, build, and testing. Recurring costs appear only if you buy ongoing support or upgrades.
Can our own team install and enroll FreeIPA clients without a partner?
Yes, many teams do. The install itself is a single command on a supported host, and the skills gap is usually in design choices: how DNS discovery works, which options to set explicitly in unattended runs, how to handle NTP, and how to remove stale state safely. Your team can do the work if it has a Linux administrator who knows SSSD, a DNS owner, and time to test on representative hosts. Hiring help makes more sense when the estate is varied, the deadline is fixed, or no one has time to write and verify the rollout runbook. Check the compatibility of your client operating systems with your FreeIPA server version before you start.
What does the work need from our side?
Plan for access and decisions, not only time. You will need the FreeIPA server details, the realm and domain names you intend to use, and the DNS owner to confirm forward and reverse records and resolver settings on the clients. You will need a time source the clients are allowed to use and the NTP settings your policy requires. A dedicated test host or two, representative of your builds, is essential. Change approvals matter because enrollment alters authentication, home directories, and possibly SSH behavior. Name one owner who can approve each change window and who can decide what happens to hosts that fail testing.
How long does it take to get a FreeIPA client pilot working?
The timeline is driven by dependencies, not by the install command. A pilot waits on DNS corrections, agreed time sources, a test host, and sign-off on which options will be used. If those are ready, the pilot is mainly a matter of enrolling a representative host, confirming Kerberos and SSSD logins, checking home directory creation and DNS updates, and recording results. If the estate contains hosts with old LDAP or SSSD configuration, cleanup testing lengthens the pilot. Ask for a written schedule that lists each dependency and its owner. No duration is given here because it depends on your environment and agreed scope.
Does unattended enrollment need extra design work?
Yes. Unattended runs remove the chance to answer prompts, so every value that interactive installs would supply must be set explicitly: the server, the domain, the realm, the choice of home directory creation, and the DNS update and NTP behavior. Credentials must come from a controlled source such as a one-time password or a managed secret, never from a shared administrator password in a script. Test the exact command on each host build, and capture its exit status and logs so failures show up in your automation, not on the host later. Decide in advance what a failed enrollment does to the host.
What should we ask for in a written quote for client enrollment?
Ask for a scope that lists the host builds covered, the enrollment method for each (interactive, unattended, or automated), and which DNS and NTP changes are included or excluded. Ask what cleanup of existing LDAP and SSSD configuration is included and how it will be verified. Ask which tests run on each distinct build and who signs off on results. Ask for the documents you will receive, such as the runbook, the option set, and the rollback steps. Finally, ask which items are one-time and which would recur if you later want support or upgrades. Compare quotes against the same written scope.
Limits to confirm in your environment before rollout
Client installation options only work as planned when the client packages, the server release, the DNS path and the host's existing identity configuration agree. The cards below list the items to verify on your own hosts and in vendor documentation before you write the install command for a fleet.
ipa-client-install version and options
The options accepted by ipa-client-install differ between package versions and between distributions, so the flags in your runbook must match the version actually installed on each client OS. Run ipa-client-install --help on a representative host from each OS image, record the version, and test the unattended flags (domain, server, realm, and home directory creation) on a throwaway host before you template them into automation. Confirm each option against the packaged man page, not against examples copied from forum posts.
Client OS support for the server release
Your fleet may run client operating systems that the FreeIPA server release does not list as supported for enrollment. Compare each client OS and version against the support statement for the server release you run, and treat anything outside it as a pilot group until the vendor or community documentation confirms the combination. Note that a client that works today can fall out of support when the server is upgraded, so record the pairing alongside your server upgrade plan.
DNS over TLS between clients and IdM DNS
DNS over TLS is a newer feature, and clients need it configured correctly before they can use it. Check whether your server release includes it, whether your clients' SSSD and resolver stack support the setting, and whether your network allows TCP port 853 from client subnets to the IdM DNS servers. Also confirm that your resolv.conf lists at least two DNS servers, as the deployment guidance recommends. Verify name resolution and SRV record lookups from a fresh client before enabling the feature across the fleet.
Time source and NTP settings
Kerberos authentication fails when client and KDC clocks drift apart, so the time source is a hard prerequisite for enrollment. Decide whether clients sync to the IdM servers, to your corporate NTP service, or to another source, and confirm that the chosen option matches the NTP flags your installer version supports. Check that the NTP daemon or chrony service on each image is running before enrollment, because a host that boots with a skewed clock can fail with errors that look like password problems.
Existing SSSD and LDAP configuration
Hosts that were configured earlier with LDAP clients, custom sssd.conf files, or nslcd may already hold settings that conflict with a new enrollment. Inventory /etc/sssd/sssd.conf, /etc/ldap.conf, /etc/nsswitch.conf, and PAM stacks on a sample of hosts from each image, then decide which settings the installer should replace and which you need to remove first. Use the cleanup options in the installer only after you have confirmed what they will delete on your own hosts.
Vendor documentation for the installer
The behavior of ipa-client-install on your distribution depends on the packaged version, the SSSD release, and any local policy, so the authoritative source is the documentation shipped with your own packages. Before you finalize the runbook, confirm the exact behavior of the home directory, DNS update, and cleanup options with your distribution's package documentation and the FreeIPA release notes for your version. Keep a copy of that evidence with the change record for auditors.
How DeployOpen scopes and delivers FreeIPA client installation options
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For FreeIPA client installation, we start from your host inventory, naming and DNS layout, and the install behavior you need, then build and document the enrollment method in your environment.
How we scope
- Inventory the hosts to enroll, their operating systems and the FreeIPA servers and DNS resolvers they will use.
- Decide which ipa-client-install options apply, including home directory creation, DNS updates, NTP settings and realm and server values.
- Record the scope in writing before work starts, since most engagements are fixed-scope with deliverables and timelines agreed up front.
How we build
- Write and test unattended install commands with explicit domain, server and realm values on representative machines first.
- Define a cleanup procedure for old LDAP and SSSD configuration on hosts that were previously joined or configured by hand.
- Test name resolution, Kerberos login, home directory creation and NTP behavior against your own FreeIPA servers before wider rollout.
How we hand over
- Deliver the tested install commands, configuration files and a runbook that names each option chosen and the reason for it.
- Document verification steps so your team can confirm a host is enrolled, resolving and authenticating correctly after installation.
- Walk your operators through the procedure and the known failure points, such as DNS misconfiguration and leftover configuration from earlier installs.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers when your estate changes after handover.
- Retainers can cover review of new client builds, changes to install options and updates when FreeIPA releases affect enrollment.
- Ask us to confirm which support and testing terms apply to your environment in the written scope before any work begins.
