The comparison comes up in design reviews, vendor evaluations, and troubleshooting calls. Teams ask which one they need, whether one can replace the other, and how the two work together. The short answer is that RADIUS decides who gets onto the network, LDAP stores who the users are, and most mature environments run both. Getting that split wrong leads to fragile designs, surprise lockouts, and long troubleshooting sessions. A wireless rollout can stall for days because nobody agreed on where group membership lives, and an audit can stall because nobody can show which system made an access decision.
RADIUS is a network access protocol that authenticates and authorizes users and devices connecting through Wi-Fi, switches, and VPNs. LDAP is a directory protocol that stores and serves user, group, and device data. They are not alternatives. A RADIUS server usually checks credentials and group membership in an LDAP directory, then returns an access decision to the network device.
Table of Contents
RADIUS vs LDAP: Two Tools for Two Jobs
RADIUS and LDAP both deal with identity, which makes them easy to mix up. RADIUS is a protocol for deciding whether a user or device may use a network service. LDAP is a protocol for reading and managing a directory of users, groups, and other objects. One decides access, and the other holds the facts.
An analogy helps. Think of a building with a front desk and a staff roster. The roster lists everyone who works there, their departments, and their roles. The front desk checks the roster, decides who may enter and which floors they may visit, and records when they arrive. The roster is the directory, and the front desk is the access decision point.
This division explains why the two coexist rather than compete. Directories excel at storing and organizing identity data, and they are the source of truth for accounts, passwords, and group membership. Network access protocols excel at carrying authentication requests from devices such as switches and access points, applying policy, and returning decisions with instructions for how to treat the connection.
The useful question is rarely which one to choose. It is how to connect them so that a user’s single identity works the same way across the network, applications, and services.
RADIUS vs LDAP: How They Differ
RADIUS, the Remote Authentication Dial-In User Service, is an authentication, authorization, and accounting protocol for network access, defined in RFC 2865. LDAP, the Lightweight Directory Access Protocol, queries and modifies entries in a directory service such as Microsoft Active Directory or OpenLDAP, and RFC 4511 defines it. They differ in purpose, transport, and data.
| Feature | RADIUS | LDAP |
|---|---|---|
| Main job | Authenticate, authorize, and account for network access | Store, search, and manage directory entries |
| Who talks | Network device (switch, access point, VPN gateway) to RADIUS server | Application or server to directory |
| Transport and ports | UDP 1812 for authentication and 1813 for accounting, or RadSec over TCP 2083 | TCP 389 with StartTLS, or LDAPS on TCP 636 |
| Data model | Holds no full identity database and consults one | Hierarchical entries with attributes |
| Typical result | Accept, reject, or challenge, plus session attributes such as a VLAN | Entries, attributes, and bind success or failure |
| Encryption | Protects only some fields by default, so use RadSec or a trusted network | Needs StartTLS or LDAPS, since a simple bind sends the password in clear text |
RADIUS works between a network access device, called the client, and a server. The client sends an access request, and the server replies with accept, reject, or challenge. LDAP works between an application or server and a directory, supporting search, bind, add, modify, and delete. A RADIUS server does not store the full identity database. It consults one, such as a directory, and applies policy to the result.
Authorization differs in style as well. RADIUS returns session-specific instructions to network devices, such as which VLAN to place a device in. LDAP supplies attributes and group data that applications or servers use to make their own decisions. In the comparison of RADIUS vs. LDAP, one carries access decisions to network equipment, and the other stores and serves the identity information behind those decisions.
Typical Use Cases for RADIUS and LDAP
RADIUS appears wherever network equipment needs to authenticate users or devices. Enterprise Wi-Fi with WPA2 or WPA3 Enterprise, wired port control with IEEE 802.1X, VPN gateways, and some network device administration all use it. Its accounting records show who connected and for how long. It is especially valued for controlling access at the edge of the network.
LDAP appears wherever applications need to look up or validate identity. Web applications, email servers, file servers, Linux systems, and many enterprise tools use it to authenticate users against a central directory and to retrieve group memberships for authorization. It also serves as address-book data for email clients and as a backend for single sign-on systems.
In brief:
- RADIUS: wireless sign-in, switch ports, VPN gateways, and device administration
- LDAP: application logins, group lookups, address books, and account provisioning
Directories also support administrative work. Provisioning tools create and update accounts through directory interfaces, and reporting tools query them for audits. Group-based access policies in applications often depend on attributes stored there, which is why the identity layer matters even in identity management tools for SaaS.
When to Use RADIUS, LDAP, or Both
Use RADIUS when network devices must authenticate users or devices before granting access. Use LDAP when applications need to verify identities or when you need a central place to store them. Use both when people sign in to Wi-Fi, VPNs, and applications with the same account and the same group memberships.
Choose RADIUS when the goal is to require authentication on wireless networks, switch ports, or VPN connections, with dynamic policy and session logging. It also fits when different access levels must apply by network segment. Teams that run remote access should see how secure remote access combines identity checks, device checks, and per-application permissions, since a VPN gateway is usually a RADIUS client. Developer teams that rely on tunnels can compare notes with this article on securing remote dev workflows with VPNs.
Choose LDAP when the goal is to store, retrieve, or manage identity information, or to authenticate users for services that support directory integration. If an application needs to verify a username and password against a central source or look up group membership, LDAP is the usual route. It is also the answer to where identity data should live.
Neither is a substitute for the other. A directory cannot natively handle 802.1X exchanges with a switch or deliver VLAN assignments, and a RADIUS server is not built to serve as a general-purpose identity database with rich schemas and admin tooling. Using one in place of the other tends to create awkward, fragile designs.
Modern environments add more pieces. Cloud identity providers, SAML and OpenID Connect for web single sign-on, and certificate authorities all take part. Web single sign-on does not remove the need for RADIUS, though, because switches and access points still speak RADIUS rather than SAML. The decision is about how each protocol fits into the larger identity design.
How RADIUS and LDAP Work Together
A common design puts the directory at the center as the source of truth, with a RADIUS server in front of the network equipment. The server receives requests from switches, access points, and gateways, validates credentials or certificates, checks group membership in the directory, and applies policy. Directory groups can map to network roles, so a member of the finance group lands in the finance segment.
A user connecting to Wi-Fi shows the full flow. The access point sends a RADIUS request, the authentication server queries the directory through LDAP to check credentials and group membership, and the server returns an authorization decision. The user sees one login, and the organization maintains one identity store. Some servers skip LDAP and talk to the directory another way. Microsoft’s Network Policy Server, for example, checks credentials against Active Directory directly.
Several practical points improve this arrangement:
- Secure the link between the authentication server and the directory with LDAPS or StartTLS, because credentials and identity data cross it.
- Use dedicated service accounts with minimal permissions for directory queries.
- Plan capacity and high availability, since an unavailable directory or authentication server can block every connection.
- Document which groups map to which network policies, so changes do not cause surprises.
Choose authentication methods carefully. Password-based methods need the RADIUS server to reach credential data in a compatible form. PEAP with MSCHAPv2, for instance, needs a password hash format that Active Directory supplies, while many LDAP directories store only salted hashes that work with simpler inner methods such as PAP inside a TLS tunnel. Certificate-based methods such as EAP-TLS reduce reliance on passwords and can still use directory attributes for authorization. Cloud directories and identity providers can serve as the identity source, sometimes through cloud-hosted RADIUS services that avoid on-premises servers.
Troubleshooting Which Layer Failed
Failures can start in the network device, the authentication server, the directory, or the credentials themselves. Reviewing logs from both layers saves time, and the same habit applies to the wider network visibility practices that catch problems early.
| Symptom | Likely layer | First check |
|---|---|---|
| The device never receives an accept or reject | RADIUS client link | Shared secret, server address, and a firewall rule for UDP 1812 |
| A valid user gets rejected | Credentials or EAP method | Whether the EAP method matches the password format in the directory |
| The user connects but lands in the wrong VLAN | Policy mapping | Which directory group matches which RADIUS policy |
| Only some users fail | Directory query | The LDAP search filter and group membership |
| Logins fail at random | Directory or server capacity | Directory availability, timeouts, and server load |
Teams that manage many switches and access points can cut configuration drift with the practices in network automation tools for scalable infrastructure, because every device needs the same RADIUS server settings.
FAQs About RADIUS vs LDAP
These are the questions administrators ask most when they compare the two protocols.
What is the main difference between RADIUS and LDAP?
RADIUS controls access to network services. It receives a request from a switch, access point, or VPN gateway and answers accept, reject, or challenge. LDAP stores and serves identity data such as users, groups, and attributes. One makes the access decision, and the other holds the information behind it. That is why most environments use them together instead of choosing one, and why a good design names which system owns each decision.
Can LDAP replace RADIUS?
No. A directory cannot handle 802.1X exchanges with a switch or access point, and it cannot return session instructions such as a VLAN assignment. LDAP can supply the credentials and group data that a RADIUS server checks, but something still has to speak RADIUS to the network equipment. Without a RADIUS server, enterprise Wi-Fi and port-based access control have nothing to talk to, and the access points have no way to ask who a user is.
Can RADIUS replace LDAP?
No. A RADIUS server is not built to be an identity database. It does not offer rich schemas, hierarchical organization, or the admin tooling that directories provide. Some small deployments keep users in a local RADIUS file, but that approach breaks down as accounts grow. Applications also expect directory lookups, so they cannot use RADIUS to retrieve group memberships or profile details.
Does RADIUS use LDAP?
Often, yes. Many RADIUS servers, such as FreeRADIUS, can query an LDAP directory to verify credentials and read group membership. Others connect to the directory a different way. Microsoft’s Network Policy Server, for example, works with Active Directory directly. What matters is that the RADIUS server consults one identity source, not that it uses LDAP specifically. Check which method your server supports before you design the link.
Which ports do RADIUS and LDAP use?
RADIUS usually uses UDP port 1812 for authentication and 1813 for accounting. RadSec, which wraps RADIUS in TLS, uses TCP port 2083. LDAP uses TCP port 389, with StartTLS available to encrypt the session, and LDAPS uses TCP port 636. Open only the ports each link needs, and keep directory ports away from untrusted networks and the open internet.
Is Active Directory LDAP or RADIUS?
Active Directory is a directory service, not a protocol. You can query it over LDAP, and it also uses Kerberos for authentication. It is not a RADIUS server. A RADIUS service can sit in front of Active Directory to authenticate network access, and Microsoft’s Network Policy Server is one common way to do that on Windows Server, with the directory still holding the accounts.
Is LDAP secure without encryption?
No. A simple LDAP bind sends the username and password in clear text, so anyone who can capture the traffic can read them. Use StartTLS on port 389 or LDAPS on port 636, and restrict which hosts can reach the directory. The same care applies to the link between the RADIUS server and the directory, since that link carries identity data and service account credentials.
Do I still need RADIUS if I use a cloud identity provider?
Usually yes. Cloud identity providers handle web sign-in through SAML and OpenID Connect, but switches, access points, and many VPN gateways still speak RADIUS. You need a RADIUS service that checks the cloud directory, either a cloud-hosted RADIUS offering or a server you run. The identity source moves to the cloud, while the network protocol stays the same, so plan for both layers during any migration.
RADIUS vs LDAP: Use Each Where It Fits
The RADIUS vs LDAP question resolves into a simple picture. One protocol decides and communicates network access decisions, and the other holds and serves the identity information that informs those decisions. They are complementary layers, and most mature environments use both.
Teams making design choices should begin by clarifying the problem: controlling access at the network edge, managing identities and groups, or both. With that clarity, the right components and the right connections between them follow naturally. Write the split down in a one-page design note so that new hires and auditors see the same picture. Treat the directory as the place where identity lives, treat the authentication server as the place where network access is decided, and document the link between them. That small amount of clarity pays off during every migration, audit, and outage. If a login failed on your network this morning, would your team know within five minutes which of the two layers to check first?
