How to Use LDAPS with RADIUS
Lightweight Directory Access Protocol (LDAP) has long been a standard protocol in directories. The problem with LDAP is that, as time goes on, it is being regarded as increasingly insecure, which is why more alternatives are being created. LDAPS, which is also known as Secure LDAP or LDAP over SSL, is one example.
RADIUS is a separate protocol that uses a server for authentication. Some use RADIUS in tandem with an LDAP server as an identity provider (IDP), such as Active Directory or Azure Active Directory. Some services, such as SecureW2’s onboarding software, are also compatible with LDAPS, allowing you to use LDAPS for onboarding and certificate enrollment, then RADIUS for certificate authentication. In this article, we’ll take a look at the various aforementioned ways LDAPS and RADIUS can work together, as well as if you should use them together.
What is LDAPS and How Does it Work?
LDAP stands for Lightweight Directory Access Protocol. The addition of the ‘s’ in LDAPS stands for “over SSL”, which is why the protocol is often called secure LDAP. Protocols are, in essence, “languages” that allow network components to communicate with each other.
Both LDAP and LDAPS are protocols that are used to query directories. The only real difference between them is that LDAPS encrypts credentials, whereas LDAP does not. That’s where the “over SSL” in secure LDAPS’s name comes from.
The LDAPS protocol can be used for all the same purposes that LDAP is. Its function is to allow you to query information in a directory, which can be related to organizations or individual devices and users.
It’s crucial to clarify here that LDAPS isn’t just the name of a protocol – LDAPS and LDAP are also often used to refer to the name of a server that utilizes LDAPS or LDAP. For instance, LDAPS is commonly used with Microsoft’s Active Directory (AD) and sometimes even Azure Active Directory. Because AD is one of the most common uses for LDAP and LDAPS, LDAPS Active Directory will be something we focus on more later.
Are LDAPS and RADIUS the Same Thing?
If you’re just learning about them, it can be easy to get LDAPS and RADIUS mixed up. They’re both protocols, after all. Despite having similar functions, however, LDAPS and RADIUS aren’t the same thing. They are two completely different protocols with their own standards.
For example, LDAPS relies on credential-based authentication. It may not make the mistake of sending said credentials in clear text like its predecessor, but there’s still no getting around the fact that it uses credentials, which simply aren’t secure.
RADIUS, on the other hand, is compatible with a range of authentication methods, including multi-factor authentication (MFA). With the addition of Public Key Infrastructure like SecureW2’s Cloud PKI, RADIUS can even be used in ultra-secure certificate-based authentication.
Additionally, RADIUS can perform server certificate validation. Server certificate validation is the process by which a server is authenticated by a device prior to the device connecting to it. This protects the device from unknowingly connecting to shady servers.
To use RADIUS, you need to have a directory of user and device information so the RADIUS can authenticate and authorize users or devices. On its own, RADIUS does not have a directory of information to verify, but this is something that could easily be provided by an LDAPS server.
In other words, LDAPS can be used with RADIUS. Let’s look at how that would work.
How to Use LDAPS with RADIUS
The good news is that you won’t need a lot to get LDAPS and RADIUS working together smoothly. In fact, you’ll just need a few things: a server configured to use LDAPS, like AD or Azure, a certificate authority to give SSL access to your directory, and a RADIUS server like our Cloud RADIUS.
We’ll give you an overview of the configuration process for both components so you understand how it works.
Configuring Azure for LDAPS
If you already use Azure Active Directory, configuring it to use LDAPS instead of regular LDAP is actually fairly simple. You’ll just need to create a certificate for Azure AD to use, enable LDAPS in Azure AD, set it up for use over the internet, then test it. You can follow the process outlined in this Microsoft guide to get it set up.
Once your Azure AD is configured to use LDAPS, you’re ready to combine it with RADIUS for increased authentication security. Alternatively, you can use LDAP/LDAPS to enroll for client certificates, but this requires you to have a Public Key Infrastructure (PKI). (Fortunately, our Cloud RADIUS comes with a managed PKI so you can get everything you need for certificate-based authentication at once.)
Configuring RADIUS with an LDAPS Server
If you’re unfamiliar with how RADIUS works, an easy way to imagine it is to picture a club with a bouncer at the door. A RADIUS server, also known as an AAA server, is that bouncer. When a user or device attempts to access a resource requiring authentication and authorization, the RADIUS will check their certificates or credentials depending on which you use for authentication.
RADIUS servers are a necessity in the 802.1x standard, which uses certificates and RADIUS servers to keep networks and resources secure. On its own, however, the RADIUS doesn’t store user and device information – it just verifies this information.
That’s where the LDAPS server you configured in the previous section comes into play. Azure AD and AD can serve as identity providers (IDPs) for the RADIUS to cross reference at the point of authentication. Our Cloud RADIUS even has a powerful identity lookup feature that allows it to check your AD at the moment of authentication, regardless of whether you’re using certificates or credentials.
Configuring Cloud RADIUS for integration with an LDAPS server is quite simple. All you need to do is access our intuitive management portal and add the LDAPS-enabled AD server. We’ll walk you through it.
Step one: Give the app access to Active Directory.
- Log in to Azure and go to App Registrations.
- Select New Registration.
- Input the settings pictured below.
Step two: Generate a client secret.
- Go to the Manage screen.
- Select Certificates and Secrets.
- Put a name in the Description field.
- Put an expiration date in the Expires field.
- Click Add. You should now see your Client Secret in the Value column. Make note of this, because you cannot recover the secret if you lose it.
Step three: Creating a Provider URL and Client ID.
- Go to the Overview screen.
- Copy your Application (client) ID. Set this aside for later.
- Copy your Directory (tenant) ID.
- Put your Directory ID in a URL following this format: https://login.microsoftonline.com/{Directory (tenant) ID}
- Set this URL aside for later.
Step four: Setting API permissions.
- Go to the Manage screen, then API Permissions.
- Select Add a Permission, then add the below-pictured permissions.
- Click Grant Admin Consent for (your organization).
Step five: Configuring SecureW2 for Azure AD.
- Go to the Device Onboarding section, then Getting Started.
- Input the settings pictured below.
- You don’t need to change any of the settings except for these ones:
SSID – Set this to the Wi-Fi network you wish to authenticate users on if applicable.
Wireless Vendor – Put your wireless infrastructure vendor here. - Wait while the Getting Started Wizard works. This takes one or two minutes.
Step six : Creating an Identity Lookup Provider.
- Go to the Identity Management screen, then to the Identity Providers section.
- Select the Add Identity Provider option.
- Add the following information:
- Name.
- Optional description.
- Type (which is Azure AD or AD in this scenario.)
- Select the Configuration option.
- In the Provider URL field, put in the URL you generated before with the Directory (tenant) ID.
- Enter the Client ID you found in Azure before.
- Enter the Client Secret you generated in step two.
- Press the Update button, then Authorize.
At this point, SecureW2’s app will test its connection to your Azure API. You can go on to add groups and network policies, but the steps thus far will help you get started utilizing both our RADIUS and LDAPS with Azure AD or AD as your identity provider server.
As we mentioned earlier on in this guide, however, LDAPS has a few flaws, one being that it relies on credential-based authentication. It’s no secret that credentials aren’t exactly an ironclad form of security, and there are better protocol alternatives out there.
Is LDAPS Really the Most Secure Authentication Protocol?
Towards the beginning of this guide, we discussed how, although LDAP and LDAPS are still common, they have flaws which make them untenable for long-term use. Namely, their reliance on insecure credential-based authentication makes them especially vulnerable.
It’s true that LDAPS makes improvements to LDAP, such as encrypting credentials as they are sent over the air, but it is still ultimately the same thing as LDAP. There are increasingly popular alternatives, including the ultra-secure Security Assertion Markup Language (SAML).
Whereas LDAP and, by extension, LDAPS are mostly associated with on-premise equipment or legacy systems, SAML was created for the Cloud-based future. As a Cloud-based access protocol, SAML can easily integrate with many identity providers, including Azure AD. SAML can also be used to implement a single sign-on (SSO) network, which is both more secure and efficient for your employees.
Like LDAPS, our Cloud RADIUS can use SAML. It can seamlessly integrate with your Cloud-based or on-premise infrastructure.
SAML: the Future-Friendly Authentication Protocol You Should Be Using
The addition of RADIUS certainly improves your organization’s authentication, and it’s true that LDAPS is better than LDAP…but LDAPS still isn’t as secure as your organization deserves. Its focus on credentials is proof of that statement.
With our Cloud RADIUS, you can cut out the middleman entirely and leave both LDAP and LDAPS out of the equation. Thanks to the superior SAML protocol, our Cloud RADIUS can bridge the gap between on-prem and Cloud-hosted infrastructure, allowing you to maintain a secure hybrid environment or migrate to the Cloud entirely. Read more about how one of our customers made the leap to cloud-based authentication with our Cloud RADIUS.
