LdapRecord-Laravel: LDAP as a first class part of a Laravel app

What the package covers, and how it installs

LdapRecord-Laravel integrates LDAP into a Laravel application, with the stated aim of multi-domain LDAP authentication and management, and the documentation lives at ldaprecord.com under the Laravel section. It is MIT licensed, published on Packagist as directorytree/ldaprecord-laravel, and the last push to the repository was on 2026-10-08 with release v4.0.5 on 2026-08-10. Installing it is one Composer command.

composer require directorytree/ldaprecord-laravel

The installation guide covers requirements and setup, and the project links a separate Directory Browser repository alongside the documentation and a discussions page, which suggests a package that expects you to be looking at the directory interactively as well as from code. The stated design goal appears first in the feature list and is worth repeating, because it explains the shape of the API. LdapRecord focuses on clean, easy to understand syntax along with thorough documentation.

Authentication, and the two things that gate it

Allowing LDAP users to log into the application is the first feature, and what sits on top of it is control over who may log in, through scopes and rules. Scopes are the coarse mechanism, essentially which parts of the directory are visible to a search, and rules are the fine one, matching attributes of a user's directory entry against conditions you define. The plain authentication configuration is documented separately from the rest, and the project links to both the usage page and the rules configuration. The point of having both is that a directory login is not automatically a user login. Anyone with a valid directory credential is not necessarily someone your application should accept, and the rules are where you say so.

Active Record models and a query builder over the directory

The part that makes this more than an auth guard is the modelling layer. LDAP objects are individual models, and you persist them to your LDAP server with a single save() call, which means a directory entry is treated as a record with the same lifecycle as a database row. On top of that sits an Eloquent-style query builder, so searching the directory uses a fluent interface you are already used to, and the project says you will feel right at home. The distinction between the two is that the model is the object, a user or a group, and the builder is the way you find objects. That pairing is what lets the same query that resolves a login also power an admin screen listing the members of a group.

Importing users and keeping them in sync

Users can be imported from the directory via a command, php artisan ldap:import, and the documentation links the importing section of the database authentication docs. The import is an Artisan command rather than a library call, which is the right shape for the job, because a directory sync is a scheduled or one-off operation rather than something a request should trigger. The consequence for your schema is that you now have two sources of user truth to reconcile, the directory and your own users table, and how you handle that reconciliation is a decision the package does not make for you. The import command gives you a way to bring records across, but the lifecycle of a user who is deleted from the directory but still has rows in your application is your problem.

Multi-domain, and the case it exists for

Multi-domain support is a feature in its own right, and it is described plainly: authenticate users from as many LDAP domains as you like, with support coming out of the box. This matters for the organisations where it comes up, where a company runs a directory per region or per subsidiary, and where the users of one domain should never see the users of another. A multi-domain setup is the kind of thing that is trivial to add later and painful to retrofit, because it changes how the connection is resolved per request, how a search is scoped, and how a user record is looked up. The documentation links a dedicated multi-domain page, which suggests it is a considered feature with its own rules rather than a flag.

The emulator, and why it changes how you test

The LDAP Directory Emulator lets you test authenticating and querying users without changing your application code, and you can create, update and delete LDAP objects without touching a real LDAP server. That is a testing story worth taking seriously, because directory code is otherwise among the least pleasant things to test. A test suite against a real directory is slow, shared state, and often skipped. An emulator that your existing test doubles already understand means the same test code runs against a directory in development and a fake one in CI, and the project says you do not change your application code to do it. The emulator is linked twice in the feature list, once for authentication and once for querying, which suggests it covers both paths rather than only the login one.

Support is a paid arrangement

There is a section on support that is unusual enough to quote rather than paraphrase. LdapRecord-Laravel is Supportware, and if you require support using the package, a sponsorship is required. The project frames it with a thank you for understanding. That is a business decision, not a technical one, and it is worth naming for what it is, because it changes who the package is for. The support sponsorship and the security disclosure email both point to the same maintainer, Steve Bauman, who states that all security vulnerabilities will be promptly addressed. The repository also carries a config/ directory, a database/ directory, resources/, src/ and tests/, with phpunit.xml at the top for the test runner.

Editorial conclusion

LdapRecord-Laravel fits a Laravel team that treats the directory as the source of user truth and wants to authenticate against it, query it and write to it with the same fluency the framework gives for a database, and it fits anyone who needs to test directory code without a live server because the emulator covers both authentication and queries. It does not fit a project that wants a plain auth guard and nothing else, since the package is much more than that, and it does not fit a team that will not pay for support, because the project states that a sponsorship is required if you require support. Before you adopt it, read the installation guide for requirements and setup, plan how the imported users reconcile with your own users table, and set the emulator up in your test suite early rather than at the end, since it changes how you write the tests around authentication.

Frequently asked questions

Official sources

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