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

Т.е. если хочешь какие-то свои дополнительные атрибуты, то надо регистрировать свой OID

желательно, если не хочешь потенциальных конфликтов, но не обязательно.

Фэйсбук тому яркий пример.

grep ldap https://ru-ru.facebook.com/careers/department?dept=it&req=a0IA000000CxIveMAF
Во, ламаки, да?
---
LDAP для самого веб-фейсбука не подходит, поскольку запись в каталог - операция дорогая, в отличии от чтения. А запись объектов и их отношений в fb более, чем частая

Любую информацию в формате ключ=значение, которая редко пишется, но часто читается.

openldap

желательно, если не хочешь потенциальных конфликтов

и обязательно, если хочешь, чтобы твоим каталогом могли пользоваться и другие люди тоже. То есть чтобы все изменения, внесённые тобой в схему каталога были не из серии «тихо сам с собой я веду беседу» - таки да, их нужно регистрировать. Кстати, регистрация делается более, чем элементарно. Другое дело, что перед тем, как придумывать отсебятину было бы неплохо ознакомиться с перечнем того, что уже придумали до вас - в 99.9% случаев это снимет вопрос о регистрации с повестки дня. zgen, это я тому товарищу, который спрашивал изначально :)

Это больше для статики — аккаунты, телефоны, адреса тысяч и тысяч работников и железок в сотнях филиалов по всему миру.

По аналогии:
LDAP - это документы, предъявляемые трейдером при регистрации на бирже
В SQL - динамичная информация о состоянии, о том, как он торгует, история того, как торговал раньше и проч.
Безусловно, самую суть бизнеса составляют динамические данные, но это всё-таки не отменяет необходимости наличия «документов» у трейдера. Т.е. LDAP содержит информацию о субъектах и объектах деятельности (действующие лица и декорации пьесы), а SQL - прежде всего информацию о самой деятельности (собственно, пьеса как таковая).

Apache DS

StreetTalk где ???

Быдлокод-с, вошедший в канон. :D А я почём знаю?

Если использовать для хранения данных о пользователях одну базу (LDAP), для хранения операций пользователей другую (SQL), то уже нельзя будет осуществлять модификацию данных в рамках одной транзакции, соответственно возникнут проблемы с согласованностью данных.

Я честно проголосовал за OpenLDAP. (Как enterpriZe-«жабабыдлокодер»(С)(ТМ))

Хотя, в общем случае, меня интересует API (http://projects.spring.io/spring-ldap/), а не конкретная реализация, которую использует конкретный заказчик.

«Понятия не имею, о чём идёт речь379 (53%)»

Как я понимаю, это те эникейщики-«админы локалхостов»(С)(ТМ), которым престижная высокооплачиваемая работа не светит. Ни разу.

ЫЫЫ

Самба - гуано
Мелкософт - актив директори - хорош, но сложен
LDAP- классика жанра, проста, доков по ней море
Остальные - незнаю, что такое. и точка.

Если использовать для хранения данных о пользователях одну базу (LDAP), для хранения операций пользователей другую (SQL), то уже нельзя будет осуществлять модификацию данных в рамках одной транзакции

Не очень понимаю, о чём идёт речь. Можно поподробнее немного?

StreetTalk где ???

Там же, где его пользователи.

Пользуюсь OpenLDAP и считаю, что ничего хуже в природе не существует.

Имеется ввиду консистентность данных: первая база подтвердила транзакцию, вторая нет: теперь надо трахаться и откатываться на первой.

Понятия не имею, о чём идёт речь

а если человек знает, что это такое, но не использует?

кроме простой иерархической структуры казённых организаций, реплицируемой в регионы, можно придумать ещё ~10^9 способов применения иерархических структур Каталогов вместо громоздких и уродливых by design реляционных баз данных

Я понимаю что такое сервер каталогов и поверхностно знаком с AD, но понятия не имею о чём речь в вышеприведённом предложении. Набор слов.

Какую транзакцию? Транзакцию изменения клиентского сертификата пользователя, фамилиии или его номера мобильника? У вас в SQL-базе в таблице «пользователи» должно быть поле «DN», это указатель на объект в Каталоге. Если вы не хотите, чтобы DN зависел от ФИО, можете использовать численный SSO ID вместо DN и делать search со scope=one или scope=sub вместо прямого чтения объекта (scope=base).

результаты опроса доставляют

Банально забыл его. Знающие люди могут ещё вспомнить про Apple'овский сервер каталогов, но при ближайшем рассмотрении тот оказывается простым OpenLDAP'ом.

Tivoli — это тоже хорошо переименованный OpenLDAP

Прочитал первую страницу и, кажется, сошел с ума.

Microsoft (AD)

Потому, что инфраструктура на ней построена. Но еще не пробовал залезать в неё со стороны Linux, т.е. через LDAP. Что порекомендуете для этого? ОС Windows Server 2008 R2.

Любой LDAP-клиент можно использовать, это же стандарт всё-таки. Если просто посмотреть/изменить - LDAP Browser/Editor по-моему до сих пор the best и работает на любой писи-платформе.
P.S. В своё время в книженции толщенной про Windows NT 2000 вычитал, что AD умеет реплицироваться по... SMTP! Интересно было бы посмотреть, как на это на практике работало :)

