LdapRecord: an Active Record style ORM for LDAP directories

Eloquent's ideas, pointed at a directory

LdapRecord is described in the project description as a fully-featured LDAP framework, and the README puts it more precisely: an Active Record ORM for working with LDAP directories.

That lineage is stated directly in the credits. The package is directly inspired by Laravel's Eloquent, and most features are direct ports to an LDAP equivalent, with the README thanking Taylor Otwell for the Eloquent work. The homepage is ldaprecord.com, and the documentation is versioned, with the current path pointing at the v4 documentation.

For a PHP developer who has used Eloquent, the shape will be immediately familiar. Directory objects are models, you query them through a connection, and the framework handles the LDAP conversation underneath. The stated aim is to connect to your LDAP servers and start running queries in a matter of minutes, and the headline features are a fluent LDAP filter builder, built-in connection management for multiple domains, and creating and modifying LDAP objects with minimal code.

The multi-domain point deserves emphasis, because it is where directory work usually gets painful. An organisation with several domains, or a set of partner directories, means several connection configurations and, in most hand written code, several sets of nearly identical helper functions. Connection management is built in here rather than left to the application.

The language is PHP, the licence is MIT, and the package is on Packagist as directorytree/ldaprecord. There is a separate repository for the Laravel integration, LdapRecord-Laravel, which matters for anyone in that ecosystem because the two are installed separately.

A fluent filter builder instead of hand built search strings

The fluent filter builder is the piece that makes the difference between an ORM and a thin LDAP wrapper.

An LDAP filter is a string in a small, unforgiving grammar, with escaping rules that will bite you the first time a value contains a parenthesis. Writing those by hand is where directory code goes wrong, and a builder that produces the filter from typed method calls removes both the grammar problem and the escaping problem from the caller.

The API surface follows the Active Record idea the README describes. You have models that represent directory objects, you have a connection that talks to a server, and the queries are expressed against the model rather than against raw protocol elements. The README frames this as creating and modifying LDAP objects with minimal code, which is the same promise Eloquent makes about relational tables.

The parts the README does not spell out are the parts you would want to know before committing: how paging is handled, how filters combine with server side sorting, and how the framework treats an LDAP result set that a server has paged. The visible documentation is a summary with links into the v4 documentation, so those details are one click away rather than in the README itself.

The Active Directory sections are more specific, and they are the part that general LDAP libraries usually leave to the reader.

Account control, password resets and the Active Directory recycle bin

The Active Directory features section is the most concrete part of the README, and it covers three operations that are tedious in raw LDAP.

The first is enabling and disabling accounts. The framework detects and assigns User Account Control values through a fluent Account Control builder, and the README links to the section on it. User Account Control is the bit field that carries the account flags in Active Directory, and setting it by hand is exactly the kind of operation where a mistake locks people out.

The second is passwords, with built-in support for both changing and resetting passwords on Active Directory accounts, each with its own documentation page. Password operations in Active Directory involve protected attributes and protocol subtleties that a plain attribute write does not cover, and the README treats changing and resetting as distinct, documented operations.

The third is restoring deleted objects, where the README says the Active Directory recycle bin is accessible and deleted objects can be restored. The documentation link is in the models section, which suggests the operation is modelled rather than bolted on, and a deleted object being restorable is a genuinely useful capability when someone deletes the wrong account.

All three are Active Directory specific, which is the clearest statement of the library's scope. It is a general LDAP framework with a first class Active Directory layer, and the parts of the API that carry real weight are the parts that assume a Microsoft directory.

Installing the package, and a local directory to try it against

Installation is one Composer command:

composer require directorytree/ldaprecord

The README then points at the installation guide for requirements and setup, and at the quickstart for connecting to your directory. Those two pages are the actual documentation, and they are versioned under the v4 path, so it is worth reading the v4 quickstart rather than a tutorial written for an earlier release.

For development, the repository carries a docker-compose file that gives you an OpenLDAP server and a web admin interface. The directory service is the osixia image at 1.4.0, configured with a local.com domain, an organisation of Local, a uid and gid of 1000, and an admin password, with ports 389 and 636 published:

services:
    ldap:
        image: osixia/openldap:1.4.0
        container_name: ldap
        restart: always
        hostname: local.com
        environment:
            LDAP_TLS_VERIFY_CLIENT: try
            LDAP_OPENLDAP_UID: 1000
            LDAP_OPENLDAP_GID: 1000
            LDAP_ORGANISATION: Local
            LDAP_DOMAIN : local.com
            LDAP_ADMIN_PASSWORD: secret

The admin interface is the osixia phpldapadmin image at 0.9.0, pointed at the ldap host and published on 6443. A bridge network named local connects the two.

This is a development fixture with a default administrator password committed to the repository, so it is useful for running the test suite and for trying filters by hand, and it is not something to expose on a shared network. The test suite itself is driven by phpunit.xml, and the workflow badge in the README points at a run-tests.yml workflow.

Support requires a sponsorship, and that is stated plainly

One section of the README is unusual enough to deserve a paragraph of its own, because it affects who can use the library and on what terms.

It is headed LdapRecord is Supportware, and it says that if you require support using LdapRecord, a sponsorship to the maintainer is required. The thanks emoji in the original is a small thing; the policy is not. A bug report, a question or a feature request from a non-sponsor is not a support request, in the terms the README sets.

The security reporting route is separate and is not gated the same way. The README asks that security vulnerabilities be emailed to Steve Bauman at the address given, and states that all security vulnerabilities will be promptly addressed. That distinction is the right one, and it is worth an adopter noticing that the two paths behave differently.

For an organisation, this is a procurement question more than a technical one. The code is MIT licensed, so using it, modifying it and shipping it are all fine without paying anyone, and the sponsorship buys support rather than rights. A team that wants a maintained dependency with a contractual support commitment would look elsewhere, and a team that is comfortable with an open source project maintained by one person with a public support policy can adopt it knowing exactly where it stands.

The credits section asks readers to support the inspiration for the project, Eloquent, through a sponsorship of Taylor Otwell, which is a nice touch and a fairly accurate description of how the ecosystem funds itself.

A 4.x line, a versioned docs site and a small test suite

The maintenance picture is a project with a recent history and a small core.

The recent releases are v4.0.8 on 2026-09-17, v4.1.0 on 2026-10-04, and v4.1.1 on 2026-10-08, with the last push to the repository on 2026-10-08. So the 4.1 line is young and moving, and the point releases are close together.

The documentation is versioned in the URL, with the core documentation living under the v4 path on ldaprecord.com. That is the arrangement a large project with a long history uses, and it is a reminder that examples found by searching may be written for a version whose behaviour differs from what you have installed. The current major is 4.x, and the documentation links in the README point at the v4 pages, so the default reading is current.

The repository itself is small and conventional: src/ for the framework, tests/ for the suite, a composer.json, a phpunit.xml, a docker-compose.yml for the development directory, and a licence.md file, which is the naming the project uses rather than the usual LICENSE.

The package is published on Packagist as directorytree/ldaprecord, with badges for total downloads, the latest version and the licence. The Laravel integration lives in its own repository, LdapRecord-Laravel, and the README links a discussions page for questions rather than pointing at an issue tracker, which is the usual arrangement for a project that would rather talk than accumulate issues.

Editorial conclusion

LdapRecord suits a PHP team that has to work with Active Directory and would rather model directory objects than assemble LDAP filters by hand, and it suits a Laravel shop that already thinks in Eloquent terms. It does not suit you if your directory work is a single one-off search, because the abstraction is heavier than a raw query, and it does not suit a project that expects a database transaction model, because a directory is not a relational store and the framework does not pretend otherwise. Check three things before you adopt it: which LDAP server you run against, since the Active Directory features are specific to that server, that you are comfortable with the maintenance terms, since the README asks for a sponsorship to obtain support, and that you read the v4 documentation rather than examples written for an earlier major version. The newest release is v4.1.1 from 2026-10-08 and the last push to the repository was on the same day.

Frequently asked questions

Official sources

1. DirectoryTree/LdapRecord on GitHub
2. License: MIT
3. Project website
4. README
5. Releases