Passkey Configuration

Overview

Passkey configuration defines global settings for FIDO2/WebAuthn authentication in FreeIPA. Passkeys provide phishing-resistant, passwordless authentication using hardware security keys (like YubiKeys), built-in platform authenticators (fingerprint readers, facial recognition), or virtual authenticators.

Unlike traditional passwords or even OTP tokens, passkeys use public-key cryptography where the private key never leaves the user’s device. This eliminates password theft, credential stuffing, and phishing attacks—even if an attacker compromises the IPA server, they cannot authenticate as users because private keys remain on user devices.

FreeIPA’s passkey support is built on industry standards:

FIDO2 (Fast IDentity Online): Authentication standard using public-key cryptography for passwordless and multi-factor authentication.

WebAuthn (Web Authentication API): W3C standard for web-based authentication via FIDO2. While primarily designed for web browsers, SSSD implements WebAuthn for command-line and graphical login.

CTAP (Client to Authenticator Protocol): Communication protocol between client devices and authenticators (security keys, platform authenticators).

Passkey configuration in IPA is minimal by design—most complexity is handled by SSSD clients and user devices. The primary global configuration is whether to require user verification during authentication.

User Verification

User verification is the process of confirming that the person using the passkey is the authorized user. This provides the “something you are” or “something you know” factor:

Verification methods:

PIN: User enters a PIN configured on the security key or device
Biometric: Fingerprint scan, facial recognition, or iris scan
External verification: Password entry, pattern lock, or other device-level authentication

Verification options (--require-user-verification):

TRUE (default): IPA requires user verification for all passkey authentications

Provides true multi-factor authentication (possession + verification)
Prevents unauthorized use of stolen security keys
More secure but requires compatible authenticators

FALSE: IPA does not require user verification

Relies solely on possession of the authenticator (single-factor)
More convenient, works with simpler security keys
Suitable for use in combination with passwords or other factors

The verification requirement is enforced during passkey registration and authentication. If set to TRUE, only authenticators capable of user verification can be registered, and all authentications must include verification.

Passkey Authentication Architecture

Registration Flow

User initiates registration: Via SSSD client (console or graphical login screen)
SSSD requests registration: Contacts IPA server for passkey registration challenge
IPA generates challenge: Creates cryptographic challenge and relying party information
User interacts with authenticator: Inserts security key, touches button, provides verification
Authenticator generates keypair: Creates new public/private key pair (private key never leaves device)
SSSD sends public key to IPA: Registers the public key and authentication mapping in user entry
Registration complete: User can now authenticate with passkey

Authentication Flow

User initiates login: At SSSD-enabled login prompt
SSSD requests authentication: Contacts IPA server for passkey authentication challenge
IPA generates challenge: Creates cryptographic challenge for registered passkeys
SSSD forwards challenge to authenticator: User device receives challenge
User interacts with authenticator: Touches button, provides verification (if required)
Authenticator signs challenge: Uses private key to sign (private key never transmitted)
SSSD sends signed response to IPA: IPA verifies signature with stored public key
IPA validates signature: Confirms authenticity and issues authentication token
Login succeeds: User gains access

This architecture ensures:

Private keys never leave user devices
Each authentication requires physical presence (user must touch authenticator)
Optional user verification adds second factor
Phishing-resistant (challenge-response is site-specific via relying party ID)

Relying Party Configuration

The Relying Party (RP) identifier is automatically configured based on the IPA domain. For example, an IPA domain example.com uses example.com as the relying party ID.

The RP ID is critical for security:

Authenticators bind private keys to the RP ID
Credentials from one RP ID cannot be used for different RP IDs
This prevents passkeys registered for attacker.com from being used for example.com

Automatic configuration: IPA automatically derives the RP ID from the IPA realm/domain. Administrators do not typically modify this.

RP name: Human-readable organization name displayed during registration (e.g., “Example Corporation IPA”). Derived from IPA realm but can be customized via SSSD configuration.

Passkey vs Other Authentication Methods

Passkey vs Password

Security:

Passkeys: Phishing-resistant, no credential theft, no password reuse
Passwords: Vulnerable to phishing, credential stuffing, weak passwords

User Experience:

Passkeys: Quick touch/biometric, no memorization required
Passwords: Requires remembering and typing complex strings

Recovery:

Passkeys: Losing authenticator requires re-registration (backup authenticators recommended)
Passwords: Can be reset via recovery mechanisms

Passkey vs OTP

Security:

Passkeys: Asymmetric crypto, phishing-resistant, device-bound
OTP: Symmetric crypto, vulnerable to phishing/MITM, secret can be compromised

User Experience:

Passkeys: One touch (with optional verification)
OTP: Type 6-8 digit code that changes frequently

Setup:

Passkeys: Requires compatible hardware/platform
OTP: Works with any smartphone app or hardware token

Passkey vs Certificate

Scope:

Passkeys: User authentication (login)
Certificates: User + service authentication, encryption, signing

Management:

Passkeys: User self-service via SSSD
Certificates: Centrally managed via IPA CA, certmonger

Hardware:

Passkeys: Security keys, platform authenticators
Certificates: Smart cards, HSMs, software stores

Examples

View Current Configuration

# Show passkey configuration (summary)
$ ipa passkeyconfig-show
  Require user verification: TRUE

View All Configuration Attributes

# Show complete configuration including LDAP attributes
$ ipa passkeyconfig-show --all
  Require user verification: TRUE
  dn: cn=passkeyconfig,cn=etc,dc=example,dc=com
  objectclass: top, nsContainer, ipaPasskeyConfigObject

Require User Verification

# Enable user verification requirement (multi-factor)
$ ipa passkeyconfig-mod --require-user-verification=TRUE
  Require user verification: TRUE

This setting:

Requires all new passkey registrations to use authenticators capable of user verification
Requires all passkey authentications to include user verification
Provides true two-factor authentication (possession + verification)
Users with verification-incapable authenticators cannot register

