Ldaptools Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for directory authentication. LDAP/Active Directory integration is a well-understood, low-differentiation capability. This package is a candidate to buy/adopt rather than hand-roll, letting the team spend roadmap capacity on core product instead of bind logic, reconnect handling, and schema quirks.
• Enterprise-readiness gating. AD/LDAP login and group-based roles are frequently a procurement blocker for on-prem and large-account deals. Whether we support it — and how soon — is a revenue-facing roadmap decision, not just an engineering one. This package sizes that work.
• Feature scoping for "LDAP support." The underlying library covers more than bind-and-authenticate: attribute/schema mapping, group resolution, multi-domain operation, and directory writes. That lets us decide whether the commitment is authentication only (cheap, defensible) or directory CRUD and group-driven authorization (much larger surface, more support burden).
• Buy-vs-fork risk posture. 48 stars and zero dependents is a weak ecosystem signal. That's a decision input on whether to adopt as-is, wrap behind our own auth adapter with a pinned version, or vendor a fork. It argues for isolation regardless of choice.
• Architecture boundary decision. Adopting any directory library forces the question of whether auth is an interface we own (swap LDAP for OIDC/SAML later) or a hard dependency. The answer shapes the identity roadmap for the next 18 months.

Important caveat for the decision record: this is a Symfony bundle, not a Laravel package, despite being catalogued alongside Laravel/PHP options. It will not drop into a Laravel app. If our stack is Laravel, the relevant artifact is the framework-agnostic ldaptools/ldaptools library — or a Laravel-native alternative like LdapRecord — and this bundle's value is mainly as a reference implementation and configuration pattern. Confirm the target stack before this enters a roadmap.

When to Consider This Package

Adopt when:

• The application is Symfony-based and the team already lives in bundle config, DI, and YAML-driven service definitions.
• You need more than a credential check: group-to-role mapping, multi-domain/forest support, attribute mapping, or directory writes are on the near-term roadmap.
• You want declarative configuration instead of scattered raw ldap_* calls, and the team lacks deep LDAP expertise.
• The integration is a secondary concern behind a stable internal interface, so slow upstream releases don't block us.

Look elsewhere when:

• The stack is Laravel or framework-agnostic. This bundle doesn't apply; start from ldaptools/ldaptools or a Laravel-native package.
• Only simple bind authentication is needed. PHP's native ldap extension is a few dozen lines; a bundle adds a dependency without adding value.
• Maintenance guarantees matter. Zero dependents and low stars mean no downstream pressure to keep it current. Verify recent releases and PHP-version support before committing — treat that as a hard gate, not a formality.
• A hosted identity provider is viable. Entra ID, Okta, or Auth0 via OIDC/SAML usually beats raw LDAP on supportability, auditability, and MFA. LDAP is the right answer mainly for on-prem customers who can't expose a directory externally.
• You need MFA, conditional access, or modern session semantics. Those belong at an IdP layer, not a bind.

How to Pitch It (Stakeholders)

To executives: Enterprise and on-prem buyers routinely require Active Directory login before they'll sign. This package is a shortcut to that capability rather than a from-scratch build, and it lets us price and sequence the "enterprise-ready" milestone concretely. The tradeoff is maturity: it's a small, low-adoption project, so we should adopt it behind an interface we control and budget a small amount of maintenance exposure rather than treat it as a long-term platform bet. My recommendation is a timeboxed spike to validate it against a real customer directory before we commit it to a release.

To engineering: This is a Symfony bundle wrapping a more capable, framework-agnostic LDAP library. It buys us schema mapping, group resolution, and multi-domain handling in configuration instead of code, which is where most LDAP projects bleed time. Two constraints: it's Symfony-only, so it's only relevant if that's our stack, and the upstream community is thin — pin the version, wrap it in an auth adapter we own, and keep the swap to OIDC or an IdP possible without touching product code. Treat it as a well-shaped reference implementation we can lean on, with a fork as the fallback, not as a dependency we inherit passively.