Проект Samba4 перешел в стадию бета-тестирования

И по причине (относительной) ущербности LDAP

Вы про X500 читать не пробовали? Начните со слова КАТАЛОГ, а там легче пойдёт - вдруг и наступит просветление. Кстати, если вместо термина «база», очень фигово ложащегося на концепцию LDAP (это там внутри бэкендами могут быть и базы в том числе), применять всё-таки термин Каталог - всё гораздо раньше встанет на свои места. Самый лучший способ понять - зайти в телефонную будку и до просветления листать такую большую Жёлтую книгу, повторяя, как мантру: «не база данных, а каталог объектов». В итоге желание сделать 3 записи для одного объекта будет вызывать у вас органическое неприятие и отвращение, головокружение и тошноту - в связи с тем, что в голове нормального человека не может ни коим образом уместиться «растроение» одной сущности (если, конечно, этот человек не священник).

и нет, потому что потеряв свой парол от портала или почты на обычном снифере в макдональдсе

Не стану углубляться в тематику сниферов и разных паролей на удаление всех пользователей из базы и rm -rf / на сервере, но отмечу всё же, что если вы беспокоитесь о безопасности и думаете о паролях, а не о парольных фразах и криптографических токенах, то вы совершенно точно о чём-то не о том думаете.

не поймут-с.

Все это очень здорово, но ситуации, когда список пользователей одно сервиса мало пересекается со списком пользователей другого сервера вполне реальны. Держать общий список в этом случае не эффективно.

ведётся начиная с _произвольной_ базы и по _атрибутам_

Ни один клиент не ищет в ldap с «_произвольной_ базы». Это просто значит, что поиск идет всегда от корня. А еще это значит, что все сервисы могут искать в одном общем дереве, что само по себе кошмар с точки зрения безопасности.

И уж если есть какая-то мощная необходимость запихать почтовый аккаунт (НЕ пользователя) в домен, то в записи такого объекта не должно быть атрибутов, дублирующих информацию о человеке. На информацию о человеке можно, например, сослаться, предварительно конечно озаботившись reference integrity.

Вот-вот. Как же задалбывают эти фанатики от технологии. Плевать на затраты, плевать на задачу, главное, соблюсти священыые принципы большой ЛДАПЫ!

Держать общий список в этом случае не эффективно.

В чем эта неэффективность выражается? Почему эффективней держать 2 пользователей?

Ни один клиент не ищет в ldap с «_произвольной_ базы». Это просто значит, что поиск идет всегда от корня.

Бред сивой кобылы, любому клиенту ты сам задаешь, где и что искать, от корня или нет, включая «детей» или нет.

Вот-вот. Как же задалбывают эти фанатики от технологии.

Задалбливают фанатики рисования велосипедов на каждый чих (а-ля напишу ка я свою схему с блек-джеком и шлюхами) и фанатики забивания гвоздей микроскопом (ну как же - ведь как использовать микроскоп зависит от задачи, у меня вот гвозди!), а потом причитания что LDAP такой-сякой.

Прежде всего, чтобы не иметь проблем ты должен понять, для чего нужен LDAP и как им правильно пользоваться. А уже потом варианты правильного использования применять в зависимости от задачи, иначе, рано или поздно, это тебе отзовется головной болью. Это называется «планирование архитектуры».

Конкретно ваши проблемы - от незнания (в частности о фильтрах) и нежелания ничего знать. Мне собственно все равно — ваши персональные архитектурные проблемы меня коснуться только тогда, когда я вашу базу буду вынужден начать поддерживать вместо вас или когда вы за помощью по LDAP сюда придете.

*коснутся

Самый лучший способ понять - зайти в телефонную будку и до просветления листать такую большую Жёлтую книгу,

а там написаны все-все данные на людей, компьютеры города, доступы во все здания и т.д.? Или это тот самый вариант, когда в телефонной книжке и в базе мвд наблюдается позорное явление «атрибутов, дублирующих информацию о человеке»?

В чем эта неэффективность выражается? Почему эффективней держать 2 пользователей?

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

Бред сивой кобылы, любому клиенту ты сам задаешь, где и что искать, от корня или нет, включая «детей» или нет.

«Не от корня, или нет», а от конкретной базы, которая в частном случае может быть и корнем. И в одном запросе можно указать только одну базу. Поэтому фраза «поиск по любой базе» применительно к одному запросу означает поиск от корня, потому что только корень гарантирует, что любой объект, куда бы мы его не поместили, попадет в зону поиска, а две или больше баз мы указать не можем.

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

