FreeIPA two-factor authentication and Kerberos FAST

How FreeIPA two-factor authentication depends on Kerberos FAST

MFA in FreeIPA relies on Kerberos FAST to protect the pre-authentication exchange, so FAST settings decide whether second factors work. When a user's OTP is checked, the second factor travels inside a protected channel established before the ticket is issued. If FAST is not in place for a given client, KDC, or trust path, the OTP step can fail even though the token and the password are correct. Teams usually notice this after enabling OTP, when some users or services start failing while others succeed. Start by confirming, for your FreeIPA release, which FAST behavior is enabled by default, which settings are exposed for configuration, and whether they apply to your Kerberos clients and to the services that accept those tickets. Treat those answers as facts to verify in your own environment, not as assumptions carried over from documentation for another version. FreeIPA supports two-factor authentication with HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including software tokens in authenticator apps and hardware tokens such as YubiKeys. It can also proxy OTP checks to an existing RADIUS server, which matters if your organization keeps a commercial OTP system during migration. Each of these paths places a different load on the authentication flow, so the failure you see may depend on the token type, the client, or whether the check is local or proxied. Map which users and services use which method before you change any Kerberos setting.

AD trusts add a second layer of complexity. When FreeIPA users authenticate against services in an Active Directory forest, or AD users sign in to Linux through a trust, the tickets and pre-authentication traffic cross a boundary your FreeIPA-only test cases may not cover. Some Windows clients and older services may not handle FAST the same way Linux clients do, so a change made to satisfy one group can break another. Before you disable FAST for any trust-related path, ask your team to list the affected services, record the authentication failures with their Kerberos error codes, and test the change against both a FreeIPA-only user and an AD user. The FreeIPA trust documentation is the natural starting point for checking the namespace and trust requirements that shape this design.

Which second-factor path fits which login scenario

This table compares four second-factor paths: native FreeIPA OTP users, YubiKey users, OTP checks proxied to an existing RADIUS server, and AD users reaching Linux through a trust. Read each row against the Kerberos settings it needs, because FAST requirements and trust behavior must be confirmed against the release you install and the current FreeIPA documentation. The main takeaway is that the path you pick determines where the OTP is checked and which Kerberos behavior you depend on.

Scenario	What the user enters	Where the OTP is checked and Kerberos needs	Main trade-off
Native FreeIPA users with TOTP or HOTP	Password followed by a one-time code from a software token app	Checked by the FreeIPA KDC during pre-authentication. Needs FAST-protected pre-authentication enabled on clients and KDC, as confirmed for your release	Simplest to run inside FreeIPA, but depends on enrolled tokens and a recovery process for lost devices
Users with YubiKeys	Password followed by a touch or OTP generated by the hardware key	Checked by the FreeIPA KDC with the same Kerberos pre-authentication path as software tokens. Confirm the key types and FAST settings with the installed release	Strong possession factor, but keys must be issued, enrolled and replaced, and lost keys need a documented procedure
OTP checks proxied to an existing RADIUS server	Password followed by the code the existing OTP system expects	FreeIPA forwards the OTP check to RADIUS while the KDC handles Kerberos. Confirm the proxy settings and how pre-authentication behaves with your RADIUS system	Keeps an existing OTP investment, but adds a dependency on the RADIUS service and its availability for every login
AD users reaching Linux through a trust	Password or second factor as configured on the AD side, then Linux access through the trust	The AD domain controllers and their Kerberos settings decide whether MFA is enforced. FreeIPA must confirm the trust and FAST behavior for AD clients before relying on it	Keeps one identity source for AD users, but second-factor enforcement sits outside FreeIPA and must be tested end to end

How FAST carries the second factor through the KDC

The OTP value must travel inside a FAST-protected channel because the pre-authentication exchange is the only place the KDC can check it. Kerberos FAST (Flexible Authentication Secure Tunneling) wraps the initial AS-REQ and its pre-authentication data in an encrypted tunnel keyed from the client's armor ticket. Without that tunnel, the OTP would appear in the clear on the network, and an attacker could replay or capture it. FreeIPA's OTP support relies on this wrapping: the KDC sees the password and the token value together, inside the armored request, and decides whether to issue a ticket.

On the KDC side, the check happens in the authentication path rather than in a separate login service. The KDC verifies the armor, unwraps the pre-authentication data, validates the password factor and then checks the OTP against the user's token entry in 389 Directory Server, which is where FreeIPA stores token state. For the client, SSSD and the Kerberos libraries must request FAST and supply the armor; the user sees a single prompt for the password and token value, and the exact prompt order depends on the SSSD and PAM configuration. Confirm the armor and option names, and the message flow, against the MIT Kerberos and FreeIPA documentation for your exact versions before you rely on them.

