howto для поднятия LDAP

поставь с гуем на первое время (да и на второе время тоже - в консоли много народу и сложное дерево держать не очень круто), вроде тот же webmin умел. Организация дерева имхо проще всего ou прямо по списку отделов компании, а поля для юзера накидай из нужных сервисов плюс стандарт,т.е. не забудь телефон, жаббер и прочее, для большинства полей есть стандартные названия, гугли по названию сервиса. Дальше смотришь ман к каждому нужному тебе сервису, организуешь под него группы и настраиваешь связку.

если гуевый, то можно посмотреть на zentyal community edition.

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

http://www.freeipa.org/page/About и соответственно http://www.freeipa.org/page/Documentation

Писать столько, что лень.

freeipa + samba.
freeipa настраивается за 1 час.
samba настраивается за 1 час.
у freeipa есть очень годный вебгуи.
для самбы надо будет поискать.

Специально для этого, придумали: microsoft active directory. Там всё есть. Гуи, будешь мышкой настраивать доступы к ldap, samba и всему остальному. Если ты сильно упорот, то можешь, ещё к домену прицепить FreeIPA. Но с трудом представляю, зачем оно тебе для твоих, более чем, типовых задач.

Ибо:

FreeIPA is an integrated Identity and Authentication solution for Linux/UNIX networked environments.

Более, чем уверен, что это не твой случай. А твой случай, это уютненькие: Windows окружения.

Нужна концепция организации LDAP каталога и примерный мануал.

В MS AD, всё есть, уже заточенные схемы, для типовых задач. Все твои squid/jabber и прочее УГ - точится под эти схемы. Можешь ещё samba4, поставить. Только с тем, учётом, что тебе нужен GUI - то тебе понадобится RSAT. А раз такая пьянка, то AD, только AD. Увы.

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

В MS AD, всё есть, уже заточенные схемы, для типовых задач.

с тем, учётом, что тебе нужен GUI- то тебе понадобится RSAT

А твой случай, это уютненькие: Windows окружения.

Если тебе нужна синхронизация с AD

Не нужно!

из своего чудесного openldap

Это фраза из личного неудачного опыта?

А раз такая пьянка, то AD, только AD. Увы.

zgen, вставте свой проф. комментарий.

Заигнорил бесполезного пропагандона.

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

Хочешь делать всё руками, и разобраться во всём, бери openldap, ставь, цепляй сервисы и т.п. ИМХО с ним лучше сперва ставить, а потом разбираться. Документация слегка надмозговая.

Хорошего гуя для openldap я не видел, если не считать какой-нибудь phpldapadmin.

Я бы написал сам что-нибудь простенькое, быстро выполняющее необходимые тебе действия.

Не нужно!

Ну не нужно, так не нужно. Можешь вопрощать дальше на форумах, тыкать не доделанный FreeIPA, и самое главное, продолжать скрещивать всё это со своим AD (ведь он у тебя есть, в условиях задачи). :) Мне не жалко.

Смотри, как релизится FreeIPA:

2015-10-08: released FreeIPA v4.2.2

2015-09-07: released FreeIPA v4.2.1

2015-07-09: released FreeIPA v4.2.0

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

вставте свой проф. комментарий.

У тебя блин, в условиях задачи, синхронизация, с AD! Какие на хрен комментарии? С AD, у тебя сможет синкаться, или FreeIPA (и то, только в одну сторону, вроде), или samba4 (если домен, не выше, чем Win2008).

ведь он у тебя есть, в условиях задачи

Где я сказал, что есть AD? Была бы AD там бы все и реализовал бы.

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

Ознакомился, избыточно. Я смотрю в сторону openldap как хранилища пользователей и информации о них, т.е. база данных. Для части сервисов авторизация будет через ldap напрямую, типа ejabberd. Для части сервисов транспортом для аккаунтов и их свойств предполагаю использовать puppet, к примеру Серверы терминалов.

Я смотрю в сторону openldap как хранилища пользователей и информации о них

Тогда готовься к тому, что удобные гуи с галочками придётся писать самому.

Apache Directory Studio

Apache Directory Studio

Присмотрюсь

Для части сервисов авторизация будет через ldap напрямую, типа ejabberd.

Без kerberos, скучно, если это в корп. сетке.