Disable User Verification Requirement

# Disable user verification requirement (single-factor)
$ ipa passkeyconfig-mod --require-user-verification=FALSE
  Require user verification: FALSE

This setting:

Allows registration of authenticators without verification capability
Allows authentication without user verification
Provides single-factor authentication (possession only)
More compatible with basic security keys

Check Verification Requirement Before Rollout

# Verify current setting before deploying passkeys
$ ipa passkeyconfig-show
  Require user verification: TRUE

# If allowing basic authenticators without verification, disable verification
$ ipa passkeyconfig-mod --require-user-verification=FALSE

Best Practices

Security Configuration

Enable user verification for high-security environments: Set --require-user-verification=TRUE when deploying passkeys as primary authentication in sensitive environments. This provides true multi-factor authentication.

Disable verification for convenience: Set --require-user-verification=FALSE when using passkeys in combination with other factors (password + passkey) or for lower-security environments where convenience is prioritized.

Consistent policy: Don’t change the verification requirement frequently. Users who registered passkeys under one policy may have authenticators incompatible with a new policy.

Document authenticator requirements: Clearly communicate to users whether verification-capable authenticators are required. This affects purchasing decisions for security keys.

Authenticator Selection

Verification-capable devices (for TRUE setting):

YubiKey 5 series with PIN or fingerprint
Platform authenticators (Windows Hello, Touch ID, Face ID)
FIDO2-certified keys with biometric sensors

Basic authenticators (for FALSE setting):

YubiKey 4 series
Basic FIDO2 security keys without verification
Virtual authenticators

Deployment Strategy

Pilot program: Deploy passkeys to a small group first, test registration and authentication workflows, gather feedback before organization-wide rollout.

Backup authenticators: Require users to register at least two passkeys (primary + backup) to prevent account lockout if primary is lost.

Gradual rollout: Don’t mandate passkey-only authentication immediately. Allow password + passkey combination during transition period.

Training: Provide clear instructions for passkey registration via SSSD. The enrollment process differs from web-based passkey registration users may be familiar with.

Hardware procurement: If requiring user verification, ensure users have compatible authenticators before mandating passkey authentication.

User Experience

Clear error messages: Configure SSSD to provide helpful error messages when passkey authentication fails (wrong authenticator, verification failed, etc.).

Multiple authenticator support: Allow users to register multiple passkeys (work laptop platform authenticator, security key for travel, backup key in safe).

Self-service management: Enable users to register and remove their own passkeys via SSSD without administrator intervention.

Account recovery: Maintain alternative authentication methods (password, OTP) as fallback if all passkeys are lost.

Operational Practices

Verification requirement stability: Choose verification requirement based on long-term security policy, not temporary needs. Changing it disrupts users with incompatible authenticators.

Monitor registration success rate: Track how many users successfully register passkeys vs. failures. High failure rates may indicate authenticator compatibility issues.

Helpdesk preparation: Train support staff on passkey concepts, troubleshooting registration failures, and guiding users through verification requirements.

Inventory management: For organization-issued security keys, maintain inventory of which users have which keys (but never store private keys—those remain on devices).

Deprecation planning: If transitioning from non-verification to verification-required, provide transition period for users to obtain compatible authenticators.

Integration Points

SSSD Clients

Passkey registration and authentication are handled entirely by SSSD on client systems:

SSSD retrieves passkey configuration from IPA
Users register passkeys via SSSD prompts (console or graphical)
SSSD stores passkey mappings in user entries
Authentication challenges flow through SSSD

Requirements: SSSD 2.9+ with passkey support enabled

User Entries

Passkey public keys and authentication mappings are stored in user LDAP entries:

Objectclass: ipaPasskeyUser (auxiliary, added to user entry)
Attribute: ipapasskey (multi-valued, optional)
Format: passkey:credentialid,pubkey (base64-encoded credential ID and public key)
Multiple passkeys per user supported
Users can manage their own passkeys (with appropriate permissions)

Authentication Types

Passkeys can be used in various authentication scenarios:

# Passkey-only authentication
$ ipa user-mod alice --user-auth-type=passkey

# Password OR passkey (either factor)
$ ipa user-mod alice --user-auth-type=password|passkey

# Password AND passkey (both factors required)
$ ipa user-mod alice --user-auth-type=password,passkey

See user topic for authentication type configuration.

WebAuthn/FIDO2 Ecosystem

IPA’s passkey implementation follows W3C WebAuthn and FIDO Alliance specifications:

Compatible with standard FIDO2 authenticators
Uses standard challenge-response protocol
Supports CTAP 1 and CTAP 2 protocols
Attestation verification (optional)

Platform Authenticators

Platform authenticators are built into devices:

Windows: Windows Hello (fingerprint, facial recognition, PIN)
macOS: Touch ID, Face ID (via compatible Macs)
Linux: Fingerprint readers (via fprintd), TPM-backed virtual authenticators

SSSD integrates with platform authenticators via standard FIDO2/WebAuthn APIs.

Security Keys

External security keys connect via USB, NFC, or Bluetooth:

YubiKey 4/5 series
Google Titan Security Keys
Feitian FIDO2 keys
Thetis FIDO2 keys
Any FIDO2-certified authenticator

Kerberos Integration

Passkey authentication integrates with Kerberos:

User authenticates with passkey via SSSD
SSSD obtains FAST armor ticket
IPA KDC validates passkey signature
TGT issued upon successful validation
User receives Kerberos credentials

This enables passkey-based Kerberos authentication for all IPA-integrated services.

Multi-Factor Authentication

Passkeys can serve as one factor in multi-factor authentication:

Passkey alone: Possession factor (if verification disabled)
Passkey with verification: Possession + knowledge/biometric (two-factor)
Password + Passkey: Knowledge + possession (two-factor)
Password + Passkey with verification: Knowledge + possession + biometric (three-factor)