А я думаю, почему IBM Developer Works опубликовали серию статей по OpenLDAP и сертификация у них тоже по нему, а Тиволи даже не упоминается. Интересно, а тот сервер каталогов, который идёт в поставке Lotus Domino, куда корнями врастает?

Странно, что об этом http://forgerock.com/products/open-identity-stack/opendj/ у нас всего 2 человека знают. На мой взгляд, это самый продвинутый, самый динамично развивающийся и самый удобный с точки зрения разработчиков современный СК. Причём у ForgeRock'а целя инфраструктура ещё к нему привязана, и это не просто люди какие-то со стороны, мелкая конторка, разработкой всех identity management компонент занимаются бывшие сотрудники Sun Microsystems, причём после ухода из Sun'а они стали работать явно эффективнее.

Хм. Создаётся ощущение что ты не понимаешь что такое транзакция и зачем они нужны. А нужны они для атомарности действия.

Объясни, при чём здесь транзакция, что ты хочешь сделать-то?

как профессионал, заявляю, openldap рулит и педалит

Легко на нем сделать нормальную master-master репликацию, backup/restore, и шифрование как репликации между узлами, так и общения с клиентами?

Я уже сказал: если у тебя две и больше баз рано или поздно ты нарвешься на сегласованность при операциях с ними. Например добавил пользователя в ldap, начал заливать его в sql базу - она сложилась домиком. Очевидно данные рассинхронизированы. Как поступать дальше? Начинать процесс с начала? С места остановки? Что будет происходить дальше решать, описывать и программировать тебе. Когда у тебя данные в одной нормальной транзакционной базе невозможна ситуация когда данные заехали частично.

Если твой AD обслуживает трех с половиной анонимусов, то проблем нет, но если хотябы тыщи полторы, то с двумя независимыми базы ты нахлебаешься быстро.

В целом такая же беда у одинокостоящего дефолтного openldap - в нем нет транзакционности: наполовину кривой ldif заедет именно наполовину и разгребать беды придется руками.

ты нахлебаешься быстро.

Не преувеличивай. Например, в банковской сфере не все транзакции обеспечиваются СУБД, например, перевод денег между счетами в разных банках. Так как базы данных разные, то атомарность этой транзакции СУБД обеспечить не сможет. И ничего, живут как-то, не хлебают.

Я именно в подобной, около финансовой сфере и работаю. Системы банковского процессинга обеспечивают подобные вещи довольно сложными методами и согласованиями между базами. Это все плод многих человеко часов. Я не говорю, что это не возможно, я говорю, что это надо предусматривать, программировать и разбираться, а не просто кричать на лоре: заведи две базы и нет проблем.

Не преувеличивай. Например, в банковской сфере не все транзакции обеспечиваются СУБД, например, перевод денег между счетами в разных банках. Так как базы данных разные, то атомарность этой транзакции СУБД обеспечить не сможет. И ничего, живут как-то, не хлебают.

Живут и жизнь та напоминает один старый анекдот:

— Доктор, я жить буду?

­— Будете, но я бы Вам не рекоммендовал.

добавил пользователя в ldap, начал заливать его в sql базу

