Recommend a local LDAP store for development

Question

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?

Answer 1

A shared LDAP server is fine, but if you're truly targeting LDAP and not just AD, then you should have multiple LDAP servers with different software. We have test AD and OpenLDAP virtual servers we use for development and testing and have run into many small differences. In production we support a few other servers but I don't know which off-hand.

Neither is really easy to setup and configure though. For AD, we ran into some issues with the fact that we wanted a test AD and didn't want it to interfere with the real company AD. OpenLDAP in general was a pain to initially setup and load some data into. I didn't do these tasks myself, so I can't provide more details, sorry.

Once setup though, they work fine and all devs and testers share these two servers. We use naming conventions so everyone knows which users are theirs to add/edit/delete without stepping on each other's toes. I don't see the need for each dev to have their own LDAP server.

Answer 2

AD as LDAP has it's own specifics, so, if you need to be polyvalent, it's reasonable to test at several LDAP servers (OpenLDAP, Apache Directory Server, AD, etc.).

Also, AD in production has several (dis)advantages to take into account:

1) Running AD just as LDAP is a bad idea -- it's too heavy and resource-consuming; 2) Don't forget that the user accounts in AD are real Windows accounts (i.e. security concerns); 3) AD is perfect for multi-site replication but it's problematic to migrate your solution to other LDAP server (it's not possible to export password hashes from AD by default);

Answer 3

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.