хранилища пользователей и информации о них, т.е. база данных.

Смотря какую информацию будешь хранить. Для базовых вещей, openldap - годен. + Можно схемами расширять. Но вот с Win2008 - не особо представляю, как можно будет связать это добро, хоть как-то.

Я смотрю в сторону openldap как хранилища пользователей и информации о них, т.е. база данных.

Судьба проекта не ясна, но есть: ReOpenLDAP - оно появилось, так-как народ уже достало, что openldap лютое УГ.

Это большая тема.

Главное, что хочу сказать - готового симплифицированного интерфейса до уровня «пара галок» нет. Т.е. если нужен именно такой уровень и владеешь php, к примеру, то можно самому написать. Есть интерфейсы типа LAM, phpldapadmin и куча других но они перегружены функционалом. Тот же apache directory studio, но последние два - это скорее ПО для управления любыми данными (выборка, запись, обновление) внутри LDAP, а не конкретно доступом к тому или иному сервису для того или иного пользователя.

Подход должен быть простым, как пробка -
составляешь список используемого ПО и список, скажем, ПО которое будет использоваться в ближайшем (1-2 года) будущем. Смотришь, какого уровня интеграция с LDAP есть.

Самая херовая интеграция - это когда тупым скриптом генерируется конфиг для приложения с данных LDAP. Самая хорошая - это когда все нативно, да еще нормальной реализацией обновления/кеширования. Есть куча промежуточных вариантов.

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

Берешь за основу схему хранения данных samba3 + openldap и вперед она расширяема для почти всего текущего по.

Если смотришь в будущее, то можешь начинать с samba4 (samba3 уже прошлый век и реально будет мало кому нужна) и смотреть её LDAP и интеграцию с ней. Плюсом будет большое сходство принципов с AD, в которой тоже можно смотреть и учиться интегрировать в него.

Тут нет смысла писать много, так что по конкретным проблемам я могу что-то определенное сказать, а разговоры в общем, тем более в текстовом виде, ну не знаю.

Еще DRVTiny спроси, он хорошо в теме шарит.

так-как народ уже достало, что openldap лютое УГ.

Подозреваю топикстартеру, как и 95% других до проблем с которыми борется reopenldap - как червю до луны.

У меня, к примеру, база ~100mb и то, только из-за binary data в LDAP

Ну в общем ходят слухи, что openldap, даже не собирается из исхдников сейчас... Как-то не комильфо. Считай, морды нету, собирается с ошибками - попахивает не нужностью. Вот я и говорю, или samba4/FreeIPA/AD. При том, меня тут гнобят, но... AD, самый зрелый. Та же самба - костыль на костыле (лично общался с разрабами), очень много не реализованно, схему ldap - расширять сложно, и т.д.

Если хочешь, бесплатно, и без SMS, то бери какой-нибудь zentyal, там тебе будет samba4 + kerberos + ldap, и веб морда. Как средний вариант: samba4 + RSAT

Ну в общем ходят слухи, что openldap, даже не собирается из исхдников сейчас

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

Как-то не комильфо.

Если это так, и это сколько-нибудь давно - согласен.
Морд под него вагон. Но надо понимать, что это всего навсего система хранения данных с инструментами выборки. А не система управления доступом или пользователями.

Та же самба - костыль на костыле (лично общался с разрабами),

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

AD, самый зрелый.

Ну если человек не хочет, что надо делать то?

схему ldap - расширять сложно, и т.д.

Ээээ? А в чем сложность то? в AD легко? легче? или что?

то бери какой-нибудь zentyal

Кстати, не такой чтобы плохой совет - по крайней мере «на посмотреть»

Наверное, но мне контроллера домена много на samba4 будь он или на чем-то другом. Kerberos тоже без надобности и веб морда. Если бы нужен был контроллер в продакте, я бы AD и использовал. Прошу в эту сторону не гнуть, топик не о том.

Я свои задачи могу решить puppet, пользователей хранить в файле или mysql. Просто некоторые сервисы нативно поддерживают LDAP (GLPI, ejabberd, Kyocera и много чего), и что бы не изобретать каталог логично использовать его. А AD это комбайн и каталог там только часть.

DALDON, еще раз мне нужно всего навсего хранить структуру каталога и удобно ее запрашивать.

