RADIUS Proxy

Overview

RADIUS (Remote Authentication Dial-In User Service) proxy integration enables FreeIPA to delegate OTP (One-Time Password) authentication to external RADIUS servers. This allows IPA to leverage existing RADIUS infrastructure for two-factor authentication without migrating tokens or rebuilding authentication systems.

When a user configured for RADIUS proxy authentication attempts to login, IPA forwards the authentication request to the configured RADIUS server rather than validating OTP codes locally. The RADIUS server validates the OTP (using its own token database) and returns success/failure to IPA, which then issues Kerberos credentials accordingly.

Why Use RADIUS Proxy?

Hardware token integration: Organizations with existing hardware token infrastructure (RSA SecurID, Duo Security, managed RADIUS services) can integrate with IPA without re-provisioning thousands of tokens.

Managed authentication services: Commercial authentication providers (Duo, Okta, Azure MFA) often provide RADIUS endpoints, enabling IPA integration with cloud-based MFA services.

Centralized token management: RADIUS servers may serve multiple applications beyond IPA. Proxying to a central RADIUS server maintains single source of truth for token assignments and policies.

Legacy compatibility: Migrating from existing RADIUS-based authentication to IPA is gradual—continue using RADIUS during transition, eventually moving to native IPA OTP tokens.

Compliance and auditing: Some organizations require specific RADIUS vendors for compliance reasons. RADIUS proxy satisfies these requirements while enabling IPA adoption.

Architecture

RADIUS proxy authentication flow:

User initiates authentication: Attempts login via kinit, SSH, or Web UI
IPA checks user configuration: User has ipaUserAuthType including OTP and RADIUS proxy assigned
IPA prompts for OTP: Requests first factor (password) and second factor (OTP code)
IPA contacts RADIUS proxy: Sends Access-Request packet to configured RADIUS server with username and OTP code
RADIUS server validates: Checks OTP against its token database (hardware tokens, soft tokens, push notifications)
RADIUS returns response: Access-Accept (success) or Access-Reject (failure)
IPA processes response: On success, issues Kerberos TGT; on failure, denies authentication
User receives credentials: Authenticated with combination of IPA password and RADIUS-validated OTP

RADIUS Proxy vs Native IPA OTP

RADIUS Proxy:

Tokens managed externally (RSA, Duo, external RADIUS)
OTP validation delegated to external server
Requires network connectivity to RADIUS server
Shared secret for RADIUS communication
Per-user RADIUS server assignment possible

Native IPA OTP:

Tokens managed in IPA (otptoken-add)
OTP validation performed by IPA KDC
No external dependencies
Token secrets stored in IPA LDAP
Full control over token lifecycle

Organizations often use RADIUS proxy during migration or for specific user populations, with native IPA OTP for others.

Configuration Components

RADIUS Proxy Server (radiusproxy-add): Defines external RADIUS server connection:

Server hostname/IP and port: Where IPA sends RADIUS requests (default port 1812)
Shared secret: Pre-shared key encrypting RADIUS packets (must match RADIUS server configuration)
Timeout: Maximum seconds to wait for RADIUS response across all retries
Retries: Number of authentication attempts before giving up
User attribute: Which IPA user attribute to send as RADIUS username (default: uid)

User Assignment (user-mod --radius): Associates users with RADIUS proxy servers. Users assigned to a RADIUS proxy will have OTP authentication delegated to that server.

Username Mapping (--userattr): Controls which user attribute is sent to RADIUS as username. RADIUS servers may expect different username formats (userid, email, employee ID) than IPA’s uid attribute.

Shared Secret Security

The RADIUS shared secret encrypts communication between IPA and the RADIUS server. This secret must be configured identically on both sides. IPA stores the secret encrypted in LDAP, but it remains accessible to administrators with appropriate privileges.

Strong shared secrets (20+ random characters) are critical because RADIUS uses MD5-based encryption, which has known weaknesses. Network segmentation and firewalls should restrict RADIUS traffic to trusted networks.

Per-User RADIUS Configuration

IPA supports assigning different users to different RADIUS proxy servers. This enables:

Department-specific RADIUS servers: Sales using Duo, Engineering using RSA
Geographic RADIUS distribution: US users to US RADIUS, EMEA users to European RADIUS
Gradual migration: Some users on legacy RADIUS, others on new RADIUS or native IPA OTP
Vendor diversity: Different user populations using different MFA providers

Each user’s ipaUserRadiusProxyServer attribute specifies which RADIUS proxy configuration to use. Users without explicit assignment can have a default RADIUS proxy.

Examples

Add a new server:
ipa radiusproxy-add MyRADIUS --server=radius.example.com:1812
Find all servers whose entries include the string “example.com”:
ipa radiusproxy-find example.com
Examine the configuration:
ipa radiusproxy-show MyRADIUS
Change the secret:
ipa radiusproxy-mod MyRADIUS --secret
Delete a configuration:
ipa radiusproxy-del MyRADIUS

Use Cases

1. Integrating with RSA SecurID

Organization has 5000 RSA SecurID hardware tokens deployed across the company. Integrating IPA with existing RSA Authentication Manager via RADIUS.

# RSA Authentication Manager configured as RADIUS server
# Server: rsa-auth.example.com
# Port: 1812 (standard RADIUS)
# Shared secret: (configured in RSA console)

# Create RADIUS proxy in IPA pointing to RSA
ipa radiusproxy-add RSA-SecurID \
  --desc="RSA Authentication Manager RADIUS proxy" \
  --server=rsa-auth.example.com:1812 \
  --secret