Configure via user authentication types.

Account Recovery

If users lose all passkeys:

Authenticate via alternative method (password, OTP if configured)
Register new passkeys via SSSD
Remove old/lost passkey entries

Administrators can remove lost passkey mappings from user entries if needed.

Security Considerations

Phishing Resistance

Passkeys are inherently phishing-resistant:

Private keys never leave authenticator device
Relying party ID prevents cross-site credential use
Challenge-response protocol prevents replay attacks
No secrets to steal from IPA server

Even if users are tricked into touching their authenticator on a phishing site, the credentials won’t work because the RP ID won’t match.

User Verification Security

With verification (TRUE):

Provides true multi-factor authentication
Prevents unauthorized use of found/stolen authenticators
Protects against “evil maid” attacks (physical access to device)

Without verification (FALSE):

Provides single-factor authentication (possession only)
Stolen authenticator can be used to authenticate
Suitable when combined with other factors (password)

Authenticator Loss

If users lose their authenticator:

With backup authenticators: User authenticates with backup, removes lost authenticator entry
Without backup: User must authenticate via fallback method (password, OTP) to register new passkey
No fallback configured: Administrator intervention required

Mitigation: Require users to register multiple passkeys and maintain alternative authentication methods.

Attestation

Passkey attestation provides cryptographic proof of authenticator type and manufacturer:

Enables restricting registration to approved authenticator models
Prevents software-based virtual authenticators (if desired)
IPA currently supports attestation validation (implementation-dependent)

Device Security

Passkey security depends on the security of the authenticator device:

Hardware security keys: High security, tamper-resistant
Platform authenticators: Security depends on device (TPM-backed preferred)
Software authenticators: Lower security, may be extractable

Private Key Protection

Private keys are protected by authenticator hardware or software:

FIDO2 certified keys: Private keys cannot be exported
Platform authenticators: Protected by OS security (keychain, TPM)
Virtual authenticators: May be backed by software, potentially exportable

Best practice: For high-security environments, require FIDO2-certified hardware authenticators.

Backup and Recovery

Unlike passwords, passkeys cannot be “reset” centrally:

Lost passkeys require re-registration
Users must maintain backup authenticators or alternative auth methods
Account lockout is permanent without recovery mechanism

Mitigation: Enforce multiple passkey registration and maintain fallback authentication methods.

Configuration Scope and Granularity

Passkey configuration is global—all users and all passkey authentications use the same user verification requirement. Organizations cannot configure different verification requirements for different user groups (e.g., require verification for administrators but not for general users). This limits security customization options. Workaround: Use different authentication type configurations (user-auth-type) to enforce stricter authentication for high-privilege accounts, such as requiring password+passkey with verification for admins while allowing passkey-only for general users.

Verification Requirement Changes Impact Existing Passkeys

Changing --require-user-verification from FALSE to TRUE doesn’t automatically invalidate passkeys registered without verification capability. Users who registered basic authenticators (no verification) under the FALSE setting will fail authentication if verification is later required. This can cause widespread authentication failures. Before enabling verification requirement, communicate with users to register verification-capable authenticators first, or plan a grace period where both policies are accepted during transition.

No Passkey Revocation List

FreeIPA doesn’t maintain a global passkey revocation list for compromised authenticators. If a specific authenticator model is found to have security vulnerabilities (e.g., extractable private keys), administrators must manually remove all passkeys associated with that authenticator model from all users. This is labor-intensive for large deployments. Implement inventory tracking of authenticator models to enable rapid revocation if needed. Attestation validation (if implemented) can help restrict registration to approved authenticator models.

Passkey Metadata Visibility

Passkey entries in user LDAP records contain metadata about authenticators (credential ID, public key, possibly attestation information). This metadata is visible to administrators and potentially to users with appropriate LDAP read permissions. While public keys are not secret, metadata may reveal authenticator models, registration timestamps, or usage patterns. Restrict LDAP read permissions for ipaPasskey attribute to necessary personnel only. Avoid storing sensitive information in passkey metadata fields.

Platform Authenticator Binding

Platform authenticators (Windows Hello, Touch ID) bind private keys to the specific device’s TPM or secure enclave. If a user’s laptop is replaced or the TPM is reset, all platform-based passkeys become unusable. Users must register new passkeys on the new device. Unlike removable security keys which can transfer between devices, platform authenticators create device-specific dependencies. Educate users to maintain at least one external security key as backup, not rely solely on platform authenticators.

Synchronization and Synced Passkeys

Some passkey providers (e.g., Apple Keychain, Google Password Manager) support “synced passkeys” where private keys are encrypted and synchronized across user’s devices via cloud services. While convenient, this introduces different security properties than device-bound passkeys: private keys potentially exist in cloud storage, multiple devices share credentials, and cloud account compromise may expose private keys. IPA cannot distinguish synced from device-bound passkeys during registration. Organizations requiring highest security should prohibit synced passkeys via policy and attestation validation.

Limited Audit Logging for Passkey Usage

Passkey authentication events are logged in IPA authentication logs, but detailed metadata about which specific passkey (credential ID) was used may not be captured comprehensively. If a user has multiple registered passkeys (laptop, phone, security key), identifying which one was used for a specific authentication requires correlation of multiple log entries. Enhance monitoring to track per-passkey usage patterns for security auditing, especially for detecting unauthorized passkey use or anomalous authentication patterns.

No Centralized Passkey Enrollment Workflow

Unlike certificate-based smartcard deployment where administrators can pre-provision certificates, passkey registration is user-driven via SSSD. Administrators cannot centrally register passkeys for users—users must perform registration themselves. This creates deployment challenges for large organizations: users may defer registration, make mistakes, or register incompatible authenticators. Develop clear enrollment documentation, provide in-person or remote assistance for initial registration, and track enrollment progress to ensure adoption.

