Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I been using LDAP for many years now and most of the firms I worked for used a development LDAP schema that was identical to the production and QA (staging) schemas. An example suffix would be:


I just started working at a new firm a few months ago and the systems administrator is telling me that I am doing it wrong. He says that in development the suffix should be "dc=firm,dc=dev".

I feel that this is going to cause a lot of issues down the road with programming and moving data for testing, among other things. I would like to get some views on this. I see the situation thusly: The data should always look like production data even in the development and staging environments.

share|improve this question
up vote 5 down vote accepted

This is a matter of preference, however there are upsides to having a development environment named different from production. The most notable being that any scripts run on the development environment will not be likely to be able to do damage if accidentally run on the production environment.

In Fantasy LifeTM we would have completely segmented networks that weren't even physically connected. One for production, one for development and testing. They would have different passwords and user accounts that would signify if it was a testing environment or not.

In Real LifeTM that's not the case. However, a "defense in depth" of your production data can utilize the simple touch of not using the exact same LDAP name between the two.

Does that make things messy if you want to take a development change and migrate it to production? Perhaps a tiny bit, however if there's not enough automation or standardization in an environment to be able to simply and effectively change suffix "dc=firm,dc=com" to suffix "dc=firm,dc=dev" then I think there are larger problems.


Both approaches are fine, if there's a larger context of security involved. I wouldn't go so far as to say one is wrong and the other correct. Take the new approach in stride and learn from it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.