ldeep: dumping an Active Directory for the report you have to write

One run, the whole directory

ldeep is described as an in-depth LDAP enumeration utility, and the shape of it is closer to a collection script than to an interactive scanner. You point it at a domain and a server, ask for `all`, and it walks the directory pulling out dozens of categories of object in one pass.

The output during a full run is a list of retrievals, each of which is either retrieved or reported as verbose output. The categories include users, computers, groups, organisational units, group policy objects, trusts, delegations, domain policy, FSMO, fsp, gmsa, smsa, pso, pkis, silos, subnets, zones, the schema, server_info, auth_policies, bitlockerkeys, dns_records and shadow_principals.

Several of those names point at configuration weaknesses rather than at directory contents, which is where the tool earns its keep. Delegations, shadow principals, group managed service accounts and the flexible single master operation roles are all configuration that is easy to leave in place and hard to find by hand across a large domain.

The tool also reports what it could not do. A run shows messages such as an invalid attribute type preventing the discovery of SCCM management points, and an invalid class in the objectClass attribute for the same purpose. The tool keeps going after a failure and records it, which is the behaviour you want in a collection run, since a single inaccessible object should not end the assessment.

Three modes: live directory, cached files, protections

The top level help shows three modes in the `Mode` argument:

  $ ldeep -h
  usage: ldeep - 2.0.4.dev6+gf055cc0 [-h] [-o OUTFILE] [--security_desc] {ldap,cache,protections} ...

  options:
    -h, --help            show this help message and exit
    -o, --outfile OUTFILE
                          Store the results in a file
    --security_desc       Enable the retrieval of security descriptors in ldeep results

  Mode:
    Available modes

    {ldap,cache,protections}
                          Operation to be performed

`ldap` runs against a live Active Directory LDAP server. `cache` runs against files saved earlier, which the documentation describes as being able to run locally on saved files. `protections` is the third mode, and the name suggests it is the view that focuses on the protection related configuration.

The cache mode is the interesting one for reporting. The example shows it reading a saved directory and listing the users it contains:

  $ ldeep cache -d backup -p winlab users
  Administrator
  [...]

That means the collection and the analysis can be separated. A single pass against the domain gathers the data, the output is stored with the `-o` option, and the interesting questions get asked afterwards against the saved copy without touching the network again. For an engagement where the domain is locked down after the initial access, that is the difference between a useful report and a single screenshot.

The `--security_desc` flag adds security descriptors to the results, and is off by default, which is sensible since pulling them costs more and changes what the output contains.

Authentication choices, and a throttle with a purpose

The LDAP mode takes the domain, the server, the base DN and the credentials. The documented example binds with a username and password against a lab server:

  $ ldeep ldap -u Administrator -p 'password' -d winlab -s ldap://10.0.0.1 all backup/winlab

The options list shows the full set of controls. The domain can be given as NetBIOS or FQDN, the LDAP path as a URL such as `ldap://corp.contoso.com:389`, and the base DN is pulled from the remote server unless you set `-b`. Authentication type is `-t {ntlm,simple}`, with NTLM as the default, and the help text is explicit that simple bind is always in cleartext with ldap as opposed to ldaps.

Two options deserve your attention. `--throttle` adds a delay between queries, described in the help as a way to sneak under detection thresholds, with the argument being the number of seconds to sleep between queries. And `--page_size` sets the page size used by the engine when querying the server, defaulting to 1000.

The throttle exists because domain controllers log and alert on unusual query patterns, and a tool that fires dozens of different LDAP searches in a few seconds will look like one. Using it is not optional politeness in an environment with detection; it is the difference between a quiet collection and a noisy one that triggers a call.

The option list also shows certificate based authentication, with `--pfx-file`, `--pfx-pass`, `--cert-pem` and `--key-pem`, plus `-k` and an `-H` option for NTLM, and `-n` to turn off encryption where it is otherwise on by default.

Installing it, with or without Kerberos

Installation is a pip command in the simplest case:

  python -m pip install ldeep

Or from the current state of the master branch:

  python -m pip install git+https://github.com/franc-pentest/ldeep