Passkey-Only Accounts Vulnerable to Device Loss

Users configured for passkey-only authentication (--user-auth-type=passkey) with single passkey registered face permanent account lockout if they lose their authenticator. Without password or OTP fallback, administrative intervention is required to reset authentication types or register new passkeys. This operational burden grows with user count. Mandate multiple passkey registration (minimum 2) and maintain fallback authentication methods for account recovery, or implement separate emergency access procedures for passkey-only accounts.

Verification Method Transparency

When --require-user-verification=TRUE, IPA requires verification but doesn’t specify which verification method (PIN, biometric, external auth). Different verification methods have different security properties: PIN can be observed or guessed, biometrics can have false accept rates, external auth may be weak. IPA trusts the authenticator’s assertion that verification occurred without validating the method used. For highest security environments requiring specific verification methods (e.g., biometric only), this may be insufficient. Implement policy requiring specific FIDO2-certified authenticators with documented verification methods.

SSSD Client Dependency

Passkey registration and authentication require SSSD 2.9+ with passkey support compiled and enabled. Older SSSD versions, clients without SSSD (e.g., some embedded systems), or operating systems lacking WebAuthn/FIDO2 support cannot use passkey authentication. This creates a heterogeneous authentication environment where some clients support passkeys and others don’t. Maintain alternative authentication methods (password, OTP) for clients incompatible with passkey support. Plan SSSD upgrades across infrastructure before mandating passkey-only authentication.

Use Cases

1. Enabling Passwordless Authentication for Administrators

IT organization wants to deploy phishing-resistant passwordless authentication for admin accounts using YubiKey 5 security keys with PIN verification.

# Enable user verification requirement for true 2FA
ipa passkeyconfig-mod --require-user-verification=TRUE
# Require user verification: TRUE

# Verify configuration
ipa passkeyconfig-show
# Require user verification: TRUE

# Configure admin user for passkey-only authentication
ipa user-mod admin --user-auth-type=passkey

# Verify auth type
ipa user-show admin | grep "User authentication types"
# User authentication types: passkey

# Admin registers YubiKey 5 via SSSD on workstation
# (User inserts key, sets PIN, touches button)
# SSSD prompts: "Touch your authenticator and enter PIN"

# Test authentication
# Admin attempts SSH login
ssh admin@server.example.com
# SSSD prompts for passkey authentication
# User touches YubiKey and enters PIN
# Login succeeds with Kerberos TGT

# No password required - true passwordless authentication
klist
# Ticket cache shows valid TGT obtained via passkey

Result: Passwordless, phishing-resistant authentication deployed for administrators using hardware security keys with PIN verification. No passwords to steal or phish.

2. Hybrid Deployment with Password and Passkey

Organization deploying passkeys gradually, allowing users to use password OR passkey during transition period.

# Disable user verification requirement for broader compatibility
ipa passkeyconfig-mod --require-user-verification=FALSE
# Require user verification: FALSE

# Allows basic security keys without PIN/biometric

# Configure users for password OR passkey (either factor)
ipa user-mod alice --user-auth-type=password,passkey

# Alice can authenticate with either password or passkey
# Registration workflow (user-initiated via SSSD):
# User runs: ipa-passkeyconfig-register
# SSSD prompts: "Insert and touch your authenticator"
# Passkey registered

# Authentication options:
# Option 1: Password
ssh alice@server.example.com
Password: ********
# Login succeeds with password

# Option 2: Passkey
ssh alice@server.example.com
# SSSD detects passkey available
# Prompts: "Touch your authenticator"
# User touches security key
# Login succeeds with passkey

# Users gradually adopt passkeys at their own pace
# After 90% adoption, transition to passkey-only

Result: Flexible deployment allowing gradual passkey adoption. Users choose most convenient authentication method during transition.

3. Requiring Multi-Factor with Passkey and Password

Financial services organization requires two-factor authentication: something you know (password) AND something you have (passkey with verification).

# Enable user verification for true MFA
ipa passkeyconfig-mod --require-user-verification=TRUE

# Configure users to require BOTH password and passkey
ipa user-mod bob --user-auth-type=password|passkey
# Note: Use pipe (|) for AND requirement

# Bob must authenticate with both factors
ssh bob@server.example.com
Password: ********
# SSSD prompts: "Touch your authenticator and verify"
# User touches YubiKey, enters PIN
# Login succeeds only after both factors provided

# Meets multi-factor authentication compliance requirements
# Password (knowledge) + Passkey with PIN (possession + knowledge) = 3 factors technically

Result: Strong multi-factor authentication combining password and passkey with verification. Meets regulatory compliance for financial services.

4. Troubleshooting Verification-Incapable Authenticator

User attempts to register passkey but fails because their authenticator doesn’t support user verification.

# Check current configuration
ipa passkeyconfig-show
# Require user verification: TRUE

# User attempts registration via SSSD
# (User's basic YubiKey 4 doesn't support PIN/biometric)

# Registration fails with error:
# "Authenticator does not support required user verification"

# Options:
# 1. User obtains verification-capable authenticator (YubiKey 5)
# 2. Temporarily disable verification requirement

# If organization policy allows, disable verification
ipa passkeyconfig-mod --require-user-verification=FALSE
# Require user verification: FALSE

# User attempts registration again
# Registration succeeds with basic YubiKey 4

# Note: This reduces security to single-factor (possession only)
# Consider combining with password: --user-auth-type=password,passkey

Result: Verification requirement incompatibility diagnosed and resolved. User educated on authenticator requirements.

5. Transitioning from OTP to Passkeys

Organization wants to migrate from OTP-based 2FA to passkey-based authentication for improved security and user experience.

# Current state: users configured for password+OTP
ipa user-show alice | grep "User authentication types"
# User authentication types: password, otp