The practical dependency is that a client or KDC path which does not negotiate FAST cannot complete an OTP login, so a mixed environment can fail for reasons that look unrelated to tokens. Before enabling MFA, verify that every client type in scope, and every trusted path that issues tickets, supports FAST in the versions you run. Test a login from each client family with a real token, and check the KDC logs for armor or pre-authentication errors, so a failure is traced to the protocol layer rather than to the user.

How MFA behaves in mixed environments with AD trusts

Native users are accounts created and stored in the IPA domain. They authenticate against the IPA KDC, so the second factor is evaluated where the OTP tokens, user policy and Kerberos preauthentication settings live. Kerberos FAST is the mechanism that protects the OTP exchange from being tampered with during the initial ticket request, which is why this population is the baseline for every other tab.

Token binding: Confirm each user's OTP token is linked to the correct user entry before enabling enforcement, including any hardware tokens.
Preauthentication settings: Check that the Kerberos settings MFA depends on are applied consistently on every IPA server that serves the KDC.
Replication state: Verify token and policy changes have replicated to all replicas, since a stale replica can accept or reject a login unexpectedly.
Test accounts: Keep at least one non-production native account with a working token to test changes before they reach all users.
Recovery path: Document how an administrator resets or re-enrolls a lost token for a native user.

Before widening the rollout, confirm each of these checks passes for a sample of native users on every client platform you support.

What breaks when FAST is disabled for AD trusts

Teams that turn off FAST for trust traffic, or configure it inconsistently, tend to hit the same few failures. The cards below pair each symptom with a likely cause and the first check to run, so you can confirm the cause in your own environment before changing settings.

OTP prompt never appears

Users from the trusted Active Directory forest log in with a password only and are never asked for a token, even though their FreeIPA account has OTP enabled. A likely cause is that the preauthentication path that carries the OTP challenge is not negotiated for cross-realm requests when FAST is off. First check: compare the KDC log for a local user and a trust user during the same login attempt, and confirm which preauthentication types each one receives.

Tickets lack expected strength

A ticket is issued, but it does not carry the authentication indicator your service policy requires, so the service refuses access. The likely cause is that the armored exchange that records the OTP factor in the ticket is missing for trust users, which leaves a weaker mechanism on the ticket. First check: inspect the authentication indicators on the issued ticket with a klist-style tool and compare them with the indicators your service requires.

Failures only for trust users

Local FreeIPA users log in cleanly while logins from AD users fail or time out at the same host and service. The likely cause is that the trust path and the local path follow different Kerberos flows, so a setting that works locally does not apply across the trust. First check: confirm that the failing and working accounts use the same host, service and client version, then compare their KDC lines for the same timestamp.

Unclear SSSD errors

SSSD logs show generic preauthentication or credential errors without naming the failed step, so the cause is hard to see from the client. The likely cause is a mismatch between what the client requests and what the KDC accepts after FAST is turned off. First check: raise the SSSD debug level on one test client, reproduce a single login, and match the timestamp against the KDC log on the server that handled the request.

Inconsistent settings across replicas

Some replicas accept the expected login flow while others reject it, so the same user sees different results depending on which server answers. The likely cause is that FAST or related Kerberos settings were changed on one server but not the others, or that a replica has not received the change. First check: compare the Kerberos configuration and the KDC process state on every replica serving the affected realm, and repeat the same login against each one.

Setting up FreeIPA two-factor authentication with FAST in mixed environments

This sequence takes a FreeIPA deployment from an inventory of login paths to tested two-factor authentication, with Kerberos FAST settings decided for native and trust traffic before any user is asked for a second factor.

