Ldaprecord Laravel Laravel Package

Product Decisions This Supports

• Enterprise deal enablement — the primary justification for resourcing this at all. "Login with your corporate account" is a recurring gate in B2B and internal-tool sales cycles, especially where on-prem Active Directory is the default identity source. This package converts an unscoped 3–6 week integration estimate into a sized, schedulable backlog item. Value it as pipeline unblocked and deal velocity gained — not as developer convenience. Without a named prospect or segment that actually requires it, label it a speculative build and deprioritize.
• Build vs. buy, resolved toward buy with evidence rather than vibes. MIT-licensed with no per-seat cost, and it eliminates the need to hand-roll — then indefinitely own — an LDAP client and authentication path. The diligence signal is release hygiene, and it holds up: v4.0 shipped with a published upgrade guide, followed by v4.0.1–v4.0.5 as narrow, credible patches (logging channel adherence, LDAP error-code parsing on failed logins, password-mutator attribute detection, a float type hint, directory emulator chunk sizing and connection preservation). Laravel 13 compatibility landed in v3.4.3 — historically the strongest abandonment signal for a Laravel package — and it's green. That's a maintained dependency, not a dormant one.
• Roadmap sequencing for an "enterprise readiness" tier, sliced so each tranche sells alone. (1) LDAP authentication behind a per-tenant flag, (2) scheduled user import and sync, (3) group → role mapping, (4) audit and compliance surface. Each ships standalone value; none blocks the next. Gate each tranche on pipeline rather than committing the whole tier up front.
• Provisioning and offboarding as an operations capability, not a cron script. ldap:import with importer query scopes plus --delete-missing turns a manual HR-to-app onboarding ritual into a scheduled job — and closes the stale-account finding that appears in most SOC 2 and GDPR reviews. For many buyers this is a more defensible value story than login itself, because it reduces headcount cost and audit exposure rather than merely adding a checkbox.
• De-risked estimation via the Directory Emulator. Testing LDAP-shaped behavior locally and in CI without a live customer directory removes the classic "we can only validate against the customer's AD in staging" bottleneck — exactly where these projects blow their estimates. It also enables a credible demo environment before a design-partner tenant exists. The volume of recent emulator fixes (memberof virtualization, custom connections, isolated chunk handling, orWhereNotHas semantics) shows this is an actively exercised path, not a decorative feature.
• Reversible rollout instead of a big-bang auth rewrite. The LDAP guard coexists with the existing database guard, so LDAP login ships per-tenant behind a flag while everyone else keeps password auth. That converts a high-blast-radius auth refactor into a togglable experiment with per-customer rollback — a materially easier approval conversation.
• Pre-built answers for security questionnaires. Configurable logging channel and level, RulePassed/RuleFailed authentication events, and password-policy rules give concrete RFP responses without commissioning an audit subsystem.
• Explicit non-goals to write down now and defend in roadmap reviews. This is LDAP (Active Directory / OpenLDAP) — not SAML, not OIDC federation, not SCIM. If buyer requirements are trending toward "Entra ID via OIDC" or "SCIM provisioning," this is a partial answer for a shrinking segment. Do not let it become the anchor of the identity roadmap.

When to Consider This Package

Adopt when most of these hold:

• You are on Laravel/PHP with a team fluent in Laravel idioms. The entire proposition is Eloquent-shaped models, a native auth guard, Artisan commands, and a testable emulator. For a non-Laravel team that leverage largely evaporates, and you should evaluate the underlying LdapRecord library or a hosted IdP instead.
• Pipeline evidence exists: a named prospect, an inbound RFP, or a segment where on-prem Active Directory is the default identity source (healthcare, manufacturing, financial services, government-adjacent, large internal IT). "Enterprises like SSO" is not evidence.
• You need directory-backed authentication and user/attribute data, not identity assertion alone. Pure SSO is better served by a hosted IdP.
• You can secure LDAP admin cooperation on the customer side: bind credentials, base DN, OU scope, schema quirks, and network reachability from your infrastructure. This operational dependency is the single most common reason these projects stall — get a named owner before committing engineering time.
• Provisioning and offboarding automation are in scope at normal volumes (hundreds to low tens of thousands of users) where scheduled imports meet the freshness requirement.
• You want no per-seat cost and no vendor lock-in, and can accept community-grade support with internal ownership of upgrades.

Look elsewhere, or scope up, when:

• The requirement is genuinely SAML / OIDC / SCIM. Use a hosted IdP (Entra ID, Okta, WorkOS, Auth0 Enterprise Connections) or self-hosted Keycloak. LdapRecord does not do federation, and customers routinely say "SSO" when they mean OIDC — qualify this in discovery before it reaches the roadmap.
• Procurement demands a contractual SLA, indemnity, or a named support contact. An MIT community package cannot clear that bar; budget a commercial IAM vendor or an explicit internal support arrangement.
• The directory is very large or highly dynamic (100K+ users, real-time propagation, multi-master replication edge cases). Scheduled imports won't hit the freshness target; evaluate dedicated sync or identity-governance tooling.
• You need advanced directory features — ADFS claims rules, certificate/smart-card auth, PKI flows, LDAP-aware MFA orchestration. Out of scope; price as custom work separately or decline.
• Your threat model or customer contracts require audited, vendor-maintained auth and crypto code. The code is sound and the package is established at 574 stars, but widely used is not audited. Make that call consciously and record it.
• Bus factor is a governance concern. Maintenance is concentrated in a small maintainer group around DirectoryTree and the dependent count is effectively nil. Mitigate by pinning versions, tracking the changelog, and budgeting upgrades as scheduled work — and keep an exit plan, which is realistic here because the guard is swappable.

Pilot exit criteria (the go/no-go gate): LDAP login works end-to-end against one real tenant directory; a scheduled import with conflict resolution runs unattended for a full cycle; --delete-missing deprovisioning is validated against a test OU; the directory emulator covers the auth and sync paths in CI; and a rollback to the database guard is demonstrated. Miss any of these and the estimate was wrong — stop and re-scope before the next tranche.

How to Pitch It (Stakeholders)

To executives: We have a recurring blocker in enterprise deals — customers want their employees signing in with corporate credentials, and today we either decline or absorb weeks of custom work. This package is a free, MIT-licensed, actively maintained Laravel component that turns that ask into a flag we can switch on per customer. It is reversible: existing customers keep their current login, and we can turn LDAP off for any account that hits trouble. It also unlocks automated user provisioning and deprovisioning, which removes manual onboarding labor and closes a stale-account finding that shows up in most security audits. The ask is one tranche of engineering time, gated on a named prospect, with a clear stopping point after each slice.

To engineering: DirectoryTree's LdapRecord-Laravel gives us an Eloquent-style ORM over LDAP, a native auth guard that coexists with our existing one, Artisan commands for import/sync/browse, and a Directory Emulator so we can test auth and sync in CI without a live customer directory — that last piece is what keeps the estimate honest. It is on v4.0.5 with a published upgrade guide, tracks Laravel 11/12/13, and its recent patch history is small, specific, and credible. Known constraints to design around: it is LDAP only — no SAML, OIDC, or SCIM — so federation stays out of scope; support is community-grade, so we pin versions and own upgrades; maintenance is concentrated in a small maintainer group, so we keep the guard swappable as an exit plan. Non-negotiable prerequisite: a named LDAP administrator on the customer side with bind credentials, base DN, and OU scope agreed before we start.