Enforce OTP for LDAP binds in FreeIPA: rollout guide

How to enforce OTP for LDAP binds in FreeIPA

To enforce OTP for LDAP binds in FreeIPA, you enable the OTP enforcement setting for LDAP authentication, which FreeIPA added in release 4.12, and then test every application that binds over LDAP before it goes live. Two-factor authentication in FreeIPA already protects Kerberos and web logins, but an application that performs a simple LDAP bind can still accept a password alone unless the directory checks for a second factor. Teams need this change when they run LDAP-based applications, such as directory-backed web apps, VPN gateways or appliances, that authenticate users directly against the directory and cannot use Kerberos.

FreeIPA supports two-factor authentication with HOTP and TOTP tokens, including software tokens and hardware tokens such as YubiKeys, and it can proxy OTP checks to an existing RADIUS server, according to the FreeIPA OTP design page at FreeIPA design: OTP. Confirm the exact enforcement option name, its scope and its default in the FreeIPA 4.13.0 release notes and in the notes for the version you run, since the setting's behavior is what closes the gap. Check whether your deployment is on 4.12 or later before you plan around it.

Before you change the setting, inventory every LDAP client and service account, record whether each one can send an OTP value in its bind, and identify those that cannot. A bind that fails after enforcement is usually a bind from a tool that sends only a password, so plan a test in a non-production replica first and verify both a successful OTP bind and a rejected password-only bind. Also confirm how existing service accounts that must bind without a token will be handled, because exemptions weaken the control and should be approved and documented.

Which enforcement choices fit which LDAP bind paths

This table compares the enforcement scopes for OTP on LDAP binds, from all users to selected groups and separate service accounts. Read each row against your own application inventory, since the cost of each option depends mostly on which clients bind over LDAP and whether they can send a one-time code. The main takeaway is that broad enforcement is simple to explain but breaks unattended binds first, so exceptions need a planned, reviewed path.

Enforcement scope	Effect on users and applications	Operational cost	When it fits
Enforce OTP for all users	Every LDAP bind by an OTP-enrolled user must include a current token code. Clients that send only a password fail until they support the second factor.	Highest. Requires an inventory of every LDAP client, user-facing and unattended, before the switch. Expect help desk load from users with unusual token setups.	Organizations where all LDAP clients are interactive and can prompt for a code, and where the security mandate covers every account.
Enforce OTP for selected user groups	Only members of named groups must supply a code on LDAP binds. Other users keep password-only binds, so their applications keep working.	Moderate. Group membership must be kept accurate, and reviews are needed when people move between groups. Gaps appear if a privileged group is left out.	Phased rollouts, or when a defined population such as administrators or remote staff carries most of the risk.
Keep service accounts on a separate bind path	Non-interactive service accounts bind without OTP, usually with a password or a stronger secret held in a vault. Human accounts are still enforced.	Moderate to high ongoing effort. Each service account needs a documented owner, a credential rotation method, tight access control and periodic review.	Applications that cannot send a one-time code and cannot move to Kerberos or certificate authentication in the near term.
Route service bind traffic through a proxy or gateway	The application binds to an intermediary that performs the check or holds the credential. Behavior depends on the intermediary's features.	High. Adds a component to build, patch, monitor and secure. Confirm the design with your architect before choosing it.	Legacy applications with fixed LDAP settings where direct changes are costly and an approved intermediary already exists.
Move applications to Kerberos or certificate authentication	Applications authenticate with a ticket or certificate rather than a simple bind, removing the password-only path for those clients.	High one-time effort for application changes, lower recurring effort for credential handling. Requires testing in each client.	Applications that support GSSAPI or certificates and are central to the bind exposure.
Keep existing binds unchanged and monitor	Nothing is enforced yet. Bind attempts are logged and reviewed so you can see which clients still send password-only binds.	Low to start, but it does not close the gap. Useful only as a short discovery step before enforcement.	Early inventory, before any enforcement decision is made.

Which applications are affected when LDAP binds skip OTP

LDAP binds that authenticate with a password alone are the path OTP enforcement changes. Each application type below uses a bind in a different way, so each has its own failure mode and its own list of things to verify before enforcement is switched on.