# Prompted for shared secret
Enter secret: ********************
# (Same secret configured in RSA Authentication Manager)

# Verify configuration
ipa radiusproxy-show RSA-SecurID
# RADIUS proxy server name: RSA-SecurID
# Description: RSA Authentication Manager RADIUS proxy
# Server: rsa-auth.example.com:1812
# Timeout: 30 (seconds)
# Retries: 3

# Configure user for RADIUS proxy authentication
ipa user-mod alice --radius=RSA-SecurID --user-auth-type=password,otp

# User alice now authenticates with:
# - First factor: IPA password
# - Second factor: RSA SecurID token (validated by RSA server via RADIUS)

# Test authentication
kinit alice
# Password for alice@EXAMPLE.COM: (IPA password)
# OTP: (6-digit code from RSA token)
# Authentication succeeds via RADIUS proxy

Result: IPA integrated with existing RSA SecurID infrastructure. No token migration required. Users continue using familiar RSA tokens.

2. Deploying Duo Security via RADIUS

Organization wants to add Duo Security push notifications for two-factor authentication.

# Configure Duo Authentication Proxy as RADIUS server
# (Duo Authentication Proxy installed on duo-proxy.example.com)
# Local RADIUS port: 1812
# Shared secret generated in Duo Admin Panel

# Add Duo RADIUS proxy to IPA
ipa radiusproxy-add Duo-Security \
  --desc="Duo Security Authentication Proxy" \
  --server=duo-proxy.example.com:1812 \
  --timeout=60 \
  --retries=2 \
  --secret

# Enter shared secret from Duo configuration
# Longer timeout (60s) accommodates push notification response time

# Assign users to Duo RADIUS
ipa user-mod bob --radius=Duo-Security --user-auth-type=password,otp

# User bob authenticates
kinit bob
# Password: (IPA password)
# OTP: (type "push" for Duo push notification)
# Duo sends push to bob's phone
# Bob approves on phone
# Authentication succeeds

# Alternative OTP methods:
# - Type 6-digit code from Duo Mobile app
# - Use SMS code
# - Use hardware token (if configured in Duo)

# Duo provides detailed authentication logs separate from IPA

Result: Duo Security push notifications integrated with IPA. Modern mobile-first MFA without managing tokens in IPA.

3. Per-Department RADIUS Configuration

Large enterprise has different MFA requirements by department: Sales uses Duo, Engineering uses YubiKey OTP via Yubico RADIUS.

# Configure Duo RADIUS for sales
ipa radiusproxy-add Duo-Sales \
  --desc="Duo Security for Sales department" \
  --server=duo-sales.example.com:1812 \
  --secret

# Configure Yubico RADIUS for engineering
ipa radiusproxy-add Yubico-Eng \
  --desc="Yubico RADIUS for Engineering" \
  --server=yubico-radius.example.com:1812 \
  --secret

# Assign sales users to Duo
for user in $(ipa group-show sales --all | grep "Member users:" | cut -d: -f2 | tr ',' '\n'); do
  ipa user-mod "$user" --radius=Duo-Sales --user-auth-type=password,otp
done

# Assign engineering users to Yubico
for user in $(ipa group-show engineering --all | grep "Member users:" | cut -d: -f2 | tr ',' '\n'); do
  ipa user-mod "$user" --radius=Yubico-Eng --user-auth-type=password,otp
done

# Each department uses their designated MFA system
# Central IPA authentication with departmental flexibility

Result: Different departments use different MFA providers while maintaining centralized IPA identity management.

4. Migrating from RADIUS to Native IPA OTP

Organization transitioning from external RADIUS to native IPA OTP tokens. Gradual migration of users.

# Current state: All users on RADIUS proxy
ipa radiusproxy-show Legacy-RADIUS
# 5000 users assigned

# Phase 1: Configure native IPA OTP alongside RADIUS
# Deploy TOTP tokens to pilot group (100 users)

for user in pilot_user1 pilot_user2 ...; do
  # Remove RADIUS assignment
  ipa user-mod "$user" --radius=

  # User enrolls native IPA token via Web UI or CLI
  # User scans QR code into Google Authenticator
done

# Phase 2: After 6 months, majority migrated
# 4000 users on native IPA OTP
# 1000 users still on RADIUS (legacy hardware tokens)

# Phase 3: Decommission RADIUS for remaining users
# Replace legacy hardware tokens with native IPA OTP

# After all users migrated:
ipa radiusproxy-del Legacy-RADIUS
# RADIUS proxy no longer needed

Result: Smooth migration from RADIUS to native IPA OTP. Gradual transition minimizes disruption.

5. Configuring Username Mapping for External RADIUS

External RADIUS server expects email address as username, but IPA uses uid (username). Configure username attribute mapping.

# RADIUS server expects: alice@example.com
# IPA uid attribute: alice

# Users have mail attribute populated
ipa user-show alice | grep "Email address"
# Email address: alice@example.com

# Configure RADIUS proxy with userattr mapping
ipa radiusproxy-add External-RADIUS \
  --desc="External RADIUS with email username" \
  --server=external-radius.example.com:1812 \
  --userattr=mail \
  --secret

# When alice authenticates:
# IPA sends "alice@example.com" to RADIUS (from mail attribute)
# RADIUS recognizes user and validates OTP
# Authentication succeeds

# Verify username mapping
ipa radiusproxy-show External-RADIUS --all
# Username attribute: mail

