Adldap2 Laravel Laravel Package

Product Decisions This Supports

• Segment expansion into on-prem / enterprise customers. Many mid-market and enterprise buyers still run Active Directory and will not accept a separate local password. This package turns "we can't support your identity provider" into a scoped, solvable requirement rather than a lost deal.
• Build vs. buy vs. adopt. The alternative is writing php-ldap bind/search/TLS handling, connection pooling, and a Laravel auth driver from scratch — roughly weeks of engineering plus ongoing maintenance. Adopting an MIT package (893 stars, mature config surface) is the cheaper path to a working prototype. The maintenance caveat below is now narrower than it was: v6.1.7 ships Laravel 10.x support, so the package is not frozen in place, but it is still officially archived.
• Roadmap sequencing for identity. Forces an explicit decision on how far you go: authentication only (bind + login) vs. directory management (user CRUD, OU moves, group membership sync, password resets). The package supports both, so it's really a product-scope question — auth-only is a 1–2 sprint slice; full provisioning is a multi-quarter platform investment.
• Role and permission model. Group-to-role mapping from AD security groups is a top-requested enterprise feature and directly reduces manual admin work; this package makes it feasible without a separate sync service.
• Onboarding/offboarding automation. Directory-driven user provisioning supports the HRIS-to-app lifecycle story ("hire in Workday → account in our app"), which is a strong differentiator in security reviews and procurement questionnaires.
• Use-case fit: internal admin consoles, employee intranets, B2B portals for customers who are themselves enterprises, and any product sold into regulated industries with directory mandates.
• Prioritization input: count how many prospects/customers ask for "AD / LDAP / SSO" in discovery. That count, not the package, should drive whether this is a now, next, or later item.

When to Consider This Package

Consider it when all of the following hold:

• You ship a Laravel application and want directory auth to feel native — an auth driver, Eloquent-style models for users/groups, config-file-driven connections — rather than bolting on a generic LDAP library.
• Your buyer has on-prem Active Directory or OpenLDAP and expects classic bind-based auth, not a cloud IdP.
• You need multiple domains/connections or group-based authorization in the same release.
• Your application is on Laravel 10.x or earlier — explicitly supported as of v6.1.7 — or you are willing to carry the compatibility work yourself for newer framework/PHP versions. Verify against your exact target before committing; do not assume forward compatibility beyond the last release.

Look elsewhere (or plan to fork) when:

• The archived status is disqualifying for your risk posture. This remains the single biggest factor. Laravel 10 support landed via a community contribution (laravel-shift), which is reassuring evidence that the package still receives occasional patches — but there is no committed upstream maintenance cadence, and LDAP is a security-sensitive surface (credential binding, TLS/StartTLS, injection-safe filter construction). Treat it as vendored code you now own, and budget accordingly — or evaluate LdapRecord / LdapRecord-Laravel, the maintained successor from the same author, as the default recommendation for new work.
• You are building on Laravel 11+ or a PHP version newer than the last release supports — compatibility is now a known, dated ceiling rather than an open question. Budget a fork or pick the successor.
• Your customer's identity story is actually cloud SSO (Entra ID, Okta, Google Workspace) with SAML/OIDC — that's a different product decision and a different library; LDAP bind is the wrong primitive.
• You only need a one-off admin login for a handful of staff — a simpler integration or a manual account may beat the operational overhead of directory config, TLS certs, and network egress rules.
• You need write-back provisioning at scale (thousands of users, scheduled sync, conflict handling) — that's a sync-service problem, not an auth-package problem, and should be scoped as its own initiative.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed integration that removes a recurring enterprise sales blocker — "your app doesn't work with our Active Directory." It lets customers log in with their corporate credentials, lets us derive roles from existing AD groups, and lets IT deprovision access centrally, which shortens security reviews and reduces our own account-management toil. The strategic value is segment access and faster enterprise onboarding, not novel functionality. The honest caveat: the upstream project was archived in early 2023, though it still receives compatibility patches — v6.1.7 added Laravel 10 support. That reduces the "abandoned dependency" risk but does not eliminate it: there is no support commitment, and we would effectively own the code if we build on it long-term. We should adopt a maintained equivalent or explicitly accept ownership of a fork — a modest, bounded engineering cost that should be priced into the proposal rather than discovered later.

To engineering: It's a Laravel-native LDAP layer — config-driven connections, an auth guard, and models for users and groups, so the integration is mostly configuration plus a group-to-role mapping layer rather than custom protocol code. v6.1.7 adds Laravel 10.x compatibility, so we have a known-good ceiling of Laravel 10 — if our roadmap has us on 11+ during this feature's lifetime, factor that in now. Two asks: (1) validate framework/PHP compatibility and TLS behavior against our target deployment before we commit, and (2) pick a maintenance posture up front — maintained successor, pinned-and-vendored fork with a named owner, or defer. We should not adopt an archived dependency in a security-sensitive path without that decision documented.