Подозреваю топикстартеру, как и 95% других до проблем с которыми борется reopenldap - как червю до луны.

Вы совершенно правы. Майское обновление ReOpenLDAP — теперь multimaster-кластер требует в разы меньше RAM

Ну если человек не хочет, что надо делать то?

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

Выглядеть это должно как взял пользователя, выбрал ресурс (к примеру samba), выбрал подресурс (папка1) и поставил галочку (пускать). Клиентов настроить можно, нужна концепция организации LDAP каталога и примерный мануал.

Наверное, но мне контроллера домена много на samba4 будь он или на чем-то другом.

Получили противоречие: сам по себе LDAP — это хранилище данных, и все. В принципе, одного openldap'а при наличии соответствующей схемы хватит для хранения пользовательских учетных данных (например, в основном актуально по сию пору), но его одного заведомо не хватит для «взял пользователя, поставил галочку» — нужно тем или иным образом организовывать нечто, традиционно называемое «контроллер домена».

что бы не изобретать каталог логично использовать его.

Чтобы не изобретать контроллер домена, логично использовать именно его. FreeIPA тебе не подойдет (он не предназначен для винды), так что вариантов видится ровно два: Samba 4 или MS AD.

Просто, я считаю, что у тебя должно быть понимание, что: Win2008, GLPI, ejabberd, Kyocera и много чего - в первую очередь пилятся для AD подобных схем. Если у тебя такого понимания нету, тогда бери openldap, впиливай дефолтные схемы, расширяй их. Ставь любой ldap редактор, и всё, в общем и целом работать то будет, вопрос удобства, и количества костылей...

А AD это комбайн и каталог там только часть.

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

Из того, что тебе кроме как: FreeIPA, samba, zentyal, AD - ничего особо другого не предлагают, можно сделать вывод, что, то, чего ты хочешь - никому кроме тебя, особо не нужно. Вот и нету никаких толковых инструментов. :(

Ну ладно, мне сказать больше нечего. :) Если найдёшь, чего-нибудь интересное, кастуй!

Есть масса готового ПО для решения Вашей задачи, но всё оно за редким исключением имитирует «некое подобие Windows Server, созданное на коленке».

Собственно, вон даже Calculate наш расейский занимается тем же самым.

Корень проблемы в том, что без «особой» настройки Open Source-софта - он как правило дружить с LDAP-каталогом и не думает. А даже и тот. что думает, делает это не всегда корректно. Так что в деле интеграции с LDAP патчи на софт и весьма специфические конфигурации - не редкость, а данность.

В Вашем случае я бы посоветовал GoSA2. По-моему в целом должна подойти, но есть один недостаток: она слегка протухла уже...

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

Относительно Windows-домена - мне кажется, небольшой домен вполне можно делать и на Samba, благо в той же GoSA2 всё нужное для этого есть.

Вывод же немного... неутешителен. На данный момент в Unix нет единого подхода к интеграции, и LDAP-каталоги этой проблемы не решают, поскольку её корень - в самих приложениях и в отсутствии стандартов на использвание промежуточных между приложением и системой хранения программных интерфейсов наподобие SASL или NSS, которые позволяли бы приложениям обращаться к общей для всех информации абстрактным образом, не вдаваясь в детали того, где эта информация лежит.

То есть был в Unix NIS - им пользовались очень ограниченно, а потом совсем забыли, была одно время повальная «мода» на керберизацию - и тоже в прошлое ушла. А сейчас - ну как был вакуум - так и есть, и можно сколько угодно это склеивать в форме Zentyal'ов, Mandriva Directory Server'ов, Calculate'ов, GoSA и т.д. - но это не сделает разношёрстный набор софта от разных разработчиков монолитной программной системой.

Считай, морды нету

У Redis тоже! И у MongoDb нету! На помойку их, нафиг они не нужны!

У MySQL есть морда и у Oracle, поэтому No Way, только ПО Oracle: ведь у этого ПО есть морда!

При том, меня тут гнобят, но... AD, самый зрелый.

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

DRVTiny, благодарю за компетентные точки над «и». Эксплуатируемый софт в большей части дружит с LDAP и это Unix софт 95%, тот что не дружит нативно синхронизирую учетные данные из LDAP посредством puppet, для этого процента это дешевле чем держать AD. Моя цель при приеме на работу в одном месте создать пользователя и разметить права, а когда получаем копию приказа об увольнении отключить доступ. Сейчас это не совсем удобно реализовано

