How FreeIPA OTP tokens add a second factor to Linux logins
If you already run FreeIPA for Kerberos authentication and host identity, a second factor is added on top of the password you already use, and FreeIPA supports this through one-time password tokens. FreeIPA supports two-factor authentication with HOTP (RFC 4226) and TOTP (RFC 6238) tokens, covering software tokens that run in an authenticator app and hardware tokens such as YubiKeys. Each user's token is stored as an entry in the directory, so the OTP check is tied to the same identity that already governs Linux logins, sudo and host access. Teams usually need this when privileged administrators log in to shared servers, when remote access crosses networks they do not fully control, or when a compliance assessor asks how authentication strength is enforced for interactive accounts.
OTP support has boundaries you should plan around. It protects the Kerberos login path that FreeIPA manages, but it does not decide on its own which services must require a second factor, how long a ticket remains acceptable, or whether a stolen password alone is enough to reach a sensitive host. Those choices are made through per-service policy, which is covered elsewhere on this page. OTP also does not replace device management or account lifecycle controls. A token that stays active after an employee leaves is still a valid credential, so token revocation belongs in your offboarding process. Confirm with your own environment whether every client, application and SSH path you use reaches FreeIPA's authentication flow, since some services may still accept passwords through a separate route.
If you already operate a commercial OTP or RADIUS system, FreeIPA can proxy OTP checks to it instead of issuing tokens itself. This matters when you want to move identity to FreeIPA without replacing the token fleet on the same day. Before you choose between native tokens and proxying, list which users, which hardware and which clients are involved, then confirm the exact token types and RADIUS server behavior your vendor supports. The FreeIPA OTP design documentation describes the token model in detail, and it is the natural next read before you write an enrollment plan.
Which OTP configuration fits which rollout
This table compares the OTP options available in FreeIPA, from per-user and global enablement to software apps, HOTP, YubiKeys and RADIUS proxying. Read each row against your user population, your existing OTP estate and your recovery capacity, then choose the combination that matches your rollout stage. The main takeaway is that enablement scope and token type are separate decisions, and the trade-offs of each are different.
| Option | Best fit | Main trade-off |
|---|---|---|
| Per-user OTP enablement | Pilot groups, administrators or a small set of privileged accounts | Users outside the enabled set keep password-only login, so coverage gaps must be tracked |
| Global OTP enablement | Organization-wide rollout once enrollment support and recovery steps are ready | Every account without a token is blocked from password-only sign-in, so enrollment must finish first |
| Software TOTP apps | Large user populations with smartphones and a low budget for hardware | Security depends on the phone, and lost or replaced devices need a re-enrollment path |
| HOTP tokens | Sites that already hold event-based hardware tokens or need counter-based devices | Counter drift can lock tokens out, so resynchronization steps must be documented |
| YubiKey hardware tokens | Privileged users and teams that want a phishing-resistant hardware factor for OTP | Each key is a physical item to issue, track and replace, which adds handling work |
| RADIUS proxying to an existing OTP system | Organizations keeping a commercial or existing OTP service during migration | Two systems must be operated, and FIPS mode and token features depend on the existing server |
Rolling out FreeIPA OTP in a pilot, then widening it
This sequence moves OTP from a lab setup to the whole user base in controlled stages, so each stage has a verified login path and a tested recovery route before the next group is added.
Confirm Kerberos and client prerequisites
The platform team checks that the IPA servers resolve correctly, that Kerberos authentication works for a test account from each client type you support, and that SSSD is running and current on those clients. Confirm the FreeIPA version on every server and replica, since OTP behavior depends on the Kerberos stack. Done means a plain password login succeeds on every representative client, with no errors in the KDC or SSSD logs. If any client fails here, fix it before enabling OTP, because a second factor layered over a broken login path makes the fault harder to find.
Select a pilot group and a recovery owner
Choose a small group of users who can give quick feedback, such as the platform or security team, and include at least one user who relies on a hardware token and one who uses a software app. Name the person who will handle token resets during the pilot and document how a user reports a lost token. Done means the pilot group is written down, each member knows the support contact, and the service desk has a documented reset procedure to follow.
Enable OTP for the pilot users
Enable OTP on the pilot accounts first, either by setting the user-level authentication type or by changing the global setting only after the pilot is verified, depending on how you want the rollout to behave. Confirm the setting on the user entries with the FreeIPA command-line or Web UI and check which authentication types each account now accepts. Done means the pilot accounts show OTP as an accepted method and an account outside the pilot still logs in with its existing method.
Enroll software and hardware tokens
Each pilot user enrolls their own token in the self-service Web UI or with the ipa otptoken-add command, using a TOTP app for software tokens (RFC 6238) or a YubiKey configured for OTP. Record the token type, the owner and the enrollment date in your token register. Done means every pilot user has at least one working token, the token appears under their account, and each user can see a valid code on their device. Ask the vendor or your hardware supplier to confirm the YubiKey OTP configuration before distributing devices.
Verify login on representative clients
Each pilot user logs in on every client type in scope, including console or SSH sessions, desktop login and any service that uses Kerberos, entering the password and the token code as prompted. Test a rejected code and a reused code so you know the server refuses them. Check the KDC and SSSD logs for each attempt. Done means each pilot user has logged in successfully on each client type and the test results are recorded. Any client that fails goes back to step one before wider rollout.
Test token loss and recovery
Simulate a lost token for one pilot account by removing or disabling the token, then run the documented reset and re-enrollment steps through the service desk. Confirm the user can log in again with a newly enrolled token and that the lost token no longer works. Done means the recovery path has been run end to end once and the time it took, and any gaps, are written into the runbook. Do not widen the rollout until the service desk can complete this procedure without help from the platform team.
Widen OTP in controlled groups
Add user groups in batches, starting with a department or site that has a working support contact, and enable OTP for each batch only after the previous batch has logged in cleanly for a period you set. Track enrollment rates, failed logins and support tickets for every batch. Done means each batch has a recorded enrollment and login result, and a global OTP setting is changed only when every account that needs OTP has a token. Ask your implementation partner to confirm the batch size and review gates in the written scope.
Security risks when OTP tokens are enrolled and lost
An OTP token is a second factor only while its secret stays secret and the right person holds the device. The cards below cover where token secrets live, who can change them, how guessing is limited, and what to do with a lost, stolen or shared token.
Token secrets live in the directory
Each HOTP or TOTP token stores a shared secret that the KDC uses to verify codes. Anyone who can read the token entries in the 389 Directory Server backend, or read a backup containing them, can potentially generate valid codes. Treat IPA backups as sensitive material, restrict who can run ipa-backup and where archives are stored, and confirm that token data is covered by the same access controls as other credentials.
Restrict who can add or remove tokens
Enrolling a token is effectively setting a user's second factor, so a helpdesk account that can add tokens can also take over an account it does not own. Review which roles can create, modify and delete OTP tokens, separate enrollment rights from password reset rights where your process allows, and log every token change so that unexpected additions are visible.
Limit guessing against the OTP field
A six-digit code gives an attacker a small search space per time window, so lockout settings matter as much as the token itself. Confirm the lockout thresholds applied to OTP authentication in your deployment, decide whether a failed OTP should lock the account, and make sure lockout behavior is understood by the helpdesk before an incident forces a decision.
Stolen or shared hardware tokens
A YubiKey proves possession of a device, but the device can be lost, lent or borrowed to complete a login for someone else. Ask whether each user is issued a personal token, whether shared desk or service tokens are prohibited, and how a found token is reported. Record which physical token is bound to which account so that revocation targets the correct device.
Apply security releases promptly
FreeIPA 4.13.4, a stabilization release dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. Because these fixes affect the same directory and authentication paths that hold OTP data, plan a security update window on every server and confirm each replica is patched, not only the first server.
Recovering access when a token is lost
The core recovery step for a lost token is to remove its record from FreeIPA and enroll a replacement, so the lost device can no longer produce valid codes. Administrators can delete the token entry with the ipa otptoken-del command or through the Web UI, then the user enrolls a new software token or YubiKey. Decide before the first incident whether a user may sign in with a password alone during the gap until the replacement is enrolled. If your policy allows any temporary exception, confirm how your FreeIPA version handles it and keep the exception short and visible in logs. Also confirm the exact command syntax for your release, since the OTP tools have changed across 4.x versions.
Restrict token deletion and reset to a narrow help desk role rather than to domain administrators. Give that role only the permissions needed to remove and reissue tokens, and do not let it change group membership, password policy or host access in the same workflow. Verify the requester's identity before any reset, using a method that does not depend on the lost device, such as a supervisor confirmation, an in-person check or a callback to a number already on file. Write these rules into the help desk runbook with examples of accepted and rejected requests, so two agents handle the same case the same way. Record each reset with the requester, the approver, the token identifier and the time, so audit reviews can match changes to tickets.
Token records are directory entries, so they replicate across FreeIPA servers like other identity data. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, which means a restore after a bad day can reintroduce deleted tokens or disturb replicas that already hold newer changes. Plan restores around the replica layout, decide which server is restored first and how the others are brought back into agreement, and rehearse the procedure on a non-production copy. Ask your team to confirm the restore steps for your topology against the FreeIPA backup and restore documentation before you need them, and keep the runbook next to the help desk procedure.
Limits to confirm before you commit to OTP
OTP in FreeIPA works well only where the surrounding environment cooperates. The cards below cover the points that most often change the design: which clients you run, how laptops behave offline, how trusts and FIPS mode interact with OTP, which hardware you can buy, and whether an existing OTP system stays in the login path.
Client distribution support
OTP login depends on SSSD and PAM configuration on every Linux client, so the distributions and versions in your fleet determine what you can enroll without custom work. Confirm which client platforms your vendors and internal standards support for FreeIPA enrollment, then test a login with a software token and a hardware token on each one. Pay attention to desktop login managers and remote shells, because each may prompt for the OTP differently.
Offline login behavior
A laptop that cannot reach the IdM servers may not complete an OTP login the same way it does on the network. Ask how cached credentials and the first online login interact with OTP in your SSSD version, and whether users can authenticate for a set period without the servers. Decide in advance how long a user may work offline and who approves exceptions, since this policy shapes the whole rollout.
Interaction with AD trusts
If you run a cross-forest trust with Active Directory, OTP results depend on how Kerberos preauthentication and ticket flags work across the trust. Test an AD user with an OTP requirement before you enable it broadly, and check whether AD-side login paths still succeed when OTP is enforced. Confirm this with your own trust configuration, because mixed environments are where OTP failures are most often discovered late.
FIPS mode constraints
Hosts or servers running in FIPS mode may restrict which OTP algorithms, hashes or token types you can use, and some hardware tokens may not meet your cryptographic module requirements. Ask your security team which algorithms are approved in your FIPS configuration, then confirm the token type and its hash choice work on those hosts. Record the result so that auditors can trace the decision.
Supported token hardware
HOTP and TOTP are standards, but a given YubiKey model, firmware version or software app may handle seeds, counters or time drift differently. Buy a small pilot set of each model you plan to issue, enroll them, and confirm that they authenticate after a server restart and after clock skew. Ask suppliers whether they will replace failed devices and what their lead time is.
RADIUS proxy fit
If an existing OTP or RADIUS system must stay in the login path, FreeIPA can proxy OTP checks to it, but your current token inventory, user assignments and reporting must still map onto that design. List which users stay on the existing system, who owns the RADIUS server, and how you will move users over in stages. Confirm the exact proxy behavior with your vendor and your own test environment before committing.
What buyers ask before hiring help with FreeIPA OTP
What drives the cost of a FreeIPA OTP rollout?
The main cost drivers are the number of users and tokens, the number of client systems that must accept OTP logins, whether an existing RADIUS or OTP system must stay in place, and how the help desk will handle lost tokens. Each adds design, testing and documentation work. Hardware tokens add procurement and distribution effort that software TOTP apps do not. Ask any provider to price each of these items separately in the written scope, so you can see which choices move the quote and which are one-time versus recurring work such as token administration and support retainers.
How long does a FreeIPA OTP pilot usually take?
A pilot length depends on the size of the test group, how many client platforms it covers, and whether an existing OTP system needs to run alongside FreeIPA. No duration is fixed in this page, so ask for a timeline in the written scope that names the pilot users, the clients in test, the enrollment steps and the exit criteria. A pilot that includes a help desk drill for a lost token usually takes longer than one that only checks login, so include that step when you compare proposals.
What does our team need to provide for the engagement?
Expect to provide a named technical owner, access to the FreeIPA servers and test clients in your own environment, a list of user groups that will enroll, and a decision on which services must accept OTP. Your help desk must agree on identity verification before a token is reset, and someone must approve the hardware token purchase if you use YubiKeys. Confirm these inputs in writing, because missing decisions on the help desk process are a common reason pilots stall.
Can our internal engineers set up FreeIPA OTP themselves?
Often yes, if your team already runs FreeIPA and has experience with Kerberos and SSSD. The work is less about the configuration commands and more about deciding policy: which users need OTP, how tokens are enrolled and recovered, and how the change affects existing logins. Internal teams that lack a tested rollback plan or a pilot group should weigh that risk against the cost of a partner. A fixed-scope engagement can cover design and testing while your staff keep operational ownership.
What does a fixed-scope quote for FreeIPA OTP cover?
A fixed-scope quote should list the agreed deliverables in writing before work starts, such as the OTP policy design, the global or per-user enablement plan, the token enrollment procedure, the lost-token recovery runbook, pilot testing and documentation. It should also state what is excluded, for example hardware token procurement, changes to third-party RADIUS systems or support after handover. Ask for each deliverable to name its acceptance check so that scope and completion are easy to verify.
How do existing RADIUS or OTP systems change the work?
If you already run a commercial OTP or RADIUS system, the work grows because FreeIPA can proxy OTP checks to an existing RADIUS server, and that path needs its own configuration, testing and per-user assignment. You also need to decide whether tokens move into FreeIPA or stay where they are during a transition. Ask the provider to confirm how the existing system is integrated, which users stay on it, and who maintains it after the change.
What should we check about lost token recovery before we commit?
Check how your help desk verifies identity, how a replacement token is issued, how the old token is revoked, and how long a user can be locked out. Confirm that administrators can disable a lost token quickly and that the process is documented and tested in the pilot. Ask whether the scope includes a runbook and staff training, since recovery procedures that exist only on paper often fail under real pressure.
How DeployOpen scopes and delivers FreeIPA OTP work
DeployOpen is a Chainscore Labs company that plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including FreeIPA. For OTP work, that means the FreeIPA servers, their replicas, the RADIUS or OTP systems they may proxy to, and the client's cloud accounts, data centers or air-gapped networks stay under the client's control. DeployOpen does not host the identity service or hold the client's token seeds outside that environment. The practical question for a CISO or platform lead is how the work is bounded before it starts, and what is delivered at the end.
Most engagements are fixed-scope. Before any configuration changes, the written scope should name the user populations moving to OTP, whether OTP is enabled per user or globally, which hardware tokens and software authenticators are approved, how enrollment will be run, and the recovery procedure for lost tokens. Ongoing support, upgrades and continuous testing are available as a retainer, which suits teams that will keep adding users, tokens and services after the first rollout. Ask for the deliverables list, the acceptance criteria and the change record format in the quote, and confirm which items recur after go-live.
DeployOpen prepares systems, configuration, procedures and evidence for compliance assessments, such as enrollment records, OTP policy settings and access logs. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination. Teams should confirm with their assessor which artifacts they will accept and how long they must be retained, before the evidence pack is defined. A quote follows from the written scope, and DeployOpen does not publish a price list.