Inventory users and login paths
Before changing anything, list every way a user authenticates against FreeIPA: console and SSH logins on Linux clients, web UI sign-in, services that request Kerberos tickets, sudo, and any Active Directory users who reach Linux through a trust. Record which users need a second factor, which service accounts must keep working without one, and which applications cannot prompt for an OTP code. Done means you have a table of paths, owners and expected factor for each. Keep this inventory with the change record, because the FAST decision in a later step depends on which of these paths cross a trust.
Confirm FreeIPA and Kerberos versions on every replica
Check the installed FreeIPA server and client versions, and the MIT Kerberos version, on each replica and on a sample of enrolled clients. Mixed versions across replicas can produce different behavior for the same login, so every server should be on the same release before you change authentication settings. Compare the results with the release notes for the version you run and with the FAST and OTP guidance in the FreeIPA documentation, and confirm the exact package names and commands for your distribution in your own environment. Record the output in a table keyed by host name. Do not proceed until all replicas report the same release family.
Decide the FAST policy for native and trust traffic
Decide, in writing, whether Kerberos FAST is required for native FreeIPA logins, for cross-realm traffic through an Active Directory trust, and for clients that cannot negotiate it. Use the trust documentation and your inventory to identify where AD users request tickets through FreeIPA, because that traffic is where a FAST-related failure is most likely to appear. Name an owner for each decision, and write down the fallback you accept if a client cannot negotiate FAST. The output is a one-page policy that the test plan references. Ask your directory and Windows administrators to confirm the trust type and the Windows versions in use, since those facts constrain the options.
Enable OTP per user or globally
Enable OTP authentication using the approach in the FreeIPA OTP design page, either for a defined group of users first or for all users at once. Start with a pilot group that represents your login paths, not only a single technical user. Confirm that the OTP setting is applied on each replica, since a change made on one server must replicate before clients see it. Check the result by logging in as a pilot user with a password only, and confirm that the password-only attempt is handled as your policy requires. Record the setting, the scope, the time of change and the pilot group membership.
Enroll test tokens for each factor type
Enroll at least one software TOTP token and one hardware token for test users, using the token types the OTP design page lists for your deployment, such as software tokens and hardware tokens. Confirm that each token generates a code that FreeIPA accepts on the first attempt and that the same code cannot be reused. Test a deliberately wrong code and confirm the rejection is logged. Store the token records and the test results in your change record, and note which test user owns each token so that lost-token recovery can be rehearsed later.
Configure RADIUS proxying if an existing OTP system stays
If an existing RADIUS-based OTP system remains in use, configure the RADIUS proxy described in the OTP design page for the users who still depend on it, and limit it to those users. Confirm the proxy server is reachable from every replica that handles authentication, and check the shared secret and timeout settings against your existing system's documentation. Test one proxied login from each replica. Expected result: the code is validated by the external system and the user receives a ticket. Record which replica handled each test, since a proxy that works on one server and fails on another is a common cause of intermittent login errors.
Test each login path against the policy
Run the tests from your inventory, one path at a time, and compare each result with the expected factor in the FAST policy. Include native Linux login over SSH, console or GDM login where used, sudo, the web UI, a service that requests a Kerberos ticket, and an AD user through the trust. For each path, record the factor requested, whether the ticket was issued, and any error text from the client and the KDC logs. A path that succeeds without the required factor, or fails for a user who should pass, is a defect to fix before rollout. Repeat the test on a replica other than the one where you made the change.
Record results and set the rollback path
Write a test report that lists every login path, the policy it was tested against, the replica and client versions, the pass or fail result, and the open items with owners. Document the rollback steps for the OTP and FAST settings, and confirm that a current FreeIPA backup exists before any production change, following the backup and restore guidance. Have the owner of each login path sign off on the result. The sequence is complete when the report shows every path passing, every open item is assigned, and the rollback steps have been reviewed by someone other than the person who wrote them.

Protecting FreeIPA two-factor authentication against downgrade paths

Two-factor authentication in FreeIPA is only as strong as the weakest path to a ticket. The cards below cover the places where an MFA-enforced user can slip back to a password-only login, and the operational controls that keep token enrollment, replicas and policy changes from weakening that protection.

Close password-only fallback paths

Enforcing OTP for a user does not stop a password-only login if other services still accept a plain password. Review which hosts, services and client configurations still allow password authentication for MFA-enforced users, including SSSD settings on Linux clients and any RADIUS or LDAP bind paths. Test each path with an account that has an OTP token, and confirm which Kerberos preauthentication mechanisms each client negotiates. Every login path must require the second factor.

Protect token seeds and enrollment

OTP token seeds are secrets stored in the directory, so anyone who can read or copy them can generate valid codes. Limit who can create, modify or export tokens, and review how enrollment is handed to users, since a token added to the wrong account or a seed shared in a ticket is a silent bypass. Confirm the enrollment and recovery steps against the OTP documentation before you publish a procedure to the help desk.

Run replicas on the hardened release

The 4.13.4 release fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. A replica on an older release can remain exposed even when the first server is patched, so inventory every server in the topology and confirm its version before you rely on MFA policy. Read the release notes for the full list of affected components.

