First there was DAP...
Directory Access Protocol was a protocol for accessing information in a directory service based on the X.500 recommendations. It specified how an X.500 Directory User Agent (DUA) communicates with a Directory System Agent (DSA) to issue a query. Using DAP, network users were able to view, modify, delete, and search for information stored in the X.500 directory if they had suitable access permissions.
But it was a complex protocol with a lot of overhead. That's why, it was generally considered 'unsuitable' for implementations in a Microsoft Windows environment. Thus, a group of developers wanted to come up with a less complex replacement for DAP, and they created LDAP in 1993. It was a new protocol that used far less code and would become more accessible to people using desktop computers. Since then, LDAP has remained very popular, to the extent that the LDAPv3 became a directory services 'standard' and it also inspired the creation of OpenLDAP, the leading open source directory services platform. It also laid out the foundation on which Microsoft built 'Active Directory' in the late 1990s. LDAP has been very crucial to developing cloud-based directories also.
-
What is LDAP?
Now, Lightweight Directory Access Protocol (LDAP) has become a standard application protocol for accessing and managing a directory service. It is supported by most vendor directory services, including Active Directory (AD), OpenLDAP, OpenDJ, etc.
--> LDAP facilitates the sharing of information on users, systems, networks, services, and applications, WITH applications and services that need it.
All in all, LDAP is an open, cross-platform protocol that is primarily used for 'authentication' and communication in directory services. It provides the LANGUAGE that applications use to communicate with each other in directory services which store computer accounts, users, and passwords and share them with other entities on your networks. This allows applications and users to find and verify the information they need from across your organization.
Popular applications that support LDAP authentication are OpenVPN, Docker, Jenkins, Kubernetes, and Linux Samba servers. System administrators also use LDAP’s single sign on (SSO) feature to manage LDAP database access.
LDAP has a wide range of uses, but the most popular is as a 'central hub' for organizations to manage authentication. It is very effective in helping your organization to store, manage, and access usernames and passwords across your networks and applications. If your organization uses the right plugins, LDAP enables you to store and verify credentials every time a user attempts to access your applications, directories, and systems.
LDAP credentials not only involve the standard username and password combinations. They can also be used to manage other organizational attributes also—such as storing addresses, structural data, and telephone numbers—which makes it crucial to managing and protecting 'identities' of your users. LDAP also connects your users with information on devices attached to your network, such as files, printers, and shared resources.
LDAP is basIcially an application layer protocol that uses port 389 via TCP or user datagram protocol (UDP). LDAP queries can be transmitted in cleartext and, depending upon configuration, it can allow for some or all data to be queried anonymously. Naturally, LDAP also supports 'authenticated connections' and also secure communication channels leveraging TLS.
It enables messages, such as client requests, server responses, and data formatting, to flow between your servers and client applications.
This process works by LDAP binding users to a server. When a client sends a request for particular information, such as user credentials, the LDAP server processes it using its internal language, then communicates with directory services before sending a response. When the client receives the response, LDAP unbinds the client from the server, and the client processes the data.
Another use for LDAP involves the System Security Services Daemon (SSSD), which is a software originally created for Linux operating systems and provides simplified access to various 'remote' identity and authentication providers. SSSD can be configured to use native LDAP domains, e.g., an LDAP identity provider with 'LDAP authentication,' or an LDAP identity provider with 'Kerberos authentication.'
-
How does LDAP Authentication work?
One of LDAP’s key functions is to provide authentication. LDAP authentication follows the client/server model. In this scenario, the client is generally an LDAP-ready system or application that is requesting information from an associated LDAP database and the server is, of course, the LDAP server. LDAP offers three forms of authentication:
1. No Authentication
The use of "No Authentication" is acceptable when sharing public data.
2. Basic Authentication
Basic Authentication is similar to Basic Authentication under HTTP. Authentication is accomplished through the use of a DN (Distinguished Name) and a password. This data is sent either in plaintext or encoded using Base64 encoding. Here’s a step-by-step breakdown of the authentication process:
- The client (an LDAP-ready system or application) sends a request to access information stored within an LDAP database.
- The client provides their LDAP server user credentials (username and password).
- The LDAP server cross-checks the user’s submitted credentials against the core user identity data stored in its LDAP database.
- If the provided credentials match the stored core user identity, the client can access the requested information.
- Incorrect credentials will lead to denied access to the LDAP database.
Note that the core user identity stored in the LDAP database isn’t necessarily just usernames and passwords, but also other attributes like addresses, telephone numbers, and group associations, etc.
3. Simple Authentication and Security Layer (SASL)
SASL is a framework for plugging in alternative security mechanisms such as Kerberos, TLS, StartTLS, etc. I will elaborate about this alternative a little later.
Well, Simple authentication enables three authentication mechanisms:
- Anonymous authentication provides a client with an anonymous status on LDAP.
- Unauthenticated authentication is only used for logging purposes and should not be used to grant access to clients.
- The name and password authentication provides access to a server using the credentials supplied.
SASL authentication works by binding the LDAP server to a 'separate' authentication process, such as Kerberos. The LDAP server will then use the LDAP protocol to send a message to the Kerberos authentication process. This starts a series of response messages that will either deliver a successful authentication or an authentication failure. These messages are all sent in clear text as default, which means anyone snooping on them will be able to read them. It is therefore crucial for you to add security measures, such as encryption, around this authentication process to ensure that your users' details and the data being shared are protected.
(My readers will be aware that I have recently shared an elaborated post on Kerberos.)
-
LDAP and Active Directory (AD)
LDAP and AD are related, but not the same.
LDAP is a software language used by directory services for authentication and to exchange formatted messages between clients. Microsoft's Active Directory (AD) is a directory server that provides critical directory services to organizations, and managing users. AD is one of several directory services available, with others including Apache Directory Server and OpenLDAP.
However, AD is the most widely used directory services system. AD stores and manages shared resources, such as domains and user information, across your organization’s network. It provides your organization with functionalities such as authenticating user credentials, handling group user management, authenticating core identities, policy administration, and user management. Active Directory (AD) supports both Kerberos and LDAP.
Since LDAP has great ability to interact with directory services (e.g., Active Directory), it is an essential tool for your business. The protocol connects clients to the information they need within directory services. In short, LDAP provides an efficient, shared language that simplifies the process of providing responses to client queries. When used securely, it allows your organization to build and manage effective databases and gives your employees the tools they need to work effectively and productively.
You can see now that both LDAP and AD work together to enable clients across your organization to access the information they need, use the applications they need, and execute the responsibilities they have. AD stores the user information and logs your organization’s digital policies. LDAP enables queries to be formatted, which can be used to extract the information required and communicated between clients.
-
Security issues concerning LDAP
LDAP is vulnerable to various security threats, including spoofing of directory services, attacks against the databases that provide the directory services. RFC 2829 – Authentication Methods for LDAP defines the basic threats to an LDAP directory service:
(1) Unauthorized access to data via data-fetching operations,
(2) Unauthorized access to reusable client authentication information by monitoring others' access,
(3) Unauthorized access to data by monitoring others' access,
(4) Unauthorized modification of data,
(5) Unauthorized modification of configuration,
(6) Unauthorized or excessive use of resources (denial of service), and
(7) Spoofing of directory: Tricking a client into believing that information came from the directory when in fact it did not, either by modifying data in transit or misdirecting the client's connection.
Kindly note that Threats (1), (4), (5) and (6) are due to hostile clients. Threats (2), (3) and (7) are due to hostile agents on the path between client and server, or posing as a server.
LDAP in itself sends its data to the directory service ‘in plain text’. That's why the unsecure LDAP traffic contains highly sensitive data that is unencrypted, and thus a sitting duck (too easy..) for attackers and hackers. LDAP authentication is not secure on its own. A passive eavesdropper could learn your LDAP password by listening in on traffic in flight.”
-
What Can You Do To Enhance LDAP Security?
LDAP clients must authenticate to the server before being allowed access to the directory. Clients (users, computers, or applications) connect to the LDAP server using a distinguished name and authentication credentials (usually a password). Authentication information is sent from the client to the server as part of a "bind" operation, and the connection is later closed using an "unbind" operation.
Unfortunately, it is possible for users to make the connection with limited or no authentication, by using either anonymous or simple authentication. You should not allow for anonymous clients to send LDAP requests to the server without first performing the bind operation.
---------
NOTE
---------
Microsoft has already issued an significant advisory against the use of 'unsecure' LDAP to Active Directory because of potential for attacks and misuse.
LDAPS should be used with Active Directory domain controllers.
This isn't to say that LDAP is completely vulnerable. LDAP supports a number of different security mechanisms, beginning from when clients initially connect to an LDAP server.
Optionally, the connection can use TLS to secure the connection as I mentioned earlier, and protect any data transmitted between the client and server.
LDAP can also be used over SSL, which extends security into the Internet. LDAPS is Secure LDAP, which encrypts LDAP connections by using SSL or TLS. Some of these types of services integrate as objects, such as PKI certificates, in the authentication process using Smart Card technologies, and in the extended properties of account objects so that they can support extra security requirements. To use SSL with LDAP, the LDAP server must have an X.509 server certificate. Additionally, SSL/TLS must be enabled on the server.
**SASL (Simple Authentication and Security Layer)** is a framework for plugging in alternative security mechanisms. These security mechanisms include:➤ Kerberos Version 4 (already mentioned above)
➤ S/Key
➤ GSSAPI
➤ CRAM-MD5
➤ TLS
➤ ANONYMOUS
----------------
REMEMBER
----------------
“The default port for LDAP is port 389, but LDAPS uses port 636 and establishes TLS/SSL upon connecting with a client.” So, please Stop allowing unsecure binds with LDAP (Port 389) immediately. Else use StartTLS on the standard LDAP 389 port. OK?
-
Kindly write 
your comments on the posts or topics, because when you do that you help me greatly in 
designing new quality article/post on cybersecurity.
your comments on the posts or topics, because when you do that you help me greatly in designing new quality article/post on cybersecurity.You can also share with all of us if the information shared here helps you in some manner.
Life is small and make the most of it!
Also take care of yourself and your beloved ones…
With thanks,
Meena R.
___
This Article Was Written & published by Meena R, Senior Manager - IT, at Luminis Consulting Services Pvt. Ltd, India.
Over the past 16 years, Meena has built a following of IT professionals, particularly in Cybersecurity, Cisco Technologies, and Networking...
She is so obsessed with Cybersecurity domain that she is going out of her way and sharing hugely valuable posts and writings about Cybersecurity on website, and social media platforms.
34,000+ professionals are following her on Facebook and mesmerized by the quality of content of her posts on Facebook.
If you haven't yet been touched by her enthusiastic work of sharing quality info about Cybersecurity, then you can follow her on Facebook:
Click Here to follow her: Cybersecurity PRISM