Home/ Questions/Q 798187
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T22:55:47+00:00

Our project uses an LDAP repository for storing users. In production this will be

  • 0

Our project uses an LDAP repository for storing users. In production this will be Active Directory. For development, we seem to have a couple of options:

  • Install an AD LDS instance that everyone uses
  • Install an AD LDS instance on every developer machine

We’re trying to keep the ‘F5’ experience as lightweight as possible, so installing things or relying on a central AD store aren’t my favorite ideas.

There are other LDAP servers, like Open LDAP. I was hoping there might be an LDAP server that simply talks to an XML file. This would allow us to store the XML file in source control and have something that is fast and works. Our nightly builds would still use AD to pick up any differences, but the hope is since we’re using LDAP it should Just Work.

Can you recommend an LDAP implementation that works well for zero-config shared-nothing development?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I used ADAM then LDS for a pretty large scale site (multiple DC’s, millions principals, ~1000 auth/profile-get TPS).

    During dev we ran an DB-like engineering environment, that touched both proposed options:

    1. Production – distributed, stable, release owned, release deployed, prod clients only.
    2. Test – distributed, stable, test owned, test-deployed, similar hardware to production.
    3. Integration – shared, less-volatile, test owned, test deployed, similar hardware to production, built depending on cycle demands.
    4. Development – shared, volatile, test owned, dev deployed. Weekly rebuilt with rollup of change scripts.
    5. Private – individual, very volatile, privately owned, privately deployed. Built on demand using checked-in change scripts.

    We relied heavily on scripting to deploy, migrate schema and sample data between environments. It was a bit of a PITA at times to write scripts to promote into shared dev, but it did force us into source control mentality for schema and test data generation very early in our cycle.

    While this was quite an overhead in v1, in subsequent versions it made upgrade and patching of the live system very natural.

    The role of the integration boxes varied by time in dev cycle, carrying either current version or future version of the schema nearer the end of cycle.

    Can collapse some of these roles – depends on the level of engineering, integration requirements, and ramifications of making mistakes. The cost of taking our systems offline was potentially millions – the rigor was worth it.

    • 0