When FreeIPA passkeys fit a Linux login program
A team that wants to move Linux logins off passwords on servers it controls can use FreeIPA passkeys, but only for a specific slice of its estate. FreeIPA stores each user's public passkey credentials and passkey settings, while SSSD on the client performs the authentication. The initial implementation, introduced in the FreeIPA 4.11.0 release, supports only physical FIDO2 devices and needs SSSD 2.9.1 or later with passkey support enabled. The question for the program is therefore less about whether passkeys are secure and more about whether every client in scope runs a supported SSSD build and whether users can be issued a physical security key.
Passkeys fit best when the goal is phishing-resistant, passwordless sign-in for named users on enrolled Linux machines, and when the team can budget for hardware keys and accept that software-only passkeys are not yet covered. OTP tokens remain the better fit where users need a software or hardware one-time code and the rest of the stack already consumes OTP through RADIUS or Kerberos. Smart cards suit environments with an existing PKI and card issuance process. External identity providers suit organizations whose primary identity lives outside IPA. Confirm with your own estate inventory which distributions ship the required SSSD version before you commit to a design.
Before you pilot, check the two gaps the project listed at the 4.11.0 release: enrolling hosts with passwordless authentication only, and logging in to the FreeIPA Web UI with passwordless methods without Kerberos. Plan for both as ongoing dependencies on password or Kerberos paths for host enrollment and administrative access, and document the fallback. Ask your FreeIPA partner or the upstream release notes whether either gap has closed in the release you intend to run, and test recovery for lost keys before users depend on them.
How IPA and SSSD split passkey responsibilities
FreeIPA splits passkey work between the server and the Linux client. IPA keeps each user's public passkey credentials and passkey settings in the directory, while SSSD on the client performs the authentication. The cards set out what each side holds, the version and configuration gates, and the gaps that still shape host and Web UI design.
IPA holds public credentials
IPA stores each user's public passkey credentials and passkey settings as directory data. Only public key material is held on the server, so IPA has nothing it could use to sign in as the user. Check who can register or remove a credential, and confirm that your offboarding process removes credential entries when a user leaves or loses a key. Confirm with the project how credential entries replicate across your servers before you rely on any replica for logins.
SSSD performs the authentication
The check happens on the client, in SSSD, which takes the authenticator's signed response and verifies it against the public credential that IPA supplied. Every host where you expect passkey logins needs SSSD with passkey support enabled, plus a FIDO2 security key the user can reach at the login prompt. Inventory which hosts meet that bar before you ask users to register keys, because a user cannot log in to a host that cannot run the check.
SSSD version floor
The 4.11.0 release notes require SSSD 2.9.1 or later with passkey support enabled. Treat that version as the minimum for planning, and check what each distribution actually ships, since a host with an older SSSD will not accept passkey logins even when IPA is current. Ask your platform team to report the SSSD version and passkey configuration for each host, and keep that report with your client enrollment records.
Physical FIDO2 devices only
The initial implementation accepts only physical FIDO2 devices, such as hardware security keys. Platform authenticators built into laptops or phones, and synced passkeys from a password manager, fall outside that first release, so leave them out of your rollout population. Confirm the current list of supported authenticator types with the project before you size the user base around any other device, because later 4.x releases may have changed this scope.
Passwordless gaps at release
At 4.11.0, two pieces were missing: enrolling hosts with passwordless authentication alone, and logging in to the FreeIPA Web UI with passwordless methods without Kerberos. Until those gaps close in your version, host enrollment and browser login need another method. Document a fallback for both, and recheck the gap list against the release notes for the exact version you deploy before you set a policy that depends on it.
Shared directory and Kerberos stack
Passkey data lives in the same stack as the rest of IPA. The About page describes 389 Directory Server as a multi-master LDAPv3 directory for users, groups, hosts and policies, with MIT Kerberos providing single sign-on and Dogtag issuing certificates. A change to a user's passkey entry therefore touches the directory and the Kerberos path, so test a credential change end to end on a replica, from registration through to a Kerberos ticket, before you run it in production.
Which authentication option fits which login path
Passkeys are the newest option in this set. The FreeIPA 4.11.0 release notes say IPA stores each user's public passkey credentials and passkey settings, while SSSD on the client performs the authentication. The initial implementation supports only physical FIDO2 devices and needs SSSD 2.9.1 or later with passkey support enabled.
- Client requirement: Every machine where passkey login is expected needs SSSD 2.9.1 or later, with passkey support turned on in its configuration. Check the version your distribution ships.
- Device type: The initial implementation covers only physical FIDO2 security keys, so plan your key inventory around that.
- Host enrollment gap: The release notes list enrolling hosts with passwordless authentication only as missing, so host enrollment still depends on a password or Kerberos path.
- Web UI gap: Logging in to the FreeIPA Web UI with passwordless methods, without Kerberos, was also missing at release.
Confirm with the FreeIPA release you run whether these two gaps are closed, because later releases may differ from the 4.11.0 notes.
Smart card login uses X.509 certificates held on a card or token to prove identity. The certificates may come from the Dogtag certificate authority integrated in FreeIPA or from an external CA, depending on your policy. The main design work is the certificate mapping that ties each certificate to the correct FreeIPA user. The supplied sources do not give the full setup steps, so confirm the details against the FreeIPA version and client stack you run.
- Certificate source: Decide whether the integrated CA or an external CA issues login certificates, because the trust chain and renewal process differ between them.
- Certificate mapping: Plan how each certificate maps to exactly one user. Mapping errors are a common cause of login failures, so test with a sample of accounts first.
- Card and middleware: Verify the card model, reader drivers and PKCS#11 middleware on each client distribution you support.
- Revocation and renewal: Define how lost cards are revoked and how certificate expiry is tracked, since a card stops working once its certificate expires or is revoked.
Ask your FreeIPA support contact to confirm the mapping method and client packages for your release before you buy cards.
FreeIPA supports two-factor authentication with HOTP tokens defined in RFC 4226 and TOTP tokens defined in RFC 6238. Software tokens and hardware tokens such as YubiKeys both fit this model. FreeIPA can also proxy OTP checks to an existing RADIUS server, which suits sites that already run one for VPN or network access. The FreeIPA OTP design page covers the token model in detail.
- Token types: HOTP is counter-based and TOTP is time-based. Choose the type that your users' apps and hardware support.
- Hardware keys: YubiKeys are named as hardware tokens. Confirm the OTP slot and mode your key uses before rollout.
- RADIUS proxy: The existing RADIUS server makes the OTP decision, so its availability becomes part of your login path.
- Second factor: OTP adds a factor on top of the password, so this path does not provide passwordless login. Plan how users recover when they lose a token.
Check token enrollment and proxy settings for your FreeIPA version before you move a user group onto this path.
External identity providers let a user sign in through a web identity system instead of relying only on credentials stored in FreeIPA. The supplied sources do not describe a passwordless login flow through an external provider for FreeIPA logins, so treat this path as a design question to settle before you commit to it. Your integration choices depend on the FreeIPA and SSSD versions you run, and on the identity provider you already operate.
- Integration method: Confirm which mechanism your FreeIPA and SSSD versions support for linking an external provider to Linux logins.
- Dependency: The external provider becomes part of the login path, so an outage there affects Linux logins for federated users.
- Break-glass access: Decide how administrators sign in when the provider is unavailable, and keep that path tested.
- Identity mapping: Map accounts between the provider and FreeIPA so that each person has one identity in each system.
Ask for a written test plan that covers login, lockout and offline behavior before you move any users onto this path.
Enabling passkeys in IPA and SSSD step by step
This sequence moves a FreeIPA domain from confirmed prerequisites to passkey logins that are tested on each client distribution, with a check at every step so problems surface before users depend on them.
Confirm the IPA release and SSSD version
Check the FreeIPA server release and the SSSD version on every Linux client that will accept passkey logins. The FreeIPA 4.11.0 release notes say the initial implementation needs SSSD 2.9.1 or later with passkey support enabled, so any client below that version cannot complete the flow. Record the results per host and per distribution. The step is done when every client in the pilot scope reports a qualifying SSSD version and you have a written inventory of exceptions to fix or exclude.
Enable passkey support in SSSD on clients
On each client in the pilot group, enable passkey support in the SSSD configuration and restart the SSSD service. The exact configuration key and file should be taken from the SSSD documentation for your version rather than from memory, and the change should be applied through your normal configuration management so it is repeatable. Confirm the setting is active by checking the effective SSSD configuration and the service status on each host. The step is complete when every pilot client shows the setting active and SSSD starts without errors in its logs.
Confirm the FIDO2 device is physical
The initial implementation supports only physical FIDO2 devices, so software authenticators and platform passkeys are out of scope for this sequence. Issue or identify a physical FIDO2 security key for each pilot user and document the make and model you approved. Confirm with your vendor and your own test that the device works with the client's USB and PAM stack before registering it. The step is complete when each pilot user has an approved physical key and your test login with that key succeeds on a single reference client.
Register each user's FIDO2 credential in IPA
Register the public credential for each pilot user in IPA. According to the FreeIPA 4.11.0 release notes, IPA stores the public passkey credential and passkey settings while SSSD performs the authentication, so only public material enters the directory. Ask each user to confirm the registration with their own key present. The check is that the credential appears in the user's record when you query it through the IPA tools, and that the user can see it in their own account view. Do not proceed for any user whose credential is missing or attached to the wrong account.
Run a pilot with a small user group
Select a small group of users and clients that reflect your real mix of hosts, then have them log in with their passkeys over the scenarios you rely on, such as console, SSH and any desktop login. Keep password fallback available for the pilot so a failed test does not lock anyone out. Record each failure with the host, distribution, SSSD version and user, and fix causes before widening scope. The step is complete when the pilot group logs in repeatedly without error and the failure log is empty or explained.
Verify logins on each distribution
Repeat the verified login tests on every Linux distribution and release present in your fleet, because SSSD packaging and PAM behavior can differ between them. Use the same test script for each platform so results compare directly. Confirm that the SSSD version on each reference host matches your inventory from the first step. The step is done when every distribution in scope has a passing login record and any unsupported combination is documented as excluded from passkey logins.
Document gaps and keep fallback paths
Record the gaps the project lists at the 4.11.0 release: enrolling hosts with passwordless authentication only, and logging in to the FreeIPA Web UI with passwordless methods without Kerberos. Confirm with the FreeIPA project's current documentation whether either gap is closed in your release before you plan around it. Document which hosts, administrative paths and Web UI logins still require passwords or other factors, and keep those fallback methods in your runbooks. The step is complete when a signed-off document lists every login path, its method and its owner.
What still needs a password, OTP or Kerberos fallback
The FreeIPA 4.11.0 release notes list two gaps that matter for any passwordless rollout: enrolling hosts with passwordless authentication only, and logging in to the FreeIPA Web UI with passwordless methods without Kerberos. Neither gap blocks passkey use for end-user logins on Linux clients, but both mean that some administrative paths still depend on a password, an OTP token or a Kerberos ticket obtained another way. Plan the rollout around those paths rather than assuming that a passkey can cover every login an administrator performs.
In practice, keep a documented fallback for host enrollment. Ask the team that enrolls machines to confirm which credential it uses today, whether that is an administrator password, a one-time enrollment method or an existing Kerberos ticket, and keep that method available until the release notes for your version show passwordless enrollment as supported. Do the same for Web UI administration: confirm that an administrator can still reach the UI with Kerberos or a password, and test that path after each upgrade, since a single broken fallback can lock out the people who would repair an identity problem.
Verify the status yourself before you change the plan. Open the release notes for the exact FreeIPA version you run, check the section on passkeys and passwordless authentication, and record the date you checked. Because the 4.11.0 notes describe the state at release, a later 4.x release may close one or both gaps, but that is only true if its notes say so. Treat the current notes as the source of truth and keep the fallback decisions in your runbook with the version they apply to.
Security and operational risks of a passwordless rollout
A passwordless rollout moves trust from a memorized secret to devices, tokens and the directory that stores them. The cards below cover where that shifts risk: lost credentials, fallback paths, the IPA servers that hold the keys and the CA duties that sit on the first server. Each one has a check to make before users are moved off passwords.
Lost or shared passkeys
A FIDO2 security key is a physical object, so loss, theft or informal sharing becomes the main credential risk. Because IPA stores only the public passkey credential, a lost key cannot be recovered from the directory; the user needs a new key enrolled. Before go-live, define who approves re-enrollment, how the user proves identity during the request, and how a lost key is revoked so it stops working at once. Confirm this flow with your help desk before the first pilot group.
Recovery path for locked-out users
Passwordless users who lose their only authenticator need a controlled way back in, and an ad hoc password reset can quietly reintroduce the weakest credential. Document a recovery procedure that names the approver, the identity check and the temporary access method, such as a one-time token or a supervised smart card issue. Test the procedure on a pilot account so the help desk has run it before a real lockout occurs.
Keeping OTP or smart card fallback
During transition, keep a second factor that works without the new passkey, so a broken SSSD configuration or an unsupported client does not block every user. FreeIPA supports HOTP and TOTP tokens and smart cards, which can serve as the fallback path. Decide which accounts keep the fallback, for how long, and who can retire it. Remove the fallback only after the passkey path has been tested on every client type in scope.
Protecting IPA servers and their backups
Passkey public keys, Kerberos keys and certificate data all live in the IPA directory, so a compromised or poorly restored server exposes the whole identity store. Follow the deployment guidance for replica counts and dedicated hardware, and keep ipa-backup output in controlled storage. Restore only current backups, because the backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Rehearse restores in a separate environment.
First server holds certificate and CRL duties
By default the first IPA server handles certificate renewal and CRL publication. If that server fails or is retired without a plan, renewals and revocation information can stop, and passwordless logins that depend on certificates or Kerberos service keys will fail later. Check which server is first in each topology, confirm that CA duties can be moved, and monitor certificate expiry on that host as part of routine operations.
Applying the 4.13.4 security release
FreeIPA 4.13.4 fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. Because these fixes touch the authentication path that passkeys rely on, schedule the update before widening the passwordless pilot and read the release notes for the affected components. Confirm the version on every replica, since a mixed-version topology can behave differently during the rollout.
Questions teams ask before moving Linux logins to passkeys
What does a FreeIPA passkey project cost and what drives the effort?
The cost is set by the written scope, not by a list price, and DeployOpen does not publish one. Most of the effort sits in the parts around the passkey itself: the FreeIPA servers already in place, the number of Linux hosts and distributions, how many users will enroll, and whether OTP, smart cards or an external identity provider must keep working during the transition. Each of those adds design, testing and change work. Ask a partner to price the one-time items (design, pilot, rollout, documentation) separately from recurring items such as upgrades, patch cycles and support. The project's own release notes name SSSD 2.9.1 or later as a prerequisite, so ask whether client upgrades are in or out of scope.
How long does a passkey pilot take?
Duration depends on what the pilot must prove, not on the passkey feature alone. A useful pilot covers one or more FreeIPA servers at the current release, a small group of enrolled hosts on a supported SSSD version, a defined set of users with physical FIDO2 devices, and a rollback path. The release notes for the initial implementation support only physical FIDO2 devices, so any plan that assumes other authenticator types needs a separate confirmation step. Ask the partner to show the timeline by milestone and to name the entry criteria, such as the SSSD version on each host and the FreeIPA release on each server, before any user is asked to enroll.
What must our internal team provide before the work starts?
Your team provides access, decisions and records. You need named owners for the FreeIPA servers, the Linux fleet, the identity policy and the helpdesk process. You also need an inventory of hosts with their operating system and SSSD version, a list of user groups and their device needs, and the current password, OTP and smart card policies. Access to the target infrastructure, change windows and a test environment that resembles production are also required. Confirm early whether your servers run a release that includes passkey support, since the initial implementation requires SSSD features that may not exist on older hosts.
Can our team deliver passkeys on FreeIPA without an outside partner?
Yes, a capable internal team can do it, provided it has FreeIPA, Kerberos and SSSD experience and the time to test. The risk points are the ones that break logins: Kerberos and SSSD configuration on every host, fallback paths during rollout, and replication behavior when servers change. The project lists host enrollment with passwordless authentication only and Web UI login without Kerberos as missing at the 4.11.0 release, so your team must plan around those gaps. A partner adds value through a written scope, a tested rollout plan and an independent review, which many teams find useful when the work is not part of their normal cycle.
Do passkeys replace OTP tokens or smart cards in FreeIPA?
Not automatically. FreeIPA supports HOTP and TOTP tokens, including software and hardware tokens, and can proxy OTP checks to an existing RADIUS server. Smart cards and certificate mapping are a separate path. Passkeys add a FIDO2 option for users who hold physical devices, and the initial implementation stores their public credentials in IPA while SSSD performs the authentication. Decide per user group whether passkeys replace, sit beside or follow OTP and smart cards, and record the fallback for lost devices. Confirm the authentication indicators and Kerberos settings each option needs before you remove an existing method.
What should a partner quote include for a passkey engagement?
A quote should list the scope in writing: the FreeIPA releases and SSSD versions in use, the platforms and distributions covered, the user groups and device types, and the authentication methods that stay in place. Ask for deliverables by name, such as a design document, a tested pilot, rollout runbooks, helpdesk procedures, backup and rollback steps, and handover training. Ask which items are one-time and which recur, what triggers a change request, and how dependencies on your own teams are handled. Ask what the partner will not do, including any host enrollment or Web UI login work the project still lists as open. Also ask how timelines are tied to your change windows.
What should we check on FreeIPA before enabling passkeys in production?
Check the FreeIPA server release, the SSSD version on every client, and whether passkey support is enabled in SSSD. Confirm that replicas and the first server behave as expected after any change, because backup guidance warns that restoring an outdated backup into an active replica topology can break replication. Verify Kerberos login, OTP login and smart card login still work for the groups that need them. Test lockout and password policy behavior with passkeys in place, and confirm that your audit records show which authentication method was used. Ask the partner to document each check and the expected result so your operations team can repeat them after upgrades.
How DeployOpen scopes and delivers FreeIPA passkey work
DeployOpen plans, implements, hardens, documents and supports FreeIPA on servers and infrastructure you control. For passkeys and passwordless authentication, we start from your login paths, client fleet and SSSD versions, then agree the boundaries in writing before any change is made.
How we scope
- Inventory which hosts, distributions and SSSD versions must support passkey logins before any design work starts
- Document which login paths stay on passwords or OTP during transition, such as Web UI and host enrollment
- Agree deliverables, test criteria and timelines in a fixed-scope written statement before work begins
How we build
- Configure user passkey credentials and passkey settings in IPA, with SSSD authentication validated on each client class
- Test FIDO2 physical device enrollment, fallback paths and lockout behavior against your written login policy
- Run a pilot group of users and hosts, recording failures, support tickets and SSSD log findings for review
How we hand over
- Deliver runbooks for enrollment, device loss, credential revocation and rollback to password or OTP methods
- Provide configuration records, test evidence and a gap register listing unsupported flows for your security team
- Walk your engineers through operations so they can run the deployment without DeployOpen involvement
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately
- Review SSSD and FreeIPA release notes for changes that affect passkey logins before each planned upgrade
- Prepare control evidence for your compliance assessment, while independent auditors issue any formal opinion
