4

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?

DarkwingDuck
  • 2,686
  • 24
  • 29
Paul Stovell
  • 32,377
  • 16
  • 80
  • 108
  • Very similar to this post: http://stackoverflow.com/questions/2361340/adam-abstraction-at-ldap-call-level – DarkwingDuck Mar 05 '10 at 04:48
  • @DarkwinDuck, it's almost the same question, but unfortunately the question you referenced doesn't have any up-voted or helpful answers. – Samuel Neff Mar 05 '10 at 15:48

3 Answers3

2

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.

stephbu
  • 5,072
  • 26
  • 42
  • Did Microsoft publish some white paper or slides about that large deployment ? I have similar need, implemented something similar, but I have to back it up with a real world equivalent. – ixe013 May 04 '12 at 12:48
  • 1
    The implementation was part of microsoft.com - about as real-world as it gets :) We talked to the PG about writing papers, but nothing came of it - there were large parts of our deployment that we couldn't write about. – stephbu May 04 '12 at 18:36
1

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);

Igor
  • 19
  • 1
  • 4
0

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.

Samuel Neff
  • 73,278
  • 17
  • 138
  • 182