Back up before authentication changes

Changes to authentication policy, OTP configuration or Kerberos settings can be hard to reverse, so take a backup before each change window. Be aware that restoring an outdated backup into an active replica topology can break replication, so restores must follow the documented procedure and never be used to roll back a single setting on a live system. Confirm backup type, retention and restore steps with the backup documentation before the change.

Limit who can change authentication policy

Authentication policy changes, such as turning OTP on or off globally, altering pre-authentication requirements or editing ticket policy, have an impact on every user. Restrict these rights to a small administrative group, use delegation rather than shared administrator accounts, and log each change for review. Check the access control and delegation documentation to confirm which roles can modify authentication settings in your version.

Questions teams ask before changing MFA in a mixed FreeIPA estate

What does changing MFA in a mixed FreeIPA estate cost?

The cost depends mostly on how many login paths the change touches, not on the FreeIPA version alone. Each path, such as console or SSH logins, SSSD-backed services, the web UI, VPN access, RADIUS-fronted applications and Active Directory users arriving through a trust, needs its own test and rollback plan. Trust complexity adds work because the trust settings, ID views and Kerberos policy must agree on both sides. Test effort is often the largest line item, since it needs a representative test population and repeated login checks. DeployOpen does not publish a price list. Most engagements are fixed-scope, so ask for each login path, trust, RADIUS integration and test cycle to appear as a separate line. Also ask which costs are one-time (design, configuration, cutover) and which recur (retainer support, token administration and re-testing after upgrades).

How long does an MFA change take to complete?

Duration is set by the number of login paths to validate, the approvals needed from Active Directory and network owners, and the number of test cycles the change requires. No supplied figure applies to every estate, so treat any duration you hear as a claim to check against your own scope. Plan time for a lab run against a copy of your topology, a pilot group that logs in on a defined schedule, a rollback rehearsal and a staged rollout by user group. Change freezes, the availability of Active Directory administrators and replica maintenance windows often set the calendar more than the technical steps do. Ask for a dated plan with entry and exit criteria for each stage and a named owner for every approval.

What access and test users must we provide before work starts?

Before work starts, the team that owns the estate needs to provide three things. Without them, the first stage of the work tends to stall.

Can our own identity team make the FAST and MFA changes?

Yes, if the team already operates FreeIPA replicas, understands how Kerberos pre-authentication works and can test the trust against a domain controller it is allowed to change. The harder part is usually coordination: the change touches FreeIPA, the Active Directory forest, RADIUS or other OTP systems and the applications that depend on them, and each owner must sign off. An internal team can own the change and still bring in an outside implementer for design review, lab testing or a fixed-scope configuration. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms in your own infrastructure, and ongoing support is available as a retainer. Ask whether your team will keep the runbook and rollback steps after handover.

Does turning on Kerberos FAST change service accounts and keytabs?

Confirm the exact behavior for your FreeIPA and Samba versions in the project documentation before you rely on any assumption. Service principals normally authenticate with keytabs and host credentials, so the first question is which accounts and automated jobs obtain Kerberos tickets through a user password, a keytab or a trust. Build an inventory that includes cron jobs, batch accounts, service principals on application servers and integrations that request tickets on behalf of a user. Test each flow in a staging realm before you change production policy. Ask the implementer whether the change applies per user, per host or realm-wide, because that scope decides how much of the inventory needs testing.

What breaks when FAST is disabled for an AD trust?

The answer depends on your FreeIPA version, your trust type and how each client requests tickets, so confirm it in the documentation and in a lab before production. Plan to test the places where the trust meets MFA. Active Directory users may be refused, or may reach a service without the second factor you expected. Cross-realm ticket requests can fail in ways that look like password errors, which sends help desks to the wrong fix. Applications that accept Kerberos tickets may return generic authentication errors. Record the exact failure for each login path, and make sure your rollback plan restores the previous Kerberos policy without changing user credentials.

How does RADIUS proxying change the MFA test effort?

Each RADIUS-backed login path adds a second system to test, and that system has its own timeouts, shared secrets, token state and failure behavior. Test what happens when the RADIUS server is slow, unreachable or rejects a token, and confirm that users are not locked out by a timeout that FreeIPA never sees. If you keep an existing OTP system during a gradual migration, test per-user assignment separately from the global policy. Confirm with your vendor and your FreeIPA documentation whether any part of the chain has limits under FIPS mode before you commit to a design. Ask for the RADIUS test cases to be listed in the written scope, with the expected result for each.

