RADIUS and LDAP get confused constantly because both show up in the same conversations about network authentication, and both can technically verify a username and password. But they solve different problems. RADIUS (Remote Authentication Dial-In User Service) is a network access protocol: it decides whether a device gets onto the network and under what policy. LDAP (Lightweight Directory Access Protocol) is a directory access protocol: it looks up who a user is inside a directory like Active Directory. One enforces network access. The other answers identity questions.
Most enterprise networks run both, not one instead of the other. This page walks through how each protocol actually works, where they overlap, and why RADIUS and LDAP often work together in traditional enterprise environments.
What Is RADIUS?
RADIUS is a networking protocol built around authentication, authorization, and accounting (AAA), the three functions security teams still refer to as “the AAA model.” When a device tries to connect to a network, whether over Wi-Fi with 802.1X, a VPN, or a wired switch port, RADIUS is typically the protocol validating that connection attempt and deciding what access to grant.
RADIUS runs over UDP, using port 1812 for authentication and 1813 for accounting, and it’s paired with Extensible Authentication Protocol (EAP) for the actual credential exchange. EAP-TLS, which uses certificates instead of passwords, has become the standard for enterprise Wi-Fi authentication precisely because RADIUS alone doesn’t specify how credentials get validated, EAP handles that part.
One detail that surprises people new to the protocol: RADIUS doesn’t store user accounts. It’s an enforcement point, not an identity database. To know whether “jsmith” is a real employee and what group they belong to, RADIUS has to ask something else, usually a directory running LDAP.
What Is LDAP?
LDAP is a protocol for reading and writing data in a directory service, most commonly Microsoft Active Directory or OpenLDAP. Think of it as the protocol client applications use to ask a directory questions: does this user exist, what’s their email address, what security groups are they in, is their password correct.
LDAP organizes data hierarchically, using a Distinguished Name to uniquely identify each entry in the directory tree. It’s built for fast lookups and searches across large sets of user and group data, which is exactly what it’s used for in identity and access management. LDAP by default runs unencrypted on port 389; encrypted LDAP (LDAPS) runs on port 636 and should be the standard in any production environment handling credentials.
LDAP has no concept of network ports, VLANs, or session accounting. It answers identity questions. What happens after that answer, whether a device actually gets network access, is outside LDAP’s job entirely.
How the Two Protocols Actually Relate
The relationship is closer to a handoff than a rivalry. When a device authenticates through RADIUS, the RADIUS server frequently needs to verify the submitted credential against a real identity source. For many deployments, that identity source is an LDAP-based directory like Active Directory. RADIUS handles the network-side enforcement, LDAP provides the identity lookup behind it.
A simplified flow looks like this: a laptop attempts to connect to corporate Wi-Fi, the switch or wireless controller (the network access server) forwards the credential to the RADIUS server, the RADIUS server checks that credential against Active Directory over LDAP, and if it’s valid, RADIUS sends an Access-Accept message back, sometimes including a VLAN assignment or other policy attributes. LDAP never talks to the network device directly. RADIUS is always the intermediary.
Key Technical Differences
| RADIUS | LDAP | |
|---|---|---|
| Primary purpose | Network access authentication, authorization, accounting | Directory data lookup and management |
| Transport | UDP, ports 1812 (auth) and 1813 (accounting) | TCP, port 389 (unencrypted) or 636 (LDAPS) |
| Stores user accounts | No, relies on an external identity source | Yes, this is its core function |
| Typical pairing | Used with 802.1X and EAP for network authentication | Used as the backend for RADIUS, SSO, and other identity lookups |
| Session accounting | Yes, tracks session start/stop and duration | No, not built for session tracking |
| Common deployment | Enforcement point at switches, wireless controllers, VPN gateways | Directory server, often Active Directory or OpenLDAP |
Where Each One Falls Short Without the Other
LDAP on its own can’t function as network access control. It has no mechanism to grant or deny a device’s connection, assign a VLAN, or track how long a session has been active. An organization relying on LDAP alone for network security is really relying on nothing at the network layer, since LDAP was never designed to sit at that enforcement point.
RADIUS on its own has no persistent identity store, which means it’s only as trustworthy as whatever backend it’s checking against. A RADIUS server pointed at a stale or poorly maintained directory will happily authenticate users who left the company months ago if their account wasn’t disabled. This is a common operational gap: security teams focus on RADIUS configuration and overlook the health of the directory data feeding it.
Choosing (or Combining) the Right Setup
For most enterprise networks, this isn’t really a choice between RADIUS and LDAP, it’s a question of how to combine them correctly. RADIUS handles connection-time enforcement across wired, wireless, and VPN access. LDAP-based Active Directory or OpenLDAP provides the identity data behind that enforcement. In a traditional RADIUS-plus-directory deployment, the two play complementary roles: RADIUS enforces the network access decision while LDAP supplies user and group information. Modern RADIUS deployments can also rely on cloud identity providers or certificate-based authentication instead of a live LDAP lookup.
The one scenario where organizations reduce LDAP dependency is a shift to certificate-based authentication, where RADIUS validates a device certificate through EAP-TLS instead of checking a password against a directory in real time. This doesn’t eliminate the directory, user provisioning still typically originates there, but it removes the live password-lookup dependency that makes a compromised or unavailable directory a single point of failure for every connection attempt.
How Portnox Simplifies RADIUS and Directory Integration
Portnox Cloud RADIUS is a hardware-free, cloud-native RADIUS service that integrates directly with existing directory infrastructure, including Active Directory, LDAP-based directories, and cloud identity providers, through IAM integrations. Organizations don’t have to choose between keeping their existing directory and modernizing their RADIUS infrastructure; Portnox connects to what’s already there.
For organizations looking to reduce dependency on password-based directory lookups at connection time, Portnox’s certificate-based authentication runs through network access control policies, validating device identity through EAP-TLS rather than a live LDAP password check on every connection. This doesn’t replace the directory as a system of record, but it does reduce how often a network authentication event depends on the directory being reachable and healthy in that exact moment.
FAQs
Do RADIUS and LDAP compete with each other or work together?
They work together in most enterprise deployments. RADIUS handles network access enforcement, deciding whether a device connects and under what policy, while LDAP provides the identity lookup behind that decision, usually through Active Directory. Neither protocol replaces the other’s function.
Can RADIUS authenticate users without an LDAP or Active Directory backend?
Yes, RADIUS can use other identity sources, including a local user database or certificate-based authentication through EAP-TLS. But in most enterprise environments, RADIUS is paired with an LDAP-based directory because that’s where user and group data already lives.
Which protocol handles authentication for Wi-Fi and switch ports?
RADIUS, typically paired with 802.1X and EAP, is the protocol that authenticates devices connecting to enterprise Wi-Fi and wired switch ports. LDAP isn’t involved directly at the network device level; it’s queried by RADIUS in the background to verify identity.
Does Portnox Cloud RADIUS require an on-premises LDAP directory to function?
No. Portnox Cloud RADIUS integrates with existing Active Directory or LDAP directories where they exist, but it also supports cloud identity providers directly, so organizations without an on-premises directory can still deploy cloud-native RADIUS authentication.
RADIUS and LDAP aren’t rival protocols competing for the same job, they’re two layers of the same access control stack: one enforcing network access, one answering the identity question behind it. If your RADIUS infrastructure still means racking hardware and manually syncing directory data, request a demo to see how Portnox Cloud RADIUS connects to your existing directory without the maintenance overhead.