Считай, что объект LDAP - это «тень» реального человека в информационном пространстве, некая «выжимка» ключевых свойств, которые достаточны для представления объекта класса «человек». Зачем ЭТО заливать в базу SQL? Я же предельно ясным русским языком говорю: должна быть просто ссылка на объект, и всё. Например, в системе госуслуг такой ссылкой является небезызвестный СНИЛС, уникальный для каждого гражданина. Это может быть ИНН, это может быть даже просто ФИО (в рамках небольшого замкнутого множества «человек"ов). Какие ещё транзакции, зачем? Вы не в курсе того, что для LDAP существует »>9000" методов кеширования, проксирования, локального реплицирования? Вы всегда можете иметь под рукой копию Каталога, до которой можно достучаться в считанные микросекунды или сколько вам там нужно.
И да, не забывайте о том, что Каталог - по определению структура более глобальная, более «общая», нежели SQL -базы. Поскольку как правило субъектов деятельности весьма ограниченное количество, а процессов, в которые они вовлечены - теоретически бесконечное.

Если твой AD обслуживает трех с половиной анонимусов

Если ваши программисты умеют работать только с SQL, убейте их монтировкой. Всех.
Ещё раз повторю: в LDAP описываются атрибуты субъектов и объектов, их базовые свойства, принадлежащие только им и не являющиеся промежуточным результатом какой-либо деятельности. Эти данные действительно статичны как статична база налогоплательщиков и да, обращение к этим данным должно иметь сугубо ссылочный характер, как на статьи БСЭ.

наполовину кривой ldif заедет именно наполовину

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

Если твой AD обслуживает трех с половиной анонимусов, то проблем нет, но если хотябы тыщи полторы, то с двумя независимыми базы ты нахлебаешься быстро.

А если 35 миллионов?

master-master сложожнее, остальное проще простого.

Ты правда идиот или только прекидываешься? Чего-ты мне твердишь про СНИЛСЫ и прочую ерунду.

В этом ldap нет ничего волшебного, это просто иерархическая бд, без транзакций, в случае openldap. Храни в ней что хочешь. Храни ИНН например. Но если ты не понимаешь зачем нужна транзакционность и консистентность операций, то умерь свой гонор, и почитай википедию хотябы.

Если ваши программисты умеют работать только с SQL, убейте их монтировкой. Всех.

Если ты не знаешь ничего кроме openldap, то убей себя сам. Я то как раз таки неплохо знаю и ldap и sql и знаю болезни обоих концепций.

Я использовал по работе OpenLDAP (поддерживал статистическое решение, почему-то реализованное через оный вместо снмп).
Не скажу, что увидел особую полезность оного.

Я то как раз таки неплохо знаю и ldap и sql и знаю болезни обоих концепций.

Пока я вижу, что ты используешь LDAP в качестве SQL. Это печально, так можно ещё много болезней понаходить. Главное, у себя их не забыть поискать.

В этом ldap нет ничего волшебного, это просто иерархическая бд, без транзакций

В этом вашем SQL нет ничего волшебного: обычная груда байт, я такую могу в шестнадцатеричном текстовом редакторе набить.
Если ты не понимаешь, зачем технология нужна, это значит только то, что проблема лично в тебе.

Но если ты не понимаешь зачем нужна транзакционность и консистентность операций, то умерь свой гонор

По-моему ты сам не понимаешь, зачем здесь приплёл транзакционность и консистентность. Потому что пользуешься LDAP-каталогом как SQL-базой. Микроскопом тоже можно гвозди забивать,я бы даже пожелал тебе в этом удачи.

Легко на нем сделать нормальную master-master репликацию

Очень просто, если master'ов - 2 (Mirroring хоть и не предназначен для записи на обоих мастерах, но это работает). С мультимастером уже сложнее: глюки могут быть замысловатыми, и в процессе эксплуатации я неоднократно сталкивался с чудесным Segmentation fault. Правда, в последние года 3 в основном это проявляется на конфигурациях с неполной/выборочной репликацией дерева.

Где ты это видишь?

В этом вашем SQL нет ничего волшебного: обычная груда байт, я такую могу в шестнадцатеричном текстовом редакторе набить.

Вот я и говорю, что ты непрофессиональная идиотина с раздутым самомнением.

SQL базу не напишешь на коленке, как и LDAP базу, впрочем. За ними стоят, в том числе, и математические труды и теории.

Потому что пользуешься LDAP-каталогом как SQL-базой

Ванга, ты?

Большое Вам спасибо, Капитан, здорово меня позабавили.

Ты меня тоже.

не знаю. говорю ж, не пользовался)