# Alternative attributes for username mapping:
# - employeeNumber (for systems using employee IDs)
# - cn (common name)
# - Custom attribute via --setattr

Result: Username mapping enables IPA integration with RADIUS servers using different username formats.

6. Troubleshooting RADIUS Authentication Failures

Users report intermittent RADIUS authentication failures. Investigating timeout and retry configuration.

# Check current RADIUS proxy configuration
ipa radiusproxy-show Corporate-RADIUS
# Server: radius.example.com:1812
# Timeout: 30 seconds
# Retries: 3

# Check IPA KDC logs for RADIUS errors
journalctl -u krb5kdc | grep -i radius | tail -50
# Shows: "RADIUS timeout after 30 seconds"
# "RADIUS server not responding"

# Test RADIUS connectivity from IPA server
# Install radtest utility
dnf install freeradius-utils

# Test RADIUS authentication
radtest alice test123 radius.example.com:1812 0 <shared-secret>
# Timeout - RADIUS server not responding

# Diagnose network connectivity
ping radius.example.com
# Packets being dropped - network issue

# Check firewall
firewall-cmd --list-all | grep 1812
# RADIUS port not allowed

# Fix firewall on IPA server
firewall-cmd --add-port=1812/udp --permanent
firewall-cmd --reload

# Increase timeout for slow network
ipa radiusproxy-mod Corporate-RADIUS --timeout=60 --retries=5
# Accommodate network latency

# Test authentication again
radtest alice test123 radius.example.com:1812 0 <shared-secret>
# Success - Received Access-Accept

# Users can now authenticate successfully

Result: RADIUS connectivity issues diagnosed and resolved. Timeout increased to accommodate network latency.

7. Rotating RADIUS Shared Secrets

Security policy requires rotating RADIUS shared secrets every 90 days.

# Generate new shared secret
NEW_SECRET=$(openssl rand -base64 32)
echo "$NEW_SECRET" > /root/radius-secret-new.txt
chmod 600 /root/radius-secret-new.txt

# Update shared secret on RADIUS server first
# (Using RADIUS server's admin interface)
# Configure new secret for IPA client

# Update shared secret in IPA
ipa radiusproxy-mod Corporate-RADIUS --secret
# Enter secret: (paste new secret)

# Test authentication with new secret
kinit testuser
# Password: ********
# OTP: 123456
# Success - authentication works with new secret

# Document rotation in security log
echo "$(date): Rotated RADIUS shared secret for Corporate-RADIUS" >> /var/log/security-changes.log

# Schedule next rotation in 90 days
echo "Rotate RADIUS secret on $(date -d '+90 days')" | at now + 90 days

Result: RADIUS shared secret rotated securely. Authentication continues without disruption.

8. High-Availability RADIUS Configuration

Critical authentication system requires redundant RADIUS servers. Configure fallback behavior.

# Primary RADIUS server
ipa radiusproxy-add RADIUS-Primary \
  --desc="Primary RADIUS server" \
  --server=radius01.example.com:1812 \
  --timeout=30 \
  --retries=3 \
  --secret

# Secondary RADIUS server (for manual fallback)
ipa radiusproxy-add RADIUS-Secondary \
  --desc="Secondary RADIUS server (failover)" \
  --server=radius02.example.com:1812 \
  --timeout=30 \
  --retries=3 \
  --secret

# Assign users to primary
ipa user-mod alice --radius=RADIUS-Primary

# If primary fails, manually switch users to secondary
# (IPA doesn't support automatic RADIUS failover)
# Create script for emergency failover

cat > /root/radius-failover.sh <<'EOF'
#!/bin/bash
# Switch all users from primary to secondary RADIUS

for user in $(ipa user-find --radius=RADIUS-Primary --pkey-only | grep "User login:" | awk '{print $3}'); do
  ipa user-mod "$user" --radius=RADIUS-Secondary
  echo "Switched $user to secondary RADIUS"
done
EOF

chmod +x /root/radius-failover.sh

# If radius01 fails:
# /root/radius-failover.sh
# All users now authenticate via radius02

# Note: Consider load balancer in front of RADIUS servers
# for automatic failover instead of manual scripting

Result: RADIUS high availability implemented with manual failover process. Users can switch to backup RADIUS server when primary fails.

9. Monitoring RADIUS Proxy Usage

IT department needs visibility into RADIUS proxy authentication patterns for capacity planning and troubleshooting.

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

echo "RADIUS Proxy Authentication Report - $(date)"
echo "============================================="

# Count RADIUS authentications in last 24 hours
TOTAL_RADIUS=$(journalctl --since "24 hours ago" -u krb5kdc | \
  grep -c "RADIUS.*Access-Accept")
echo "Successful RADIUS authentications (24h): $TOTAL_RADIUS"

# Count failures
FAILED_RADIUS=$(journalctl --since "24 hours ago" -u krb5kdc | \
  grep -c "RADIUS.*Access-Reject")
echo "Failed RADIUS authentications (24h): $FAILED_RADIUS"

# Count timeouts
TIMEOUT_RADIUS=$(journalctl --since "24 hours ago" -u krb5kdc | \
  grep -c "RADIUS.*timeout")
echo "RADIUS timeouts (24h): $TIMEOUT_RADIUS"

# Users assigned to RADIUS proxies
for proxy in $(ipa radiusproxy-find --pkey-only | grep "RADIUS proxy server name:" | awk '{print $5}'); do
  count=$(ipa user-find --radius=$proxy --pkey-only | grep -c "User login:")
  echo "Users assigned to $proxy: $count"
