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.
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 enables an entity to look up data stored in a server. 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.
The Difference Between LDAP and Active 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.
Is LDAP Secure?
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 it’s 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 cyber attacks,Luckily, there is a better security measure.
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.
The post Lightweight Directory Access Protocol (LDAP): Explained appeared first on SecureW2.