Using FreeIPA Kerberos from systems outside the domain without enrolling them
A build agent or admin laptop often needs FreeIPA Kerberos tickets without becoming an enrolled client. The supported method is a separate krb5 configuration that the external system reads through the KRB5_CONFIG variable. Red Hat's guide for accessing Identity Management services describes the procedure: copy the IdM krb5.conf to a new file name rather than overwriting the existing one, point KRB5_CONFIG at that copy, and also copy the snippets from /etc/krb5.conf.d/ so that any settings split into those files are carried over. The result is a host that can request tickets for IdM principals while its own system configuration stays untouched.
This approach does not change the host's status. The machine is still unenrolled, so it has no SSSD, no host object in IdM, and no HBAC or sudo rules applied to it. The owner of the external system still has to solve two dependencies that Kerberos imposes. First, DNS: the client must resolve the IdM servers and the realm's service records correctly, so confirm which resolver the build agent uses and that it returns IdM answers for the realm, following the DNS design in your own environment. Second, time: Red Hat's IdM installation guide states that Kerberos fails when a client's clock differs from the KDC's by more than five minutes, so confirm that NTP is running on the agent and on any laptop before troubleshooting authentication errors.
Before rolling this out, decide which principals the external systems may hold, who copies and refreshes the configuration when IdM changes, and how keytabs for unattended agents are stored and rotated. Ask your team to test a ticket request from the agent with kinit and a klist check, and to confirm the clock offset as part of the same test. The configuration copy must be updated whenever the IdM krb5.conf changes, so record that step in the runbook.
What an external machine needs before it can get a ticket
An external machine only obtains a Kerberos ticket when four things line up: the right krb5 configuration, a route to the KDC, a clock inside the tolerance Kerberos allows, and a principal that IdM recognizes. Each card below is one of those prerequisites, with the check to run before you troubleshoot anything else.
A separate IdM krb5 configuration
Copy the IdM krb5.conf to its own file rather than overwriting the system file on the external machine, so local settings and other realms keep working. Point the KRB5_CONFIG variable at that copy in the shell or tool that needs the ticket. Confirm the file names and paths your IdM server version uses, because the copy process depends on the release and distribution in your environment.
Krb5 snippets from the drop-in directory
The IdM configuration may depend on snippets stored in /etc/krb5.conf.d/, and a copied main file alone can leave out settings that the realm expects. Copy the snippet files along with the main configuration, and keep their names so they load in the same order. Ask your IdM administrator which snippets the realm publishes before you assume the set is complete.
Reachable KDC and IdM DNS
Kerberos clients locate the KDC through DNS and the configuration, so the external machine must resolve the IdM server names and reach the KDC port on them. Test name resolution for the IdM servers from that machine before testing authentication, and confirm that a firewall or VPN rule allows the traffic. Ask your network team which DNS servers answer for the IdM domain when the machine sits outside your internal network.
Clock within five minutes
Kerberos fails when the client clock differs from the KDC clock by more than five minutes. Build agents and ephemeral containers often run without a dependable time source, so their clocks drift or reset. Run an NTP client on the external machine and check the offset against the IdM servers before you blame credentials.
A valid user principal
The ticket request succeeds only for a principal that exists in IdM, is enabled, and has credentials the account can use. A service account used by a build agent needs its own principal and a keytab, not a shared personal login. Confirm with your IdM administrator that the account is active and that the realm name in the request matches the realm in the copied configuration.
Version and guide applicability
The Red Hat guides cited here target RHEL 9, so confirm that your IdM server version and client platform behave the same way before you copy the steps. Ask your IdM administrator for the server version and check the release notes for changes to Kerberos or DNS behavior. Treat any difference as a reason to test on a non-production external machine first.
How to set up KRB5_CONFIG on an unenrolled host
This sequence gives an unenrolled machine its own Kerberos configuration that points at your IdM realm, so tools can obtain and check tickets without changing the host's existing krb5 setup. Each step ends with a check you can run before moving on.
Fetch the IdM krb5.conf from an enrolled host
Someone with access to an enrolled IdM client or server copies the file
/etc/krb5.conffrom that machine to the unenrolled host, using a channel your security team approves. Confirm the copy by opening the file and checking that the default realm and KDC entries match your IdM realm and servers. Do not edit the file on the enrolled host, because it governs that machine's own logins.Save the configuration under a new file name
On the unenrolled host, save the copied file as a separate name such as
/etc/krb5.idm.confinstead of writing over/etc/krb5.conf. This keeps any existing Kerberos settings for other realms or services intact. Confirm the file exists and that/etc/krb5.confstill has its original contents, checking with a diff or a hash if the host had a previous configuration.Copy the snippets from krb5.conf.d
Copy every file under
/etc/krb5.conf.d/from the enrolled host into the same directory on the unenrolled host, keeping file names unchanged. The snippets hold settings that the main file includes, so missing ones can cause lookups to fail in ways that look like password errors. Confirm the directory contents match the source by comparing file names and sizes, and review each snippet for host names that are specific to the source machine.Point KRB5_CONFIG at the new file
Export the variable in the shell or the job environment that will run Kerberos tools, for example with
export KRB5_CONFIG=/etc/krb5.idm.conf. For build agents, set the variable in the service or runner definition so every job inherits it. Confirm the setting withecho $KRB5_CONFIGin the same session that will run the tests. Note that the variable applies only to processes that read it, so check each tool you intend to use.Obtain a ticket with kinit
Run
kinitwith a test principal that exists in your IdM realm and has a known password or credential, and enter the password when prompted. A successful run returns to the prompt without an error. If it fails, check the clock and DNS resolution first, because Kerberos depends on both. Record the principal name used so the test can be repeated later.Confirm the ticket with klist
Run
klistin the same environment and confirm that the output lists the test principal, the realm you expect, and a ticket-granting ticket with a valid expiry time. Also confirm that the service name shows the krbtgt principal for your IdM realm. Ifklistreads a different cache or realm, the variable is not reaching the process, so return to the previous step. Runkdestroyafterward if the test ticket should not remain on the host.
Why DNS and clock drift break Kerberos for external systems
Kerberos fails when the client clock differs from the KDC by more than five minutes, according to Red Hat's IdM installation guide. An external machine cannot be relied on to keep time simply because it works for other tasks. Build agents in ephemeral containers, laptops that sleep for days and VMs restored from snapshots are the usual sources of drift. Before any ticket request, check that the machine syncs with an NTP source your organization controls, and confirm with the IdM team which time servers the realm expects. A skewed clock typically shows up as an authentication error that looks like a password or principal problem, so time should be the first thing ruled out.
Name resolution is the second dependency, and it is easy to miss because the external machine does not enroll and does not manage its own DNS entries. Kerberos locates the KDC and kpasswd services through DNS SRV records in the IdM zone, and the [domain] and [realm] mappings in the copied krb5 configuration must match names that resolve from that machine. If the external system sits on a different network segment, it may resolve the IdM servers through a corporate resolver that has no view of the IdM zone. Ask the IdM team to confirm which IdM server hostnames, SRV record names and DNS servers the external system should use, whether those names resolve from the target network, and whether any DNS changes are planned during the period when the system will depend on them.
Changes on the IdM side can break external systems without any change on their side. Server renames, replica retirement, DNS zone edits and a new DNS forwarder can all alter what the SRV records return. Agree with the IdM team on a named owner for these records and a notice period before topology changes, and have the external system's owner rerun a simple kinit test after each one. Record the expected hostnames, realm and time source in the runbook for the external system, so an outage can be checked against a known baseline rather than reconstructed from memory.
Which krb5 settings and snippets map to which IdM values
This table maps each krb5 setting and snippet on an external machine to the IdM value it must match. Read it as a checklist: copy every realm, KDC and admin server value from the target IdM deployment instead of assuming defaults. The main takeaway is that a mismatch in any one of these values, or in the DNS names behind them, causes authentication to fail even when the password is correct.
| Setting or snippet | IdM value it must match | What to check on the external system |
|---|---|---|
| Realm (default_realm) | The Kerberos realm of the IdM deployment, typically the uppercase form of the IdM DNS domain | Copy the value from the IdM server's krb5.conf. Do not derive it from the hostname or the domain of the client machine. |
| KDC entries (realms section) | Hostnames of IdM servers running the KDC for that realm | Use fully qualified names that resolve from the external machine. Confirm each name against the target deployment's current replicas. |
| Admin server entries (realms section) | Hostname of the IdM server handling kadmin and password change requests | Copy the admin server name from the target deployment. Confirm that it is reachable on the required ports from this network. |
| Domain-to-realm mapping (domain_realm section) | The IdM DNS domain mapped to the IdM realm | Confirm the mapping matches the copied file. An incorrect mapping sends lookups to the wrong realm. |
| Snippets in /etc/krb5.conf.d/ | Additional settings shipped with the IdM client configuration, copied from an enrolled IdM host | Copy the snippets along with the main file. Confirm each one against the target deployment, since snippet contents can change between releases. |
| KRB5_CONFIG variable | Path to the separate krb5 file used for IdM, not the system-wide /etc/krb5.conf | Set it in the shell or service environment that runs Kerberos tools. Verify with a test ticket request before relying on it. |
| DNS names for IdM servers | Forward and reverse records for each KDC and admin server name | Confirm resolution from the external machine. Kerberos depends on names matching the configured hosts, so a stale or missing record breaks logins. |
| Clock synchronization (time requirement) | Machine clock within five minutes of the KDC clock, per Red Hat's IdM installation guide | Confirm NTP or chrony is running and synchronized on the external system. Clock drift is a common cause of failures that look like password errors. |
Keeping credentials and tickets safe on machines you do not manage
A machine outside the IdM domain holds Kerberos material that IdM cannot wipe or lock. The cards below cover the decisions that limit what a stolen ticket, copied keytab or misplaced krb5 file can do, and the IdM settings that keep authentication from a host under your control.
Restrict the separate krb5 file
The copied IdM krb5.conf and its snippets describe your realm, KDCs and domain mappings, so they are configuration rather than secrets. Still, keep them readable only by the users and tools that need them, and store them in a location that your configuration management can overwrite. Confirm with your own security baseline whether the file belongs in a managed path or a per-user path, and that no other krb5.conf on the host is silently replaced.
Limit which principals the host can use
A build agent should authenticate as the service or automation principal it needs, not as an administrator who happens to have a password. Create dedicated principals for each external system, grant them only the roles and host access they require, and avoid sharing one personal account across machines. Ask your IdM administrators to confirm which principals are allowed to request tickets from each host before go-live.
Protect the credential cache
A Kerberos ticket cache on an unmanaged laptop or agent is a bearer credential until its lifetime ends, and IdM cannot revoke it from the host. Keep tickets short-lived, destroy them with kdestroy at the end of a job, and avoid world-readable cache locations on shared build hosts. Check where your krb5 configuration places the cache and whether your OS or CI platform clears it between runs.
Avoid keytabs on laptops
A keytab stores long-term keys that never expire on their own, so copying one onto a laptop turns that machine into a permanent credential store. Where an interactive user can type a password to obtain a ticket, that flow is usually the safer choice. Reserve keytabs for unattended services that cannot prompt, store them with restrictive file modes, and plan rotation with your service principal process.
Control hosts and users with access policy
IdM host-based access control rules decide which users may log in to which enrolled hosts, but they apply to enrolled machines and their SSSD and PAM stack. An external system that only authenticates with Kerberos may not pass through that path, so confirm with your IdM team which rules apply to it and which services accept its tickets. Review these rules alongside the principal list whenever a new external system is added.
Check clock and DNS before trusting results
Kerberos fails when a client's clock differs from the KDC's by more than five minutes, and an unmanaged host with drifting time can fail in confusing ways. Equally, the host must resolve the KDC and service names correctly through the DNS servers you list in its resolver configuration. Verify time synchronization and name resolution on each external system as part of its acceptance test.
Why kinit or service access fails on an external system
This table pairs each common failure on an unenrolled machine with its likely cause and the fix to try first. Work down the rows in order, because clock and DNS problems often produce errors that look like password or permission failures. The main takeaway is that most failures trace to time, name resolution or the wrong krb5 file, and only the last row involves IdM access policy.
| Symptom | Likely cause | Fix |
|---|---|---|
| kinit fails with a clock or skew error | The external system's clock differs from the KDC's by more than five minutes, which Red Hat's IdM installation guide says makes Kerberos fail. | Synchronize the machine with an NTP source that the IdM servers also use, then confirm the offset before retrying kinit. |
| Host or service name does not resolve to an IdM server | The machine's resolver does not use IdM DNS, so SRV records and the IdM server hostnames used in the realm cannot be found. | Point the machine's resolver at IdM DNS servers, or add the required records to your local resolver, and confirm each IdM server name resolves forward and in reverse. |
| kinit uses the wrong realm or KDC | KRB5_CONFIG points to a file that is missing the IdM realm or refers to a different realm, so the client contacts an unexpected KDC. | Run echo $KRB5_CONFIG in the same shell you use for kinit, correct the variable, and check that the file names your IdM realm in uppercase. |
| Existing system Kerberos settings stop working after setup | An earlier copy of IdM's krb5.conf overwrote /etc/krb5.conf, which broke other realms or applications on the same host. | Restore the original /etc/krb5.conf from backup, store the IdM file under a separate name, and set KRB5_CONFIG to that file only for the tools that need IdM. |
| Realm is found, but IdM-specific settings or domain mappings are missing | Snippets in /etc/krb5.conf.d/ were not copied with the IdM configuration, so settings the IdM file depends on are absent. | Copy the snippets from /etc/krb5.conf.d/ on an enrolled IdM host into the same path on the external system, as Red Hat's accessing IdM services guide describes. |
| kinit succeeds, but service access is denied | The principal is not allowed by the access rules for that host or service, such as HBAC rules, so authentication works and authorization fails. | Check the user's HBAC rules and group membership for the target service, then ask an IdM administrator to confirm the principal is permitted for that system. |
| Service principal or keytab is rejected | The service principal is not registered for the external host, or the keytab was created for a different hostname or was rotated after it was copied. | Confirm the principal name matches the host's FQDN, retrieve a current keytab, and check that the external host is allowed to use that service. |
Questions teams ask before connecting outside machines to FreeIPA Kerberos
Can our team set up Kerberos on outside machines without a partner?
Yes, for a small number of hosts, a team with Linux administration skills and access to the IdM administrator can usually do it alone. The work is a separate krb5 configuration file, a KRB5_CONFIG variable pointing at it, and copies of the snippets from /etc/krb5.conf.d/. The harder part is agreeing on who owns the DNS records, the clock sources, and the access rules, because those sit with the IdM team. Teams with many build agents, mixed distributions, or strict change control often find the coordination takes longer than the configuration itself.
What makes the effort grow for external Kerberos access?
The main drivers are the number of hosts, how many distributions and krb5 versions they run, who controls DNS, and how well time sync is managed. Each machine needs its own configuration check and a test login. DNS matters because Kerberos depends on resolving the KDC and realm names correctly, so teams that do not own their resolver settings need the network owner involved. Time sync matters because Kerberos fails when a client clock differs from the KDC by more than five minutes, according to Red Hat's IdM installation guide. Access policy, meaning which principals may request tickets from which hosts, adds review work on the IdM side.
What do we need from the IdM team before we start?
Ask the IdM team for a copy of the current krb5.conf from an enrolled client, the realm name, the list of KDC and admin server hostnames, and confirmation that DNS SRV records or explicit entries resolve from the outside machines. You also need a service or user principal for each use case, a decision on keytab handling, and an agreed owner for password or key rotation. Confirm which IdM servers are reachable from the network segment where the build agents run, because firewall rules are often the cause of failed logins.
Is enrolling the host in FreeIPA a better option?
Enrollment is often better when the machine is long-lived, has a stable hostname, and needs host-based access control, SSH key distribution, or sudo rules. Enrollment gives the host its own identity and lets IdM manage its policies, which an external Kerberos setup does not. An external configuration is usually the better fit for ephemeral build agents, contractor laptops, or systems that must not join the domain. Decide this per machine class, and confirm with the IdM team what enrollment would change for the host's access and audit trail.
Which parts of the engagement does a fixed-scope quote usually cover?
A fixed-scope quote should list the hosts or host classes in scope, the distributions and krb5 versions, the configuration and snippet deliverables, the DNS and time checks, the test cases, and the handover documentation. It should also name what is out of scope, such as changes to IdM policy, new principals beyond an agreed number, or enrollment of machines. DeployOpen plans and implements this work in writing before it starts, and the quote follows from that written scope. Ask for the acceptance tests and who performs each one.
What should we ask a partner to confirm before signing?
Ask how they will verify DNS resolution and clock offset from each external host, how they will test a ticket request and a service login, and how the configuration is kept consistent across machines. Ask who owns the IdM-side changes and whether the handover includes a runbook for adding a host later. Confirm the ticket lifetime and renewal behavior your IdM team expects, and whether the work assumes any change to the IdM servers. Request the exact list of deliverables and the sign-off steps in writing.
What goes wrong most often with outside Kerberos clients?
The most common failures are clock drift beyond five minutes, DNS names that resolve to the wrong address or not at all, copied configuration that overwrites an existing /etc/krb5.conf, and firewall rules that block the KDC port. Teams also miss snippets in /etc/krb5.conf.d/, which leaves realm settings incomplete. Build agents that cache tickets across jobs can produce confusing failures when principals or keytabs change. Test each host class against a known principal before it reaches production pipelines.
What DeployOpen confirms before any external Kerberos work starts
Before any external Kerberos work starts, DeployOpen agrees the scope in writing. The agreement names which external systems will get Kerberos tickets, which principals they will use, and which admin or build tasks depend on them. The written scope also states the deliverables, such as a working krb5.conf on each external host, the snippets copied from /etc/krb5.conf.d/, and the test results. Most engagements are fixed-scope, so the client knows what is included before the first host is touched.
Next, DeployOpen confirms the target environment with the client. That means the exact FreeIPA server version, the operating system and SSSD or krb5 packages on the external hosts, and the DNS and time sources those hosts use. Because the release notes for FreeIPA 4.13.4 changed authentication checks, the version in use decides which behavior is tested. The client should confirm the FreeIPA version, the realm name, and whether any server sits behind a load balancer or a separate network segment.
DeployOpen then documents the krb5 files and tests from representative external hosts, not from a single lab machine. The client should expect a written record of the separate krb5 file name, the KRB5_CONFIG setting used by each tool, and the clock and DNS checks run on each host class, such as build agents and admin laptops. Each host class is tested before the work is accepted. Ask for the test cases and the list of hosts they cover, and confirm which ones the client's own team will repeat after handover.
How DeployOpen scopes and supports external Kerberos access
DeployOpen plans and implements FreeIPA on infrastructure you control, including the client-side Kerberos setup that lets build agents and admin laptops authenticate to IdM without being enrolled. Engagements are fixed-scope, with the configuration, time and DNS checks agreed in writing before work starts.
How we scope
- Inventory which external systems need Kerberos tickets, and which services and principals they will reach in FreeIPA
- Confirm how each machine resolves IdM DNS names and whether it can reach the KDC and time sources
- Agree in writing which systems are in scope, who owns each krb5 file, and how access is approved
How we build
- Copy the IdM krb5.conf to a separate file name, leaving any existing system configuration untouched
- Set KRB5_CONFIG on each external system and copy the required snippets from the krb5.conf.d directory
- Test ticket requests from every system class, and confirm clock skew stays within the five-minute tolerance
How we hand over
- Deliver the separate krb5 configuration, environment settings and snippet inventory for each system class
- Document the DNS records, time synchronization checks and the steps to verify a working ticket
- Provide a runbook that explains how to add a new external machine and how to rotate its credentials
How we support
- Review external Kerberos configuration when FreeIPA releases change client or server behavior
- Re-test external systems after clock, DNS or network changes that could break ticket issuance
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
