Blog · Guides

RADIUS vs LDAP: what's the difference, and how they work together

LDAP is a directory you look users up in; RADIUS is a protocol network devices use to ask whether a user may connect. How each works, when you need both, and how to run them from one identity provider.

Casdoor Team · October 20, 2026 · 4 min read

This guide is written by the team that builds Casdoor and describes the standards as published (listed under Sources), with notes on how Casdoor implements them as of October 20, 2026. Spotted a mistake? Tell us.

RADIUS and LDAP show up together so often (in VPN guides, Wi-Fi setups and firewall manuals) that they are easy to confuse. They solve different problems:

  • LDAP is a protocol for reading and searching a directory: users, groups and their attributes, organized in a tree.
  • RADIUS is a protocol a network device (a VPN gateway, a Wi-Fi controller, a switch) uses to ask a server one question: may this user connect?

A typical setup uses both: the device speaks RADIUS to a RADIUS server, and the RADIUS server checks the password against an LDAP directory.

At a glance

LDAP RADIUS
What it is A directory access protocol An authentication, authorization and accounting (AAA) protocol
Main question it answers "Who is this user, and what are their attributes and groups?" "May this user connect to the network right now?"
Typical clients Applications, Linux hosts, mail servers, NAS devices, other identity systems VPN gateways, Wi-Fi controllers, switches, firewalls
Transport TCP 389, or 636 for LDAPS UDP 1812 (authentication) and 1813 (accounting)
Stores users? Yes, it is the store No, it asks a backend (a file, a database, LDAP, an IdP)
Accounting No Yes: session start, stop and usage records
MFA Not part of the protocol Possible with Access-Challenge (for example, asking for a one-time code)
Spec RFC 4511 RFC 2865, RFC 2866

How LDAP works

An LDAP server holds entries in a tree, such as uid=alice,ou=people,dc=example,dc=com. Clients do two things with it:

  1. Bind: authenticate as a user, usually with a distinguished name (DN) and password. A successful bind is how many apps "check a password against LDAP".
  2. Search: find entries and read their attributes, such as mail, memberOf or uidNumber.

So an application that "supports LDAP login" typically binds as a service account, searches for the user by username or email, then binds as that user with the password they typed. LDAP knows nothing about networks, sessions or how long someone stays connected. It just answers questions about the directory.

How RADIUS works

A RADIUS client (the network device, called the NAS) sends an Access-Request containing the username and password, encrypted with a secret the device shares with the server. The server answers with:

  • Access-Accept, optionally with attributes such as a VLAN or a session timeout,
  • Access-Reject, or
  • Access-Challenge, asking for more, such as a one-time code from an authenticator app.

When the user connects and disconnects, the device sends Accounting-Request packets so you have a record of who was online, when and for how long.

When you need which

  • An app needs to look up users and groups (a wiki, Jenkins, a NAS, a Linux host): LDAP.
  • A device needs to admit users to the network (VPN, enterprise Wi-Fi, switch port, firewall admin login): RADIUS.
  • Both is the common case in a company: a directory of record, plus RADIUS in front of it for the network.

Newer web apps should use neither and speak OpenID Connect or SAML instead. LDAP and RADIUS are for software and hardware that only understands them.

RADIUS with an LDAP backend

The classic architecture looks like this:

  1. A user connects to the VPN. The VPN gateway sends an Access-Request to the RADIUS server.
  2. The RADIUS server binds to LDAP with the user's credentials (or looks up the user and checks group membership).
  3. If the bind succeeds and the user is in the right group, the RADIUS server returns Access-Accept.

It works, but it means running and securing two more servers (often FreeRADIUS and OpenLDAP) next to the identity provider your web apps already use, and keeping users, groups and MFA consistent across all three.

One identity provider for both

Casdoor can serve both protocols itself, from the same users that sign in to your web apps over OIDC and SAML:

  • LDAP server: apps bind and search against Casdoor's users and groups, over LDAP or LDAPS. Users with MFA turned on can't log in with a password over LDAP, since LDAP has no way to ask for a second factor.
  • RADIUS server: VPNs and Wi-Fi controllers send Access-Requests to Casdoor. If the user has an authenticator app (TOTP) set up, Casdoor replies with an Access-Challenge asking for the code. Accounting requests are recorded too.

You can still sync users in from an existing directory, such as Active Directory or Entra ID, and keep that as the source of truth. See the LDAP and RADIUS page for details, or run it as a managed instance with Casdoor Cloud, from $24/month billed yearly.

FAQ

Is RADIUS more secure than LDAP? Neither is secure on its own over an untrusted network. Use LDAPS (or StartTLS) for LDAP. Classic RADIUS only hides the password with a shared secret, so keep it on a trusted network or wrap it in RADIUS over TLS (RadSec) or a VPN.

Can RADIUS replace LDAP? No. RADIUS can't list users or read their attributes for an application. It only answers access requests.

Can I use Microsoft Entra ID for RADIUS? Entra ID doesn't speak RADIUS itself. Microsoft's NPS extension forwards RADIUS requests from an on-premises NPS server to Entra multifactor authentication, or you can sync users from Entra ID into an identity provider that serves RADIUS, such as Casdoor.