Introduction to FreeRadius in a Passwordless World

Ever tried explaining to a ceo why the "legacy" radio server is still the heart of your passwordless rollout? It's a weird spot to be in, but here we are.

Freeradius remains the go-to backend because it handles the messy bridge between modern certificates and network hardware. Even as we ditch passwords for tokens, radius stays relevant for a few big reasons:

• EAP-TLS is King: In industries like healthcare, moving to passwordless usually means pushing certificates to devices. freeradius handles this via eap-tls, ensuring only "known" hardware hits the vpn.
• Infrastructure Backbone: Whether it's retail point-of-sale systems or finance office wifi, hardware vendors still speak radius. You can't just api-call your way into an old access point.
• CIAM Integration: Modern identity setups often need to map a digital token back to a physical port. freeradius acts as the glue here.

According to experts at InkBridge Networks, the biggest hurdle for beginners isn't the debug info itself, but rather the initial setup of the eap module and certificate authority. If the shared secret is off or the ca isn't recognized, the whole "passwordless" dream falls apart fast.

Next, we’ll dive into the complexities of certificate management and why EAP-TLS often fails in production.

The Nightmare of Certificate Management

So, you finally got your passwordless eap-tls flow working in the lab, and then you move to production and everything breaks. It’s usually because certificate management is a total nightmare.

The most common "kick in the teeth" is the unknown CA error. This happens when the client (like a doctor's tablet or a retail scanner) doesn't trust the certificate freeradius is flashing at it.

• Missing Root CA: If the client doesn't have your root ca in its trust store, it’ll kill the connection immediately. You have to push that root cert via mdm or gpo before the login even starts.
• Wrong cert Chain: Sometimes the server sends its own cert but forgets the intermediates. The client sees a gap in the chain and freaks out.
• Expired/mismatched certs: Check your dates. Also, make sure the "Common Name" (CN) or Subject Alternative Name (SAN) matches what the client expects.

Real-time revocation is the other big beast. If a finance exec loses their laptop, you need that certificate dead now. Setting up an ocsp responder or a crl (Certificate Revocation List) is mandatory.

However, you gotta watch out for "fail-closed" behavior. In the eap module config, you have to choose between a "hard-fail" or "soft-fail" for ocsp. If you pick hard-fail and your ocsp responder goes down for maintenance, freeradius will block every single user from the network. Most people prefer a soft-fail so the wifi doesn't die just because a background service is laggy.

Next up, we’re gonna look at why your shared secrets are probably lying to you.

Connectivity and Shared Secret Mismatches

Ever spent three hours staring at a config file only to realize you swapped a '1' for an 'l' in a password? It’s the kind of thing that makes you want to throw your laptop out a window.

One thing that confuses people is the term "passwordless." When we say passwordless, we mean the user doesn't have a password (they use eap-tls certificates). But the infrastructure—the connection between your access point (NAS) and the freeradius server—still requires a "shared secret." This secret is just for packet integrity between the hardware and the server. If this secret is wrong, nothing works.

• Check clients.conf: You gotta define every single nas or access point here. If the ip address doesn't match exactly—maybe because of a dhcp change—the server drops the packet.
• The -X trick: Running radiusd -X is mandatory. It’ll show you the exact ip the packet is coming from, which is often different than what you thought it was.
• Typos are killers: Shared secrets are used to sign the packets. If the secret on your ruckus ap doesn't match the one in clients.conf, the message-authenticator check fails and freeradius discards the request as "invalid."

Honestly, most connectivity issues come down to these two files. Double check your ip ranges and copy-paste your secrets instead of typing them. Next, we're gonna look at why your database might be lying to you about user permissions.

Database Integration and CIAM Sync Issues

When you're ditching passwords for certificates, your database doesn't just store credentials anymore; it maps identities to roles. If that sync breaks, your "secure" network becomes a brick.

Mapping Modern Tokens

In a modern ciam setup, you aren't just looking for a username. You’re often dealing with oidc or saml tokens. You need to map these modern identity attributes to radius attributes. For example, you might take a "department" claim from a token and map it to the Tunnel-Private-Group-Id attribute so the user gets put in the right vlan. If this mapping isn't explicit in your sql queries or unlang logic, the server won't know what to do with the "passwordless" user once they're authenticated.

This error is a total liar: "Cleartext-Password not found"

This error (or sometimes just a generic Auth-Type := Reject) is a total liar. In a passwordless world, you don't have cleartext passwords, but freeradius might still look for them if your protocol and storage don't match up.

• Hash Mismatches: If you're trying to use legacy inner-tunnel methods with modern hashes, the server gets confused. For eap-tls, you mostly care about the User-Name matching your db record.
• Attribute Sync: You need to map your sql columns to radius attributes. If the query returns a null because of a schema change, the user gets rejected even if their cert is valid.

Honestly, if you're tired of fighting with database drivers and manual syncs, you might want to look at a managed ciam. You can quickly integrate passwordless authentication for web and mobile applications with MojoAuth to give users a smooth, secure login experience without these radius headaches.

Debugging and Advanced Troubleshooting

If you aren't running radiusd -X, you're basically flying blind in a storm. This mode is the only way to see the server's internal monologue.

• Spotting silent drops: Sometimes the server says nothing to the client but the logs reveal a "Received packet from unknown client" error. This usually means your nas ip or shared secret is wrong.
• Verifying VLANs: If a user connects but can't reach the internet, it's often a vlan mismatch. Check the -X output for the Tunnel-Private-Group-Id attribute in the Access-Accept packet. If that ID doesn't match what's configured on your switch port, the packet gets dropped or tagged wrong.
• TLS Alert Fatal: If you see unknown CA, it's rarely a server bug. As noted earlier, this means the client doesn't trust the certificate freeradius is showing.

Sometimes the built-in logic isn't enough. You can use unlang to write custom policies that handle these edge cases without recompiling the whole server.

post-auth {
    if (TLS-Client-Cert-Common-Name =~ /admin-.*/) {
        update reply {
            Service-Type = Administrative-User
        }
    }
}

Conclusion and Best Practices

Wrapping up a freeradius rollout for passwordless is mostly about understanding its role as a technical bridge. As we discussed in the intro, freeradius is the glue between modern certificate-based identity and the "old school" hardware that runs our offices and hospitals.

Keeping things stable long-term means focusing on these three areas:

• Automate eap-tls Renewals: Don't let a doctor's tablet go dark because a cert expired. Use scep or est protocols to handle renewals.
• Audit Shared Secrets: Remember, even in a passwordless world, your infrastructure secrets need to be right. Regularly rotate secrets in clients.conf.
• Centralize Identity: Moving toward a unified ciam like mojoauth helps sync roles across the whole api ecosystem, making the radius server's job much easier.

Honestly, just keep radiusd -X in your back pocket. Most "impossible" bugs in healthcare or retail setups are just a mismatched ca or a greedy firewall rule. Stay lazy by automating the hard parts early.

*** This is a Security Bloggers Network syndicated blog from MojoAuth - Advanced Authentication & Identity Solutions authored by MojoAuth - Advanced Authentication & Identity Solutions. Read the original post at: https://mojoauth.com/blog/common-issues-with-freeradius-in-passwordless-implementations