done

# List configured RADIUS proxies
echo ""
echo "Configured RADIUS Proxies:"
ipa radiusproxy-find --pkey-only

EOF

chmod +x /root/monitor-radius-auth.sh

# Run monitoring
/root/monitor-radius-auth.sh

# Schedule daily reports
echo "0 9 * * * /root/monitor-radius-auth.sh | mail -s 'Daily RADIUS Report' it-team@example.com" | crontab -

Result: Automated monitoring provides visibility into RADIUS proxy usage, failures, and timeout patterns.

10. Removing RADIUS Proxy After Migration

After completing migration to native IPA OTP, decommissioning RADIUS proxy infrastructure.

# Verify no users still assigned to RADIUS proxy
ipa user-find --radius=Legacy-RADIUS --pkey-only
# 0 users matched (all migrated)

# Double-check all RADIUS proxies
for proxy in $(ipa radiusproxy-find --pkey-only | grep "RADIUS proxy server name:" | awk '{print $5}'); do
  count=$(ipa user-find --radius=$proxy --pkey-only | grep -c "User login:")
  if [ "$count" -gt 0 ]; then
    echo "WARNING: $proxy still has $count users assigned"
  fi
done

# All RADIUS proxies have 0 users - safe to remove

# Delete RADIUS proxy configurations
ipa radiusproxy-del Legacy-RADIUS
ipa radiusproxy-del Backup-RADIUS

# Verify deletion
ipa radiusproxy-find
# 0 RADIUS proxy servers matched

# Decommission RADIUS servers (external infrastructure)
# Update firewall rules to remove RADIUS port exceptions

# Document completion of migration
cat > /root/radius-migration-complete.txt <<EOF
RADIUS to IPA OTP Migration Complete
=====================================
Date: $(date)

All users migrated from external RADIUS to native IPA OTP.
RADIUS proxy configurations removed from IPA.
External RADIUS servers decommissioned.

New authentication: IPA password + IPA OTP tokens (TOTP/HOTP)
EOF

Result: Clean decommissioning of RADIUS infrastructure after successful migration to native IPA OTP.

Security Considerations

Shared Secret Strength and Distribution

RADIUS shared secrets encrypt authentication traffic between IPA and RADIUS servers using MD5-based algorithms with known cryptographic weaknesses. Weak shared secrets (short passwords, dictionary words) can be brute-forced if an attacker captures RADIUS packets. Generate strong secrets (20+ random characters) using cryptographic random generators: openssl rand -base64 32. Shared secrets must be securely distributed to RADIUS administrators—never send via unencrypted email or store in plaintext outside IPA. IPA stores secrets encrypted in LDAP, but administrators with sufficient privileges can retrieve them. Rotate secrets periodically (90 days) to limit exposure window.

RADIUS Traffic Exposure

RADIUS protocol encrypts only the user password attribute (OTP code), not the entire packet. Username, authentication timing, and metadata travel in cleartext. An attacker sniffing network traffic can identify which users are authenticating, when, and potentially correlate authentication patterns with business operations. While the OTP code itself is protected by the shared secret, weak secrets undermine this protection. Mitigate by restricting RADIUS traffic to trusted network segments (VLAN isolation, dedicated management network) and using firewalls to block RADIUS ports except between IPA and RADIUS servers. Consider VPN or IPsec tunnels for RADIUS traffic traversing untrusted networks.

RADIUS Server Compromise Impact

If the external RADIUS server is compromised, attackers gain ability to accept or reject authentication for any IPA user assigned to that RADIUS proxy. An attacker controlling the RADIUS server can grant access to unauthorized users or deny access to legitimate users (denial of service). RADIUS servers are high-value targets equivalent to authentication infrastructure. Ensure RADIUS servers follow security best practices: hardening, patch management, access controls, audit logging, intrusion detection. Monitor RADIUS servers for unauthorized configuration changes or unusual authentication patterns. Implement compensating controls: restrict RADIUS proxy usage to non-privileged users, maintain alternative authentication for administrators (native IPA OTP, certificates).

Per-User RADIUS Assignment Visibility

User-to-RADIUS proxy assignments are stored in IPA LDAP and visible to any authenticated user via ipa user-show <username> --all. This information disclosure reveals which authentication systems specific users use (Duo, RSA, etc.) and organizational structure (department assignments). While not directly exploitable, it aids attacker reconnaissance. Sensitive user populations (executives, administrators) may have their special authentication requirements exposed. Restrict LDAP read permissions for ipaUserRadiusProxyServer attribute if organization requires hiding this information, though this breaks some IPA functionality.

RADIUS Server Availability as Single Point of Failure

Users assigned to RADIUS proxy cannot authenticate if the RADIUS server is unreachable (network partition, server outage, firewall misconfiguration). This creates availability dependency on external infrastructure. Unlike native IPA OTP (which functions entirely within IPA infrastructure), RADIUS proxy introduces external failure modes. For critical accounts (administrators, emergency access), maintain alternative authentication methods not dependent on RADIUS (native IPA password, certificates, passkeys). Document RADIUS outage procedures: emergency access via alternative methods, manual RADIUS proxy reassignment, or temporary auth-type changes.

Timeout and Retry Configuration DoS Risk

Conservative timeout (--timeout=60) and retry (--retries=5) settings create user experience problems—users wait 300 seconds (5 minutes) for authentication to fail if RADIUS server is down. Aggressive timeout/retry settings (--timeout=10 --retries=1) reduce user wait but increase false negatives from transient network issues. Attackers aware of timeout configuration can launch denial-of-service attacks: overload RADIUS server causing slow responses that exceed timeout, locking users out. Balance timeout/retry for acceptable failure recovery (30s timeout, 2-3 retries) without creating extended wait times during outages.

