How FreeIPA enforces MFA for one service without locking out the rest
Authentication indicators let FreeIPA require a specific mechanism, such as OTP, a smart card or an external identity provider, for one service without changing the login policy for every host. Teams need this when a privileged application, a file share or an admin console must demand a stronger factor, while general logins, batch jobs and older clients keep working as they do today. The decision starts with a list of services and the mechanism each one needs, because an indicator is only useful when it maps to a service that already has a clear owner.
FreeIPA combines 389 Directory Server for users, groups and policy, MIT Kerberos as the key distribution center, the Dogtag certificate system and SSSD on Linux clients. The Kerberos layer is where the MFA result is carried: the KDC records how a ticket was issued, and services that check that record can then accept or refuse it. This is why MFA design in FreeIPA is a Kerberos design question as much as an identity question, and why the same OTP or smart card setup can behave differently depending on which service asks for the ticket.
Before you rely on indicators, confirm the exact indicator names and the matching rules for the FreeIPA version you run, since these details are version-specific and should be checked against the release notes and design documentation for that version. Then test each protected service from a client that is enrolled, from one that is not, and from a trusted Active Directory user if you have a trust. Record which logins are refused and why, so that a service can be restricted without locking out the core services you must keep reachable.
Choosing which mechanism each service requires
This table compares the authentication mechanisms you can require for a FreeIPA-protected service, from password only to smart cards and external identity providers. Read each row as a question: when the mechanism fits, what must be in place first, and what usually goes wrong.
| Mechanism | When it fits | What it depends on | Main risk |
|---|---|---|---|
| Password only | Low-risk internal services where users already sign on through Kerberos and no second factor is required by policy | Kerberos KDC and user password policy in FreeIPA | Phished or reused passwords grant full access to the service |
| HOTP tokens | Users who need a fixed-counter token, often hardware tokens, for services that run without a clock-synced device | OTP token enrollment per user, token synchronization, and a recovery process for lost tokens | Counter drift after repeated failed attempts can lock users out until an administrator resynchronizes the token |
| TOTP tokens (software or hardware) | Most user-facing services where users have a phone app or a YubiKey and clocks on the KDC and client are synchronized | OTP enrollment, time synchronization, and Kerberos FAST for the authentication flow to carry the second factor | Clock skew, lost devices, and users who enroll a software token on a shared or unmanaged phone |
| Smart card | Privileged administrators and regulated users who must prove possession of a managed certificate | Certificate issuance from the integrated CA, certificate mapping to user entries, and client smart card configuration | Expired or revoked certificates block login, and mapping errors can break access for a whole group |
| External IdP (OAuth 2.0) | Organizations that already centralize sign-in with an external provider and want Kerberos to accept that result | An external OAuth 2.0 identity provider configured for FreeIPA, plus client and Kerberos settings that accept it | Dependency on the external provider's availability and policy, which sits outside your FreeIPA administration |
| Existing OTP or RADIUS system | Sites that keep a commercial OTP service while moving identity to FreeIPA | RADIUS proxy configuration and per-user assignment in FreeIPA | Two systems must stay aligned, and FIPS limits may restrict which proxy setup is possible |
| Authentication indicator per service | Services where only some resources need a stronger mechanism than the rest of the realm | Authentication indicators assigned to the service principal and ticket policy set for each mechanism | Indicators are not enforced on a service that does not check them, so the requirement must be tested per service |
Setting up per-service MFA in the right order
This sequence moves a FreeIPA realm from a working Kerberos and OTP baseline to per-service authentication indicators, with a login check on a must-stay-open core service at every stage so a bad rule never locks the organization out.
Confirm the Kerberos and OTP baseline
Start on a test realm that matches production as closely as practical. Confirm that Kerberos authentication works for a test user from a enrolled Linux client, that the KDC and at least one replica answer, and that OTP is enabled for the test user with a working software or hardware token. Check the exact OTP and Kerberos settings against the FreeIPA OTP design page and the documentation for your installed release, because option names and defaults change between 4.x versions. The step is done when a token-based login succeeds on the test client and the logs show the expected authentication path.
Enroll tokens or certificates for a pilot group
Choose a small pilot group, such as platform administrators, and enroll each member with the mechanism you intend to require: OTP tokens, smart cards or an external identity provider where your release supports it. Record which users hold which mechanism, because the indicator and ticket policy in later steps depend on that mapping. Keep the pilot group out of production-critical roles until the rollback path has been tested. The step is done when every pilot user can log in once with their new mechanism on the test realm and the enrollment record matches the plan.
Map each service to a required indicator
Write a table that lists every service, the authentication indicator it requires, and the mechanisms allowed to satisfy it. Mark core services that must stay open, including the login path your administrators use to reach FreeIPA itself, SSH to recovery hosts and the services that other systems depend on for authentication. Confirm the indicator names and how they are assigned against the documentation for your release before writing any rule. The step is done when a reviewer can read the table and state, for each service, who may reach it and with which mechanism, and when the must-stay-open list is agreed in writing.
Apply ticket policy per mechanism
Configure the Kerberos ticket policy so that tickets obtained through each mechanism carry the right indicator, and so that services check that indicator on access. Apply the rule to the pilot group first and leave other users on the existing policy. Verify on the test client that a ticket from a password-only login is refused by the restricted service while a ticket from an OTP login is accepted. The step is done when both outcomes are observed and recorded, and a login to a must-stay-open core service still succeeds for a pilot user.
Test with a user from each mechanism
Run the full test matrix with one account for each mechanism: password only, OTP, smart card or external identity provider, and an administrator account. For each account, attempt login to every service in the table and record the expected and actual result. Include a web login, an SSH login and a command-line Kerberos request, since each path can handle indicators differently. Confirm the results against the documentation for your release instead of assuming a pass. The step is done when every cell in the matrix matches the planned outcome, with no unexpected denials on core services.
Document and keep a rollback path
Before widening the rule to more users, write down the exact steps to revert each indicator requirement, the order in which to revert them, and who may do it. Keep one administrator session with a pre-existing, tested login path open during any change window. Take a backup with ipa-backup before each widening step, and confirm the restore procedure in the backup documentation for your topology. The step is done when the rollback steps have been rehearsed on the test realm and a named owner has confirmed they can execute them without relying on the rule being changed.
Widen the rule in stages with core checks
Expand the policy group by group, rerunning the test matrix and the core-service login check after each expansion. Watch the authentication logs for unexpected denials and address each one before the next group moves. Do not change core services that must stay open, and reconfirm them after every stage. The step is done when the final group is enrolled, the full matrix passes on production, and the core-service login check has been recorded at every stage.
Which core services you must not restrict
Some FreeIPA services must stay reachable with a password or Kerberos ticket alone, because the platform depends on them to keep working. An authentication indicator that forces OTP or a smart card onto the wrong service can lock out first logins, host enrollment and renewal, certificate maintenance and administrators at the same time. Before you attach any indicator rule, list the core paths and mark each one as excluded from strong-mechanism requirements, with a named owner and a written reason.
The core paths are the KDC for first logins and ticket issuance, host enrollment and keytab renewal, certificate renewal and CRL publication, DNS and NTP that clients resolve and synchronize against, and the admin accounts used for recovery. The backup documentation notes that the first server handles certificate renewal and CRL publication by default, so an indicator rule that blocks that server's administrative or service activity can silently stop renewals until certificates expire. Each DeployOpen-style plan should confirm which server holds those roles in your topology, and the FreeIPA deployment recommendations advise at least two to three replicas in each datacenter, so the exclusions must apply consistently across every replica, not only the first one.
Write a break-glass procedure before enforcement starts. It should name the accounts allowed to use password-only or ticket-only access, where their credentials are stored offline, who approves their use, and how each use is logged and reviewed. Test it in a non-production replica: lock out a standard admin path on purpose, confirm the break-glass account can still renew a host, reissue a service certificate and resolve a DNS record, then restore normal policy. Repeat the test after every upgrade or change to indicator rules, and record the results. Confirm with your identity team how often the drill must run under your own control framework.
Security risks of indicator-based policy
Authentication indicators only protect a service if the mechanism, the ticket and the topology behind them all hold their assurance level. The cards below cover the failure modes that most often undo a per-service MFA policy, with the control to apply to each.
Weaker mechanisms stay valid
A password-only or low-assurance ticket can still reach a service that requires OTP if the service accepts any indicator at or above its threshold. Map each sensitive service to the indicators it accepts, then test with a password-only login and confirm the service refuses it. Check every accepted indicator, not only the one you configured first. Confirm how your FreeIPA version evaluates these indicators before you rely on the mapping.
Ticket lifetimes outlast the MFA decision
A Kerberos ticket issued after a strong login keeps its authentication strength until it expires, so a long lifetime extends access well beyond the MFA event. Review the ticket lifetime and renewal settings for each service class, and shorten them for the most sensitive systems. Ask your team to document who can renew tickets and under what conditions.
Password fallback in mixed environments
Where AD trusts, older clients or legacy applications still accept password-only Kerberos, a user can bypass the MFA requirement by choosing a path that never presents a second factor. Inventory every client and trust that can request tickets for protected services, and decide whether each one can enforce the policy. Treat any path that cannot as an exception with a named owner and an end date.
Misconfigured service principals
An authentication indicator set on the wrong service principal, or on a principal shared by several services, can either block legitimate access or leave a sensitive service unprotected. Review each service principal and its host, and confirm the policy attaches to the principal your application actually requests. Keep a written list of which principal guards which service, and check it after every host rename or service move.
Administrators locked out by policy
A policy that requires a hardware token for administrative services can lock out the only administrators who can change the policy. Keep at least one break-glass administrator path that you test before the policy goes live, and confirm which token types each administrator holds. Apply the change to a non-production realm first and record the rollback steps before enforcing anything in production.
Policy changes without a topology check
Changing authentication policy on one server without checking the replication topology can leave replicas enforcing different rules for the same service. Before any change, confirm that every replica is healthy and that the change has replicated, then test logins against more than one replica. The 4.13.4 release notes describe hardened authentication checks across the API, so confirm the patch level of every server in your topology and record the result before you change policy.
What teams ask before enforcing MFA per service in FreeIPA
What makes enforcing MFA per service in FreeIPA more or less work?
The effort follows the number of services, the mechanisms you allow for each one, the client platforms that must present them, and the trust relationships that bring in users from outside FreeIPA. Each service needs its own decision about which authentication indicator it requires, which Kerberos ticket policy applies, and which fallback users may take. A small set of Linux hosts with one mechanism, such as OTP, is a contained job. Adding smart cards, a RADIUS proxy to an existing OTP system, or an external identity provider adds configuration and test cases on both the server and the client side. Ask any partner to price the work from a written list of services, mechanisms and platforms, and to show which items are one-time configuration and which recur as token, policy or user administration.
How long does a pilot for per-service MFA take?
The duration of a pilot depends on how many services are in the first wave, how many mechanisms each one must accept, whether test accounts and a staging FreeIPA topology already exist, and how quickly change windows can be booked. A pilot usually covers one or two low-risk services, a small group of test users, and a rollback path, before wider rollout. Teams often lose more time waiting for approvals and for tokens to be issued than on configuration. Confirm the pilot exit criteria in writing before work starts, including which login paths were tested, which failure cases were checked, and who signs off on each service.
What must our team provide before the work starts?
The work moves faster when your team supplies the following before kickoff:
- Named identity owners who decide which users, groups and roles are in scope for each service.
- A service inventory listing hosts, applications, protocols and the authentication path each one uses today.
- Test accounts in every relevant group, plus a staging FreeIPA environment that matches production versions.
- Change windows for each affected service, and an agreed rollback procedure.
You should also name the people who handle help desk calls during rollout and who approves token recovery. Without these, configuration often stops at the first decision that nobody can make.
Can our internal team enforce MFA per service without a partner?
An internal team with working FreeIPA administration experience can often do the work alone, especially for a small number of services and one mechanism. The harder parts are usually Kerberos ticket behavior across clients, testing every login path including SSH, console and web, and handling exceptions cleanly. Teams that lack recent FreeIPA administration, or that must support smart cards or trust relationships at the same time, tend to benefit from a fixed-scope engagement with written deliverables. DeployOpen plans, implements, documents and tests this kind of configuration inside your own infrastructure, but it does not issue audit reports or certifications, so your assessors still need evidence from your environment.
How do we handle Active Directory users who sign in through a trust?
Active Directory users reach FreeIPA services through a cross-forest trust, so their authentication depends on what the AD side can actually present. Before writing any indicator rule, confirm which authentication methods the AD users can use, how their tickets are issued, and whether Kerberos FAST is in place for the trust. Some MFA settings that work for native FreeIPA users do not apply cleanly to trusted users, so each service that accepts them needs its own test. The trust also requires a DNS domain that does not overlap with any AD forest domain. Treat AD users as a separate test group with their own acceptance criteria rather than assuming native behavior carries over.
What changes for users once MFA is enforced per service?
Users see a second factor only on the services you choose, so the everyday change depends on which applications and hosts fall under the new rule. Typical changes include enrolling a software or hardware token, entering a one-time code at login for protected services, and receiving a different error when a service rejects a ticket that lacks the required indicator. Users with lost or unregistered tokens need a documented recovery path, and their help desk must know it before the first change window. Communicate the affected services, enrollment steps and recovery contacts in advance, and test the messages with a small group.
What to confirm in your environment before you rely on indicators
Authentication indicators only work when every link in the chain honors them: the FreeIPA release, the client platform, the SSSD version, the trust configuration and the services themselves. The cards below list what to verify, and each item should be confirmed in the vendor documentation or a lab test before any service is restricted.
Indicator names and ticket policy options
Confirm which authentication indicator names and ticket policy options your FreeIPA release supports, and how they map to the OTP, smart card and external IdP mechanisms you plan to require. The names and options differ between releases, so do not copy values from examples or older guides. Record the exact names your servers accept, then test that a ticket issued by each mechanism carries the expected indicator before writing any service rule.
Client platform and SSSD version support
Check whether each client operating system and its SSSD version honors the indicator, since a client that ignores it will either fail closed or quietly issue a weaker ticket. Test on every distribution in your fleet, including the versions your teams run on laptops and bastion hosts. Note that a single successful test on one platform does not show that the others behave the same way.
Active Directory users through a trust
Confirm how indicators behave for AD users who authenticate through a cross-forest trust, because the trust path can change which mechanisms and ticket attributes reach the Linux host. Check the trust type and the ID mapping in use, and test a real AD login against each restricted service. Do not assume that an indicator set for native FreeIPA users applies to trusted users.
Kerberos FAST dependency
Confirm that Kerberos FAST is enabled wherever two-factor authentication runs, because FreeIPA's OTP checks depend on it and disabling it for AD trusts can break MFA in mixed environments. Verify the setting on the KDC and on each affected client, then repeat the login test after any change. Treat this as a prerequisite check rather than an optional tuning step.
FIPS limits for RADIUS-proxied OTP
Confirm whether your FIPS-enabled hosts can proxy OTP checks to an existing RADIUS server, since FIPS mode can restrict the algorithms and token types that work. Ask the RADIUS vendor and FreeIPA documentation which combinations are supported, and test the full login path on a FIPS host before you rely on it for a restricted service. Document any service that must fall back to a different mechanism.
Smart card login and service ticket handling
Confirm that your clients support smart card login with the certificate mapping you have chosen, and that each target service accepts and renews Kerberos tickets the way you expect. Some services cache credentials, refuse renewal or ignore indicator-based restrictions, so test ticket lifetime, renewal and re-authentication against each one. Record the results so the restriction list reflects tested behavior, not assumptions.
How DeployOpen scopes and delivers per-service MFA on FreeIPA
DeployOpen plans, implements, tests and documents FreeIPA deployments on servers you control, including the authentication indicator design that decides which services require OTP, smart card or external IdP login. Engagements are fixed-scope, with the service list, policy design and acceptance tests agreed in writing before work starts.
How we scope
- Inventory every service, host and login path that could be restricted by an authentication indicator
- Agree in writing which services require OTP, smart card or external IdP authentication, and which must stay available
- Confirm the Kerberos FAST position for each client group and any Active Directory trust before policy changes
How we build
- Configure authentication indicators and ticket policy per mechanism on the IPA servers, in a staged order that keeps core services reachable
- Test each restricted service with OTP, smart card and fallback logins on representative clients, then record the results
- Keep rollback steps for every policy change and apply changes to a non-production replica topology first
How we hand over
- Deliver a service-by-service policy register showing the required indicator, ticket lifetime and owner for each
- Document the acceptance tests, the rollback procedure and the list of core services that must never be restricted
- Walk your administrators through changes, lockout recovery and how to add a new service to the policy
How we support
- Review policy drift and new FreeIPA releases before upgrades, using the release notes for each version you run
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped in writing
- Run periodic verification of restricted services after identity, client or certificate changes in your environment