Web applications with directory logins

Web apps that authenticate users by binding to FreeIPA over LDAP send the username and password directly to the directory. Once OTP is enforced for binds, a user who has a token must append the one-time code to the password, and a web form built for a plain password will reject it. Check whether each app accepts a combined password and code, whether it caches bind results, and whether users with tokens can still sign in through its login page. Test every login path with a token enrolled.

Mail and collaboration servers

Mail transfer agents, IMAP and POP servers, and groupware often bind to LDAP for each login and for address lookups. Mail clients usually cannot prompt for a one-time code, so a bind that now requires OTP may fail for every device that stores a password. Confirm which clients use the directory for authentication, which ones use a separate lookup account, and whether app-specific credentials are an option in your design.

VPN and network appliances

Many VPN concentrators, firewalls and network devices authenticate users against LDAP and expect a single password field. Some of these appliances already support RADIUS-based OTP, and others do not. Where an appliance cannot send a second factor over LDAP, the bind may fail or may silently revert to a path that skips OTP. List each appliance, its LDAP authentication method and whether it can use RADIUS proxying with FreeIPA before you enforce.

Linux PAM and SSSD-adjacent tools

Tools that use PAM modules, nss_ldap-style lookups or direct LDAP simple binds on Linux hosts can sit outside the Kerberos and SSSD login path that FreeIPA normally manages. Identify which local services bind over LDAP with a user password, rather than through Kerberos or SSSD, and confirm how each one handles a prompt for a one-time code. Test on a non-production client before changing the directory policy.

Service accounts used by scripts and integrations

Scripts, cron jobs, CI pipelines and integrations often hold a bind password for a directory account. These accounts usually cannot answer an OTP challenge, so enforcement can stop jobs that ran without interruption for years. Build an inventory of every bind DN, the systems that hold its password and the job schedules that depend on it. Decide with the owners whether each job moves to Kerberos, a keytab or a dedicated bind path before enforcement.

Enterprise applications with bind-based lookups

Business applications often bind as a user only to read attributes such as group membership, manager or department, even when the main login uses SSO. A lookup bind that succeeds with a password alone would stay outside OTP enforcement. Review each application's directory configuration, separate its authentication binds from its lookup binds, and confirm with the vendor how the application behaves when a bind is refused. Record the result before the change window.

Rollout sequence for OTP-enforced LDAP binds

This sequence moves LDAP OTP enforcement from inventory to production in ordered stages, with a test at each stage so every application is checked before the setting changes on live replicas. It produces a tested application list, a verified rollback path and a change record showing which binds require a token.

Inventory LDAP clients and bind accounts
List every application, script and service that binds to FreeIPA over LDAP. For each entry, record the bind DN, the bind method (simple bind, SASL or Kerberos), the users who authenticate through it and a named owner. Applications that bind with a service account often need a separate decision, so flag them now. The step is done when the owners have signed off on the list and every entry has a bind method recorded.
Confirm the FreeIPA version and read the release notes
Run ipa --version on every server and replica. Confirm that the deployment runs release 4.12 or later and that all servers match. Read the 4.12 release notes for how LDAP OTP enforcement behaves and which setting controls it. Read the 4.13.4 release notes for the two CVEs it fixed and the authentication checks it hardened. The step is done when every server reports the same version and the release notes are filed with the change record.
Enroll OTP tokens for test users
Create dedicated test accounts that mirror the roles in your inventory. Enroll a software token (TOTP or HOTP) for each, and a hardware token where your users need one, following the FreeIPA OTP design. Confirm the token exists with ipa otptoken-find --owner=<testuser> and that each test user can complete a web UI login with a current code. The step is done when every test account has at least one working token.
Enable enforcement on a test topology
Build a non-production FreeIPA topology at the same version, with at least one replica set up like production. Turn on LDAP OTP enforcement using the setting named in the 4.12 release notes. Test the same account twice: once with the password alone, which should be refused, and once with the password plus a current token, which should succeed. Illustrative check: ldapwhoami -x -D "uid=testuser,cn=users,cn=accounts,dc=example,dc=com" -W. Confirm with each client how the token is combined with the password.
Verify each application against the test topology
Walk through the inventory and run each application's login with and without a token. Include service accounts and scheduled jobs. Record the expected and observed result for each row. Look for applications that cannot send a token, sessions that fail when a token expires and clients that cache old authentication results. Mark blocked items and get a decision from the owner before production. The step is done when every row has a pass, a documented exception or a blocked status with an owner.
Prepare backups and the rollback plan
Take a full ipa-backup on the primary server and store it off the host. Note which server handles certificate renewal and CRL publication by default, because that server needs the same care during the change. The rollback reverts the enforcement setting and reruns the bind tests. Restoring an outdated backup into a live replica topology can break replication, so treat a restore as a last resort. The step is done when the backup is verified and the rollback has been rehearsed in the test topology.
Stage the production change one replica at a time
Apply the enforcement change to one production replica during the change window your team has agreed. Run the bind test set against that replica and confirm that clients using it still authenticate as expected. Then apply the change to the remaining replicas in sequence, testing each one before moving on. Keep other replicas serving clients while each change is verified. The step is done when every replica passes the bind test set.
Monitor authentication and close the rollout
Watch directory and application logs for refused binds over the observation period your owners agree on. Compare each unexpected failure with the inventory and resolve it. Update the inventory with the final bind methods and record every exception with an owner and a review date. Store the test results and log review with the change record. The step is done when no unexplained failures remain and the exception list is complete.