Username Mapping Attribute Exposure

The --userattr parameter controls which IPA user attribute is sent to RADIUS as username. If this maps to sensitive attributes (e.g., employeeNumber, socialSecurityNumber if improperly stored), those values transit the network in RADIUS packets (cleartext except password field). While unusual, misconfiguration could expose sensitive data. Use only appropriate non-sensitive attributes for username mapping (uid, mail, cn). Review RADIUS server logs to verify expected usernames are transmitted, not sensitive data. Document username mapping decisions and validate RADIUS server receives expected username formats.

RADIUS Server Logging and Audit Trails

Authentication events logged in IPA (/var/log/krb5kdc.log) indicate RADIUS proxy authentication but detailed OTP validation occurs on the RADIUS server. IPA logs show “RADIUS Access-Accept” or “Access-Reject” without context about why (wrong OTP, expired token, user not found). Comprehensive security auditing requires aggregating logs from both IPA and RADIUS servers. RADIUS server compromise could enable log tampering—attacker accepts invalid authentication while logging shows legitimate rejection. Implement centralized log collection (SIEM) combining IPA and RADIUS logs, protecting log integrity with write-once storage or blockchain-based audit trails.

Migration State Complexity

During RADIUS-to-native-IPA OTP migration, users exist in mixed authentication states: some on RADIUS, some on native OTP, some with both configured. This complexity creates security gaps: administrators may lose track of authentication requirements, users may have inconsistent MFA strength (native TOTP vs. push notification vs. hardware token), and policy enforcement becomes difficult. Maintain migration tracking spreadsheet documenting each user’s authentication state. Implement automated checks for orphaned RADIUS assignments (user assigned to deleted RADIUS proxy). Complete migration expeditiously to minimize mixed-state duration.

RADIUS Proxy Deletion Without User Cleanup

Deleting RADIUS proxy configuration (radiusproxy-del) doesn’t automatically update users assigned to that proxy. Users retain ipaUserRadiusProxyServer pointing to non-existent proxy, causing authentication failures without clear error messages. Before deleting RADIUS proxies, query for assigned users: ipa user-find --radius=<proxy-name> and reassign them. If proxy deleted accidentally, users experience cryptic “RADIUS error” failures until assignments are cleaned up manually. Implement pre-deletion checks in operational procedures: verify zero users assigned before allowing deletion.

Limited RADIUS Protocol Security Features

RADIUS protocol predates modern security practices—MD5-based encryption, no certificate-based authentication, limited message integrity protection. More secure alternatives exist (TACACS+, DIAMETER, direct OAuth/OIDC integration) but RADIUS remains ubiquitous for legacy compatibility. Organizations deploying new MFA infrastructure should consider modern alternatives (native IPA OTP, passkeys, external IdP via OAuth) rather than RADIUS proxy. RADIUS proxy is appropriate for integrating existing RADIUS investments during transition, not recommended for greenfield deployments.

Shared Secret Storage in IPA LDAP

RADIUS shared secrets are stored encrypted in IPA LDAP but remain accessible to IPA administrators and potentially to attackers compromising IPA infrastructure. If an attacker gains LDAP access (via IPA compromise or LDAP replication intercept), they can extract encrypted secrets and potentially decrypt them. This differs from native IPA OTP where token secrets are stored with similar protection. Use strong RADIUS shared secrets (40+ character random strings) to resist decryption attempts. Rotate secrets regularly. Implement monitoring for unexpected RADIUS proxy configuration reads (potential secret extraction attempts).

Troubleshooting

RADIUS Authentication Fails with “Access Denied”

Symptoms: User enters correct IPA password and valid OTP code, but authentication fails with generic “Access denied” error.

Diagnosis:

# Check user's RADIUS proxy assignment
ipa user-show alice | grep "RADIUS proxy server"
# RADIUS proxy server: Corporate-RADIUS

# Verify RADIUS proxy exists
ipa radiusproxy-show Corporate-RADIUS
# RADIUS proxy server name: Corporate-RADIUS
# Server: radius.example.com:1812

# Check IPA KDC logs
journalctl -u krb5kdc | grep -i radius | tail -20
# Shows: "RADIUS Access-Reject for user alice"

# RADIUS server rejected authentication
# Possible causes:
# 1. User not configured in RADIUS server
# 2. OTP code incorrect
# 3. Token not synchronized
# 4. Username mismatch (IPA sends 'alice', RADIUS expects 'alice@example.com')

Resolution: RADIUS server rejected authentication. Check: (1) User exists in RADIUS server database (verify user provisioning). (2) OTP code was valid (ask user to try new code). (3) Token synchronized (RADIUS servers may require sync after prolonged non-use). (4) Username format matches RADIUS expectations—check --userattr mapping: ipa radiusproxy-show Corporate-RADIUS | grep "Username attribute". Review RADIUS server logs for detailed rejection reason.

RADIUS Authentication Timeout

Symptoms: Authentication hangs for 30+ seconds, then fails with timeout error.

Diagnosis:

# Check RADIUS proxy timeout configuration
ipa radiusproxy-show Corporate-RADIUS
# Timeout: 30 seconds
# Retries: 3
# Total wait: 30s * 3 = 90 seconds