Kerberos support needs native extensions and some headers, and the two distributions named in the documentation show what that means in practice:

  sudo apt-get install -y libkrb5-dev krb5-config gcc python3-dev

  sudo pacman -S krb5

The development path uses pdm as the build system. Install pdm, clone, then install an isolated environment and run the tool locally:

  python -m pip install pdm
  git clone https://github.com/franc-pentest/ldeep && cd ldeep

  pdm install

  pdm run ldeep

For a container, the repository includes a Dockerfile with a comment showing both the build and the run command:

# Build command: docker build -t ldeep .
# Execute with: docker run --rm ldeep $args

FROM python:3.12-slim
WORKDIR /ldeep
RUN apt-get update && apt-get install -y --no-install-recommends \
    git libkrb5-dev gcc python3-dev \
    && rm -rf /var/lib/apt/lists/*
COPY . .
RUN pip install .
ENTRYPOINT [ "ldeep" ]

The container image installs the same Kerberos headers, so the container is a reasonable way to avoid polluting a workstation with build tooling for a tool you may only use during an engagement.

Dependencies reveal what the tool actually does

The project metadata lists the runtime dependencies, and they explain a lot about the scope. `ldap3-bleeding-edge` is pinned to an exact version, `2.10.1.1337`, which is a fork of the ldap3 library maintained for this kind of tooling and pinned because its behaviour matters for the results. `gssapi` provides the Kerberos side, and `dnspython` handles the DNS record retrievals.

Then there are the cryptography packages: `cryptography`, `pycryptodome`, `pycryptodomex`, `oscrypto` and `dpapi-ng`. The last one is the giveaway, since DPAPI is the Windows data protection API, and decrypting stored credentials is not something a general purpose LDAP client needs. The combination with `bitlockerkeys` and `shadow_principals` in the retrieval list tells you the tool is built to pull data that is encrypted at rest in a Windows environment.

The interface layer is `commandparse`, with `termcolor` for the coloured output markers and `tqdm` for progress bars during the long retrievals.

Python support is declared as 3.9 up to but not including 3.16, the project is marked as Beta, and the version number is generated from the source control history by pdm, which is why the help output shows a development version like 2.0.4.dev6 with a commit hash in it. The console entry point is `ldeep.__main__:main`, and the development dependencies include `nuitka`, which is used to compile the tool into a standalone binary, plus ruff, black and twine.

An assessment tool with a clear line about authorisation

The project keywords are pentesting, security, Windows, Active Directory and networks, and one of the authors lists a synacktiv.com email address, so the intended context is an authorised engagement rather than opportunistic use. The dependencies on stored credentials and the throttle option both point the same way: this is a tool for someone with legitimate access who needs to be careful about how they use it.

That framing is the honest caveat to keep in mind. A tool that can pull delegation configuration, shadow principals, bitlocker keys and stored credentials from a directory is not something to point at a domain you are not engaged to test, and the presence of write-capable operations in the mode list, such as adding a user to a group or changing UAC, means the same argument applies to the actions as to the reads.

On maintenance, the releases are 2.0.0 on 2026-02-19, 2.0.2 on 2026-05-06 and 2.0.3 on 2026-05-23, and the last push was on 2026-10-18 on the default branch `master`, with the repository not archived. The version scheme shows a project that restarted its numbering for the 2.x line, which is what you would expect after a rewrite, and the pinned bleeding edge ldap3 dependency suggests the maintainers track changes in that library deliberately.

The licence is MIT, with the licence file at the root of the repository.

Editorial conclusion

ldeep suits a penetration tester or security auditor who has authorised access to a domain and needs one tool that collects the directory material a report needs rather than a dozen one-off queries. It is the wrong tool for an environment where you may not touch the domain, since every mode either binds to LDAP or reads a cache someone else produced, and it is a poor fit if you cannot run Python with native build tooling, because the Kerberos support needs a compiler and the krb5 headers. Before you run it, use `--throttle` as the documentation intends, confirm you have written authorisation for the domain, and check that the `ldap3-bleeding-edge` pin in `pyproject.toml` still matches the server you are testing.

Frequently asked questions

Official sources

1. franc-pentest/ldeep on GitHub
2. Issues
3. License: MIT
4. README
5. Releases