Testing LDAP binds before enforcement reaches production

Rollout testing is the main control against this change, because a broken LDAP bind can lock out applications, not just individual users. Once OTP enforcement applies to LDAP authentication, every service account, directory browser, mail client, VPN gateway or script that binds over LDAP with a password alone will start failing at the same moment. Before enforcement reaches production, build a test matrix that covers each bind type in use (simple binds with a user DN, binds with a service account, and any binds that search before authenticating), each client library and runtime that issues them (including the LDAP libraries in your own applications and any SSSD-backed paths), and each token type your users hold, including software TOTP or HOTP tokens and hardware tokens such as YubiKeys. Inventory the applications from the bind logs of your current directory before you write the matrix, since an application nobody remembers is the one most likely to fail.

Test the matrix against every FreeIPA server that will answer LDAP requests, not only the one you administer from. Replicas that have not yet received the new configuration or that run a different release can return different results for the same bind, so confirm the behavior on each replica and check that a bind routed to any server in your topology gives the same answer. Confirm the exact enforcement setting and its scope for your release in the FreeIPA 4.12 release documentation and the OTP design page before you write test cases, rather than relying on memory of how the feature behaves.

Document a rollback before the first test run. The rollback should state the configuration change that restores password-only binds, who may approve it, which applications are expected to recover without a restart, and how you will confirm that a rollback has taken effect on every replica. Record each test result against the matrix so that the evidence can be reused in a compliance review. A rollback you have rehearsed in a non-production environment is worth more than one written down but never exercised.

Security risks during a partial OTP rollout

Enforcing OTP for LDAP binds is rarely a single switch. While some applications, accounts and replicas are still on the old path, the gaps move rather than close. The cards below cover where those gaps tend to sit and what to check before and after each step.

Bind-only accounts left behind

Accounts that exist only so an application can bind over LDAP often have no owner, no OTP token and no login history. When enforcement is turned on for the wider population, these accounts may be the ones that quietly keep working on a password alone, or break at a bad moment. Export the accounts that bind over LDAP, assign each one an owner, and decide per account whether it moves to a supported bind method or is retired.

Service accounts that cannot hold tokens

Batch jobs, monitoring agents and integrations cannot type a one-time password. Enforcing OTP for them without a plan breaks them, and leaving them exempt keeps a password-only path open. Inventory each service identity, record who depends on it, and document the compensating controls for any exception, such as restricted network source and a narrow directory scope, with a review date.

Token enrollment gaps

Users who never enrolled a token, or who enrolled a token that was later lost, can be locked out once enforcement applies to them. Staff may then ask for temporary exemptions, which is where partial rollouts drift. Before each enforcement wave, confirm enrollment coverage by group, decide which token types are allowed (software or hardware), and agree on who verifies identity before a token is reset.