What should a written scope for this work include?

A written scope should name every login path in the estate, the trust and domain controllers in scope, and the RADIUS or OTP systems that are changing. It should list the FreeIPA replicas affected and the change windows agreed for each one. Add the test population, the test cases with expected results and the rollback criteria for each stage. Name what the implementer delivers, such as a design document, configuration, a runbook and handover training, and what your team delivers, such as access, approvals and sign-off. State what is excluded, including applications you own or other identity sources. Finally, ask whether post-change support is a separate retainer, since the written scope decides which costs are fixed and which recur.

What to confirm in your environment before relying on FAST-backed MFA

FAST-backed MFA depends on the exact FreeIPA and MIT Kerberos builds, the AD trust layout, every client that must send an OTP, and the behavior of any RADIUS server in the path. Confirm each item in your own environment, because the cards below describe what to check, not what a given version will do.

FreeIPA and Kerberos versions

Record the FreeIPA server version on every replica and the MIT Kerberos and SSSD versions on each client class. Run ipa --version on the servers and check the installed krb5 and sssd packages on clients. Mixed versions across replicas can produce different FAST behavior, so confirm that every server and client that handles MFA is on a version your team has tested. Check the FreeIPA release notes for the version you run before assuming a fix or feature is present.

AD forest and trust configuration

Confirm whether the trust with Active Directory is one-way or two-way, which DNS domains each side uses, and whether the IPA domain overlaps any AD domain, since the trust requires non-overlapping names. Ask your AD team which authentication policies and Kerberos armoring settings apply to the domain controllers, because those decide whether FAST is requested and enforced across the trust. Record the answers in writing before you change FAST settings.

Clients and services that cannot send an OTP

Inventory every login path that may not carry a second factor, including cron jobs, service accounts, legacy SSH clients, batch tools and older applications that request tickets directly. Test each one against an OTP-enforced policy in a staging realm. Some of these paths may fail after enforcement, and some may need a separate exception or a redesigned service account. Do not assume that a path will work because the user normally logs in interactively.

RADIUS server behavior when proxying

If FreeIPA proxies OTP checks to an existing RADIUS server, ask the owner of that server how it handles timeouts, retries, token lockouts, and unreachable backends. Confirm which user identifiers it expects and whether it returns a result that FreeIPA can map back to a Kerberos decision. Test a failed and a slow response in staging, because a silent timeout can look like a wrong code to the user.

FIPS constraints

If your hosts run in FIPS mode or your policy requires it, confirm which OTP mechanisms, hash functions and RADIUS integrations are permitted on your OS build and in your FreeIPA version. Check the vendor documentation for your platform and the FreeIPA OTP design page for the algorithms involved. Do not assume that a token type that works on a non-FIPS host will work on a FIPS host.

Failover testing between replicas

Write a test plan that stops one replica at a time while logins, ticket renewals and OTP checks continue. Confirm that the KDC on each remaining replica enforces the same authentication policy, and that token state and lockout counters replicate as expected. Record the results and the recovery steps your team will use if a replica returns with stale data. Run this test after each FreeIPA upgrade as well as at initial rollout.

How DeployOpen scopes and delivers FreeIPA MFA work

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA. For Kerberos FAST and two-factor authentication, we start by mapping which services, clients and trusts depend on the Kerberos settings before any change is made to the realm.

How we scope

Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
The written scope lists which hosts, services, AD trusts and OTP or RADIUS paths the FAST and MFA changes touch.
We ask for an inventory of clients and services that authenticate through Kerberos, including any that use older mechanisms.
Quotes follow from the written scope, so ask for each item to be listed separately.

How we build

We test FAST and OTP preauthentication settings in a non-production realm that mirrors your production topology.
Each change is recorded with its rollback steps, so a failed authentication test can be reversed.
Test cases cover password, OTP and trust logins for both Linux clients and any Active Directory users in scope.
Configuration is written as reviewable code where your team uses that approach for infrastructure.

How we hand over

You receive documentation of the final Kerberos and MFA configuration, the test results and the known limits found during testing.
Runbooks describe OTP token enrollment, lost-token recovery and how to check FAST status after a change.
We walk your identity and platform engineers through the verification steps they will repeat after future changes.
Documentation names the settings that other teams must not change without a review.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
Retainer work can cover re-testing after FreeIPA security releases and checks after AD trust changes.
Confirm with us what response and coverage terms a retainer includes before you sign, since these are set in the written agreement.
DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.