Offline login with SSSD credential caching: when remote machines must keep working
Laptops and remote servers lose contact with FreeIPA during travel, office network outages and WAN failures, and users still need to sign in. SSSD can cache credentials on the client so a user who has logged in before can authenticate without reaching the server, and that behavior is a deliberate trade-off: the machine keeps working, but it accepts logins that the central directory can no longer check. FreeIPA itself provides the central side of this arrangement through 389 Directory Server for users and groups, the MIT Kerberos KDC for single sign-on, and SSSD on each client, which handles the lookup and caching. Caching is a client-side function of SSSD rather than a separate FreeIPA service, so you should confirm the exact caching behavior for your client release in its SSSD documentation before you design around it.
The decision to make first is which machines and which users need offline logins at all. Shared servers in a data center usually reach their FreeIPA replicas reliably and gain little from a cache, while field laptops for staff who travel gain a lot. Ask your team to list the account types involved, since a cached password for a privileged administrator is a larger exposure than one for a standard user. Also confirm whether your policy allows local cached credentials for each group, because a password that was valid when cached may later be disabled, locked or changed in FreeIPA, and the client will not learn about that until it reconnects. Plan a reconnection check and a way to revoke access on a lost device before rollout.
Which cache and offline settings fit which population
This table compares offline logon choices for three populations: mobile laptop users, fixed datacenter servers and privileged administrators. Read each row as a setting, then check the column for the population it suits. The main takeaway is that offline access should be narrowed for administrators and widened only where the risk of a stale or stolen cache is accepted.
| Setting | Mobile laptops with mobile staff | Fixed datacenter servers | Privileged administrators |
|---|---|---|---|
Offline logon enabled (cache_credentials) | Usually true, so staff can work on planes or in sites without reliable links. Confirm with your risk owner. | Usually false or limited, since servers normally reach IdM over the network. | Usually false for admin accounts, so privileged logons always verify against live IdM. |
Cache expiry (offline_credentials_expiration) | Set a bounded number of days. Confirm the value against your policy and travel patterns. | Not usually relevant, because servers stay connected and cached logons add little. | Keep as short as practical, or disable offline use entirely. Confirm with your security team. |
Allowed users and groups (ldap_pwd_policy and access rules) | Limit to named staff groups, not all directory users. Confirm how your HBAC rules apply offline. | Restrict to local service accounts only if needed. Most logons should still go through IdM. | Exclude from offline use or limit to break-glass accounts with documented handling. |
| OTP login accepted offline | Consider only if your OTP design supports it and tokens are not shared. Confirm with the vendor documentation. | Generally not needed for console or SSH access used from the datacenter network. | Avoid offline OTP for privileged logons. Require a live check at each sign-in. |
Cache timeout for lookups (entry_cache_timeout) | Tune for responsiveness and freshness of group membership changes. Confirm the value in your environment. | Tune for fast lookups and predictable performance across many hosts. | Shorter timeouts help revoked admin rights take effect sooner. Confirm the trade-off with operations. |
| Main risk to accept | Cached credentials on a lost or stolen device, plus stale group membership until reconnection. | Low exposure, but a failed IdM path can block logons if offline access is disabled. | Revoked or changed privilege may persist offline, so keep this population on live checks. |
How OTP logins behave offline and what to test
OTP factors depend on the FreeIPA server for validation, so a machine that is offline cannot check a one-time code the way it checks a cached password. The cards below cover the token types, why offline validation is not possible, the lockout risk, and the test steps to run before you decide which hosts keep offline login.
Supported token types
FreeIPA supports two-factor authentication with HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including software tokens and hardware tokens such as YubiKeys. Both types are validated by the FreeIPA server. Before you plan offline access, confirm which token types your users carry and whether each one can be enrolled and used on the hosts you intend to protect.
Why offline OTP cannot be validated
An OTP check needs the server to confirm the code and update the token state. A host that cannot reach FreeIPA has no way to verify a code, so offline login for OTP users is not a cached-credential case. Treat any offline OTP acceptance as a deliberate exception, and confirm with your own SSSD configuration and tests how a given host responds when the server is unreachable.
Privileged accounts need online checks
For administrators and accounts that reach sudo or sensitive hosts, requiring online authentication is usually the safer position. A stolen laptop with a cached administrator login gives an attacker more reach than a standard user account. Decide which groups must authenticate against the server, then restrict offline login for those hosts or accounts through access rules rather than relying on users to behave.
Lockout and token drift risk
Offline attempts cannot update server-side counters, so a user may be locked out or fall out of sync with a token once the machine reconnects. Ask your team to document how failed attempts are counted during an outage, how token resynchronization is handled, and who resets a locked account. Test this with a deliberately mismatched token before any rollout.
Test offline behavior on each host type
Build a test matrix covering a laptop, a remote server and a host in a branch network. For each, disconnect the network, attempt password and OTP logins, confirm which cached entries are used, and reconnect to observe the sync. Record the results so your decision on each host class rests on observed behavior, not on the documentation alone.
Setting up offline login on enrolled clients
This sequence takes an enrolled Linux client from a working FreeIPA login to a documented offline configuration that has been tested with the network disconnected. Each step ends with a check so the team can show that cached logins, expiry and reconnection behave as the agreed policy says.
Confirm enrollment and SSSD version on each distribution
The platform or client engineer confirms, on every distribution in scope, that the host is enrolled in the intended realm and that SSSD is running and current. Run
ipa-client-install --helponly if you need to review options, then check enrollment withipa host-showfrom an administrator account andidfor a known IPA user on the host. Record the SSSD package version from your package manager, since cache behavior and option names can differ between releases. Confirm the exact client support position for each distribution with the FreeIPA client and server version compatibility guidance before you build the baseline. The step is done when a directory lookup and a Kerberos login succeed on every host in the pilot group.Agree the offline login policy in writing
The security owner and the IAM team decide who may log in offline, on which host classes, and for how long a cached credential remains valid. Laptops, shared servers and jump hosts usually carry different risks, so write a separate row for each class. Include the decision on whether offline logins require a one-time password, which depends on your MFA design and the OTP rules you have configured in FreeIPA. Name the owner who approves exceptions and the process for revoking access from a lost device. The step is done when the signed policy lists hosts, users, cache lifetime and the approver, and a reviewer outside the project has read it.
Configure cache and offline settings in SSSD
The client engineer edits the SSSD configuration on a pilot host, normally
/etc/sssd/sssd.conf, and sets the cache and domain options that match the agreed policy. Review the credential cache options in the SSSD manual for your installed version before choosing values, because option names and defaults are version-specific. Apply the same file through your configuration management tool so every host in a class gets identical settings. Restart SSSD and confirm the file parses with a clean service start in the system journal. The step is done when the pilot host starts SSSD without errors and the settings match the signed policy line for line.Prime the cache with a successful online login
Before testing offline behavior, the engineer logs in as each test user while the host can reach the FreeIPA servers, so SSSD stores that user's credentials and group memberships. Use an account that represents each access class in the policy, including a user who is a member of a restricted group. Confirm the cache is populated with
sssctl user-showfor each test user, and check thatsssctl domain-statusreports the domain as online. The step is done when every test user appears in the cache with the expected groups and the domain status is online.Test offline login with the network disconnected
The tester disconnects the pilot host from the network, using the physical interface or a firewall rule that blocks traffic to the FreeIPA servers and DNS, then attempts a console or SSH login with each test user. Record which logins succeed, which fail, and the exact message SSSD writes, both on the console and in the journal. Confirm that
sssctl domain-statusreports the domain as offline, and that users outside the policy are refused. Repeat the test for every host class in scope. The step is done when the results match the policy table, and any unexpected result has a logged cause and a fix or an accepted exception.Verify cache expiry and reconnection behavior
The tester checks what happens after the cache lifetime in the policy has passed, and what happens when the network returns. Use a test window that reflects the configured setting, and do not rely on a default value without confirming it in your SSSD version. Attempt a login after expiry while the host is still offline, then restore connectivity and confirm SSSD returns to the online state and accepts a fresh login. Check that a credential revoked in FreeIPA stops working after the host reconnects. The step is done when expired credentials are refused offline, revocation takes effect after reconnection, and the results are logged with timestamps.
Record the configuration and set a review date
The engineer records the final configuration, the policy version, the test results and the distribution and SSSD versions in the team's configuration repository and change record. Include the exact settings applied to each host class, the test accounts used, the disconnected test evidence and the named approver. Ask the security owner to set a review date, and tie it to any FreeIPA upgrade or SSSD package change, since those can alter cache behavior. The step is done when another engineer can rebuild the host class from the record and repeat the disconnected test with the same results.
Security trade-offs of caching credentials on endpoints
Caching lets a laptop or server log in when FreeIPA is unreachable, but the cached material then lives on the endpoint and outlives changes made in the directory. The cards below cover what an attacker or a stale cache can reach, and which server-side and policy controls limit that exposure.
Cached material on stolen laptops
A laptop that leaves the building may carry cached verifiers for every user who logged in while it was connected. Offline login means an attacker with local access can attempt guesses without contacting the server, so the number of users cached on each machine matters. Ask whether disk encryption is enforced on every endpoint and whether shared or kiosk machines are allowed to cache domain accounts at all.
Stale access after disablement
When an account is disabled or a user leaves, the change lands in FreeIPA, but a cached endpoint may still accept that user until the cache is refreshed or expires. Test the full path: disable an account, then confirm how long an offline laptop keeps accepting it. Document who owns that gap and which cache lifetime the business accepts for leavers.
Cache lifetime as a risk dial
The longer credentials remain cached, the longer a revoked or stolen identity stays usable on the endpoint. Shorter lifetimes reduce exposure but increase failures for users who work offline for days. Set the value per host class, such as laptops versus servers, and record the chosen setting as a documented decision rather than a default left in place.
Host compromise exposes cached data
An attacker with root on a host can read whatever SSSD keeps locally, so the cache adds to the impact of a host breach rather than standing apart from it. Limit which users may log in offline, apply host access rules, and treat cached entries as sensitive when you decide what a server should store.
Interaction with password and lockout policy
Offline logins are checked against the cache, so server-side lockout counters do not see failed local attempts. Review the FreeIPA password policy and lockout settings alongside the offline design, and confirm with your security team whether local failures should be logged, alerted on or limited by endpoint controls.
Server patch level and related controls
The FreeIPA 4.13.4 security release fixed LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API, so server patch level matters for any caching design that depends on the directory. Confirm your servers run a current release. The FreeIPA security hardening and MFA topics cover the server-side controls that complement endpoint caching.
Operating offline login after rollout
Offline login stays safe only if someone checks it on a schedule. The first routine is an inventory: keep a record of which hosts and laptops have offline caching enabled, which SSSD configuration each one carries, and which group or host class it belongs to. Confirm this inventory against what FreeIPA reports for enrolled hosts, since a machine that was reimaged or re-enrolled may still hold an old cache policy. Whenever you change cache lifetimes or offline OTP rules in a policy, treat that change as a rollout with its own check, because an existing laptop keeps the settings it last received until SSSD picks up the new configuration. Confirm with your own test hosts how and when SSSD applies a changed setting before you assume a fleet-wide effect.
The harder case is an offboarded user whose laptop has been offline. Disabling the account in FreeIPA stops new logins once the host reconnects, but a cached credential can still open the machine while it stays disconnected. Your offboarding runbook should therefore include the endpoint: lock or wipe the device, remove the user from host access rules, and clear cached entries on servers where the user had access. Rotating or resetting OTP tokens for a user follows the same logic. A token that was reset in FreeIPA may still validate against a cached verifier on a host that has not reconnected, so decide in advance how quickly high-risk hosts must reconnect and how you will verify it. Test the offline path after every SSSD, distribution or FreeIPA client upgrade, and record the result. Topology changes deserve their own check. If you add, remove or move FreeIPA servers, or change the DNS and discovery settings clients rely on, hosts may take longer to reconnect or fail to find a server, and their cache behaves differently during that gap. Restoring a FreeIPA server from backup does not restore client caches, so a host that cached credentials before an incident keeps those entries until it talks to a healthy server again. Plan restore drills so that you confirm, on a sample of clients, how reconnection and cache refresh behave, and confirm the exact recovery steps with your own environment and vendor documentation.
What to confirm for your estate before enabling offline login
Which distributions and SSSD versions support offline login for my fleet?
Confirm the exact distribution release and SSSD package version on each client class before you enable caching, because offline behavior depends on the SSSD build and not only on the FreeIPA server version. Ask your distribution vendor or check the packaged SSSD release notes for the cache and offline options you plan to set. Then test one machine from each class: a current laptop image, a long-lived server and any non-RHEL client. Record the results in your own test environment, since support position for non-RHEL clients is a separate question to settle with your vendor or with DeployOpen before rollout.
How does offline login behave for each account type on my hosts?
Test each account type separately: regular user accounts, service or system accounts, administrator accounts with sudo rights and any accounts created locally on the host. Cached credentials usually apply to directory-backed users who have logged in before, so a user who never authenticated on that machine may have no usable offline path. Confirm with a test that a first-time login fails cleanly when the server is unreachable, and that cached sudo and access rules behave as your policy expects. Write down which accounts you expect to work offline so reviewers can compare the result against that list.
Does offline OTP work with the tokens my users carry?
Confirm this for your own token mix before you promise offline OTP to users. FreeIPA supports HOTP and TOTP tokens, including software tokens and hardware tokens such as YubiKeys, and can proxy OTP checks to a RADIUS server, according to the FreeIPA OTP design page. Offline use of each token type depends on whether the client can verify it without contacting the server, and that behavior is something to test rather than assume. Check the OTP design page and your SSSD version notes, then run a login test with each token type while the server is blocked from the client network.
Where are cached credentials stored on laptops, and are they encrypted?
Identify the cache file location and its protection on every device class before enabling caching. SSSD keeps its cache in its own data directory on disk, and the protection you get depends on whether the laptop uses full-disk encryption, how file permissions are set and who has administrative access to the machine. Confirm with your endpoint team that disk encryption is enforced by policy, that the cache directory has restrictive permissions, and that removing a device or a user's access clears or invalidates the cached material. Verify these settings on a test image rather than relying on defaults.
Do my regulations restrict storing login credentials on local devices?
Ask your compliance lead and your regulator or assessor whether any rule limits local storage of authentication material, password hashes or Kerberos tickets on endpoints. Requirements vary by sector and by the framework you are assessed against, so the answer must come from the rule itself and from your assessor, not from a general statement. If caching is restricted, you may need to limit offline login to specific device classes, shorten retention or disable it for privileged accounts. Document the decision and the evidence that supports it, since DeployOpen prepares controls and evidence for assessments but does not issue audit findings.
How long should cached credentials stay valid, and who sets that limit?
Set the cache lifetime as a documented policy decision, owned by your security team, and confirm that the SSSD setting you choose enforces it on your versions. The right value depends on how long a laptop may be offline, how quickly you must revoke access after an offboarding event and what your assessors expect. Test revocation: disable a test account on the server, keep the client offline and confirm what still works and for how long. Record the setting, the test result and the review date in your change records.
What does it cost to test and roll out offline login, and who pays for it?
Cost depends on the number of device classes, the token mix, the regulatory review and whether your own staff run the test matrix. Your internal cost covers identity engineers, endpoint administrators, a test lab and time for compliance review. If you engage DeployOpen, the work is quoted from a written scope that lists the distributions, account types and token types to test and the deliverables such as cache settings and a runbook. DeployOpen does not publish prices. Ask any partner for the test matrix, the number of devices covered and what recurs after rollout, such as re-testing on each distribution upgrade.
Can my own team run the offline login tests without outside help?
Yes, if you have a test environment that can isolate a client from the FreeIPA servers and enough engineering time to run the matrix. The tests are repeatable: block the server network, attempt logins for each account and token type, verify the cache location and check revocation timing. The skills needed are FreeIPA administration, SSSD configuration, endpoint management and a clear test plan agreed with your security owner. If these are scarce on your team, a fixed-scope engagement can cover the matrix and the runbook, and DeployOpen can also support the testing as a retainer if you want continuous checks after upgrades.
How DeployOpen scopes offline login work for FreeIPA estates
Offline login for a FreeIPA estate starts with a written scope agreed before any client is changed. DeployOpen sets out which machine groups will cache credentials, which distributions and SSSD versions are in the estate, which users may log in while the FreeIPA servers are unreachable, and which services (SSH, console, display manager, sudo) the offline behavior must cover. The scope also states what is out of bounds, such as offline login for privileged administrator accounts or for hosts that hold regulated data. The written scope is the basis for the quote, so the client can see what is included before work begins. Ask the proposal to name the SSSD settings it will change, the files it will touch and the evidence it will produce at the end.
Testing is planned per distribution, because the same SSSD cache and PAM settings can behave differently across RHEL, Ubuntu and Debian and across their supported SSSD versions. A test plan for each distribution should cover a first login that populates the cache, a login with the FreeIPA servers blocked at the network layer, a login after the cached password or OTP has been changed on the server, and a login after the cache has expired. Each test should record the sssd.conf values in effect, the time window the client was offline and the result in the audit log. Ask for the test matrix in the scope document and confirm that the client's own pilot hosts will be used for the final run, not only a lab image.
Runbooks and optional retainer support turn the design into something the client's operations team can run. Runbooks cover how to change cache settings across the estate, how to revoke cached access for a departed user, how to recover a host whose cache is corrupted and how to verify offline behavior after a SSSD or distribution update. DeployOpen can deliver these as documents inside the client's own repository. Ongoing support, retesting after upgrades and periodic review of cache settings are available as a retainer, and the terms, response expectations and fees are agreed in writing. Work is carried out in the client's own infrastructure, and DeployOpen prepares controls and evidence for assessments without issuing audit reports or certifications.