Token recovery and reset paths

Recovery is a security decision as much as a help desk task. A reset path that accepts a phone call without verification can undo the protection that enforcement is meant to add. Write the recovery procedure, limit who can reset tokens, and log each reset so that unusual patterns are visible during the rollout period.

Replicas on mixed versions

A partial rollout can leave some replicas and clients on a different release from others. Confirm which FreeIPA version each server runs and update in a deliberate order, so that authentication behaves the same on every server a client might contact. Check the release notes for each version involved before changing servers.

Keeping FreeIPA current

The FreeIPA 4.13.4 release notes describe fixes for two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. A deployment waiting on OTP enforcement should not also wait on these fixes. Read the release notes for your exact version, plan the update, and verify the result on a test replica before production.

Questions buyers ask about OTP for LDAP binds

What does OTP enforcement for LDAP binds cost?

Cost depends on the written scope, and DeployOpen does not publish a price list, so a quote follows from the scope agreed before work starts. The main cost components are application discovery and bind analysis, FreeIPA configuration changes, test planning and execution, and support during change windows. Most of this work is one-time. Recurring cost appears only if you add a retainer for upgrades, testing or ongoing support. Ask for each component to be priced separately, and ask which items are fixed in the scope and which depend on how many applications discovery finds. Ask the partner to state its assumptions about your replica layout and token policy, since both change the amount of testing required.

How long does an OTP for LDAP bind rollout take?

The duration is set by the number of applications, the bind types they use, and the change windows your teams can allow. No fixed duration applies to every environment, so ask for a timeline built from your own inventory. Replica layout also affects timing. FreeIPA's deployment recommendations advise two to three replicas in each datacenter, and changes should be rehearsed on non-production replicas before production. Ask the partner to show which steps run in parallel, which wait on application owners, and which depend on a change window. Any schedule should name the acceptance tests that close each phase.

What must our internal team provide before a rollout starts?

Your team provides the inputs that discovery cannot infer. The usual list includes:

An inventory of every application that binds to LDAP, with the bind method and the owner of each application
Test user accounts, with OTP tokens enrolled and access to test the sign-in path for each application
Change windows approved by the teams that run the applications and the directory
Access to a non-production FreeIPA environment that matches production as closely as practical
Named contacts who can approve rollback decisions during each window

Missing inventory entries are the most common cause of late surprises, so ask the partner to define how discovery will check the inventory against actual bind traffic.

Can our own team enforce OTP for LDAP binds without a partner?

A team with FreeIPA operations experience can do this work internally, and the decision depends on the skills and capacity available. The work involves reading the FreeIPA OTP design, configuring the directory, enrolling tokens, testing each application bind path, and managing replication and rollback. Internal teams usually struggle with applications they do not own, where the bind behavior is undocumented. Whichever way you choose, write down the rollout plan, rehearse it on a test topology, and agree on who can stop the change. If you engage a partner, ask for a written scope that states which tasks you keep and which the partner runs.

How should LDAP service accounts be handled when OTP is enforced?

Service accounts need a decision per account before enforcement, because a bind that cannot present a one-time code will fail once the requirement applies. The options to evaluate are whether the application can send an OTP, whether the account can move to a different authentication path that your security policy approves, or whether it needs a documented exception with compensating controls. Each option has an owner and a review date. Confirm the exact behavior for service accounts in the FreeIPA release you run, using the FreeIPA OTP design page as a starting point, and test every service account in the non-production environment before the production change window.

Which applications are likely to break when LDAP binds require OTP?

The applications most likely to break are those that bind with a stored password and have no way to send a second factor. Applications that cache credentials, retry binds automatically, or report only generic authentication errors also make failures hard to diagnose. The drivers are the bind type, the application's support for interactive or token-based prompts, and how it handles failed binds. Ask the partner to classify each application into one of a few categories, such as works unchanged, needs configuration change, or needs an exception, and to test each category with the same acceptance criteria.

What should a written scope for LDAP OTP enforcement include?

A written scope should name each deliverable and the conditions for finishing it. Request these items:

The application inventory and bind classification, with owners named for each application
The token policy, including which token types are allowed (HOTP and TOTP are supported by FreeIPA, and hardware tokens are possible) and whether any RADIUS proxying applies
The service account decisions and the approval path for exceptions
A test plan with acceptance criteria per application and per replica
A backup taken before each change, using the FreeIPA backup tooling, and a tested rollback procedure
Change windows, communication steps and a list of out-of-scope applications

Ask for the scope to state what happens if discovery finds more applications than expected.

Limits to confirm in your environment

LDAP OTP enforcement changes how every bind to FreeIPA is checked, so the release, the client libraries and the account types all need confirmation before a policy goes live. The cards below cover what to verify with the FreeIPA release notes, each application vendor and your own user population.

Confirm the release and option names

Enforcement of OTP on LDAP authentication was added in FreeIPA 4.12, and the exact setting names and default behavior should be read from the release notes for the version you run. Check whether the option applies per user, per group or server-wide, and whether it is on by default. Test the setting on a non-production server before you rely on its name in change records or runbooks. Your upgrade path also matters, because a server running an older 4.x release will not enforce the rule at all.

Check each application's bind flow

Every application that binds over LDAP must send a second factor in the form its library expects. Ask each vendor whether its LDAP client supports an OTP-aware bind, how it passes the token, and whether it retries or caches sessions. Applications that only send a username and password will fail once enforcement is active. Build a test matrix with one entry per application and per authentication path, including web logins, admin consoles and scheduled jobs.

Map service and password-only accounts

Service accounts, integration bind users and automation identities often authenticate with a static password and no token device. Identify every such account in your directory and decide whether it needs an exception, a move to Kerberos or certificate authentication, or a rewrite of the client. Ask the vendor or project how its bind credentials are stored and rotated. Confirm with your own security team which exceptions they will approve and how each exception is reviewed.

Confirm token types for your users

FreeIPA supports HOTP and TOTP tokens, including software tokens and hardware tokens such as YubiKeys. Confirm which token types each user group actually holds and whether every user has enrolled one before enforcement begins. Check how lost, reissued and shared devices are handled, and whether the self-service enrollment path works for contractors and remote staff. Users without a token will be locked out of LDAP-dependent tools, so the enrollment count is a go or no-go input.

Test RADIUS proxying and FIPS restrictions

If you proxy OTP checks to an existing RADIUS server, confirm with the FreeIPA documentation and your RADIUS vendor how the LDAP bind path interacts with that proxy and whether the enforcement setting changes its behavior. Separately, if your hosts run in FIPS mode, confirm which token types, Kerberos encryption types and RADIUS features are permitted under FIPS restrictions. Run both combinations in a lab that matches production before you change any policy.

How DeployOpen works on this

DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA. For OTP enforcement on LDAP binds, the work starts with an inventory of which applications bind over LDAP and how, then moves through a written scope, a staged rollout in a non-production topology, and a handover your team can run.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists every LDAP-bound application, its bind method and whether it can send an OTP value.
The scope names the FreeIPA servers, replicas and client groups where the enforcement change will apply.
Quotes follow from the written scope, so ask for each inventory item and test step to be listed separately.

How we build

Configure the enforcement setting and the password policy changes on a non-production FreeIPA topology first.
Test each application's LDAP bind path with OTP enforced, including service accounts that bind without a token.
Record the result for each application, with the exception handling chosen for any that cannot send an OTP.
Confirm that FreeIPA 4.12 or later is running on every server before the setting is applied, as the feature depends on it.

How we hand over

Provide documentation of the final enforcement configuration, the application inventory and the test results.
Document the rollback steps for each replica so your team can revert a change without restoring from backup.
Walk your identity and application owners through the bind inventory and the exception process.
Deliver the test scripts and checks in your repositories so future regressions can be rerun by your team.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for FreeIPA estates.
A retainer can cover re-testing LDAP binds after new applications are added or FreeIPA security releases are applied.
Ask whether a retainer includes review of new LDAP-bound applications before they reach production.
Confirm response terms and access arrangements in the written agreement, since these vary by engagement.