# Phase 1: Allow passkey in addition to OTP
ipa passkeyconfig-mod --require-user-verification=FALSE
# Compatible with basic authenticators

# Configure users for password + (OTP or passkey)
ipa user-mod alice --user-auth-type=password,otp,passkey

# Alice registers passkey via SSSD
# Can now use OTP or passkey for second factor

# Phase 2: After 60 days, majority have passkeys registered
# Check adoption rate
ldapsearch -x -b "cn=users,cn=accounts,dc=example,dc=com" \
  "(ipaPasskey=*)" dn | grep "^dn:" | wc -l
# 450 users (of 500) have passkeys

# Transition remaining users
# Communicate: "OTP being phased out, register passkey by MM/DD"

# Phase 3: Remove OTP requirement
ipa user-mod alice --user-auth-type=password,passkey
# OTP tokens no longer required

Result: Smooth migration from OTP to passkeys with phased approach. Improved user experience and stronger security.

6. Mandating Backup Passkeys to Prevent Lockout

Organization experienced account lockouts from users losing their only passkey. Implementing policy requiring multiple passkeys.

# Document policy requiring 2+ passkeys per user
cat > /root/passkey-policy.md <<EOF
Passkey Registration Policy
===========================

All users must register minimum TWO passkeys:
1. Primary: Work device platform authenticator or security key
2. Backup: Security key stored in secure location

Rationale: Prevent account lockout if primary authenticator lost/damaged.

Enforcement: Manual verification via LDAP query.
EOF

# Monitor passkey registration counts
for user in $(ipa user-find --pkey-only | grep "User login:" | awk '{print $3}'); do
  count=$(ipa user-show "$user" --all | grep -c "ipaPasskey:")
  if [ "$count" -lt 2 ]; then
    echo "WARNING: $user has only $count passkey(s)"
  fi
done

# Email users with <2 passkeys
# "Please register a backup passkey to prevent account lockout"

# For high-value accounts, enforce via process
# Admin review: verified 2+ passkeys before enabling passkey-only auth

Result: Policy preventing account lockouts. Users maintain backup authentication methods.

7. Deploying Platform Authenticators for Corporate Laptops

Corporation deploying Windows Hello (fingerprint/facial recognition) on corporate laptops for convenient passwordless login.

# Disable user verification requirement not needed
# (Windows Hello provides biometric verification inherently)
ipa passkeyconfig-mod --require-user-verification=FALSE

# Configure users for passkey OR password during rollout
ipa user-mod alice --user-auth-type=password,passkey

# Users enroll Windows Hello on corporate laptops
# (Via SSSD graphical login prompt or command-line)

# User boots laptop, sees login screen
# Windows Hello fingerprint prompt appears
# User scans fingerprint -> SSSD authenticates via passkey -> login succeeds

# Kerberos TGT obtained automatically
# User has SSO to all IPA services

# After deployment to all corporate devices, can consider passkey-only
# But maintain password fallback for remote access scenarios

Result: Convenient biometric login deployed across corporate laptops. Improved user experience with maintained security.

8. Restricting Authentication to Specific Authenticator Models

Security team wants to ensure only approved FIDO2-certified authenticators are used (e.g., YubiKey 5 series only).

# Passkey configuration doesn't support authenticator restrictions directly
# Must implement via attestation validation (if available in IPA version)

# Check if attestation validation supported
ipa passkeyconfig-show --all
# (May show attestation-related attributes in newer versions)

# Alternative: Document policy and implement manual verification
cat > /root/approved-authenticators.txt <<EOF
Approved Authenticators:
- YubiKey 5 Series (NFC, USB-A, USB-C)
- Google Titan Security Key
- Feitian BioPass FIDO2

Registration approval process:
1. User registers passkey
2. Admin reviews authenticator model (via user report or attestation)
3. Admin approves or removes unauthorized passkeys
EOF

# Audit registered passkeys
# Check attestation data (implementation-specific)
ldapsearch -x -b "cn=users,cn=accounts,dc=example,dc=com" \
  "ipaPasskey=*" ipaPasskey | grep -i attestation

# Remove passkeys from unauthorized authenticators
# ipa user-mod <user> --delattr=ipaPasskey="<credential-id>"

Result: Policy-based restriction to approved authenticators. Manual enforcement until attestation validation available.

9. Monitoring Passkey Adoption and Usage

IT department tracking passkey deployment progress and authentication patterns for business reporting.

# Create monitoring script
cat > /root/monitor-passkey-adoption.sh <<'EOF'
#!/bin/bash

echo "Passkey Adoption Report - $(date)"
echo "=================================="

# Total users
TOTAL_USERS=$(ipa user-find --pkey-only | grep "User login:" | wc -l)
echo "Total users: $TOTAL_USERS"

# Users with passkeys
USERS_WITH_PASSKEYS=$(ldapsearch -x -b "cn=users,cn=accounts,dc=example,dc=com" \
  "(ipaPasskey=*)" dn | grep "^dn:" | wc -l)
echo "Users with passkeys: $USERS_WITH_PASSKEYS"

# Adoption percentage
ADOPTION_PCT=$(awk "BEGIN {printf \"%.1f\", ($USERS_WITH_PASSKEYS / $TOTAL_USERS) * 100}")
echo "Adoption rate: ${ADOPTION_PCT}%"

# Passkey authentication events (last 24 hours)
PASSKEY_AUTHS=$(journalctl --since "24 hours ago" -u krb5kdc | \
  grep -c "passkey.*success")
echo "Passkey authentications (24h): $PASSKEY_AUTHS"

# Current configuration
echo ""
echo "Current Configuration:"
ipa passkeyconfig-show
EOF

chmod +x /root/monitor-passkey-adoption.sh

# Run report
/root/monitor-passkey-adoption.sh

# Schedule monthly reports
echo "0 0 1 * * /root/monitor-passkey-adoption.sh | mail -s 'Monthly Passkey Adoption Report' it-team@example.com" | crontab -