В этом случае - согласен, проще. Ещё варианты есть?

В этом случае - согласен, проще. Ещё варианты есть?

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

Собственно, в первом случае востребовано единое дерево объектов, а во втором это дерево пилят, что бы иметь возможность невозбранно управлять одним не трогая другого. Да, есть пограничные ситуации, когда в целом все, например централизовано и красиво, но есть ряд исключений и наоборот, когда все в отдельно, но есть и общее. Решение зависит от задачи.

В любом случае, в чистом разуме, чтобы использовать ЛДАП, как каталог, нужно иметь возможность класть в него любые объекты с любыми атрибутами и обеспечить хотя бы эффективный поиск и чтение. Ни один ЛДАП-сервер с этим не справляется и не справится никогда, поэтому вопрос стоит не только не в том, как именно лучше использовать LDAP, а еще и в том, сколько он потянет.

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

Собственно, в первом случае востребовано единое дерево объектов, а во втором это дерево пилят, что бы иметь возможность невозбранно управлять одним не трогая другого.

Особенность в том, что невозможно невозбранно управлять данными человека Василий Пупкин, не трогая его данные или «размножая» Пупкина. Мало того, каталог - структура, которая сама по себе - просто набор статичных «исходных данных», частая запись в него - явление довольно странное и нетипичное. Насчёт безопасности - если вы потрудитесь изучить систему ACL для OpenLDAP того же, то узнаете, что стандартом и является поатрибутное ограничение доступа, так что сервисы и не обязаны читать «не свою» информацию, они её не просто увидят в результатах поиска.

В любом случае, в чистом разуме, чтобы использовать ЛДАП, как каталог, нужно иметь возможность класть в него любые объекты с любыми атрибутами и обеспечить хотя бы эффективный поиск и чтение.

Внезапно, это не «нужно», а «уже есть» - почитай года так с 95-го...

Ни один ЛДАП-сервер с этим не справляется и не справится никогда

Мне почему-то кажется, что это не LDAP-сервер с чем-то не справляется...

а две или больше баз мы указать не можем.

Что ещё за две базы, можно подробнее?

А еще это значит, что все сервисы могут искать в одном общем дереве, что само по себе кошмар с точки зрения безопасности.

Кошмар с точки зрения безопасности - авторизация по паролям и не защищённые LDAP-соединения. Всё остальное решается на уровне ACL. Если вам так нужно разместить мега-специфичную для сервиса информацию, то вы её вообще можете запихать в какой-нибудь MySQL, потому что центральной идеей LDAP как раз является прежде всего предоставление в унифицированном виде общей информации об объекте, которая нужна многим. Условно говоря, номер телефона человека должен быть в каталоге, потому что это информация общего плана, а вот какое-нибудь время последней авторизации SIP-клиента пользователя на шлюзе Asterisk должно быть где угодно, но только не в LDAP, потому что это служебная информация очень узкого назначения, да ещё и часто обновляемая. Думайте о LDAP, как о хранилище паспортов объектов - zgen очень верно ведь показал эту аналогию. Ну неужели вы в паспорте будете вписывать артикул своего любимого пива в «Утконосе»?

Насчёт безопасности - если вы потрудитесь изучить систему ACL для OpenLDAP того же, то узнаете, что стандартом и является поатрибутное ограничение доступа,

давно уже изучил. Управление схемами и аклами в openldap примитивно.

Ладно еще 389. Там хоть нормальный синтаксис и на ходу можно аклы менять. И схемы простыми ldifами ставятся.

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

угу, а к ним еще вселенский моск нужен, чтобы контролировал области видимости.

Внезапно, это не «нужно», а «уже есть» - почитай года так с 95-го...

и вешается на интенсивных запросах. На почте, например.

Мне почему-то кажется, что это не LDAP-сервер с чем-то не справляется...

и опять фанатизм.

Кошмар с точки зрения безопасности - авторизация по паролям и не защищённые LDAP-соединения.

Угу, а курение убивает. Казалось бы, при чем тут банальности? Если бы могли обойтись без паролей - обходились бы. Кому они нужны сами по себе? Это строго ортогональный вопрос. Как и использование ssl, тунелей и т.п. средств защиты коммуникаций.

Думайте о LDAP, как о хранилище паспортов объектов - zgen очень верно ведь показал эту аналогию. Ну неужели вы в паспорте будете вписывать артикул своего любимого пива в «Утконосе»?

