For many years, LDAP has been the dominant protocol for secure user authentication for on-premise directories. Organizations have used LDAP to store and retrieve data from directory services and is a critical part of the blueprint for Active Directory (AD), the most widely used directory service. Historically, LDAP provided an efficient level of security for organizations to deploy WPA2-Enterprise.
Fortunately, SecureW2’s Cloud PKI services help AD/LDAP environments seamlessly migrate to the cloud with a passwordless Azure solution. But if you want to keep LDAP and AD, we also offer the #1 BYOD onboarding client that allows your end users to self-service themselves for PEAP-MSCHAPv2 802.1X authentication. Without the onboarding client, you could miss configuring server certificate validation and leave your network exposed. SecureW2’s Cloud PKI can be set up in under an hour and doesn’t require any forklift upgrades, just see what our customers have to say.
This article takes a deep dive into LDAP and examines whether its security standards hold up to more modern cyber threats.
What is LDAP?
Lightweight Directory Access Protocol, or LDAP, is a software protocol that stores and arranges data to make it easily searchable. The data can be any information about organizations, devices, or users stored in directories. LDAP is the protocol used by servers to speak with on-premise directories.
Data is stored in a hierarchical structure called a Directory Information Tree (DIT), which organizes data into a branching “tree” structure, making it easier for admins to navigate their directories, find specific data, and administer user access policies.
What Does “Lightweight” Mean?
The predecessor to LDAP, the Directory Access Protocol, was developed as part of the x.500 directory service. However, it used the OSI protocol stack which didn’t fit with many networks and therefore was difficult to implement.
LDAP was developed to be a lightweight (meaning less code) alternative protocol that could access x.500 directory services with TCP/IP protocol, which was (and is) the standard for the internet.
What Does LDAP Do?
The main purpose of LDAP is to serve as a central hub for authentication and authorization. LDAP helps organizations store user credentials (username/password) and then access them later, like when a user is attempting to access an LDAP-enabled application. That user’s credentials stored in LDAP authenticate the user.
User attributes can also be stored in LDAP, which determines what that user is allowed to access based on policies set by the directory.
How Does LDAP Work?
LDAP is based on a client-server interaction. The client begins a session with the server, called a “binding”. The client presents their user credentials which the server can compare against the directory and authorize access based on that user’s attributes.
LDAP can be broken down into 4 models which explain 4 different services provided by an LDAP Server.
This model determines what information can be stored in LDAP and relies on “entries”. An entry is an identifier for a real-world object (servers, devices, users) in a network through attributes describing the object. Entries help determine the user’s network access levels.
Here, entries are assigned Distinguished Names (DN) based on their position in the DIT hierarchy. DNs are composed of Relative Distinguished Names (RDN), which themselves represent each entry attribute. In simpler terms, RDN is like a Filename in Windows, while the DN is like the File Pathname.
The functional model defines what functions you can do with an LDAP server. These functions can be broken down into three main categories, each with their own subcategories.
- Query – Goes and fetches the requested information stored in the directory.
- Update – Modifies the information in the directory. Users can add, delete, or modify existing information.
- Authentication – Allows users to connect and disconnect with the LDAP server.This handy chart provided by Hack2Secure does an excellent job outlining each function.
The Security model gives clients an opportunity to provide their identity for authentication. Once authenticated, servers can determine what level of access is granted to the client based on their policies. Expanding on the Bind operation from the Functional Model, there are three options for binding:
- No Authentication – This option is recommended for instances where credential theft is not an issue. Anyone who leaves the DN and password fields blanks will be defined as an anonymous user and be assigned access levels based on existing network policies. This option is usually left for installments or other instances where authentication is not required.
- Basic Authentication – The LDAP client is required to provide a DN and a password for authentication. The server then compares the DN and password against the network directory and grants them access based on the user’s attributes. The credentials are sent over cleartext, meaning they can be easily read by an unauthorized party if one were to infiltrate their session
- SASL – Simple Authentication and Security Layer, or SASL, is a protocol that requires both the client and server to provide identifying information.
LDAP and Actvie Directory
Though many use LDAP and Active Directory (AD) interchangeably, they are in fact two different types of software, though they can work together. Think of LDAP as the language that AD is able to speak. The task of LDAP is to extract information stored in AD. When a user looks something up in AD, like a computer or printer, LDAP is what’s used to find the relevant information and present the results to the user.
AD is the most widely used directory server and it uses LDAP to communicate. LDAP is the protocol used to query, maintain, and determine access in order for AD to function.
Another difference between LDAP and AD is how they handle device management. AD has a mechanism called Group Policy (GPO) which allows admins to control Windows devices and offers Single Sign-On abilities, neither of which is available with LDAP. When it comes to ability, there’s a lot to be desired with LDAP, meaning AD-domain admins are on their own when implementing LDAP-compatible devices and servers.
Unfortunately, standard LDAP security doesn’t fare well against cyber threats, which we’ll discuss next.
LDAPS: Enabling LDAP over SSL/TLS
LDAP security is imperative since it involves the storage and retrieval of sensitive information. However, standard LDAP traffic is not encrypted, leaving it vulnerable to cyber attacks. LDAP isn’t able to secure authentication on its own, which spawned the implementation of Secure LDAP (LDAPS). After connecting to a client, LDAPS encrypts web traffic with SSL/TLS to establish a bind with the directory.
SSL/TLS encryption is an internet standard because it uses digital x.509 certificates to secure a connection between client and server. Certificates serve as identifiers for the device/server in which it resides.
Most organizations that encrypt LDAP traffic use a username and password for authentication purposes. While that method works, it leaves much to be desired in regards to security. LDAP systems that rely on credential-based authentication are still fairly vulnerable. Passwords can be easily forgotten, shared, and stolen, leaving the network susceptible to over-the-air credential theft.
Worse, the standard LDAP authentication method doesn’t even encrypt web traffic, meaning network admins are left with the job of configuring LDAP to securely encrypt for their environments.
The main problem lies with organizations authenticating users with passwords because passwords are insufficient to protect against modern cyber attacks. Passwords lack the fortitude to stand against modern cyber attacks like the brute force attack, which is a method that sends endless credential attempts, or the man-in-the-middle attack, which pretends to be a legitimate network entity and connects with an approved network user.
Default LDAP settings barely stand a chance against modern cyberattacks. Luckily, there is a better security measure: digital certificates with a PKI.
RADIUS Authentication with LDAP
There are many resources out there that compare LDAP and RADIUS. While they both can perform similar functions, it doesn’t make much sense to compare considering that an LDAP server can store user information and a RADIUS server cannot. LDAP doesn’t provide MFA capabilities or accounting logs, but you can perform those functions by adding RADIUS.
If your LDAP server contains your user directory, you can connect a RADIUS server to authenticate against your LDAP directory to authorize access to Wi-Fi, VPN, and all your web applications.
A cloud-based RADIUS server is the best practice for authenticating users because the industry’s moving away from on-premise infrastructures. Cloud RADIUS can be integrated into an AD/LDAP environment and dynamically authenticate users by directly referencing the directory. Any policies attributed to a user will be enforced in real-time, simplifying user segmentation.
Cloud RADIUS comes pre-built for 802.1x/EAP-TLS authentication with x.509 certificates, which is an easy way to configure a WPA2-Enterprise network.
Configuring LDAP for WPA2-Enterprise
LDAP used to be required for credential-based authentication, and as a result, many organizations built their authentication infrastructure around it. But as technology has progressed, credentials have become less and less of a reliable form of security. This has prompted many to search for alternative authentication methods.
In recent years, we’ve seen more and more organizations begin to switch from passwords to digital certificates for network authentication. Certificates automatically authenticate to the secure network when within range and do not need to be entered or remembered by the user. Certificates prevent Over-The-Air attacks and a myriad of threats that credentials are susceptible to with EAP-TLS authentication.
Whereas enrolling devices used to be considered complex, the JoinNow onboarding solution allows users to self-configure for certificates in minutes. Once equipped with a certificate, the user can be authenticated to the network for years and will never have to deal with pesky password reset policies. SecureW2 not only offers solutions for issuing certificates but also turnkey PKI services that provide the entire infrastructure required to switch over from credentials to certificates.
Ditch LDAP For a Managed PKI Solution
Organizations across the industry are leaving passwords behind to authenticate with digital certificates. Digital certificates can be configured to automatically authenticate to a network securely and aren’t bogged down by all the vulnerabilities of passwords.
Certificate-based authentication eliminates the necessity of passwords and over-the-air credential thefts because they can encrypt user credentials. Man-in-the-middle attacks rely on user credentials being shared in plaintext over the air, making them easy to intercept.
SecureW2 offers a Managed Cloud PKI, a turnkey PKI solution that can be integrated into any environment and enable certificate-based authentication in a matter of hours. Enrolling devices for 802.1x settings used to be considered difficult, but our JoinNow onboarding solution grants admins the ability to provision a certificate onto every BYOD, including non-Windows devices. Organizations that use MDMs can build powerful gateway APIs and leverage their existing IDP to deliver certificates to every managed device.
SecureW2’s PKI works with all LDAP and SAML IDP providers. You can leverage your current AD or leave it behind entirely. Our Dynamic Cloud RADIUS uses an industry-first solution to reference the directory directly. The server can look up in real time the validity of the user and their identifying information. Historically, this was only possible with LDAP, but with SecureW2 is available to anyone who integrates our service into their environment.
Stronger Security with Certificate-based Authentication
LDAP is widely used due in no small part to its compatibility with Active Directory. However, that doesn’t mean admins need to be held back with antiquated authentication methods that leave their networks vulnerable to cyber attacks. Luckily, SecureW2 offers an easy solution to eliminate over-the-air credential theft and bolster network security all around by deploying certificate-based authentication. Integrate your LDAP Identity Provider with our turnkey Managed PKI solution, which is much more affordable than legacy on-prem servers.
How do I find LDAP in Windows?
Whether you’re working at a large company or SMB, you’re probably interacting on a daily basis with LDAP. As your LDAP directory grows, it’s easy to get lost in all the entries that you may have to manage. Luckily, there is a command that will help you search for entries in an LDAP directory tree: Nslookup.
Use Nslookup to verify the SRV records, follow these steps:
- Click Start and Run.
- In the Open box, type “cmd”.
- Enter nslookup.
- Enter set type=all.
- Enter “_ldap._tcp.dc._msdcs.Domain_Name”, where Domain_Name is the name of your domain.
How do I know if LDAP is configured?
If you’re configuring filters for search parameters for your LDAP server, you should perform authentication tests to confirm that your search filters are successful. All search filters must be working properly to ensure successful integrations with your LDAP server.
- Go to System > System Security.
- Click Test LDAP authentication settings.
- Test the LDAP user name search filter. In the LDAP user name field, type the name of an existing LDAP user. Click Test LDAP query.
- Test the LDAP group name search filter. Use an existing LDAP group name.
- Test the LDAP username to make sure that the query syntax is correct and that LDAP user group role inheritance works properly.
How do I connect an LDAP server?
JoinNow MultiOS and Connector supports an authentication mechanism that can be readily tailored to any LDAP server’s method and IDP to authenticate users by a login name. When a user attempts to log in, each LDAP server that is enabled for authentication is verified.
The following demonstrates the steps involved to configure the integration:
- Configure the Identity Provider
- Begin by configuring the attribute mapping of the IDP. Here you will customize the fields that are populated by the attributes of your network users and will be used to define different user groups within your network.
- Configure the Network Policies
- Nearly all organizations have different user groups that require varying levels of access to networks, servers, data, etc. By onboarding with SecureW2, you can automatically separate users into groups by configuring their attributes to identify and segment users. For example, a university would configure the onboarding software to segment users based on their status as a student or a professor.
For a more detailed guide, visit our configuring WPA2-Enterprise for AD/LDAP servers guide.
How do I fix LDAP?
When resolving the LDAP server address, the system supports DNS SRV and AAA lookups. The system always tries in the first instance to set up a TLS connection with the LDAP server. If that fails it may fall back to a TCP connection if possible. To establish a TLS connection, the LDAP server’s certificate must be signed by an authority trusted in the CA certificates store.
Also, the resolved LDAP server address must match the CN (common name) contained within the certificate presented by the LDAP server. The system will connect to the port returned by an SRV lookup, or it will connect to 389 (TCP) or 636 (TLS).
Requests to search the Active Directory Global Catalog use ports 3268 (TCP) and 3269 (TLS).