# Check IPA KDC logs
journalctl -u krb5kdc | grep -i "radius.*timeout"
# "RADIUS timeout after 30 seconds"
# "No response from RADIUS server"

# Test RADIUS connectivity from IPA server
ping radius.example.com
# Packet loss or high latency

# Test RADIUS port
nc -zvu radius.example.com 1812
# Connection timeout - firewall blocking?

# Check firewall rules
firewall-cmd --list-all | grep 1812
# Port not allowed

Resolution: RADIUS server not reachable. Check: (1) Network connectivity: ping radius.example.com. (2) Firewall rules: ensure UDP port 1812 allowed from IPA to RADIUS server. (3) RADIUS server running: verify service status on RADIUS host. (4) Increase timeout if network latency high: ipa radiusproxy-mod Corporate-RADIUS --timeout=60. (5) Check RADIUS server configuration: ensure IPA server IP allowed as RADIUS client.

Wrong Username Sent to RADIUS Server

Symptoms: IPA sends username in format RADIUS doesn’t recognize, causing authentication failures.

Diagnosis:

# Check username attribute mapping
ipa radiusproxy-show External-RADIUS | grep "Username attribute"
# Username attribute: uid

# IPA sends: alice (from uid attribute)
# RADIUS expects: alice@example.com

# Check user attributes
ipa user-show alice | grep -E "(User login|Email)"
# User login: alice
# Email address: alice@example.com

# RADIUS server expects email, IPA sending uid

Resolution: Username format mismatch. Configure --userattr to send expected attribute: ipa radiusproxy-mod External-RADIUS --userattr=mail. This sends email address instead of uid. Verify RADIUS server receives expected format by checking RADIUS server logs or testing with radtest utility. Common username mappings: uid (username), mail (email), employeeNumber (employee ID), cn (common name).

Shared Secret Mismatch

Symptoms: All RADIUS authentications fail immediately with “shared secret” or “authentication error” messages.

Diagnosis:

# Check IPA KDC logs
journalctl -u krb5kdc | grep -i radius
# "RADIUS: Bad authenticator" or "Invalid response"

# Indicates shared secret mismatch between IPA and RADIUS server

# Verify shared secret hasn't been changed on RADIUS server
# (Check RADIUS server configuration)

# IPA secret can't be viewed (encrypted)
# Must re-enter

Resolution: Shared secret mismatch between IPA and RADIUS server. Verify current shared secret with RADIUS administrator. Update IPA with correct secret: ipa radiusproxy-mod Corporate-RADIUS --secret (enter matching secret). Test authentication after update. If secret unknown, regenerate on both sides: (1) Generate new secret: openssl rand -base64 32. (2) Configure on RADIUS server. (3) Update in IPA. (4) Test authentication.

User Has No RADIUS Proxy Assigned

Symptoms: User configured for OTP authentication but IPA doesn’t prompt for OTP or authentication fails with “no OTP method configured”.

Diagnosis:

# Check user's authentication type
ipa user-show bob | grep "User authentication types"
# User authentication types: password, otp

# User configured for OTP, but which OTP method?

# Check RADIUS proxy assignment
ipa user-show bob | grep "RADIUS proxy server"
# (No output - no RADIUS proxy assigned)

# Check for IPA OTP tokens
ipa otptoken-find --user=bob
# 0 OTP tokens matched

# User configured for OTP but has neither RADIUS proxy nor IPA tokens

Resolution: User requires OTP but has no OTP method configured. Options: (1) Assign RADIUS proxy: ipa user-mod bob --radius=Corporate-RADIUS. (2) Enroll native IPA OTP token: ipa otptoken-add --owner=bob --type=totp (user scans QR code). (3) If OTP not needed, remove from auth types: ipa user-mod bob --user-auth-type=password.

Cannot Delete RADIUS Proxy (Users Still Assigned)

Symptoms: Attempting to delete RADIUS proxy fails or succeeds but users experience authentication failures.

Diagnosis:

# Try to delete RADIUS proxy
ipa radiusproxy-del Old-RADIUS
# Succeeded (unexpected - should check for users first)

# Users assigned to Old-RADIUS now fail authentication
ipa user-find --radius=Old-RADIUS --pkey-only
# 150 users matched (users still assigned to deleted proxy!)

# These users will fail RADIUS authentication

Resolution: IPA allows RADIUS proxy deletion even with users assigned (differs from some other objects). Before deleting RADIUS proxy, reassign users: (1) Find assigned users: ipa user-find --radius=Old-RADIUS. (2) Reassign to different proxy: ipa user-mod <user> --radius=New-RADIUS. (3) Or remove RADIUS assignment: ipa user-mod <user> --radius=. (4) After all users reassigned, delete proxy. If already deleted, manually clean up user assignments or reassign to new proxy.

RADIUS Proxy Not Replicating to Other IPA Servers

Symptoms: RADIUS proxy created on ipa01, but not visible on ipa02.

Diagnosis:

# Check on ipa01
ssh ipa01 "ipa radiusproxy-show Corporate-RADIUS"
# Shows RADIUS proxy configuration

# Check on ipa02
ssh ipa02 "ipa radiusproxy-show Corporate-RADIUS"
# ipa: ERROR: Corporate-RADIUS: RADIUS proxy server not found

# Replication issue

# Check replication status
ipa-replica-manage list
ipa topologysuffix-verify domain
# Look for replication errors

Resolution: RADIUS proxy configuration stored in LDAP should replicate automatically. Replication delay or failure prevents propagation. Wait 30-60 seconds for replication. Verify replication agreements healthy. Force sync: ipa-replica-manage force-sync --from=ipa01. If replication broken, fix LDAP replication before RADIUS proxy will propagate. Check for LDAP replication conflicts.