Result: Data-driven visibility into passkey deployment progress. Enables informed decisions about authentication policy evolution.

10. Reverting Verification Requirement After User Complaints

Organization enabled user verification but received complaints about authentication failures and usability issues.

# Current state
ipa passkeyconfig-show
# Require user verification: TRUE

# Review support tickets
# Many users report: "Passkey not working after policy change"
# Issue: Users with basic authenticators (no verification) failing

# Decision: Revert to verification-optional for broader compatibility
ipa passkeyconfig-mod --require-user-verification=FALSE
# Require user verification: FALSE

# Communicate to users
cat > /tmp/passkey-policy-update.txt <<EOF
Passkey Policy Update

User verification requirement has been removed.

What this means:
- Passkeys registered without PIN/biometric will now work
- Security keys without verification capability are supported
- Authentication is simplified (touch only, no PIN required)

Note: This changes authentication from 2-factor to 1-factor (possession only).
For high-security access, we recommend using password + passkey combination.

Contact IT if you have questions.
EOF

# Send email to all users
mail -s "Passkey Policy Update" all-users@example.com < /tmp/passkey-policy-update.txt

# Update documentation to reflect verification optional
# Monitor authentication success rates - should improve

Result: User feedback addressed by reverting policy. Balance between security and usability adjusted based on operational experience.

Troubleshooting

Passkey Registration Fails with “Verification Not Supported”

Symptoms: User attempts to register passkey via SSSD, receives error “Authenticator does not support required user verification”.

Diagnosis:

# Check passkey configuration
ipa passkeyconfig-show
# Require user verification: TRUE

# User's authenticator doesn't support PIN or biometric
# (e.g., basic YubiKey 4, simple FIDO2 keys)

# Verify authenticator capabilities
# Ask user what model authenticator they have
# YubiKey 4: No verification support
# YubiKey 5: Supports PIN verification
# Basic FIDO keys: Often no verification

Resolution: Options: (1) User obtains verification-capable authenticator (YubiKey 5, platform authenticator with biometric). (2) Disable verification requirement if policy allows: ipa passkeyconfig-mod --require-user-verification=FALSE. If verification required for security compliance, option 1 is necessary. Document approved authenticator models to prevent future issues.

Existing Passkeys Stop Working After Policy Change

Symptoms: After enabling user verification requirement, users with previously registered passkeys cannot authenticate.

Diagnosis:

# Check when verification was enabled
ipa-audit | grep passkeyconfig-mod
# Modified 2 days ago: --require-user-verification=TRUE

# Users registered passkeys before policy change
# Their authenticators may lack verification capability

# Check user's passkey metadata
ipa user-show alice --all | grep ipaPasskey
# Passkey registered without verification capability

Resolution: Passkeys registered before verification requirement enabled may be incompatible. Options: (1) Revert policy temporarily: ipa passkeyconfig-mod --require-user-verification=FALSE. (2) Have affected users re-register with verification-capable authenticators. Communicate policy changes in advance and provide transition period for users to register compatible authenticators before enforcing verification.

Cannot Modify Passkey Configuration (Permission Denied)

Symptoms: User receives “Insufficient access” error when attempting to modify passkey configuration.

Diagnosis:

# Attempt to modify configuration
ipa passkeyconfig-mod --require-user-verification=TRUE
# ipa: ERROR: Insufficient access

# Check user's permissions
ipa user-show currentuser | grep memberof
# Member of groups: ipausers (not admins)

# Passkey configuration requires admin privileges

Resolution: Add user to admins group: ipa group-add-member admins --users=user. Passkey configuration is global and requires administrative privileges. Cannot be delegated separately from general admin access in default IPA RBAC.

Platform Authenticator Stops Working After Device Reinstall

Symptoms: User reinstalled operating system, now platform authenticator (Windows Hello, Touch ID) doesn’t work for IPA authentication.

Diagnosis:

# Platform authenticator private keys stored in TPM/secure enclave
# OS reinstall or TPM clear destroys private keys

# User's passkey registered on old OS installation
# Private key no longer exists on device

# Check user's passkeys
ipa user-show alice --all | grep ipaPasskey
# Shows passkey credential ID from old installation

Resolution: Platform authenticator passkeys are device/OS-installation-specific. After OS reinstall: (1) Remove old passkey entry: ipa user-mod alice --delattr=ipaPasskey="<old-credential-id>". (2) Register new passkey with reinstalled OS. (3) Educate users to maintain external security key as backup, not rely solely on platform authenticators. Document in passkey enrollment guide.

Multiple Passkeys Registered But Only One Works

Symptoms: User registered 3 passkeys (laptop, phone, security key) but only laptop passkey works. Others fail authentication.

Diagnosis:

# Check all user's registered passkeys
ipa user-show alice --all | grep ipaPasskey
# Shows 3 passkey entries with different credential IDs

# Test authentication with each authenticator
# Laptop: Works
# Phone: Fails with "invalid signature"
# Security key: Fails with "invalid signature"

# Possible causes:
# 1. Phone/key registered with wrong relying party ID
# 2. Registration process errors
# 3. Authenticator synchronization issues (for synced passkeys)

Resolution: Non-working passkeys likely registered incorrectly or with incompatible settings. Remove and re-register: ipa user-mod alice --delattr=ipaPasskey="<failing-credential-id>". During re-registration, ensure correct IPA domain/realm selected. For synced passkeys (cloud-backed), verify sync completed before using on different devices.

Passkey Authentication Works But Kerberos TGT Not Issued

Symptoms: User successfully authenticates with passkey (SSSD confirms), but no Kerberos credentials obtained.

Diagnosis:

# User completes passkey authentication
# SSSD shows: "Authentication successful"

# But klist shows no tickets
klist
# klist: No credentials cache found