Ну в LDAP таких полей море. И самое главное, возникает вопрос, а нафига тогда LDAP в том виде, в котором оно есть, если в ней нет полной информации об объекте? С таким же успехом можно хранить паспорта в мыскле и реплицировать их в базы сервисов, от которых все равно не избавиться, раз в ЛДАП артикул своего любимого пива в «Утконосе» не вписать?

Что ещё за две базы, можно подробнее?

базы поиска. ключ -d

Ладно еще 389. Там хоть нормальный синтаксис и на ходу можно аклы менять. И схемы простыми ldifами ставятся.

И менять на лету и схемы простыми ldif'ами OpenLDAP уже давно поддерживает :/

давно уже изучил.

Видно, что давно. Очень давно.

И схемы простыми ldifами ставятся.

Месье не осилил cn=config? Вообще в OpenLDAP начиная с 2.4 cn=config является основным механизмом конфигурирования (как вы это называеете - ldif'ами), а slapd.conf сильно не рекомендуется и может использоваться только в редких случаях, когда какой-то мега-ценный оверлей или бэкенд ещё не может настраиваться через cn=config. Впрочем, сейчас всё, что живо и поддерживается переехало, а что не переехало, то рано или поздно само загнётся, а оно вам надо?

угу, а к ним еще вселенский моск нужен, чтобы контролировал области видимости.

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

и вешается на интенсивных запросах. На почте, например.

Нда. Это просто ...ц. OpenLDAP Admin Guide, смотрите в сторону такой замечательной вещи, как индексирование. Правда помогает. И кстати в реляционных СУБД тоже.

С таким же успехом можно хранить паспорта в мыскле и реплицировать их в базы сервисов, от которых все равно не избавиться, раз в ЛДАП артикул своего любимого пива в «Утконосе» не вписать?

В базе MySQL создаётся поле «uid», по этому полю в LDAP можно найти всю информацию, которая относится к объекту. Вам же в какой-нибудь военный билет не вписывают всё, что у них там в военкомате имеется в деле? Опять же, никто не запретит запихать в объект всё, что угодно, это уже действительно вопрос удобства и целесообразности.

Главная ваша ошибка всё та же, что и раньше: LDAP - это вообще НЕ БАЗА. Это каталог тех объектов, которые как-либо участвуют в вашей IT-инфраструктуре. И этот каталог прежде всего и нужен как наиболее авторитетный источник информации. В разных базах типа SQL и каких угодно может быть сколько угодно упоминаний Пупкина, но в итоге Пупкин должен однозначно ассоциироваться с объектом в реестре/каталоге. Это примерно как самоуправление на местах: везде могут быть свои нормативные законы, но в итоге они обязаны быть согласованы с Конституцией. И это не фанатизм, потому что в таком случае вы можете сходить к Java-разработчикам и сказать, что их иерархии объектов с JNDI - это фанатизм, что всё оно нафиг не упёрлось и вообще можно программить в процедурном стиле.

Если бы могли обойтись без паролей - обходились бы

Стесняюсь даже предположить... Нет денег на флэшку с токеном для каждого сотрудника?

Видно, что давно. Очень давно.

На самом деле openldap уже лет пять не смотрел. Переполз на (теперь уже) 389.

Стесняюсь даже предположить... Нет денег на флэшку с токеном для каждого сотрудника?

Во первых, нет. Во вторых, затраты не ограничиваются одной флешкой.

Главная ваша ошибка всё та же, что и раньше: LDAP - это вообще НЕ БАЗА. Это каталог тех объектов, которые как-либо участвуют в вашей IT-инфраструктуре. И этот каталог прежде всего и нужен как наиболее авторитетный источник информации.

В таком режиме он элементарно не удобен и поэтому не нужен. Проще и лучше тогда сделать свою базу со всеми нужными полями и из нее реплицировать нужные срезы информации в другие сервисы. Иначе мы получаем лишние лукапы по сети на ровном месте. Да, для вшивых нагрузок в организациях центр в LDAP вполне подходит, но для реальной нагрузки...

И это не фанатизм, потому что в таком случае вы можете сходить к Java-разработчикам и сказать, что их иерархии объектов с JNDI - это фанатизм, что всё оно нафиг не упёрлось и вообще можно программить в процедурном стиле.

В джаве никто не выносит дерево классов в сеть на уровень предприятия, чтобы при упадании сети в жабка дохла...

Да, для вшивых нагрузок в организациях центр в LDAP вполне подходит, но для реальной нагрузки...

Репликация там есть. На чтение объектов LDAP быстрее SQL.

Репликация там есть.

Это не отвечает на вопрос, зачем LDAP?

На чтение объектов LDAP быстрее SQL.

Ога. Пока Озу хватает.

AVL2, LDAP - вещь, которая ещё в каменном веке реплицировалась и была нативно распределённой. Реляционные базы данных через Ж. как-то, усложняя на ровном месте элементарное, научились реплицироваться только лет через 10 после LDAP. Но тогда LDAP-сервера уже умели работать в режиме мультимастера, прокси с кешированием запросов, балансировщика, и, например, в режиме прокси умели обращаться к нескольким серверам, «склеивая» ответы в одну виртуальную ирерархию. Вы поймите, я не пропагандирую LDAP как панацею и не считаю, что у технологии нет недостатков. Меня коробит то, что вы называете недостатками то, что либо существует либо только в вашей голове, либо не является недостатками. А о реальных косяках типа «уникального» DN и отсутствии вменяемых стандартов в самой в общем-то важной части - части организации распределённого каталога, - вы попросту не знаете.

Проще и лучше тогда сделать свою базу со всеми нужными полями и из нее реплицировать нужные срезы информации в другие сервисы

Простите, но не слишком ли это тупо? Зачем реплицировать что-то куда-то, если речь идёт об информации, которая нужна только данному сервису и больше никому? Если позарез нужны данные из каталога в базе сервиса - копируйте их раз в сутки, это куда проще, чем создавать велосипед для франкенштейна с кучей выковыренных из самых интимных мест полей. Неужели так трудно понять, что есть данные для внутреннего пользования того или иного сервиса и есть данные, относящиеся глобально к объекту и различными сервисами разделяемые? Ну уж хотя бы про свой горячо любимый пароль подумайте: опустим пока, что есть SASL и сервисам нельзя позволять напрямую пытаться делать BIND на СК. Пароль-то - поле, разделяемое между всеми. А ещё многим нужен email, номер телефона, полное имя, фамилию, инициалы, подразделение, менеджера, уникальный числовой идентификатор сотрудника, да в общем я даже маленькую фотку человека обычно в каталог помещаю, это всего несколько килобайт...

Насчёт пароля уточню особо, что если какой-то сервис прямо должен читать это поле, то такой сервис следует либо пофиксить, либо доработать. Обращение к userPassword или аналогам происходит неявно - попыткой аутентификации с переданным паролем.

чтобы при упадании сети в жабка дохла...

У меня тут небольшой вычислительный кластер, на каждой машине реплика нужной для аутентификации пользователей кластера части каталога. Отваливание сети никак на работу аутентификации не влияет, то есть совсем вообще никак.

AVL2, LDAP - вещь, которая ещё в каменном веке реплицировалась и была нативно распределённой.

да в какой реальности вы все живете, что у вас ldap (небось еще и openldap) все давно умел и умеет. А в реальности мультимастер с AD в 389 до сих пор глючит, как смертный грех. Между собой еще ничего, но тоже ведь не идеал.

Но тогда LDAP-сервера уже умели работать в режиме мультимастера, прокси с кешированием запросов, балансировщика, и, например, в режиме прокси умели обращаться к нескольким серверам, «склеивая» ответы в одну виртуальную ирерархию.

и потребовался редхат, чтобы купить и открыть монстра netskape planet...

Меня коробит то, что вы называете недостатками то, что либо существует либо только в вашей голове, либо не является недостатками. А о реальных косяках типа «уникального» DN и отсутствии вменяемых стандартов в самой в общем-то важной части - части организации распределённого каталога, - вы попросту не знаете.

Да како смысл ковырять проблемы столь высокого уровня, если то, что есть, даже в теории не имеет практического смысла? ДА, технология старая, да, она ограничено работоспособна, но это тупик и именно поэтому LDAP сегодня живет только там, где на него поставили и никогда не слезут- в AD и адресных книжках. Все остальное прекрасно живет и без LDAP и живет ведь...

Зачем реплицировать что-то куда-то, если речь идёт об информации, которая нужна только данному сервису и больше никому?

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

Пароль-то - поле, разделяемое между всеми.

далеко не всегда.

У меня тут небольшой вычислительный кластер, на каждой машине реплика нужной для аутентификации пользователей кластера части каталога. Отваливание сети никак на работу аутентификации не влияет, то есть совсем вообще никак.

ну вот, осталось понять, зачем там именно ldap.

Насчёт пароля уточню особо, что если какой-то сервис прямо должен читать это поле, то такой сервис следует либо пофиксить, либо доработать. Обращение к userPassword или аналогам происходит неявно - попыткой аутентификации с переданным паролем.

Что влечет за собой передачу открытого пароля по сети. Зашибись, решеньице. ЗАто в LDAP мы гордо храним хеш и спим спокойно. Враг пароль не расшифрует.

ну вот, осталось понять, зачем там именно ldap.

Потому что под вашу БД надо писать (и поддерживать) велосипеды, а LDAP поддерживается большинством приложений разного уровня - от коммутаторов до любимого тут Ынтерпрайза.

Что влечет за собой передачу открытого пароля по сети.

ssl/tls

А в реальности мультимастер с AD в 389 до сих пор глючит, как смертный грех.

Не юзайте говняшку.

Потому что под вашу БД надо писать (и поддерживать) велосипеды, а LDAP поддерживается большинством приложений разного уровня - от коммутаторов до любимого тут Ынтерпрайза.

Воот. Это +. Поэтому и жив АД, что его поддерживают клиенты.

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

Приложениям нужен конкретный срез каталога, достаточный для их функционирования. Но здесь и сейчас, а не там, в недрах сети.

И второе, приложения могут не любить LDAP, а любить, к примеру, postgresql или mysql, как это делают днс или pure-ftpd. Жить одним ldap, как минимум, неэффективно да и не всегда возможно.

Да, если речь про инфраструктуру АД, где поднял домен и нате готовый инструмен для ведения учеток, днс-записей и т.д., то да, но с этой точки зрения похрен что там внутри - все равно поднимем домен и что он предложит, то и используем.

А если выбор есть, например, своя админка, то не вижу никакого смысла делать центральный каталог в LDAP. Гораздо гибче вести свою базу, а из нее уже формировать ldap каталоги для тех клиентов, которым они нужны.

ssl/tls

ну бредово же отмахиваться от проблемы открытой передачи пароля топором ssl/tls. Это же очевидный архитектурный изъян.

Но здесь и сейчас, а не там, в недрах сети.

Нет никаких недр сети - кому нужно, у того реплика каталога под боком.

И второе, приложения могут не любить LDAP

bind работает с ldap. pure-ftpd - работает с ldap.

Да, если речь про инфраструктуру АД,

Речь про инфраструктуру, которую ты сам спланировал. Хочешь DNS в ldap - пожалуйста. Хочешь sip accounts в ldap - пожалуйста, хочешь свое приложение в ldap - пожалуйста, хочешь dhcp, apache, nginx, samba, wifi - пожалуйста. И тэ дэ и тэ пэ.

Гораздо гибче вести свою базу, а из нее уже формировать ldap каталоги для тех клиентов, которым они нужны.

Писать велосипеды. Ну пишите, что ж с вами поделать.

Речь про инфраструктуру, которую ты сам спланировал. Хочешь DNS в ldap - пожалуйста. Хочешь sip accounts в ldap - пожалуйста, хочешь свое приложение в ldap - пожалуйста, хочешь dhcp, apache, nginx, samba, wifi - пожалуйста. И тэ дэ и тэ пэ.

Все это прекрасно работает и без ldap. И работает надежней.

ЗАто в LDAP мы гордо храним хеш и спим спокойно

Я сейчас вас вообще сражу наповал откровением. Дело в том, что стандартный механизм аутентификации в OpenLDAP - это... ага, SASL. А SASL - это что такое...? Бегом в поиск! :)

И работает надежней.

Пополам! Нет, жёлтое! Что за бред вообще, что за детский лепет? Когда надёжнее, где надёжнее, что, почему, откуда берутся такие утверждения вообще?!

Я сейчас вас вообще сражу наповал откровением. Дело в том, что стандартный механизм аутентификации в OpenLDAP - это... ага, SASL. А SASL - это что такое...? Бегом в поиск! :)

О чем и речь. Ура, внутре у нас sasl! Враг не пройдет. Правда чтобы дойти до него, надо передать пароль нашему сервису запиской через бомжа в метро.

Пополам! Нет, жёлтое! Что за бред вообще, что за детский лепет? Когда надёжнее, где надёжнее, что, почему, откуда берутся такие утверждения вообще?!

опыт? openldap может и не стартовать. Или стартовать позднее. Или отвалиться с течением времени. Все это было.

Все это прекрасно работает и без ldap. И работает надежней.

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

опыт? openldap может и не стартовать. Или стартовать позднее. Или отвалиться с течением времени. Все это было.

руки?