Permission Denied Modifying RADIUS Proxy

Symptoms: User receives “Insufficient access” when attempting to modify RADIUS proxy configuration.

Diagnosis:

# Attempt to modify RADIUS proxy
ipa radiusproxy-mod Corporate-RADIUS --timeout=60
# ipa: ERROR: Insufficient access: Insufficient 'write' privilege

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

# RADIUS proxy management requires admin privileges

Resolution: RADIUS proxy configuration requires administrative privileges. Add user to admins group: ipa group-add-member admins --users=user. Alternatively, create custom RBAC role with RADIUS proxy permissions and assign to user. RADIUS proxy management cannot be delegated separately from general administrative access in default IPA configuration.

High Retry Count Causes Long Authentication Delays

Symptoms: When RADIUS server is down, users wait several minutes before authentication fails.

Diagnosis:

# Check RADIUS proxy configuration
ipa radiusproxy-show Corporate-RADIUS
# Timeout: 60 seconds
# Retries: 5

# Total potential wait: 60s * 5 = 300 seconds (5 minutes!)

# When RADIUS server unreachable, users wait full 5 minutes
# Creates poor user experience

Resolution: Reduce retry count to minimize wait during outages: ipa radiusproxy-mod Corporate-RADIUS --retries=2. Balance between recovering from transient network issues (retries help) and failing fast during extended outages (fewer retries better). Typical configuration: timeout=30s, retries=2-3 (total wait 60-90 seconds). Monitor RADIUS availability and adjust based on actual network reliability.

Authentication Works But Kerberos TGT Not Issued

Symptoms: RADIUS authentication succeeds (Access-Accept returned), but user doesn’t receive Kerberos credentials.

Diagnosis:

# User authenticates
kinit alice
# Password: ********
# OTP: 123456
# (hangs or returns without error)

# Check if TGT issued
klist
# klist: No credentials cache found

# Check KDC logs
journalctl -u krb5kdc | tail -50
# "RADIUS Access-Accept for alice"
# "TGT issuance failed: user account disabled"

# RADIUS authentication succeeded but Kerberos failed for other reason
# Check user account status
ipa user-show alice | grep disabled
# Account disabled: True (account is disabled!)

Resolution: RADIUS authentication is one step; Kerberos TGT issuance is separate. Even if RADIUS succeeds, TGT issuance can fail for other reasons: (1) Account disabled: ipa user-enable alice. (2) Password expired (first factor). (3) Kerberos policy issues. (4) KDC configuration errors. Check KDC logs for specific failure reason after RADIUS acceptance.

RADIUS Server Logs Show Different Username Than Expected

Symptoms: RADIUS server receiving unexpected username format causing authorization failures.

Diagnosis:

# IPA configuration
ipa radiusproxy-show Corporate-RADIUS | grep "Username attribute"
# Username attribute: uid

# RADIUS server logs show:
# "Authentication request for user: alice"

# Expected: "alice@example.com"
# Actual: "alice"

# Username mapping sending uid instead of mail

Resolution: Configure username attribute to send expected format: ipa radiusproxy-mod Corporate-RADIUS --userattr=mail. This changes IPA to send email address (alice@example.com) instead of uid (alice). Test authentication and verify RADIUS server logs now show expected username. If user doesn’t have mail attribute populated, populate it: ipa user-mod alice --email=alice@example.com.

RADIUS Proxy Shows Incorrect Server Address

Symptoms: RADIUS proxy configured with wrong server address, needs correction.

Diagnosis:

# Check current configuration
ipa radiusproxy-show Corporate-RADIUS
# Server: old-radius.example.com:1812

# Server hostname changed or configuration error
# Need to update to new-radius.example.com

Resolution: Modify RADIUS proxy server address: ipa radiusproxy-mod Corporate-RADIUS --server=new-radius.example.com:1812. Verify change: ipa radiusproxy-show Corporate-RADIUS. Test authentication after change. Ensure firewall rules allow connectivity to new server address. Coordinate with RADIUS administrator to ensure IPA server registered as client on new RADIUS server.

Multiple RADIUS Proxies Configured, Unclear Which One Is Used

Symptoms: Several RADIUS proxies configured, administrator uncertain which applies to specific users.

Diagnosis:

# List all RADIUS proxies
ipa radiusproxy-find
# Shows: Primary-RADIUS, Secondary-RADIUS, Duo-RADIUS, Legacy-RADIUS

# Check specific user's assignment
ipa user-show alice | grep "RADIUS proxy server"
# RADIUS proxy server: Duo-RADIUS

# Alice uses Duo-RADIUS, not Primary-RADIUS

Resolution: Users are assigned to specific RADIUS proxies via --radius user attribute. Check user’s assignment: ipa user-show <user> | grep "RADIUS proxy server". Find all users assigned to specific proxy: ipa user-find --radius=Duo-RADIUS. Document RADIUS proxy assignments (which users/groups use which proxy) to avoid confusion. Consider naming scheme indicating purpose (Duo-Sales, RSA-Engineering).

RADIUS Authentication Succeeds But Logs Show Failures

Symptoms: User successfully authenticates, but IPA logs show RADIUS Access-Reject messages.

Diagnosis:

# Check KDC logs
journalctl -u krb5kdc | grep "alice.*RADIUS"
# "RADIUS Access-Reject for alice (attempt 1)"
# "RADIUS Access-Reject for alice (attempt 2)"
# "RADIUS Access-Accept for alice (attempt 3)"

