Сервер каталогов какого производителя предпочитаете?

А где Apache DS? Добавь чтоль

Прошу простить меня великодушно, но уже нельзя изменить. Каюсь, я просто не рассчитывал на то, что опрос опубликуют и поэтому подошёл к его публикации несколько легкомысленно :)

Если этот LDIF модифицирует сразу дофига объектов, то да. А это, собственно, зачем надо? Транзакционность обычного LDAP-каталога действительно рапространяется на модификацию одного объекта, потому что свойством целостности состояния обладает именно объект, а не каталог.

Допустим, список чего-то (сотрудники, клиенты, товары и т.д.) лежит в OpenLDAP. Чтобы избежать проблем с переименованием нужно использовать некий числовой идентификатор, назначая новому элементу списка новое уникальное значение (о чём вы кажется упоминали). Самый простой вариант — где-то хранить номер последнего элемента (или искать наибольший из существующих номеров), увеличивать его на 1 и сохранять новое значение (если каждый раз ищем, то, соответственно, не сохраняем). Я правильно понимаю, что средствами OpenLDAP такую задачу не решить? Вы ведь понимаете, в чём проблема?

В LDAP есть стандартная атомарная операция инкремента вообще-то, вы не в курсе? LDAP-сервер сам прибавляет и сам записывает результат, и всё это в рамках внутренней транзакции.
http://ldapwiki.willeke.com/wiki/LDAP Modify-Increment Extension

Кстати говоря, а где Landscape? Опрос люто неполон.

Иерархическая СУБД, оптимизированная для чтения.

А вообще устаревшая ерунда, привет из 80-х. Не нужно оно нигде сейчас, реляционные СУБД предпочтительней. Разве что по историческим причинам в системах аутентификации используют, т.к. почти все серьёзные продукты умеют аутентифицироваться по LDAP-у, т.е. самый простой способ хранить юзеров в одном месте для кучи сервисов.

т.к. почти все серьёзные продукты умеют аутентифицироваться

Так как почти все умеют работать со стандартами и никого не волнует, какую вы там гениальную реляционную СУБД наваяли на коленке? Ну да, ну да. Судьба такая, что делать.
Ну и как бы скорость чтения в LDAP раз так в 200 повыше, чем в реляционных СУБД, где что-то ещё по жизни пишется параллельно.
Насчёт привета из 80-х - ну, извините, реляционные СУБД - привет точно оттуда же.
Вообще то, что именно в России сплошь и рядом ИТшники пишут SQL-базы сотнями, в которых фигурируют одни и те же объекты инфраструктуры, но отследить это (их аутентичность) ни коим образом невозможно - характеризует исключительно недоразвитость отечественного ИТ в целом. У нас и бизнес такой - урвать бабла побыстрее, поспекулировать, наобмануть, с хитрецой пролезть. Говорить о системном подходе в нашем Отечестве не приходится, ибо с фундаментальной наукой умерло вообще всё фундаментальное, остались лишь героические ваятели оснасток AD в IM-клиенте Miranda.

В каком месте Landscape - это LDAP-каталог?

Если говорить о самостоятельных LDAP-серверах, то в первую очередь не хватает конечно ApacheDS, потом наверное всё же Novell eDirectory, Domino LDAP, CommuniGate LDAP. Последний - полное убожество, не умеющее вообще ничего, но вследствие распространённости CGP применяется достаточно широко, поэтому нельзя совсем о нём забывать.

ну я хз тогда, думал тут аналоги АД в выборе

Landscape - это такой классический пример удачного LDAP-клиента, наравне с Samba3, Zimbra и GoSA, например. GoSA кстати куда более AD, чем Landscape, на мой взгляд.