а когда получаем копию приказа об увольнении отключить доступ

Представьте, что эта учётная запись не должна быть удалена, но должна потерять доступ к корпоративной почте, jabber'у, системе контроля версий, Redmine'у, OTRS'у, входу по ssh извне - и прочим, и прочим.

Как бы Вы стали решать эту проблему? Что подразумевается под «разметить права»? Должен быть какой-то атрибут со списком доступных пользователю сервисов или наоборот - в каждом сервисе должно быть прописано, какие пользователи и какой уровень прав будут иметь при доступе к нему?

Я к тому веду, что система контроля доступа (аутентификации и авторизации) должна быть скорее неким API (наподобие WebSSO), который запрашивают все перечисленные приложения. LDAP-каталог, и близко не является системой контроля доступа (хотя, безусловно, там есть ACL применительно к доступу в сам каталог - как и в MySQL такие ACL есть, как и в Oracle и т.д.), не может быть этаким super-cow-power, решающим проблему отсутствия единой системы аутентификации. здесь нужно смотреть специализированные решения. А уж будут они использовать LDAP или нет - это их личное дело. Хотя я, безусловно за то, чтобы всё-таки использовали :)

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

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

Представьте, что эта учётная запись не должна быть удалена, но должна потерять доступ к корпоративной почте, jabber'у, системе контроля версий, Redmine'у, OTRS'у, входу по ssh извне - и прочим, и прочим.

Да, правильнее сказать она должна быть заблокирована.

Как бы Вы стали решать эту проблему? Что подразумевается под «разметить права»? Должен быть какой-то атрибут со списком доступных пользователю сервисов или наоборот - в каждом сервисе должно быть прописано, какие пользователи и какой уровень прав будут иметь при доступе к нему?

Именно эти две схемы и рассматриваю, либо создание атрибутов в одной единственной схеме, либо подключение схем специализированных для сервисов. Взвешиваю подходы, читаю Форум проекта Pro-LDAP.ru. Словосочетание «разметить права» корректнее читать в кавычках. Я подразумеваю какой либо способ вообще указать пользователю сервис и уровень доступа или указать сервису и уровню доступа пользователя.

Я к тому веду, что система контроля доступа (аутентификации и авторизации) должна быть скорее неким API (наподобие WebSSO), который запрашивают все перечисленные приложения. LDAP-каталог, и близко не является системой контроля доступа (хотя, безусловно, там есть ACL применительно к доступу в сам каталог - как и в MySQL такие ACL есть, как и в Oracle и т.д.), не может быть этаким super-cow-power, решающим проблему отсутствия единой системы аутентификации. здесь нужно смотреть специализированные решения. А уж будут они использовать LDAP или нет - это их личное дело. Хотя я, безусловно за то, чтобы всё-таки использовали :)

Вот тут я не смог понять Ваш посыл. Применяя Ваше высказывание на теоретические данные сказанное понимается и преимущества просматриваются, но анализируя конкретные сервисы: openvpn, glpi, roundcube, squid не вижу описанных нюансов, которые могут мне не позволить авторизовать пользователей в этих сервисах используя нативную поддержку LDAP. Т.е. если не затрагивать сам процесс авторизации и плюсы/минусы каждого результат будет один и тот же.

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

Именно из этих соображений и для этих целей подразумеваю LDAP.

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

В данном случае я вижу единственный вариант «обхода»: переставить всё с ног на голову и на уровне LDAP ACL не давать пользователям, под которыми биндятся к серверу сами приложения, получать доступ к тем учётным записям, которым нельзя соотв. приложениями пользоваться. Это очень примитивно и криво с точки зрения концепции, но на практике совместно с ACL'ями самих приложений (для реализации уровней доступа тех, кому всё же «можно») - должно работать.

К сожалению, даже правильно аутентифицировать пользователей с использованием LDAP-каталога умеют далеко не все приложения

В целом я думаю да, но используемые нами приложения в общем как-то поддерживают авторизацию ldap и даже ACL приложений. Поправьте если я не прав: glpi,squid,файловый сервер samba, хранение сертификатов openvpn, ejabberd, postfix, roundcube адресные книги.

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

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