Deep dive into LDAP
Why LDAP?
In today’s enterprise environments, managing user identities, authentication, and access control across a growing number of systems is a critical challenge. LDAP (Lightweight Directory Access Protocol) plays a foundational role in solving this. It provides a centralized, standardized way to query and manage user and device information stored in directory services like Microsoft Active Directory.
But from an offensive security perspective, LDAP can also be a valuable reconnaissance and attack surface within Active Directory (AD) environments. Because LDAP is used to query objects like:
- Domain Computers
- Domain Users
- Domain Group Information
- Default Domain Policy
- Domain Functional Levels
- Password Policy
- Group Policy Objects (GPOs)
- Kerberos Delegation
- Domain Trusts
- Access Control Lists (ACLs)
Active Directory Structure
Active Directory (AD) is organized as a hierarchical tree structure. At the top is the forest, which serves as the security boundary and can include one or more domains. Each domain can also have nested subdomains, forming a tiered arrangement.
A forest includes all domains under a single administrative control, while a domain provides a logical grouping of objects like users, computers, and groups, all of which are accessible within that domain.
Within each domain, AD includes several built-in Organizational Units (OUs) — such as “Domain Controllers,” “Users,” and “Computers.” Administrators can also create custom OUs as needed. These OUs can contain both objects and nested OUs, enabling structured management and the application of distinct Group Policies at different levels. That will be useful later when constructing LDAP query
Why creating LDAP tool?
As I got deeper into AD security, I realized that tools like BloodHound and ldapsearch, while powerful, abstract away too much. I wanted to truly understand how LDAP works under the hood, how filters are built, how ACLs are retrieved, and how enumeration actually happens.
It wasn’t all about coding, it was about visibility, control, and learning AD the hard way. And it paid off.
LDAP different authentications methods
Simple Authentication: This includes anonymous authentication, unauthenticated authentication, and username/password authentication. Simple authentication means that a username and password create a BIND request to authenticate to the LDAP server.
SASL Authentication: SASL (Simple Authentication and Security Layer) uses a challenge-response protocol to authenticate the client and establish a secure communication layer and consists of 4 mechanisms:
- PLAIN: Sends the username and password in clear text (Base64-encoded, not encrypted).
- DIGEST-MD5 (Deprecated): Uses challenge-response with MD5 hashing to avoid sending passwords in clear text.
- GSSAPI (Kerberos): Uses Kerberos tickets for mutual authentication and encryption.
- EXTERNAL: Relies on an external mechanism (e.g., TLS client certs) for identity assertion.
The tool can be found here, and I will be working more on it and on this post in the near future.