Keeping your current OTP system while moving identity to FreeIPA
FreeIPA can proxy OTP checks to an existing RADIUS server, so an established commercial OTP or RADIUS service can keep validating one-time codes while identity, Kerberos tickets and host access move to FreeIPA. Teams need this when the OTP platform is tied to VPN concentrators, network devices, hardware tokens already issued to staff, or compliance evidence that cannot be rebuilt in a single change window. Native HOTP and TOTP tokens in FreeIPA are the simpler path when no existing OTP investment has to be preserved, because FreeIPA then stores and checks the tokens itself.
The decision starts with an inventory. List every application, gateway and user population that depends on the current OTP system, and note which ones authenticate through RADIUS and which use vendor-specific agents or APIs. Confirm with your OTP vendor whether its RADIUS service accepts requests from a new source host, which shared secrets and attributes it expects, and whether it supports the challenge-response flow your clients use. Also confirm whether tokens are stored in the vendor system or can be imported. DeployOpen plans and implements this proxy configuration inside your own infrastructure, so the design can be checked against your network zones and change-control rules before any user is moved.
Per-user assignment is what makes the migration gradual. Only accounts you select are sent to the RADIUS proxy, while the rest keep their current OTP method or none. Plan the assignment groups, the fallback behavior if the external server is unreachable, and the test accounts used to prove each step. Those decisions determine how long the old and new systems run side by side, and they should be written down before the first user changes.
Which FreeIPA OTP path fits your current system
This table compares native FreeIPA OTP tokens (HOTP and TOTP, software and hardware) with proxying OTP checks to an existing RADIUS server. Read each row against your current token inventory, your RADIUS vendor's behavior and the timeline for moving users, then use the rows that matter most to choose a path or a combination.
| Question | Native FreeIPA OTP | RADIUS proxy to existing OTP system |
|---|---|---|
| When it fits | New or greenfield two-factor rollout where FreeIPA will own token enrollment and policy | An existing commercial OTP or RADIUS system must stay in service during a gradual move |
| Token types | HOTP and TOTP software tokens and hardware tokens such as YubiKeys | Whatever token types the existing system supports, as confirmed with its vendor |
| What moves to FreeIPA | Users, token records and OTP enrollment are managed in FreeIPA | User identity and Kerberos login start in FreeIPA; OTP verification stays with the existing server |
| What stays where it is | Nothing external is required for OTP checks | Token database, enrollment tools and OTP verification remain in the existing system |
| Per-user assignment | Enable OTP for individual users or globally, as set in FreeIPA | Route only selected users to the proxy, which needs a per-user configuration plan |
| Ongoing dependency | FreeIPA servers hold the OTP data and must be backed up with the rest of identity | Login depends on both FreeIPA and the RADIUS server being reachable |
| Vendor-specific behavior | Documented in the FreeIPA OTP design | Confirm response handling, challenge flows and token types with your RADIUS vendor before cutover |
| Exit path | Migrating OTP tokens to another FreeIPA deployment is supported by ipa-migrate | Plan how tokens and enrollments are retired when the existing system is decommissioned |
How the RADIUS proxy handles per-user OTP checks
FreeIPA does not check the one-time password itself when a user is routed to an existing system. It hands the OTP verification to a RADIUS server you configure, and the decision about which users take that path is made per user. The proxy is set up as a RADIUS proxy configuration object in FreeIPA, and the user entry is then linked to it. Users without that link continue to authenticate against FreeIPA's native HOTP and TOTP tokens. This means one identity domain can run two OTP sources at once, which is the basis for a gradual migration. Confirm with your FreeIPA version's documentation the exact command names and object attributes, since the proxy configuration and assignment steps are not detailed in the facts available here.
Before any user is assigned, confirm what the RADIUS server must accept from FreeIPA. The items to verify are the shared secret that both sides hold, the network path from the FreeIPA servers to the RADIUS listener (including any firewall rules between the IdM replicas and the RADIUS host), and the service account or client entry the RADIUS system expects for FreeIPA as a caller. Check that each FreeIPA server that can receive a login is able to reach the RADIUS server, not only the first server, because a replica that cannot reach it will fail OTP checks for the users routed there. Ask your existing OTP vendor which port, protocol variant and attribute handling it supports, and test the path from every replica before you assign production users.
Plan the assignment list as a controlled change. Start with a small group of accounts that the RADIUS system already serves, record which users are linked to the proxy, and keep a rollback path that returns a user to native tokens. Watch for users who hold both an existing commercial token and a FreeIPA token, since the authentication outcome must be predictable for them. Also verify that the OTP checks you rely on are still enforced after a Kerberos ticket is issued, because the second factor must sit inside the same authentication flow your services expect. Record every routing change, because a user missing from the proxy list may silently fall back to a different second factor.
How to configure the RADIUS proxy step by step
This sequence moves users from an existing OTP system to FreeIPA one pilot group at a time, so each stage is proven with a real Kerberos login before more accounts depend on it. Each step closes with a check that tells you whether to continue.
Inventory current OTP users and tokens
Before changing anything, list every account that signs in with a one-time password today, the token type each one uses (software app, hardware key or SMS if your system supports it), and the services that depend on that second factor. Record which accounts also exist in FreeIPA, because a user must exist in FreeIPA before any proxied check can apply to them. Ask your current OTP vendor how tokens are stored and whether seeds can be exported. Done means you have a reconciled list of users, token types and dependent services, signed off by the owners of those services.
Confirm the RADIUS server's supported behavior
Read your existing RADIUS or OTP vendor's documentation and confirm the points that determine the proxy design: the authentication protocols it accepts, how it expects the password and OTP to be sent together or separately, the shared secret handling, which client addresses it will accept requests from, and how it responds to a rejected or timed-out request. Confirm with the vendor whether it runs in a FIPS mode and what that mode restricts. Done means you have a written list of answers, and any gap, such as a required password format FreeIPA cannot send, is resolved or accepted before configuration begins.
Configure the RADIUS proxy for a pilot group
On the FreeIPA server, define the RADIUS proxy server with the connection details and shared secret your team confirmed in the previous step, then create a small pilot group in FreeIPA and assign OTP authentication to those users only, rather than enabling it for the whole directory. Keep the global OTP setting unchanged so that every other account continues to authenticate exactly as before. Done means the proxy definition exists, the pilot group is the only population with the proxied OTP setting, and you can list that configuration back from FreeIPA to confirm it was saved.
Test a Kerberos login with OTP end to end
Have a pilot user sign in from a enrolled Linux client using Kerberos with the password and the current one-time code, and confirm that the ticket is issued only after the RADIUS server accepts the code. Repeat with a wrong code and with an expired code to confirm that access is denied and that the failure appears in the FreeIPA and RADIUS logs. Also test a user outside the pilot group to confirm the old behavior is unchanged. Done means the successful login, both failure cases and the unchanged control account all match what you expected, and the test results are recorded.
Confirm failover and lockout behavior
Stop or block access to the RADIUS server in a controlled test window and observe what a pilot user sees: whether the login fails cleanly, how long it takes, and whether any account lockout counter moves. Check that the FreeIPA password policy and the RADIUS server's own lockout rules do not conflict in a way that locks out legitimate users. Restore connectivity and confirm logins recover without a restart. Done means you have a documented behavior for an outage, and the operations team has agreed how it will respond.
Extend assignment in stages
Add users to the proxied OTP setting in groups, not in one step, and run the same login checks from the previous steps on each new group before adding the next. Track the number of users on each stage and keep a rollback path in which a group can be removed from the proxied setting if a problem appears. Confirm that each token enrollment and reset flow still works for the new users. Done means every group has passed the login checks, rollback has been tested once, and the remaining users are either migrated or listed with a documented reason for staying on the old system.
Retire the old path only after proof
Once all intended users authenticate through FreeIPA with the proxy, review the old OTP system's logs for a period your security team sets, looking for any remaining authentication that bypasses FreeIPA. Only then plan the decommissioning of the old RADIUS or OTP service, including how its audit records will be kept for your retention obligations. Ask your compliance lead which records must be preserved and in what form before deletion. Done means no unexpected authentications appear in the old logs and the retention decision is written down.
FIPS limits to check before you commit
FIPS mode can change which cryptographic paths a proxied OTP check may use, and it can apply to the FreeIPA servers, the RADIUS server and the link between them. The cards below list the points to settle with your FIPS owner and each vendor before you choose a proxy design.
HMAC and hash support for OTP
HOTP and TOTP tokens rely on HMAC constructions defined in the RFC specifications that FreeIPA implements. Ask which HMAC and hash implementations your FIPS module exposes to the OTP validation code on each server that checks tokens, and whether any proxied step uses a different library. Mismatches like this tend to surface only at login time, so confirm the exact algorithms for each token type you plan to enroll and record the answer per token type.
FreeIPA servers in FIPS mode
Decide whether the IdM servers themselves run in FIPS mode before you add a proxy, because the proxy path runs through Kerberos, LDAP and certificate services on those hosts. Confirm the server mode with the FIPS owner, and check whether your chosen FreeIPA release and platform support it for the components you use. Then verify that OTP enrollment, Kerberos authentication and client login all succeed on a test replica. Do not assume the proxy behaves the same on a FIPS host as on a standard one.
External RADIUS server validation
The commercial OTP or RADIUS system sits outside FreeIPA's control, so its cryptographic status is a separate question. Ask the vendor for the FIPS validation references that apply to the exact product version and mode you will run, and whether those references cover the OTP verification function rather than only the general platform. Keep the references with the change record. If the vendor cannot name a version and mode, treat the proxy as unconfirmed until your FIPS owner accepts it.
RADIUS transport and shared secrets
The link between FreeIPA and the RADIUS server carries every OTP request. In its base form, RADIUS protects packet authenticity and attribute hiding with MD5 and a shared secret. Ask your FIPS owner whether that protection is acceptable, or whether the link must run over a protected network segment or a transport the RADIUS server supports. Confirm the secret length, storage location and rotation process too, since a weak secret undermines any cryptographic assurance.
Test matrix on a FIPS host
Build the test on a non-production FIPS host that matches production. Cover each OTP token type you will allow, a successful and a failed proxy check, RADIUS server failover, lockout after repeated failures, and a login from a client that cannot reach the RADIUS server. Record the FIPS mode, package versions and RADIUS product version used, because a later patch to any of them can change the result. Repeat the matrix after every security update.
Evidence for the change record
Auditors and internal reviewers will ask how the proxy path was approved, so assemble the evidence before rollout. Keep the vendor validation references, the FreeIPA and client versions, the proxy configuration, the test results and the FIPS owner's sign-off in one record. Agree in writing who signs off, and which changes trigger a new review, such as a server upgrade or a change to the RADIUS product. Ask that this evidence be named as a deliverable in any written scope.
A gradual migration path from the existing OTP system
The safest way to leave an existing OTP system is to run both systems side by side and move users in cohorts, so that every change can be reversed before the old system is retired. Start by putting FreeIPA in front of the current RADIUS server through its OTP proxy configuration, so that users keep their existing tokens and login flow while FreeIPA becomes the place where authentication decisions are made. Assign a small pilot cohort first, for example a group of administrators, and confirm that the per-user assignment works as intended for both the proxied and the native FreeIPA token paths. Keep the list of migrated users in a FreeIPA group so the scope of each phase is auditable.
Before any phase change, take a backup with ipa-backup. The FreeIPA backup documentation warns that the first server handles certificate renewal and CRL publication by default, and that restoring an outdated backup into an active replica topology can break replication. Plan for this by treating backups as a gate in every change window, by recording which server holds each role, and by agreeing with your operations team who is allowed to run a restore. Confirm with your platform team how replicas in each datacenter are currently configured before you start, because a restore decision depends on that layout, not just on the backup file.
Move token enrollment to FreeIPA only after the pilot cohort has used FreeIPA-issued tokens through a full cycle, including a lost token replacement. Retire the old OTP system last, and only after you have run the recovery procedures for lost tokens, locked accounts and a failed server in a test environment and recorded the results. Ask your own team and any partner to confirm the exact recovery steps for the proxied configuration, because the vendor and version of your existing RADIUS server determine what can be exported and what must be re-enrolled. Keep the old system read-only for a defined period so that you can compare authentication logs against the new path before decommissioning.
Security and operational risks of a RADIUS proxy
A RADIUS proxy puts FreeIPA and your existing OTP system in the same login path, so each link becomes a place where credentials, logs or availability can fail. The cards below cover the risks to plan for before you point production logins at the proxy.
Shared secret handling
The FreeIPA server and the existing RADIUS server authenticate each other with a shared secret. Anyone who reads that secret can impersonate either side or inspect traffic between them. Confirm where the secret is stored, who can read it, how it is rotated, and that it is set identically on both ends. Treat it as a credential with an owner and a rotation procedure, not as a configuration detail.
One external dependency for login
Once the proxy is in place, password-plus-OTP logins for affected users depend on the external OTP system being reachable and responsive. A slow or unreachable RADIUS server can delay or block sign-in even when FreeIPA itself is healthy. Map which accounts, services and hosts take this path, and document who owns the external system and how its outages are reported to the identity team.
Audit trail across two systems
A failed or successful OTP check now leaves records in two places: the RADIUS server and FreeIPA, Kerberos and SSSD logs on the client. Investigators need to correlate them by username, time and source host. Decide which system is the authoritative record for each event, agree on time synchronization across all of them, and confirm that log retention in the external system meets your own policy.
Replica and backup coverage
The external OTP system and its configuration are outside FreeIPA's backup scope, so they need their own backup and restore plan. On the FreeIPA side, the backup guidance warns that restoring an outdated backup into an active replica topology can break replication, and that the first server handles certificate renewal and CRL publication by default. Test restores of both sides together, and confirm which replica the proxy settings point to after a failover.
Keeping the proxy path available
A proxy path that works only in normal conditions gives little protection during an outage. Decide in advance whether affected users wait for the external system, whether any emergency access exists, and who may approve a temporary change. Test the failure case by stopping the RADIUS service in a non-production environment and confirming that the behavior matches the documented procedure. Write that procedure before go-live.
Questions buyers ask before a RADIUS proxy project
What drives the cost of a FreeIPA RADIUS proxy project?
The largest drivers are the number of users and devices that authenticate through the existing OTP system, the mix of token types (software TOTP, HOTP and hardware tokens), whether FIPS mode applies to any part of the estate, and how much the current OTP or RADIUS vendor cooperates. Each driver changes the amount of configuration, testing and coordination needed. Cost has two parts: one-time work to design, configure, test and cut over, and any recurring support you buy afterward. Ask for a quote that lists each driver as a separate line item so you can see which assumption moves the price.
How long does a gradual migration from an OTP system to FreeIPA take?
Duration depends on the number of user groups, how many applications and VPN or network devices send RADIUS requests, how many tokens must be moved or re-enrolled, and how long your change process takes for each cutover wave. Vendor constraints on exporting token seeds or on changing the RADIUS server address can also add time. Because the proxy lets you move users in batches, the timeline is usually set by the slowest application group rather than by the technical configuration itself. Ask for a plan that splits the work into waves and names the approvals each wave needs.
What does our team need to provide for the engagement?
You will need to provide an inventory of RADIUS clients and the applications behind them, a list of user populations and their current token types, access to the existing OTP system's configuration and logs, and a named owner for each application that will change its RADIUS target. Your network or platform team must allow the FreeIPA servers to reach the existing RADIUS server, and your security team should confirm the FIPS and audit requirements that apply. Early decisions on help desk procedures for lost tokens also reduce rework during cutover.
Can our internal team run a RADIUS proxy migration without a partner?
Yes, if your team already operates FreeIPA and the existing OTP system, has staff who understand RADIUS and Kerberos, and can run test and rollback exercises. The work is manageable for a team with that experience, but it still needs planned testing across each client type and a clear rollback path. A partner adds the most value when the team lacks FreeIPA or RADIUS depth, when several vendors and application groups must be coordinated, or when the migration must be documented for auditors. Confirm the skills your staff have before deciding.
How do we ask for a fixed-scope quote for this work?
Send a written scope that lists the RADIUS clients in scope, the user and token populations, the FIPS or other compliance requirements, the number of cutover waves, the systems you will provide access to, and the deliverables you expect, such as configuration, runbooks and test records. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and the quote follows from that written scope. Ask the provider to state what is excluded, such as vendor license changes, token hardware purchases or changes to applications, so that gaps are visible before signature.
What limits does FIPS mode place on a RADIUS proxy design?
FIPS requirements can restrict which authentication methods and cryptographic components are available on the FreeIPA servers and clients, so some OTP flows that work in a standard build may need a different design or may not be approved for your environment. The effect is to narrow choices and add validation work, not to remove the proxy pattern itself. Confirm with your compliance owner which FIPS scope applies to the servers, the clients and the proxied traffic, and ask the implementer to document any method that cannot be used under that scope.
What should we check with our current OTP vendor before starting?
Confirm the licence terms that allow the existing RADIUS or OTP server to keep running during the proxy period, whether token seeds or enrolment data can be exported in a usable format, and how the vendor supports change requests for RADIUS shared secrets and client lists. Also check support hours and notice periods for any changes, because a proxy design depends on the vendor's system remaining available until the final cutover. Put these answers in the scope document so the migration plan reflects what the vendor actually permits.
How DeployOpen scopes and delivers this work
DeployOpen plans, implements, documents and supports FreeIPA inside your own infrastructure, including the RADIUS proxy work described on this page. The RADIUS proxy, the per-user assignment rules and the migration path are normally delivered under a fixed scope agreed in writing before work starts. That scope names the FreeIPA servers and clients in play, the existing OTP or RADIUS system being kept, the user populations and services that will move, the acceptance tests, and the handover material. Ongoing support, upgrades and continuous testing are available as a retainer once the initial work is in production.
DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move cost are the ones the scope should spell out: how many user groups and services are proxied, how many RADIUS or OTP systems are involved, whether FIPS mode constraints apply to the target hosts, how much testing against your existing system is needed, and whether the work is delivered on your premises or remotely with your change controls. Ask for a quote that separates one-time build work from any recurring support, and that states which of your staff must be available for approvals, test accounts and cutover windows.
DeployOpen is not an official partner, reseller or certified provider of FreeIPA, its upstream projects or the commercial OTP vendor you already run, and it does not issue audit reports or certifications. If your assessor needs evidence that the proxy behaves as designed, DeployOpen can prepare the configuration records, test results and change documentation, but the assessment itself remains with your independent auditor. Confirm with your own environment owners which systems are in scope before you request a quote, because the scope is what the fixed price and timeline are built on.
