Adldap2 Laravel Laravel Package

Technical Evaluation

Architecture fit

Adldap2-Laravel is a thin Laravel service-provider wrapper around the adldap2/adldap2 core library. It binds an LDAP connection manager into the container, exposes a facade, provides a config file (config/ldap.php) supporting multiple connections and auto-connect, and ships an authentication guard/driver plus a trait for Eloquent models that imports LDAP attributes into a local users table. As a fit for a Laravel application it is idiomatic and low-friction; as a fit for a new build it is a dead end, because the package is archived upstream (last tagged release 2023-02-15, now followed by v6.1.7) and its core dependency adldap2/adldap2 is likewise archived. The author's own guidance is to move to LdapRecord (ldaprecord-laravel), the successor project with a substantially similar API and a documented migration path.

v6.1.7 adds Laravel 10.x compatibility (contributed via laravel-shift, PR #932). This is a compatibility patch, not a resumption of maintenance: no new features, no security process, no roadmap, no active issue triage. It does confirm the package runs on Laravel 10 and, by extension, extends the runway to the next major (Laravel 11) as the likely forcing function. It also demonstrates that the archived repository is soft-archived — a mechanical PR can still be merged — which slightly narrows the "totally abandoned" framing but does not restore ownership, disclosure handling, or CVE response.

Net: good architectural ergonomics, still unacceptable lifecycle posture. Treat this evaluation as "should we keep it, fork it, or replace it," not "should we adopt it."

Integration feasibility

• Greenfield integration is straightforward technically — Composer install, publish config, set env vars, wire the guard — typically a 1–3 day effort for a competent Laravel developer against a test directory (OpenLDAP or a Windows Server test domain).
• Laravel 10 is now explicitly supported. Confirms the practical upper bound on a maintained runtime; assumes PHP 8.1–8.2 per the L10 matrix. Laravel 11 is not covered and is the next likely break.
• Requires the ext-ldap PHP extension and outbound LDAPS (636) or StartTLS reachability to domain controllers; this is a platform/network prerequisite, not a code concern.
• Supports Active Directory and OpenLDAP; AD-specific features (recursive groups, memberOf, password hashing/modify, account lockout semantics) are where most of the real integration risk sits.
• Write operations (create/modify/delete users, password changes) are supported but are the least-tested surface and are exactly the area where an unmaintained library is most dangerous.

Technical risk

Secondary risks unchanged: issues/PRs may close, community forks exist but are unvetted, documentation remains online and accurate for the frozen version. v6.1.7 slightly improves the picture — pinning to it is preferable to an older tag — but the dependency-scanning story (abandoned-package warnings) is unchanged.

Key questions

1. Is this an existing production dependency (retain/remediate decision) or a proposed new one? If proposed, why not LdapRecord directly?
2. What is our Laravel upgrade cadence, and does the Composer constraint set survive Laravel 11 without a fork? (v6.1.7 clears L10; treat L11 as the next decision gate.)
3. Do we need write-back to the directory (provisioning, password reset, group management), or read-only authentication and attribute sync?
4. What is our risk tolerance for an unpatched tier-0 auth dependency — does InfoSec require a maintained upstream or an internal fork with a named owner?
5. Do we have an internal AD/LDAP test directory, or will integration be validated against production?
6. Has anyone audited the vendored code for TLS certificate verification and bind-timeout behavior? (Unmaintained LDAP clients frequently ship permissive TLS defaults.)
7. What is the exit cost — how many call sites touch the Adldap facade directly rather than an internal interface?
8. Does v6.1.7 materially change our L11/L11+ timeline? If we were blocked on L10, we are no longer blocked — but the migration is deferred, not cancelled.

Integration Approach

Stack fit

Fits any Laravel 6–10 application with PHP 7.3–8.x (L10 requires 8.1++) and ext-ldap. v6.1.7 is the recommended pin if staying on the package; it is the only tag validated against L10. The auth guard drops into config/auth.php alongside existing providers, so it composes with local database auth if you need a hybrid (e.g., LDAP for staff, local for service accounts). The Eloquent sync trait assumes a conventional users table with email/username/objectguid columns; if your schema diverges, expect custom mapping work.

Migration path

Recommend replace, don't adopt. Target LdapRecord-Laravel:

1. Inventory all Adldap:: facade calls, guard configuration, model traits, and any raw adldap2 core usage via static analysis/grep. This defines the blast radius.
2. Introduce an internal seam — a DirectoryProvider interface (authenticate, findUser, syncAttributes, inGroup) — and reimplement the current adapter behind it. This is the single highest-value step and can be done on the archived library.
3. Swap the implementation to LdapRecord behind the same interface. API similarity makes this largely mechanical; the differences concentrate in configuration keys, the guard class, and the sync trait.
4. Run both against a shadow directory in staging, diffing auth results and synced attributes before cutover.
5. Decommission the archived dependency and remove the package from composer.json entirely.

If short-term retention is chosen (now more defensible given L10 support in v6.1.7), pin to v6.1.7, fork to an internal namespace, add it to the dependency-review and CVE-watch process, and assign a named owner with an explicit sunset date. Do not let the recent tag be read as evidence that an upgrade path exists beyond L11.

Compatibility

v6.1.7 clears Laravel 10. Verify before any commitment: exact PHP 8.1/8.2 constraints of v6.1.7 versus your target runtime; ext-ldap availability in all deploy targets including CI and containers; LDAP client library behavior with LDAPS and modern TLS; and whether the guard supports Laravel 10's Auth::attempt contract fully (remember-me, session regeneration, password rehash hooks). Note that L11 is not covered by any released tag — treat L11 as the de facto migration deadline.

Sequencing

Seam first, replacement second, removal third. The v6.1.7 patch removes the imminent L10 constraint conflict as a forcing function, so if L10 is your target you will not get a natural trigger — schedule the migration explicitly rather than waiting for the next upgrade to force it. Do not pair a Laravel 11 upgrade with an LDAP provider swap in the same release; if L11 is on the roadmap, the LdapRecord migration should precede it, not follow.

Operational Impact

Maintenance

Effectively zero upstream maintenance, but with a caveat new to v6.1.7: the repository is soft-archived — mechanical PRs (compat patches) can still land, while security triage, issue acknowledgement, and roadmap do not exist. Plan accordingly:

• Bug fixes, PHP/Laravel compatibility beyond L10, and security review remain yours.
• Budget a fork-maintenance allowance of roughly 5–15 engineer-days per year for a pinned fork, versus near-zero for LdapRecord.
• Dependency scanners (Dependabot, Snyk, composer audit) will flag the abandoned package indefinitely; the v6.1.7 tag does not clear those warnings. Expect either noise or an accepted-risk exception re-justified each cycle.
• Risk of deferral has increased: the L10 patch makes "we'll migrate later" cheaper to say. Add an explicit calendar trigger (L11 upgrade planning, or a sunset date) so the migration does not drift.

Support

No vendor, no active issue tracker for triage, no SLAs. The v6.1.7 merge shows some responsiveness to mechanical contributions, but that is not a support channel — do not rely on it for a bug you file. Support remains Stack Overflow and archived GitHub issues. Internal team knowledge is the de facto documentation; ensure at least two engineers understand the bind flow and the attribute-sync logic. The LdapRecord docs are the best available substitute reference.

Scaling

LDAP auth is low-throughput relative to typical web traffic, so raw scaling is rarely the constraint. Unchanged from prior assessment:

• Connection handling — one bind per request (or per auth attempt) is normal; avoid connection-per-attribute-lookup patterns. Paged searches (ldap_control_paged_result) matter on directories with large OUs.
• Failover — multi-domain-controller config exists but health-based failover is naive; a hung DC can add seconds to every login.
• Sync load — bulk attribute syncs against large directories should be queued, not inline in the request path.
• Worker exhaustion — LDAP socket timeouts are the classic cause of PHP-FPM pool saturation during a directory outage. Set aggressive connect/read timeouts and fail closed with a clear error page.

Failure modes

1. Directory unreachable — total auth outage; all users locked out. Mitigate with an explicit break-glass local admin path independent of LDAP.
2. TLS certificate expiry or CA rotation — sudden auth failure with opaque errors; monitor cert expiry on the LDAP endpoint.
3. Account lockout storms — retry logic or cached-credential retries against AD can lock out users org-wide. Ensure no automatic retry on bind failure.
4. Silent attribute drift — schema changes or AD-side moves break group mapping without raising errors; alert on sync failures and diff counts.
5. Unpatched vulnerability — no upstream fix path; only mitigation is the fork or the migration. The v6.1.7 patch does not change this.
6. Migration complacency — the L10 patch reads as "still alive" to stakeholders who do not track the archive status. Budget effort to keep the migration on the roadmap.

Ramp-up

Low for a Laravel developer: published config, facade, guard, and trait are conventional, and the archived docs remain usable. Estimate 1–2 days to productive, 1 week to confident on AD-specific behavior (nested groups, sAMAccountName vs userPrincipalName, DN escaping). The harder ramp is operational, not developer: on-call staff need runbooks for directory outages, TLS failures, and lockout incidents, plus a documented recovery procedure that does not route through LDAP.

Recommendation: Do not adopt. If already present, pin to v6.1.7 (the only L10-validated tag), isolate behind an interface, migrate to LdapRecord-Laravel on a defined calendar trigger — Laravel 11 planning is a natural one — and remove the dependency. If migration is genuinely blocked, treat the fork as a formal, owned, time-boxed risk acceptance, not a silent default, and do not let the v6.1.7 compat patch be read internally as evidence of ongoing upstream support.