# Check KDC logs
journalctl -u krb5kdc | grep passkey | tail -20
# May show: "Passkey validated but TGT issuance failed"

# Check user's Kerberos principal
ipa user-show alice | grep "Principal name"
# Principal name: alice@EXAMPLE.COM

# Check if user account enabled
ipa user-show alice | grep "disabled"
# Should not show account disabled

Resolution: Passkey validation succeeded but Kerberos TGT issuance failed. Common causes: (1) User account disabled: ipa user-enable alice. (2) Kerberos principal issues: verify principal exists and matches. (3) KDC configuration error: check /var/log/krb5kdc.log for detailed errors. (4) SSSD credential caching issue: sssctl cache-expire && systemctl restart sssd.

SSSD Not Prompting for Passkey

Symptoms: User has passkey registered but SSSD prompts for password instead of offering passkey authentication.

Diagnosis:

# Check user authentication types
ipa user-show alice | grep "User authentication types"
# User authentication types: password, passkey

# Both password and passkey enabled - SSSD may prefer password

# Check SSSD version
sssd --version
# Must be 2.9+ for passkey support

# Check SSSD configuration
grep -i passkey /etc/sssd/sssd.conf
# Should have passkey support enabled

# Check SSSD logs
journalctl -u sssd | grep -i passkey
# Look for passkey detection errors

Resolution: SSSD may not be configured for passkey support or user auth type allows password. Options: (1) Remove password auth: ipa user-mod alice --user-auth-type=passkey (passkey-only). (2) Configure SSSD to prefer passkey over password (SSSD configuration). (3) Upgrade SSSD to 2.9+ if older version. (4) Restart SSSD after configuration changes: systemctl restart sssd.

Passkey Registration Succeeds But Doesn’t Appear in IPA

Symptoms: SSSD reports successful passkey registration, but ipa user-show doesn’t show the passkey.

Diagnosis:

# SSSD shows: "Passkey registered successfully"

# But checking IPA:
ipa user-show alice --all | grep ipaPasskey
# (No output - no passkey attribute)

# Check SSSD logs for actual result
journalctl -u sssd | grep -i "passkey.*register"
# May show error after success message

# Check LDAP directly
ldapsearch -x -b "uid=alice,cn=users,cn=accounts,dc=example,dc=com" \
  ipaPasskey
# Check if attribute exists in LDAP

Resolution: Registration may have failed after success message. Common causes: (1) LDAP write permission issue: verify user has permission to modify own ipaPasskey attribute. (2) SSSD-IPA communication error: check network connectivity and IPA server logs. (3) Replication delay: wait 30-60 seconds and check again. (4) Retry registration: ipa-passkeyconfig-register (or via SSSD prompts).

Symptoms: Passkey works for console login (tty) but not for graphical display manager (GDM, SDDM, etc.) or vice versa.

Diagnosis:

# Console login (tty1): Passkey works
# GDM login: Passkey doesn't work or not prompted

# Check SSSD configuration for different PAM services
# Console uses login PAM service
# GDM uses gdm-password PAM service

# Check PAM configuration
cat /etc/pam.d/gdm-password
# Verify SSSD module enabled

# Check SSSD passkey integration with different login methods
journalctl -u sssd | grep -E "(gdm|login).*passkey"

Resolution: Different login methods may have different PAM configurations or SSSD integration. Ensure SSSD passkey support enabled for all relevant PAM services. Check display manager compatibility with WebAuthn/FIDO2. Some older display managers lack passkey prompt support. Consider upgrading display manager or using console login for pass key authentication.

Passkey Authentication Slow (5-10 Seconds)

Symptoms: Passkey authentication takes significantly longer than expected. User touches authenticator but waits 5-10 seconds before login succeeds.

Diagnosis:

# Normal passkey auth: <2 seconds
# Current experience: 5-10 seconds

# Check network latency to IPA server
ping -c 5 ipa.example.com
# High latency may slow challenge-response

# Check SSSD logs for timing
journalctl -u sssd | grep -i "passkey.*duration"

# Check if multiple IPA servers configured
grep server /etc/sssd/sssd.conf
# SSSD may be trying failed servers before succeeding

Resolution: Slow passkey authentication usually indicates network latency or server failover delays. Options: (1) Improve network connectivity to IPA servers. (2) Configure SSSD to prefer local/fast IPA servers. (3) Check IPA server performance (high load slows responses). (4) Verify DNS resolution isn’t causing delays. Passkey authentication requires multiple round-trips to IPA server; network issues amplify delay.

Cannot Remove Old Passkey Entry

Symptoms: Attempting to remove lost/old passkey fails with error.

Diagnosis:

# User lost old authenticator, wants to remove entry
ipa user-mod alice --delattr=ipaPasskey="<credential-id>"
# ipa: ERROR: no modifications to be performed

# Or:
# ipa: ERROR: attribute not found

# Check existing passkeys
ipa user-show alice --all | grep ipaPasskey
# May show different credential ID format than expected

Resolution: Credential ID format may be incorrect or attribute doesn’t exist. Options: (1) Get exact credential ID from ipa user-show alice --all --raw. (2) Use LDAP modify directly: ldapmodify -x -D "cn=Directory Manager" -W with delete operation. (3) Have user re-register passkey, which may overwrite old entries. (4) Administrative passkey management (if implemented): remove via admin interface.

Passkey Works on Some Replicas But Not Others

Symptoms: User can authenticate with passkey against ipa01.example.com but fails against ipa02.example.com.

Diagnosis:

# Test against different replicas
ssh -o "Host=ipa01.example.com" alice@server
# Passkey prompt - works

ssh -o "Host=ipa02.example.com" alice@server
# Passkey prompt - fails

# Check if passkey replicated
ssh ipa01 "ipa user-show alice --all | grep ipaPasskey"
# Shows passkey entry

ssh ipa02 "ipa user-show alice --all | grep ipaPasskey"
# No passkey entry (replication issue)