# Multiple rejections followed by acceptance

# User may have typo'd OTP first two times
# Or token was desynchronized and synced on third attempt

Resolution: This is normal behavior when user enters incorrect OTP codes before correct one. Multiple Access-Reject messages followed by Access-Accept indicate: (1) User typo on OTP (common). (2) Token synchronization (HOTP tokens may require multiple attempts). (3) User switching between different OTP methods (trying SMS code, then push, then hardware token). Not a configuration issue. If excessive retries observed, investigate user behavior or token synchronization issues.

Commands

radiusproxy-add

Usage: ipa [global-options] radiusproxy-add NAME [options]

Add a new RADIUS proxy server.

Arguments

Argument	Required	Description
`NAME`	yes	RADIUS proxy server name

Options

Option	Description
`--desc DESC`	A description of this RADIUS proxy server
`--server SERVER`	The hostname or IP (with or without port)
`--secret SECRET`	The secret used to encrypt data
`--timeout TIMEOUT`	The total timeout across all retries (in seconds)
`--retries RETRIES`	The number of times to retry authentication
`--userattr USERATTR`	The username attribute on the user object
`--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
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.

radiusproxy-del

Usage: ipa [global-options] radiusproxy-del NAME [options]

Delete a RADIUS proxy server.

Arguments

Argument	Required	Description
`NAME`	yes	RADIUS proxy server name

Options

Option	Description
`--continue`	Continuous mode: Don’t stop on errors.

radiusproxy-find

Usage: ipa [global-options] radiusproxy-find [CRITERIA] [options]

Search for RADIUS proxy servers.

Arguments

Argument Required Description

CRITERIA no A string searched in all relevant object attributes

Options

Option	Description
`--name NAME`	RADIUS proxy server name
`--desc DESC`	A description of this RADIUS proxy server
`--server SERVER`	The hostname or IP (with or without port)
`--timeout TIMEOUT`	The total timeout across all retries (in seconds)
`--retries RETRIES`	The number of times to retry authentication
`--userattr USERATTR`	The username attribute on the user object
`--timelimit TIMELIMIT`	Time limit of search in seconds (0 is unlimited)
`--sizelimit SIZELIMIT`	Maximum number of entries returned (0 is unlimited)
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--pkey-only`	Results should contain primary key attribute only (“name”)

radiusproxy-mod

Usage: ipa [global-options] radiusproxy-mod NAME [options]

Modify a RADIUS proxy server.

Arguments

Argument	Required	Description
`NAME`	yes	RADIUS proxy server name

Options

Option	Description
`--desc DESC`	A description of this RADIUS proxy server
`--server SERVER`	The hostname or IP (with or without port)
`--secret SECRET`	The secret used to encrypt data
`--timeout TIMEOUT`	The total timeout across all retries (in seconds)
`--retries RETRIES`	The number of times to retry authentication
`--userattr USERATTR`	The username attribute on the user object
`--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.
`--rename RENAME`	Rename the RADIUS proxy server object

radiusproxy-show

Usage: ipa [global-options] radiusproxy-show NAME [options]

Display information about a RADIUS proxy server.

Arguments

Argument	Required	Description
`NAME`	yes	RADIUS proxy server name

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

Why Use RADIUS Proxy?

Architecture

RADIUS Proxy vs Native IPA OTP

Configuration Components

Shared Secret Security

Per-User RADIUS Configuration

Examples

Use Cases

1. Integrating with RSA SecurID

2. Deploying Duo Security via RADIUS

3. Per-Department RADIUS Configuration

4. Migrating from RADIUS to Native IPA OTP

5. Configuring Username Mapping for External RADIUS

6. Troubleshooting RADIUS Authentication Failures

7. Rotating RADIUS Shared Secrets

8. High-Availability RADIUS Configuration

9. Monitoring RADIUS Proxy Usage

10. Removing RADIUS Proxy After Migration

Security Considerations

Shared Secret Strength and Distribution

RADIUS Traffic Exposure

RADIUS Server Compromise Impact

Per-User RADIUS Assignment Visibility

RADIUS Server Availability as Single Point of Failure

Timeout and Retry Configuration DoS Risk

Username Mapping Attribute Exposure

RADIUS Server Logging and Audit Trails

Migration State Complexity

RADIUS Proxy Deletion Without User Cleanup

Limited RADIUS Protocol Security Features

Shared Secret Storage in IPA LDAP

Troubleshooting

RADIUS Authentication Fails with “Access Denied”

RADIUS Authentication Timeout

Wrong Username Sent to RADIUS Server

Shared Secret Mismatch

User Has No RADIUS Proxy Assigned

Cannot Delete RADIUS Proxy (Users Still Assigned)

RADIUS Proxy Not Replicating to Other IPA Servers

Permission Denied Modifying RADIUS Proxy

High Retry Count Causes Long Authentication Delays

Authentication Works But Kerberos TGT Not Issued

RADIUS Server Logs Show Different Username Than Expected

RADIUS Proxy Shows Incorrect Server Address

Multiple RADIUS Proxies Configured, Unclear Which One Is Used

RADIUS Authentication Succeeds But Logs Show Failures

Commands

Commands

radiusproxy-add

Arguments

Options

radiusproxy-del

Arguments

Options

radiusproxy-find

Arguments

Options

radiusproxy-mod

Arguments

Options

radiusproxy-show

Arguments

Options

Related Topics