# Check replication status
ipa-replica-manage list
# Verify replication agreements exist

ipa topologysuffix-verify domain
# Check for replication errors

Resolution: Passkey entry not replicated to all servers. Fix LDAP replication: (1) Verify replication agreements healthy. (2) Force sync: ipa-replica-manage force-sync --from=ipa01. (3) Check for replication conflicts. (4) After replication completes, passkey works on all replicas. Users may experience inconsistent behavior during replication delays.

Verification Requirement Shows Wrong Value

Symptoms: Modified verification requirement but passkeyconfig-show displays old value.

Diagnosis:

# Set verification to TRUE
ipa passkeyconfig-mod --require-user-verification=TRUE
# Command reports success

# Check configuration
ipa passkeyconfig-show
# Require user verification: FALSE (old value!)

# Check replication
# May be reading from un-replicated replica

# Force specific server
ipa -s ipa01.example.com passkeyconfig-show
# Require user verification: TRUE (correct on ipa01)

Resolution: Multi-replica environment with replication delay. Configuration modified on one server, reading from another. Wait 30-60 seconds for replication. Force specific server for read: ipa -s ipa01.example.com passkeyconfig-show. If values don’t eventually sync, check LDAP replication health.

Passkey Prompt Appears But Authenticator Not Responding

Symptoms: SSSD prompts “Touch your authenticator” but nothing happens when user touches security key or attempts biometric.

Diagnosis:

# SSSD prompt appears
# User touches YubiKey - LED blinks but no progress

# Check authenticator connectivity
lsusb | grep -i yubikey
# Verify USB security key detected

# Check FIDO2/WebAuthn functionality
# Test with fido2-token command (if available)
fido2-token -L
# Should list connected authenticators

# Check for conflicting processes
ps aux | grep -E "(pcscd|fido|webauthn)"
# Multiple processes may conflict

# Check SSSD debuglogs
sssctl debug-level 9
# Attempt authentication again
journalctl -u sssd -f
# Look for FIDO/WebAuthn errors

Resolution: Authenticator detected but not responding to SSSD. Common causes: (1) USB permission issues: ensure user has access to FIDO devices (udev rules). (2) Conflicting processes: stop other FIDO-related services temporarily. (3) Authenticator firmware issue: update firmware or try different authenticator. (4) SSSD/libfido2 compatibility: ensure latest versions. Reboot may resolve transient issues.

Commands

passkeyconfig-mod

Usage: ipa [global-options] passkeyconfig-mod [options]

Modify Passkey configuration.

Options

Option	Description
`--require-user-verification REQUIRE-USER-VERIFICATION`	Require user verification during authentication
`--setattr SETATTR`	Set an attribute to a name/value pair. Format is attr=value.
`--addattr ADDATTR`	Add an attribute/value pair. Format is attr=value. The attribute
`--delattr DELATTR`	Delete an attribute/value pair. The option will be evaluated
`--rights`	Display the access rights of this entry (requires —all). See ipa man page for details.
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.

passkeyconfig-show

Usage: ipa [global-options] passkeyconfig-show [options]

Show the current Passkey configuration.

Options

Option	Description
`--rights`	Display the access rights of this entry (requires —all). See ipa man page for details.
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.

Overview

User Verification

Passkey Authentication Architecture

Registration Flow

Authentication Flow

Relying Party Configuration

Passkey vs Other Authentication Methods

Passkey vs Password

Passkey vs OTP

Passkey vs Certificate

Examples

View Current Configuration

View All Configuration Attributes

Require User Verification

Disable User Verification Requirement

Check Verification Requirement Before Rollout

Best Practices

Security Configuration

Authenticator Selection

Deployment Strategy

User Experience

Operational Practices

Integration Points

SSSD Clients

User Entries

Authentication Types

WebAuthn/FIDO2 Ecosystem

Platform Authenticators

Security Keys

Kerberos Integration

Multi-Factor Authentication

Account Recovery

Security Considerations

Phishing Resistance

User Verification Security

Authenticator Loss

Attestation

Device Security

Private Key Protection

Backup and Recovery

Configuration Scope and Granularity

Verification Requirement Changes Impact Existing Passkeys

No Passkey Revocation List

Passkey Metadata Visibility

Platform Authenticator Binding

Synchronization and Synced Passkeys

Limited Audit Logging for Passkey Usage

No Centralized Passkey Enrollment Workflow

Passkey-Only Accounts Vulnerable to Device Loss

Verification Method Transparency

SSSD Client Dependency

Use Cases

1. Enabling Passwordless Authentication for Administrators

2. Hybrid Deployment with Password and Passkey

3. Requiring Multi-Factor with Passkey and Password

4. Troubleshooting Verification-Incapable Authenticator

5. Transitioning from OTP to Passkeys

6. Mandating Backup Passkeys to Prevent Lockout

7. Deploying Platform Authenticators for Corporate Laptops

8. Restricting Authentication to Specific Authenticator Models

9. Monitoring Passkey Adoption and Usage

10. Reverting Verification Requirement After User Complaints

Troubleshooting

Passkey Registration Fails with “Verification Not Supported”

Existing Passkeys Stop Working After Policy Change

Cannot Modify Passkey Configuration (Permission Denied)

Platform Authenticator Stops Working After Device Reinstall

Multiple Passkeys Registered But Only One Works

Passkey Authentication Works But Kerberos TGT Not Issued

SSSD Not Prompting for Passkey

Passkey Registration Succeeds But Doesn’t Appear in IPA

Different Behavior Between Console and Graphical Login

Passkey Authentication Slow (5-10 Seconds)

Cannot Remove Old Passkey Entry

Passkey Works on Some Replicas But Not Others

Verification Requirement Shows Wrong Value

Passkey Prompt Appears But Authenticator Not Responding

Commands

passkeyconfig-mod