Про LDAP и авторизацию в домене

Автор: dvc Дата: 13.07.2006 08:38 Только что натолкнулся на сайт [www.ldapzone.spb.ru] (хотите верьте, хотите нет). Не успел даже полазить по нему основательно, поскольку уже на главной странице увидел очень коротко и внятно сформулированную проблему, об которую бьюсь уже несколько недель. Цитирую:


"Для чего я создал этот сайт

Если вы каким-то образом узнали о существовании этого сайта, то вам, скорее всего, известно, что такое ОС GNU/Linux. И, конечно же, вы уже знаете все или почти все её достоинства. Впрочем, возможно, вы также слышали и о кое-каких недостатках.

В мире разрабатывается множество дистрибутивов Linux. И почти все разработчики заявляют о своём стремлении сделать Linux проще для конечного пользователя, который может не быть компьютерным гуру. Моё видение ситуации состоит в том, что Linux также должен развиваться и в сторону упрощения его для системных администраторов, а одним из источников сложности классических UNIX, по моему мнению, является хранение пользовательских аккаунтов в простых текстовых файлах /etc/passwd с вытекающими из этого последствиями при увеличении количества серверов и пользователей. Пока что самым перспективным решением считается применение служб каталогов для создания гомогенной среды доступа пользователей к ресурсам локальной сети. Однако до сих пор ни один дистрибутив Linux в мире не ориентирован на использование служб каталогов хотя бы даже как альтернативы /etc/passwd. Ну, и кроме того, я вдруг обнаружил, что в русскоязычной части Интернета совсем нет сайтов, посвященных проблемам служб каталогов.
Надеюсь, существование этого сайта приближает день появления на свет GNU ОС, администрирование которой не становилось бы причиной головной боли сисадмина."


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

Тем, кто не верит, что это реальная проблема, могу посоветовать уже "отработанную" мной ссылку: [www.linuxrsp.ru]

Документ замечательный, но после распечатки занимает 16 страниц. Это без подробностей и деталей. Только самое жизненно необходимое. Для того, чтобы настроить аналог ActiveDirectory, с возможностью авторизации и Windows и *nix клиентов, нужно поднять и настроить: DDNS+DHCP (с возможностью регистрации самими пользователями), OpenLDAP, OpenSSL, Stunnel, Samba (c winbind), Kerberos (можно и без неё, но это будет не полноценный AD), iptables (ну желательно подправить). Ну могут еще подтребоваться pam-модули, скрипты для миграции с других решений и т.п. Это на самом деле звучит страшно. И выглядит страшно. Но самое страшное, что не очень прозрачно описано, как клиентов авторизовывать в этом счастье минимальными усилиями. Может быть можно придумать инструмент, который будет еще на этапе инсталляции (как винда) говорить: нашел ethernet - если хочешь, войду в домен (и потом действительно прозрачно входить в домен, со всеми вытекающими вкусностями). А если хочешь, подыму свой личный LDAP (вы же используете локальный sendmail для отправки административных сообщений) или сделаю контроллер домена на этой машине.

Лично для меня, эти сложности на данном этапе - единственное препятствие для разворачивания сетки с Линукс-десктопами на своей фирме и широкой рекомендации всем остальным. Как ни крути, а без Самбы в локальной сети сейчас обойтись практически невозможно. Хотя бы из соображений совместимости, одна-две машины будут оставаться под виндой. Плюс может потребоваться подключить гостя со своим ноутбуком и т.п.
И, в общем, всё уже сделано, чтобы организовать такую структуру без помощи win-серверов. Но... Винда пока далеко впреди по скорости развертывания домена и требованиям к начальному уровню админа. А жаль... Очень хотелось бы услышать мнение/рекомендации разработчиков!
Re: Про LDAP и авторизацию в домене 27.09.2006 16:08dvc Ау?! Разработчики! Ну хоть что-нибудь скажите по сабжу...

Систему авторизации, основанную на LDAP построить ВОЗМОЖНО. Я лично это сделал - и это работает вполне прилично. Готов поделиться любой информацией, которая понадобится. Причем, зная, что и куда ввести, сделать это можно сравнительно быстро. Инструменты для добавления/удаления/редактирования учетных записей - есть. Не без проблем, но таки работают. И миграцию учетных записей сделать не суперпросто, но вполне реально.


Для последующей настройки клиента достаточно подредактировать 2-3 файла. И все будет совершенно прозрачно.

Также можно положить в LDAP файлы зон DNS, после чего ими становится гораздо проще управлять (я имею ввиду случай DDNS).

Также можно настроить авторизацию пользователей Apache, Squid, завести отдельную почтовую базу или только псевдонимы и адресную книгу и еще много всякого разного. Причем, большую часть приложений, если только им не нужна отдельная база учетных записей, можно вообще не перенастраивать, поскольку они будут пользовать авторизацию через pam или nss.

Это очень нужная штука, потому что винда делает линукс как стоячего именно в области разворачивания домена. Причем, как я уже писал, линукс решение должно быть "по умолчанию" из коробки и быть ориентированным на гетерогенную сеть. Даже уточнюсь - на гетерогенную сеть с линуксовым контроллером домена и смешанными десктопами. С поддержкой Samba и NFS ресурсов и хранением учетных записей юзеров в OpenLDAP, защищенном посредством TLS или еще как-нибудь. Ориентированную изначально на возможность полного отказа от виндовой составляющей этой конструкции, а не построенную на виндовом фундаменте грубую подделку, которая оригинал никогда догнать не сможет!!!

Конечно, желательно сделать легкой настройку сервера (создание сертификатов, настройка репликации, входов - алиасов, добавление "умолчальных" объектов для Posix и Samba аккаунтов и т.п.), но гораздо важнее сделать легкой настройку клиента на вход в домен.

Этого я не встречал нигде ("сильноплатные" *никсы не рассматриваем Улыбка ), но это очень-очень востребованная фича. И за нею будущее. Ибо маломальски крупная сетка без домена - это несерьезно. А сетка с линуксовыми десктопами и виндовым контроллером домена - полный изврат! Хотя бы потому, что схемы безопасности разные и получить с AD-домена чисто линуксовые параметры просто нереально.


Очень хотелось бы услышать пару ласковых от разработчиков. Улыбка
Re: Про LDAP и авторизацию в домене 28.09.2006 10:24DRVTiny dvc, давайте объединим усилия! Я тоже у себя пытаюсь сделать полную интеграцию сетевых служб на базе LDAP, так же, как Вы считаю, что котлеты должны лежать отдельно от мух и не должно быть такого, чтобы приложения имели приоритет над теми данными, которые они обрабатывают! Во главу угла должны быть поставлены объекты, с которыми работает сервер - хосты LAN, учётные записи пользователей, группы, права и списки контроля доступа, а не разрозненные приложения с их бестолковой формалистикой настроек, полным хаосом и отсутствием всякой стандартизации в плане организации информации. Это сетевые службы должны приспосабливаться к системе хранения данных, а не данные должны дублироваться для каждого приложения в своём формате!
Сейчас я пытаюсь объединить учётные записи DHCP и доменные записи компьютеров в одно целое так, чтобы все свойства объекта "компьютер" были объединены в одной учётной записи LDAP (в дальнейшем сюда же, в учётную запись компьютера, хочу добавить его DNS-имя для named). Пока что я застрял на том, что objectClass: sambaSAMAccount совершенно не дружит с objectClass: dhcpHost.
Поможете?
Re: Про LDAP и авторизацию в домене 29.09.2006 10:18dvc Касательно перемещения всех настроек в LDAP я не совсем уверен... какой смысл выкладывать в сетевую БД то, что нужно только локально. Делать еще один реестр винды, при падении которого рухнет вся система? Своими руками ковырять потенциальную дыру, которая открывает абсолютный контроль над системой?

---
Сейчас я пытаюсь объединить учётные записи DHCP и доменные записи компьютеров в
одно целое так, чтобы все свойства объекта "компьютер" были объединены в одной учётной
записи LDAP (в дальнейшем сюда же, в учётную запись компьютера, хочу добавить его
DNS-имя для named). Пока что я застрял на том, что objectClass: sambaSAMAccount
совершенно не дружит с objectClass: dhcpHost.
---

Во-первых, если корректно настроен DDNS, то в dhcp конфиге хранятся только специфические параметры подсети и зарезервированые имена, адреса. Всё остальное автоматом ложится в зоны DNS. Причем неважно, где физически лежат данные - это проблема DNS, а DHCP обращается к нему по стандартному протоколу (впрочем, как и все остальные).
Во-вторых, даже в windows-домене, я сильно сомневаюсь, чтобы зоны DNS лежали в одной куче с учетными записями компов. Соответственно также заточена и Самба - в ней нет соответствующих атрибутов, просто потому, что это проблемы из другой плоскости, к доменной структуре не сильно относящейся. Так что пользы от такой интеграции будет чуть.
В третьих, для повышения образованности, а в какой схеме описан objectClass: dhcpHost? В схемах core,cosine, samba, nis и dnszone я его не нашел (может быть плохо искал?).


Давайте не путать теплое с мягким и вспомним, что изначально LDAP ориентирован не на удобное РЕДАКТИРОВАНИЕ, а на удобное ЧТЕНИЕ нужной информации.
Я уверен что будет польза от следующих вещей:
1) Интеграция в одном entry samba и posix аккаунтов. С синхронизацией паролей или без таковой.
2) Добавление туда же ObjectClass: InetOrgPerson из одноименной схемы, для использования базы в качестве сетевой адресной книги.
3) Добавление таблицы почтовых псевдонимов (но только при огромном их количестве), потому что это тоже информация скорее внутренняя, чем внешняя.
4) Перемещение в LDAP записей зон DDNS. Именно DDNS, потому что во всех прочих случаях особого смысла в этом нет (кроме, может быть, ускорения поиска по базе при наличии сотен или даже тысяч записей). Именно в данном случае (несмотря на мое предыдущее высказывание) я вижу дополнительное удобство для редактирования статических учетных записей - редактирование через консоль, хм, несколько неудобно на мой взгляд. Да и то, для маленькой фирмы это абсолютно безразлично, поскольку можно остановить DNS и DHCP на минуту, подредактировать текстовики, убить jnl файлы и снова всё запустить.

А авторизация различных служб, типа Apache, Squid и т.п. может проходить на этой основе, либо для них нужно создавать отдельные ветки и вставлять в них objectClass: simpleSecurityObject (в простейшем случае. Вообще в схеме core есть достаточно объектов, чтобы настроить авторизацию на нужном уровне безопасности). Про почту можно сказать то же самое.

Дело ведь в том, что из множества Posix-аккаунтов на данном сервере, все с uid <500, не должны попадать в ldap. Те POSIX-аккаунты, которые предназначены для удаленной авторизации, должны иметь заведомо очень большие uid,gid (например, >10 000), чтобы избежать несанкционированного доступа с других машин с совпадающими uid, gid (да и то этот вопрос нужно как-то дополнительно контролировать в настройках NFS, SSH и т.п.).

Каждый Samba-аккаунт ДОЛЖЕН иметь соответствующий ему POSIX-аккаунт (и группы тоже), но их может быть меньше, чем POSIX-пользователей. Про разные пароли я уже написал.

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

Почтовый домен может быть реальным (для posix-аккаунтов) и/или виртуальным (своя отдельная база). Если база отдельная и очень важно иметь удобный интерфейс для администрирования аккаунтами, то вполне возможно, что более логичным будет положить их, например, в POSTGRE. В общем доступе нужны только те адреса, к которым есть уточняющая информация (ФИО, тел. и т.п.), все остальное - внутренние проблемы почтового сервера.

Аккаунты для доступа к SQUID и Apache может быть логично привязать к POSIX или SAMBA-аккаунтам или опять же сделать отдельные базы - все зависит от тех. задания. Даже привязав аккаунты к, например, POSIX записям, можно сделать отдельные атрибуты для паролей. Или атрибуты позволяющие сузить множество аккаунтов, которым разрешен доступ к данному сервису.

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

Я пока остановился на миграции SAMBA и POSIX, потом планирую прикрутить авторизацию SQUID и Apache (скорее всего пароли будут браться из posix-аккаунта), а потом сделать адресную книжку. Причем, скорее всего это будет база наших клиентов, а не сотрудников... Будет ли после этого что-то зависит от успехов на предыдущих этапах...
Re: Про LDAP и авторизацию в домене 29.09.2006 11:51DRVTiny ---
Во-первых, если корректно настроен DDNS, то в dhcp конфиге хранятся только специфические параметры подсети и зарезервированые имена, адреса.
---
Не знаю, как у Вас, но у меня там хранится информация о соответствии мак-адреса сетевой карты её IP-адресу. Насколько я знаю, к этому уровню модели OSI dns вообще отношенияне имеет. Кстати, хотя у меня и используется внутренний DNS-сервер, никакого прока я лично от него не вижу. Как раз собственный DNS небольшим организациям по-моему нафиг не нужен, тем паче, что в домене его с успехом заменит WINS.
---
Касательно перемещения всех настроек в LDAP я не совсем уверен... какой смысл выкладывать в сетевую БД то, что нужно только локально.
---
Очень просто: для того, чтобы несколько различных сервисов могли пользоваться одной и той же информацией. Кстати, не знаю, как у Вас, но у меня LDAP слушает только loopback. При необходимости доступ к нему осуществляется по stunnel'ю с ещё одного компа сети. Всем остальным доступ закрыт.
---
Делать еще один реестр винды, при падении которого рухнет вся система?
---
Если у Вас нет привычки делать резервные копии, то у Вас в олюбом случае система рано или поздно рухнет. А если такая привычка есть, то по-моему вполне очевидно, что делать регулярный дамп LDAP'а несколько проще, нежели постоянно зеркалить весь /etc, в котором мусора процентов 90, наверное, если не больше. А вообще я лично против реестра ничего не имею. Не вина Microsoft в том, что программы его используют в качестве базы данных на все случаи жизни. А при регулярном резервном копировании ничего страшного в "падении" реестра на серверах, где лишние 10 минут простоя погоды не сделают, по-моему нет. Впрочем, в этом отношении LDAP отличается гораздо более высокой надёжностью.
---
Во-вторых, даже в windows-домене, я сильно сомневаюсь, чтобы зоны DNS лежали в одной куче с учетными записями компов.
---
Зона DNS - это навязанное нам абстрактное понятие. Собственно, что такое зона? По сути, это просто сегмент сети. Но сеть состоит из компьютеров, а DNS-сервер видит одни только соответствия имени IP-адресу (в прямом и обратном порядке), но ведь имя и IP-адрес это же атрибуты какого-то конкретного объекта! Или Вы полагаете, что нужно логически разделять понятия хост DHCP, хост DNS, хост LAN, рабочая станция домена? Это ведь всё один и тот же компьютер! Так почему нельзя просто взять и собрать все сведения о нём в одной записи и заставить службы понять наконец, что объекты, с которыми они работают, не являются примитивными, плоскими и односложными, понять, что контекст, в котором они свойства этих объектов воспринимают, не является единственно возможным?
Кстати, а знакомы ли Вы с парадигмами объектно-ориентированного программирования, терминами "наследование", "полиморфизм", "инкапсуляция"? Вам не кажется, что в рамках этой парадигмы любая сеть может быть описана как достаточно простая и логичная совокупность иерархических структур, взаимосвязанных между собой как вертиакльными, так и горизонтальными связями. В Microsoft это уже давно поняли и создали централизованную службу Active Directory. Интересно, сколько сотен лет придётся ждать появления чего-то подобного в закостенелом "классическом" (наверное, маразматика Леонида Ильича Брежнева тоже можно назвать "классиком";-) UNIX? Существование "философии DNS", "философии почтового сервера", "философии контроллера домена" - это полный анахронизм, и по-моему только администраторы UNIX-систем до сих пор не могут этого понять (и слепо поклоняются всевозможным базам данных потому что они обеспечивают хоть какой-то уровень интеграции данных), потому что весь остальной мир уже давно использует объектно-ориентированный подход, при котором первичен ОБЪЕКТ, а не ПРИЛОЖЕНИЕ, которое с ним работает, использует его свойства. Не должны DNS-записи быть привязаны к тому формату, в котором их удобно видеть BIND'у, не должны учётные записи почтового сервера подчиняться правилам игры, устанавливаемым sendmail'ом или любым другим почтовиком. Информация должна иметь единообразное представление, и приложения обязаны под это представление гибко подстраиваться, А НЕ НАОБОРОТ!
Re: Про LDAP и авторизацию в домене 29.09.2006 13:15dvc "Все это и умно и глупо" (с) Собака на сене

В идеальном далеком будущем наверное так и надо... чтобы был один ключ от всех дверей... чтобы все денежки складывались в один кошелек и т.п.

Unix way - как я его понимаю, состоит не только в том, чтобы все было маленьким и простым. Очень важный аспект - разделяй и влавствуй. Взлом/авария одного сервиса, одной базы не должен выводить из строя всю систему. До тех пор, пока плюсы интеграции явно не перевешивают её минусы, лучше, чтобы каждый игрался в своей песочнице по своим правилам. И общался с другими по специально заточенным для этого протоколам. Это принципиальная философская проблема, на которую каждый пытается ответить по-своему и тяготеет к одному из полюсов. LDAP конечно хорош необычайно и в плане масштабируемости и в плане отказоустойчивости и шифрование ему очень к лицу и т.п. Но факт остается фактом - *никсы заточены под параноиков. Каждое приложение должно иметь доступ только к тем данным, которые ему нужны и ни граммом больше.

>Не знаю, как у Вас, но у меня там хранится информация о соответствии мак-адреса сетевой карты её IP-адресу.
У вас уже есть другой сервис, который нуждается в этой информации? У меня нет. Это теоретически можно прикрутить к какому-нибудь ACL, но я пока даже в планах не имею что-то фильтровать по MAC-адресу или его паре с IP. Зачем тогда головняк с нестандартной конфигурацией, в которой другой специалист мозг сломает, пытаясь разобраться? Нет, ну если есть такое желание + софтина, которая умеет лазить в лдап, то разумеется надо делать, а "про запас"... см.выше.

>Очень просто: для того, чтобы несколько различных сервисов могли пользоваться одной и той же информацией.
Повторюсь - зачем самбе мак-адреса и ip? А кому еще они нужны? Для начала нужно найти пару приложений, а потом интегрировать нужные им данные.

>Кстати, не знаю, как у Вас, но у меня LDAP слушает только loopback. При необходимости доступ к нему осуществляется по stunnel'ю с ещё одного компа сети. Всем остальным доступ закрыт.
А за каким вам тогда LDAP, я извиняюсь? У меня есть доступ из локалки, а потом будет с фиксированных внешних ip, чтобы отдельные ветки сделать для филиалов и хранить их там. Я же через него клиентов авторизую. Если мне нужна просто БД, то я и с mysql обойдусь прекрасно или другой sql. Атрибутов можно навешать сколько угодно, доступ на уровне полей настроить. Древовидную структуру можно с помощью двух ключей реализовать и в плоской таблице - нет проблем. Шифрование - тоже можно. И еще очень много того, чего в LDAP не включили и никогда не включат из соображений простоты реализации.

Мне, по большому счету LDAP не нужен даже для Samba-аккаунтов. Потому что samba-клиенты замечательно авторизуются через саму самбу (и не нужно их уговаривать напрямую лазить в LDAP). Так конечно красивенько и аккуратненько, но функциональности почти не добавляет.
А вот добавление POSIX-аккаунтов и групп мне дало возможность создать родной линуксовый контроллер домена, чего невозможно достигнуть с файлами /etc/{passwd,group,shadow}. Ведь главная функция контроллера домена - хранение базы учетных записей и предоставление интерфейса для авторизации. А прочие ресурсы могут предоставлять другие серверы. Только права на все, что угодно будут привязаны именно к этой базе.

>Не вина Microsoft в том, что программы его используют в качестве базы данных на все случаи жизни.
Вина M$ в том, что они суют в реестр все настройки самой системы и падение реестра вызывает со 100% вероятностью падение всей системы. Резервировать/реплицировать LDAP конечно гораздо проще, чем реестр, но проблема именно философская - см. выше.
И вы меня неправильно поняли, если считаете, что я против резервирования - я только за. Обоими руками. Просто угрозы могут быть разные и не от всех спасает резервное копирование.

>Зона DNS - это навязанное нам абстрактное понятие... весь остальной мир уже давно использует объектно-ориентированный подход, при котором первичен ОБЪЕКТ, а не ПРИЛОЖЕНИЕ...Не должны DNS-записи быть привязаны к тому формату, в котором их удобно видеть BIND'у, не должны учётные записи почтового сервера подчиняться правилам игры, устанавливаемым sendmail'ом или любым другим почтовиком...Информация должна иметь единообразное представление, и приложения обязаны под это представление гибко подстраиваться...

Гладко было на бумаге... Реально, существуют и работают сотни протоколов на всех уровнях. И это не только потому, что кому-то жалко бросить "полный анахронизм"...
Простой пример: поток биржевых котировок. Сначала думаем про максимальную совместимость и говорим, формат сообщений - подвид XML, клиент будет писаться на Java. Начинаем писать и реализовывать... С удивлением обнаруживаем, что трафик зашкаливает за все разумные пределы, клиент тормозит, а всех желаемых функций реализовать именно в Java не удается. Плюем на совместимость и делаем собственный формат данных, оптимизированный под конкретный поток и клиента пишем на каком-нибудь диалекте C, со вставками ассемблера в самых критичных местах.

Единый формат, единый стандарт и т.п. будет настолько громоздким, что никто не станет его реализовывать. LDAP хорош именно тем, что он упрощен и сознательно ограничен по функциональности. Не всякие данные в него полезут одинаково хорошо, даже если это данные об одном и том же объекте. Иначе можно до маразма дойти - а чего бы не положить в ldap, не только сертификат юзера, но и его домашний каталог со всеми файлами? Это же его файлы!

Не устаю повторять - интеграция нужна там, где от нее есть РЕАЛЬНАЯ, а не гипотетическая польза! В остальных случаях - марш в свою песочницу!
Re: Про LDAP и авторизацию в домене 29.09.2006 14:40DRVTiny ---
У вас уже есть другой сервис, который нуждается в этой информации?
---
Скрипту, формирующему правила IPTables. Хотел прикрутить ebtables на фильтрацию мак-адресов, но пока за это не берусь, поскольку здесь как всегда возникает проблема с остуствием интеграции: ebtables и iptables никак не взаимодействуют. Есть вариант намертво прошить таблицу мак-адресов в arp и использовать arpwatcher для получения сообщений о "левых" маках в сети, но мне, откровенно говоря, проще через iptables фильтровать по mac-source'у и писать простым и понятным образом в логи (а можно и через ULOG хоть в базу MySQL, хоть ещё куда).
---
Зачем тогда головняк с нестандартной конфигурацией, в которой другой специалист мозг сломает, пытаясь разобраться?
---
Так, собственно, что есть стандартная конфигурация? Вот уж действиительно, вовремя Вы вспомнили о стандартах. Их полное отсутствие - этот как раз и есть самое слабое место (у меня это вызывает ассоциации с занозой в одном месте) Linux, работающего хоть на сервере, хоть на дектопе. Так что здесь каждый сисадмин лепит то, что ему лично нравится. Сами пишем фаерволлы, сами сочиняем скрипты, сами переделываем исходники, если они работают не совсем так, как хотелось бы. У нас есть полный простор для имитации бурной деятельности.
---
Вина M$ в том, что они суют в реестр все настройки самой системы и падение реестра вызывает со 100% вероятностью падение всей системы.
---
По аналогии можно говорить о /etc, который общем-то тоже может накрыться, тем более тчо доступ к этому каталогу без использования сложных в настройке IDS'ов ограничивают только права пользователя, под которым работает тот или иной сервис. Кстати, Вы, наверное, заметили, что по сути /etc - это та же помойка, что и реестр Windows, туда тоже все, кому не лень, свои "общесистемные настройки" пишут. А то, что Windows не грузится с испорченным реестром - это что, действительно большая проблема? Хм... возможно, но насколько я знаю, современные серверные Форточки не столь критично к этоиу относятся и могут восстанавливать реестр из контрольных точек.
---
Если мне нужна просто БД, то я и с mysql обойдусь прекрасно или другой sql.
---
А мне вот LDAP нравится. И не только мне. Тот же Active Directory в доменах Microsoft используется безотносительно к тому, нужен он за пределами контроллера домена или нет. А sql... Можно и микроскопом гвозди забивать, но реестроподобную конфигурацию удобнее всё-таки хранить в LDAP.
---
Простой пример: поток биржевых котировок.
---
Пример исключительно простой и главное - идеально соответствует теме разговора Улыбка Кстати, я не сторонник XML и считаю, что должен использоваться либо удобный для чтения plain-text формат, либо компактный бинарный. Третьего не дано. XML - крайне неудачный вариант структуризации human-readable данных.
---
Единый формат, единый стандарт и т.п. будет настолько громоздким, что никто не станет его реализовывать.
---
В UNIX-да, безусловно. Здесь люди не видят леса за деревьями, потому что деревьев слишком много.
Re: Про LDAP и авторизацию в домене 29.09.2006 14:46DRVTiny ---
Иначе можно до маразма дойти - а чего бы не положить в ldap, не только сертификат юзера, но и его домашний каталог со всеми файлами?
---
Так вот именно таким маразмом и является файловая система UNIX: здесь файлы домашнего каталога пользователя хранятся там же, где и настройки (для того, чтобы это создавало меньше проблем используется уродливый костыль в виде точки в начале имени каталога). Собственно, в самом /etc многие приложения собственные данные хранят.
А в LDAP - там только настройки хранятся, Вы разве не в курсе? Улыбка Я что-то не улавливаю аналогии между мак-адресом компьютера и файлами в домашнем каталоге пользователя...
Re: Про LDAP и авторизацию в домене 29.09.2006 15:59dvc >>У вас уже есть другой сервис, который нуждается в этой информации?

>Скрипту, формирующему правила IPTables.

це конечно круто, но таким макаром в файл dhcpd.leases лазить ничуть не труднее. Разве что у вас dhcp будет на другом сервере крутиться... В таком случае да - оно вам надо.
Но я вам буду очень признателен, если вы мне подскажете настройки самого dhcpd, которые позволяют эту иформацию расположить в лдапе. Или ссылку подкинете. Для повышения образованности...

>Так, собственно, что есть стандартная конфигурация? Вот уж действиительно, вовремя Вы вспомнили о стандартах.
Стандартная, применительно к dhcpd, та, которая указана во всех руководствах и манах. И такая стандартная методика есть для каждого отдельного сервиса. Вот, например, для той же самбы расположение учеток в лдапе - один из стандартных вариантов. Никто не будет особо ломать голову, как с этим жить - достаточно обратиться к литературе по теме. И для DNS есть руководство. И схема соотв. есть. А вариант расположения информации из dhcpd я не встречал еще ни разу. Ругаясь на расположение конфигов в /etc и домашних каталогах, вы нападаете на фундаментальный стандарт - POSIX, благодаря которому сохраняется максимальная совместимость и переносимость софта на разные платформы и операционные системы. То, что все отличия от стандартной конфигурации лежат в каталоге пользователя - вас бесит. А то, что ветка реестра юзера лежит в его подпапке Documents and Settings - это нормально? А то, что можно взять свой home и пересесть с Linux на BSD и все умолчальные программы будут работать с твоими настройками - это уже ничего не значит? Да с той же виндой: вы свои настройки из 98-й в 2000-ю перенести не сможете, либо получите вагон геморроя от того, что они кардинально отличаются... Да что в 2000-ю, попробуйте хотя бы из 98-й в Me это перенести. А еще нужно про те программы будет подумать, которые все свои настройки хранят в ini-файлах у себя в Program files и плевали на реестр... Но это уже действительно в другую сторону...


>По аналогии можно говорить о /etc, который общем-то тоже может накрыться, тем более тчо доступ к этому каталогу без использования сложных в настройке IDS'ов ограничивают только права пользователя, под которым работает тот или иной сервис.

Если накроется контроллер винта или еще что-то фатальное, то тут действительно ничего не поможет. А если на винте будет бэд-блок, то накроется один-два конфига и вероятность того, что это будут такие конфиги, без которых никак не загрузить систему - очень мала. Даже если так - загружаемся с другого винта или livecd, и сливаем всю инфу, за вычетом парочки конфигов. Отказоустойчивость налицо. Будет потеряно только то, что действительно физически разрушено. Разрушение любого файла с инфой любой базы данных - на порядок фатальнее.

>Кстати, Вы, наверное, заметили, что по сути /etc - это та же помойка, что и реестр Windows, туда тоже все, кому не лень, свои "общесистемные настройки" пишут.

Только от удвоения количества конфигов в /etc не наступают такие же тормоза, как от удвоения размера реестра... Особенно если пользовать reiserfs.

>А то, что Windows не грузится с испорченным реестром - это что, действительно большая проблема? Хм... возможно, но насколько я знаю, современные серверные Форточки не столь критично к этоиу относятся и могут восстанавливать реестр из контрольных точек.

Если они смогут загрузиться вообще... Опять же проблема - чтобы восстановить рухнувшую систему на линуксе, нужно загрузиться с livecd, подмонтировать винт и поработать в текстовом редакторе или даже просто в проводнике. А в случае рухнувшей винды для подключения к локальному реестру требуется какой-то волшебный реаниматор, про который я где-то как-то слышал, но наблюдать не приходилось (говорят, что очень тормозной). Как и к любой другой БД. Впрочем, в линуксе можно еще сделать chroot на локальный винт и попытаться запустить соотв. сервис или какие-то его родные утилитки... Можно, но однако сложнее, чем с текстовичками...

>А мне вот LDAP нравится. И не только мне. Тот же Active Directory в доменах Microsoft используется безотносительно к тому, нужен он за пределами контроллера домена или нет. А sql... Можно и микроскопом гвозди забивать, но реестроподобную конфигурацию удобнее всё-таки хранить в LDAP.

Мы об одном и том же разными словами. Если вам вообще БД - то фиолетово, чем пользоваться и почему бы не sql-based, если она дает больше свободы при манипуляцих с данными. Если вам локальный доступ к немногочисленным настройкам - сначала попробуйте через обычный текстовый файл, а уже потом извращайтесь. Если вам интеграцию с одним-двумя локальными приложениями (тем паче скриптами) - текстовый файл не хуже других. Но если вам нужен удаленный доступ для прямой авторизации или к какой-то инфе типа адресная книга, каталог - вот тогда нужна софтина, которая будет отвечать на удаленные запросы и посылать ответы в стандартном формате. В принципе можно наваять свой скрипт и подвесить его на xined, а откуда он будет брать эту инфу - безразлично удаленным клиентам. Но есть ldap, и этот стандарт понимают большинство почтовых клиентов и под него написан pam модуль. Про забивание гвоздей микроскопом - меня всегда убивало, что практически пустая AD ставится на сравнительно неплохой машинке минут 10-20. То есть моих данных в ней даже процента не наберется - Остальное все - про запас. Вот это действительно забивание гвоздей микроскопом!

>XML - крайне неудачный вариант структуризации human-readable данных.
Как же весь мир тупит!!! Может скромнее немного нужно быть? А?
Re: Про LDAP и авторизацию в домене 29.09.2006 16:22nektofil Отвечая DRVTiny, dvc писал(а):

>> XML - крайне неудачный вариант структуризации human-readable
>> данных.
> Как же весь мир тупит!!! Может скромнее немного нужно быть? А?
>

Как-же, как-же: "1000000 леммингов не могут ошибаться!" (с)

Но это все лирика.

Может вместо клановых войн действительно что-нибудь реальное
получится сделать? Я вот сверху тему почитал, и тоже начал
слюной исходить. А дальше... Вопли и сопли... Ну сделайте
каждый по своему, а потом сравите. Зачем же собачиться по
ерунде?
Re: Про LDAP и авторизацию в домене 29.09.2006 16:41DRVTiny ---
Но я вам буду очень признателен, если вы мне подскажете настройки самого dhcpd, которые позволяют
---
Вот мой /etc/dhcpd.conf (переводы строк пришлось вручную набивать):
---
ldap-server "localhost";
ldap-port 389;
ldap-username "cn=Manager,ou=DHCP Server,dc=nespilan,dc=ru";
ldap-password "не скажу";
ldap-base-dn "ou=DHCP Server,dc=nespilan,dc=ru";
ldap-method dynamic;
---
Описание того, как перенести настройки DHCP в LDAP, можно найти на ldapzone.spb.ru. Кстати, Вы ж там были вроде?
---
благодаря которому сохраняется максимальная совместимость и переносимость софта на разные платформы и операционные системы.
---
Да, но LDAP вообще-то работает не только подо всеми POSIX-фанатеющими системами, но и под Windows, и под полуосью. Я что-то не припомню где там /etc... Наверное искать надо в WinNT/System32/Drivers Улыбка Кстати, в Linux есть ещё и собственный стандарт организации файловой системы (Linux FileSystem Hierarchy), пусть не противоречащий POSIX, но тем не менее свой.
Я думаю, что если какой-то стандарт тормозит развитие отрасли, то проблема в стандарте. В области IT не место "национальной самобытности" и "традициям народов Севера". Если уж и следовать стандарту, то осознанно, а не потому, что "так уж исторически сложилось". Некогда люди имели привычку ходить с дубинками наперевес и без набедренной повязки. Это же не значит, что человеку следовало жить в пещерах и до наших дней? Вы представьте только, ведь если бы человек до сих пор ходил с дубинкой и выковыривал себе червей на ужин палкой-копалкой, стандарт POSIX - этот предмет оголтелого идолопоклонничества, так никогда бы и не появился на свет.
---
Может скромнее немного нужно быть?
---
Нет, просто нужно думать своей головой Улыбка Вам - не мне.
Re: Про LDAP и авторизацию в домене 29.09.2006 17:03DRVTiny ---
Как-же, как-же: "1000000 леммингов не могут ошибаться!" (с)
---
Вот-вот. Меня как-то мало волнует, что там думает по поводу XML Билл Гейтс или Ричард Столлман, мне важно, насколько этот формат удобен лично для меня, насколько он оптимален. Ничего хорошего я о нём сказать не могу. Это всё-таки не HTML, который можно редактировать и вручную (изначально HTML был задуман как простой до безобразия язык разметки, с которым может управиться даже школьник или домохозяйка) - большинство же прочих языков разметки, построенных на XML, не предназначены для ручной правки. В таком случае и не понятно, а зачем вообще нужна избыточность, все эти лишние символы <,>,/, английские слова и т.д.? Если Вы не программировали на ассемблере, то наверное не знаете, сколько ценной информации можно уместить буквально в одном байте. Я когда пишу низкоуровневый код, каждый байт экономлю, каждый бит, а XML эти байты буквально растранжиривает! Мало того, XML нужно ещё интерпретировать, а это уже растранжиривание системных ресурсов, мощности процессора.
Вы вот часто занимаетесь правкой SVG-рисунков или документов OpenOffice/MS Office в простом текстовом редакторе? А ведь XML избыточен именно ради читабельности. Но кому она нужна, эта читабельность? Тем, кому лень нормальные конфигураторы писать для своих программ?
---
зачем же собачиться по ерунде?
---
А что, это так со стороны выглядит? Улыбка Плохо, очень плохо... постараюсь исправиться ;-)
Re: Про LDAP и авторизацию в домене 29.09.2006 18:06nektofil Ну нельзя же так ради кально подходить к вопросу. Улыбка
Иногда приходится жертвовать размером для повышения производительности.
Когда я пишу на ассемблере, я тоже не только байты экономлю. Иногда
до битов дело доходит. А такты считать -- самое обычное занятие.

С другой стороны, когда рядом сидят **N** программеров, и у каждого
к **любой** программе отдельная конфигурялка со своим форматом и
интерфейсом... Иногда хочется их всех "вывести в чистое поле..."
ну и дальше по тексту.

Поэтому **в данном случае** я предпочитаю XML-ные конфиги. И к
**каждому** требую dtd-шку. Ибо нефиг. ;-)

Так что всему своё время и место.

ЗЫЖ А SVG-шку я-таки пару раз в **vi** редактировал. ;-)
Re: Про LDAP и авторизацию в домене 29.09.2006 19:16DRVTiny ---
С другой стороны, когда рядом сидят **N** программеров, и у каждого
к **любой** программе отдельная конфигурялка со своим форматом и
интерфейсом.
---
В принципе, я думаю, и XML несложно в некое подобие байт-кода превратить, "скомпилировать". Нельзя же это всё прямо так, текстом передавать и обрабатывать. Это как минимум просто неэкомное расходование памяти, ресурсов процесора и трафика. Трафик можно сэкономить только за счёт ресурсов процессора, сжимая XML-файлы - разве это выход? Всё равно же этот XML парситься в какую-то промежуточную форму, так почему бы не передавать его уже в этой самой форме, не читабельной, но понятной любой программе без интерпретации с использованием внешних библиотек.

Впрочем, это уже отступление от темы интеграции настроек на базе LDAP...
Re: Про LDAP и авторизацию в домене 29.09.2006 19:55nektofil В принципе это здравая мысль. Но. О5-таки все зависит от точки зрения.
Лично мне проще залезть обычным текстовым редактором в xml-ный
файл и поправить его. Или "подточить" svg-шный шаблон для
логиновского окна в X-ах. Вместо того, чтобы искать
специализированную прогу для правки байт-кода. Но это снова
тема для очередного холивара.
Кому-то нравится компилированный реестр, а кому-то ближе "текстовая
помойка /etc". ;-)

Для высокопроизводительных задач конечно же эффективнее использовать
нечто бинарное. Для увеличения надежности и удобства настройки
имхо лучше текст. Конструктор гибче, **хорошо сделанный** станок
надежнее и эффективнее. Одним важнее время разработки/внедрения,
другим -- загрузка процессора. Универсального решения, удовлетворяющего
ВСЕХ не существует. Это прописные истины, но их в спорах
постоянно забывают. Грустный

> Впрочем, это уже отступление от темы интеграции настроек на базе LDAP...

Да. Действительно. Вопрос на столько философский, что его даже во
"Флейм" выносить не имеет смысла. Улыбка
Re: Про LDAP и авторизацию в домене 29.09.2006 21:10Woodoo DRVTiny писал(а):

> В UNIX-да, безусловно. Здесь люди не видят леса за деревьями,
> потому что деревьев слишком много.

Здесь люди поливают каждое дерево и не требуют от раффлезии быть баобабом.
А ветку и впрямь во флейм нужно.
Re: Про LDAP и авторизацию в домене 30.09.2006 08:20DRVTiny ---
А ветку и впрямь во флейм нужно.
---
Слава Богу, что появился мудрый Вуду и рассказал, что кому нужно делать. Без тебя здесь никто бы не справился.

**Re2dvc**
---
Впрочем, в линуксе можно еще сделать chroot на локальный винт и попытаться запустить соотв. сервис или какие-то его родные утилитки
---
Зачем? Можно взять резервную копию каталога /var/lib/ldap и скопировать её поверх поврежденной базы. собственно, примернотоже самое Вы бы сделали, если бы накрылся /etc: восстановились бы из резервной копии.
---
А в случае рухнувшей винды для подключения к локальному реестру требуется какой-то волшебный реаниматор
---
Опять же, он нужен только тем (здесь нелестный эпитет), которые вовремя не делают резервную копию файлов реестра. Если же эта копия есть, никто не мешает Вам даже из под Linux (благо, что сейчас вышла бета драйвера NTFS с поддержкой записи) перезаписать испорченые файлы резервной копией. Так что не вижу, в чём тут может быть проблема, собственно и зачем могут понадобиться какие-то хитрые реаниматоры.
Re: Про LDAP и авторизацию в домене 30.09.2006 13:18Woodoo DRVTiny писал(а):

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

Удивительный человек.
Если тебя раздражает *nix-операционка - зачем ты ей пользуешься?
Если тебя раздражают люди - зачем ты с ними общаешься?
Если тебя раздражает чужое мнение - зачем ты высказываешь свое?
Re: Про LDAP и авторизацию в домене 30.09.2006 14:35DRVTiny Очень интересное мнение... Я его уважаю и горячо приветствую.
Но дело в том, что тема, открытая не Вами, посвящена LDAP, и я не очень понимаю, почему, собственно, нужно от неё так далеко отклоняться.

Вуду, для того, чтобы я к Вам проникся ещё более глбоким уважением, не могли бы Вы дать совет, как добавить objectClass из одной LDAP-схемы в другую. Буду благодарен...
Re: Про LDAP и авторизацию в домене 30.09.2006 20:00Woodoo DRVTiny писал(а):

> Вуду, для того, чтобы я ...

Неправильная мотивация.
Re: Про LDAP и авторизацию в домене 30.09.2006 22:05DRVTiny Ты просто ни черта не знаешь Улыбка Не хочешь знать... Это сугубо женский менталитет - подстраиваться под окружающий мир, проявляя чудеса адаптации, полагая его незыблемым и неизменным. Вырождение генофонда стирает различия...
Re: Про LDAP и авторизацию в домене 01.10.2006 01:07Woodoo DRVTiny писал(а):

Скажи, а конфиг самого ldap-а ты в каком виде собираешься держать?

> Ты просто ни черта не знаешь Улыбка Не хочешь знать... Это сугубо
> женский менталитет - подстраиваться под окружающий мир,
> проявляя чудеса адаптации, полагая его незыблемым и неизменным.
> Вырождение генофонда стирает различия...

Не разглядел, это - попытка уязвить? ;-)
Re: Про LDAP и авторизацию в домене 01.10.2006 10:18DRVTiny >Скажи, а конфиг самого ldap-а ты в каком виде собираешься держать?
Не скажу. Это секрет фирмы ;-)

---
Не разглядел, это - попытка уязвить? ;-)
---
Нет, это констатация факта. Сисадмины слишком много пива пьют, а это отражается на соотношении мужских и женских гормонов в пользу последних. Отсутствие стремления к идеалу, побарабанное отношение ко всему, что не касается basic instict'ов, примитивная адаптация к окружающей среде - явные признаки вырождения человечества, во всяком случае - мужской его половины.
Re: Про LDAP и авторизацию в домене 01.10.2006 11:13Woodoo DRVTiny писал(а):

> >Скажи, а конфиг самого ldap-а ты в каком виде собираешься
> держать?
> Не скажу. Это секрет фирмы ;-)

Хорошо.
А я знаю уже по меньшей мере 3 потенциальных уязвимости архитектуры комплекса, если основываться на тезисах, услышанных от тебя ранее (в этой ветке). Либо эти тезисы в корне неверны и не имеют ничего общего с практической реализацией.
Но тоже "не скажу" - и не только потому, что хочу пококетничать. Просто они произрастают из ненавистной тебе *nix-философии. Ж)
Надеюсь, сам выяснишь **до** конечного RC. Катается от смеха

Кстати, ты не брезгуешь пользоваться *nix модульными технологиями? Не смущает, что реализация **твоего** идеала - результат взаимодействия (возможности взаимодействия) неидеальных с твоей точки зрения компонентов? И безупречность работы твоего комплекса - в безупречности работы его составляющих? Ж)

> ---
> Не разглядел, это - попытка уязвить? ;-)
> ---
> Нет, это констатация факта. Сисадмины слишком много пива пьют,
> а это отражается на соотношении мужских и женских гормонов в
> пользу последних. Отсутствие стремления к идеалу, побарабанное
> отношение ко всему, что не касается basic instict'ов,
> примитивная адаптация к окружающей среде - явные признаки
> вырождения человечества, во всяком случае - мужской его
> половины.

Мужская хромосома (в контексте генофонда) всегда была носителем информации об **изменении** условий среды обитания, тем самым обеспечивая адаптацию следующих поколений.
Попеняй Богу. ;-)
Re: Про LDAP и авторизацию в домене 01.10.2006 13:31DRVTiny ---
А я знаю уже по меньшей мере 3 потенциальных уязвимости архитектуры комплекса
---
Это просто смешно! Тебе не кажется, что нужно сначала поставить определённую цель, сформулировать идею и хотя бы начать претворять её в жизнь с чисто функциональной точки зрения, а потом уже задумываться о том, что где-то там чего-то "небезопасно". Безопасность - это свойство системы, но если нет самой системы,то о чём вообще может идти речь? Логика "если так безопасно, то иначе будет небезопасно" просто ущербна и потому, мягко говоря, неубедительна. Я считаю, что модель Active Directory во сто крат надёжнее и безопаснее устаревшей ещё в каменном веке модели хранения одних и тех же настроек в сотне различных мест и обеспечения синхронизации этих настроек в самых бредовых формах своего представления с помощью соплей в виде perl-скриптов, тормозящих систему, пишущихся каждым админом "под себя" (так старики-инсультники тоже много чего делают под себя) и соответственно, также содержащих потенциальные уязвимости. Ограничить доступ к закрытой системе - "чёрному ящику" LDAP на порядок проще, нежели сделать тоже самое с полностью открытой системой - поддеревом /etc. Это всё равно, что сравнивать надёжность и безопасность политик "всё запрещено, кроме явно разрешённого" и "всё разрешено, кроме явно запрещённого".

Уволишь сисадмина - а потом с его скриптами в количестве миллиона штук будешь голову ломать: как вся эта хрень работает, что вообще делает и на черта нужна? А иначе... Нужно добавить любую самую плёвую настройку - изучай формат 50 различных конфигов, обеспечивай непротиворечивость того, что ты туда внёс, потом ещё с десяток различных служб перезапусти (при этом не забудь о том, что часть из них запускается через супервизор xinetd, часть - через daemontools, а остальные - как SysV-сервисы). Если это UNIX-way, то ты меня извини, но все, кто от такого UNIX-way пребывают в диком восторге, просто дуремары, для которых важен не результат, а сам процесс тупой имитации бурной деятельности.
---
Кстати, ты не брезгуешь пользоваться *nix модульными технологиями?
---
Объясни мне, пожалуйста, при чём тут это? Давай тогда уж будем говорить о том, что, например, интеграция, которую обеспечивают стандарты FreeDesktop.ORG'а, делает рабочие столы пользователей потенциально уязвимыми: а то мало ли, удалит человек весь /usr/share/icons и привязки в MIME-типам, и DBUS с HAL'ем, и *.desktop-файлы главного меню, а после этого у него ни Gnome, ни KDE работать не будут. А вот если бы у Гнома и KDE было всё своё: и HAL, и DBUS, и формат ярлыков, и формат/место хранения базы MIME-типов, и многое-многое другое, то ведь не так-то просто было бы пользователю или злоумышленнику всё это угробить: представляешь, ведь это сколько ж добра в этом случае пришлось бы поудалять! А ты представь себе только, как будет неприятно, если вдруг накроется /usr/share/locale! Я думаю, может, вообще стоит перейти на систему, при которой каждое приложение будет хранить перевод сообщений только в своих собственных папочках, в собственном, понятном только ему формате? Это ж какая надёжность будет необыкновенная: "Назад, в будущее!", снова залезть на деревья и жизнерадостно улюлюкать с ветвей. Или в пещеры... Представляешь, насколько надёжны пещеры: потолок у них не падает, сгореть они от непогашенного окурка не могут...

Я ничего не имею против модулей, сам в дестве очень любил конструкторы, но я прекрасно помню, как меня раздражало, когда детальки от различных конструкторов плохо стыковались друг с другом. Я, кстати, уже тогда догадался, что можно штырьки на пластмассовых детальках дорабатывать напильником для того, чтобы они под типоразмеры пазов подходили, но ты знаешь, мне почему-то этот процесс совершенно не казался увлекательным... На сегодняшний день "идеология" Симуляции Бурной Деятельности UNIX предлагает даже не напильником что-то дорабатывать, а вовсе склеивать детальки соплями, потому что на этих детальках пазы и штырьки вовсе отсутствуют (они, оказывается, сложны в
изготовлении).

---
Мужская хромосома (в контексте генофонда) всегда была носителем информации об изменении условий среды обитания, тем самым обеспечивая адаптацию следующих поколений.
---
И в чём это противоречит сказанному мной? Я, собственно, и говорил именно о том, что у современных администраторов UNIX-систем то, что ни называют "здоровым консерватизмом", на самом деле есть очевидный признак вырождения "мужской хромосомы" со всеми вытекающими отсюда последствиями. Не здоровый это консерватизм. Гермафроидальный.
Re: Про LDAP и авторизацию в домене 01.10.2006 18:26DRVTiny Только что установил опытным путём:
objectClass: top
objectClass: dhcpHost
objectClass: posixAccount
objectClass: sambaSAMAccount
Неплохо уживаются друг с другом! Я сделал так, что dhcpHost стал одним из objectClass'ов схемы samba.schema (соотв. образом заменил его OID), сюда же с новыми OID'ами перекинул нужные dhcpHost'у атрибуты. Всё работает! По крайней мере у меня дома...
Re: Про LDAP и авторизацию в домене 02.10.2006 10:00dvc 2DRVTiny.
Флаг тебе в руки... Я свои руки пожалуй из этой темы умою...
Слишком нервно и бесперспективно пытаться объяснить фанату, что переделать весь линукс на корню, только для того чтобы удовлетворить его идеалам об интеграции, а затем сделать эту поделку мировым стандартом - занятие провальное по причине непредставимой ему глобальности задачи и большой сомнительности конечной выгоды...

Тем не менее несколько слов не могу не добавить...

---

Вот мой /etc/dhcpd.conf (переводы строк пришлось вручную набивать):

ldap-server "localhost";
ldap-port 389;
ldap-username "cn=Manager,ou=DHCP Server,dc=nespilan,dc=ru";
ldap-password "не скажу";
ldap-base-dn "ou=DHCP Server,dc=nespilan,dc=ru";
ldap-method dynamic;

Описание того, как перенести настройки DHCP в LDAP, можно найти на ldapzone.spb.ru. Кстати, Вы ж там были вроде?
---

Это информативно - решпект. Будем поискать и разбираться. На ldapzone.spb.ru был и даже выкачал его на свой винт полностью, но на всё почитать времени, как обычно, не хватило.
Касательно переносимости на windows я ничего не говорил - я говорил про стандарт POSIX, который винда поддерживает только на бумаге, да и то оченно своеобычно. Не хочу начинать новую дискуссию - просто констатирую факт передергивания.

---
objectClass: top
objectClass: dhcpHost
objectClass: posixAccount
objectClass: sambaSAMAccount
Неплохо уживаются друг с другом! Я сделал так, что dhcpHost стал одним из objectClass'ов схемы samba.schema (соотв. образом заменил его OID), сюда же с новыми OID'ами перекинул нужные dhcpHost'у атрибуты. Всё работает! По крайней мере у меня дома...
---
Сделать новую схему или отредактировать старую не так уж сложно. Сложно сделать так, чтобы её описание попало в RFC, а оттуда на большинство серверов, использующих LDAP. То, что вы проповедуете гипотетически, в реалиях разобъется о вышеобозначенную глобальность задачи. А будучи реализованным только на вашей машине, окажется поделкой не лучше и не хуже, чем перловые скрипты других админов. Ибо нестандартно. Об этом я вам пытаюсь втолковать.


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

---
Давай тогда уж будем говорить о том, что, например, интеграция, которую обеспечивают стандарты FreeDesktop.ORG'а, делает рабочие столы пользователей потенциально уязвимыми
---
Действительно делает. Зачем здесь сарказм ядовитый? Но это как раз тот случай, когда плюсы интеграции видны невооруженным взглядом, и выгоднее бороться с минусами, чем отказываться от таких плюсов. Если вы сумеете доказать, что ваши предложения также очевидно положительны - за вами пойдут миллионы. А пока вы никого убедить толком не сумели, судя по обсуждению - эмоции, понты, наполеоновские планы.


2nektofil.
Я уже сделал рабочий вариант с POSIX и Samba аккаунтами. Это то, что описано в нескольких источниках, в т.ч. и довольно древних. Это то, от чего я вижу очевидную выгоду (и уже даже нагло пользуюсь этой выгодой ;-) ), что достаточно просто внедрить и на что достаточно просто переехать с другой конфигурации, без глобальной переделки unix в windows. Я готов запостить все ссылки и конфиги, которые будут нужны и добавить свои комментарии. Я буду заведомо рад любой конструктивной критике, а еще больше буду рад конструктивной помощи.

Но думаю, что делать это нужно будет в другой теме и даже в другой ветке.
Сюда я кидал предложение разработчикам сделать вариант из коробки. И просто хотел уточнить (в основном именно для разработчиков), что я не фанатею от идеи засунуть ВСЁ в LDAP. А вот удаленная авторизация unix-пользователей в смешанной сети с unix-сервером во главе (или, по крайней мере, в наличии Улыбка) - штука определенно востребованная. Имеет смысл помучаться.

Я хочу подчеркнуть, что у меня в /etc/{passwd,shadow,group} так и остались лежать учетные записи root и всех служб. Они мне в LDAP без надобности. Я предпринял дополнительные меры, чтобы uid-ы, gid-ы posix учеток в LDAP были очень большими, иначе возможны конфликты в сети. Самбовые учетки я туда сунул больше для красоты - функционально нет в этом никакой необходимости. Потому что удаленным клиентам самбы не нужен прямой доступ в LDAP. И я не собираюсь агитировать за помещение в LDAP никаких конфигов. Если они сейчас лежат в файлах, значит вовне они не нужны. Все, что я сделал, я сделал без редактирования существующих схем LDAP и считаю это большим очевидным плюсом. Также я считаю плюсом, что это решение позволяет для каждой рабочей станции делать локальный или сетевой /home одной строчкой в /etc/fstab, в зависимости от необходимости. Как корректно сделать такую настройку для каждого юзера - хотелось бы обсудить...

Если кому-то нужно помещать в LDAP другую информацию - какие проблемы? Друг! Расскажи, почему тебе это оказалось нужно? Чем тебе это помогло? Мы все будем счастливы разделить с тобой эту радость. Но только не надо абстрактных аргументов об удобстве, единстве и т.п. Люди вокруг занятые и у всех уже что-то так или иначе крутится-вертится. А от добра добра не ищут.

К сожалению, в ближайшие пару-тройку дней я не смогу появляться на этом форуме. Но потом сделаю соотв. тему в ветке Администрирование и начнем обмениваться опытом. Чем больше будет сеток с такой или близкой конфигурацией, тем легче будет всем участникам.
Re: Про LDAP и авторизацию в домене 02.10.2006 10:45DRVTiny ---
Слишком нервно и бесперспективно пытаться объяснить фанату, что переделать весь линукс на корню
---
Никто ничего не собирается переделывать на корню. Я просто говорю о том, к чему следует стремиться, что позволит сделать UNIX гибкой и лёгкой в настройке системой. Я постараюсь выкладывать свои наработки... где-нибудь (надо будет подумать, где. Скорее всего, на асплинэте), а там уж личное дело каждого, будет ими кто-либо пользоваться или нет. Кстати, если Вы ен в курсе, в Enterprise продуктах Novell'а и RedHat'а есть собственные наработки по интеграции различных служб на базе LDAP, поэтому я не очень понимаю, что такого криминального можно увидеть в самой идее использования AD-подобного дерева вместо горстки конфигов.
---
Будем поискать и разбираться.
---
Так что там искать: читайте по ссылке, там буквально в двух словах про DHCP сказано (на самом деле с DHCP всё оказывается даже не просто, а вовсе элементарно). Ссылка: [ldapzone.spb.ru]
Re: Про LDAP и авторизацию в домене 02.10.2006 11:00DRVTiny ---
Сделать новую схему или отредактировать старую не так уж сложно. Сложно сделать так, чтобы её описание попало в RFC
---
Лично мне это нафиг не надо. Та же dhcp.schema ни в какие RFC не внесена, и никто, как ин старнно, от этого не страдает.
---
То, что вы проповедуете гипотетически, в реалиях разобъется о вышеобозначенную глобальность задачи.
---
Что тут глобального? Я ж не призываю переписывать все приложения так, чтобы они свои настройки брали из свойств объектов в иерархии справочника LDAP, я призываю для тех приложений, которые уже могут интегрироваться с LDAP'ом, использовать эту возможность с максимальной для себя выгодой. Между прочим, для настройки через LDAP достаточно одного GQ или веб-интерфейса, а для настройки этих же приложений через конфигураторы нужно для каждого формата конфига свой парсер писать...
---
А будучи реализованным только на вашей машине
---
Я с удовольствием выложу свою схему в открытый доступ. Кому надо - пусть пользуется.
---
Может я отстал от жизни (хм?), но когда я последний раз пытался скопировать файл реестра на рабочей машине, меня система посылала далеко и надолго.
---
Хорошо, ну а кто Вам помешает скопировать каталог /var/lib/ldap?
Re: Про LDAP и авторизацию в домене 02.10.2006 12:05DRVTiny Натупил я с этим dhcpHost'ом Грустный
На самом деле там всего лишь нужно было удалить из учёток рабочих станций домена совершенно пустопорожние классы pinetOrgPerson, organizationalPerson, person - они там **не нужны**, и могут быть запросто заменены dhcpHost'ом (он как раз STRUCTURAL, SUP top).
Написал крохотный скрипт для поиска атрибута/класса по всех схемам в /etc/openldap/schema:
#!/bin/sh
idOBJ="$1"
find /etc/openldap/schema/ -name "*.schema" | while read f; do
sed -nr "/NAME\s+"\'"${idOBJ}"\'"/p" "$f" | grep -q "${idOBJ}" && \
echo "Object ${idOBJ} was found in $f"
done
Re: Про LDAP и авторизацию в домене 02.10.2006 14:20dvc >Та же dhcp.schema ни в какие RFC не внесена, и никто, как ин старнно, от этого не страдает.
Страдаете вы, в первую очередь, потому что приходите к тому, от чего убежать пытаетесь. Неуниверсальность. Вместо того, чтобы другу/знакомому посоветовать "измени в конфиге таком-то такую-то строчку и перезапусти сервис", вы будете объяснять, что "нужно скачать патчик к dhcp с этого сайта, а схему для лдапа с того, а инструкцию ко всему этому с третьего, потом взять у тебя парсер, для миграции записей и получить ldif, а уже после этого измени в конфиге таком-то такую-то строчку и перезапусти сервис". Хорошо, когда сложные вещи уже идут в коробке с дистрибутивом. Те же Enterprise-версии RedHat и т.п. И когда к ним уже есть руководство по установке/настройке. Так может сначала поискать дистрибутив, в котором будет всё необходимое для этого? Или попытаться уговорить разработчиков ASP Улыбка

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

Между прочим, webmin уже давно написан. И для тех приложений, которые умеют работать с LDAP, и для многих других и даже для доступа собственно в LDAP. Централизация необычайная, веб-интерфейс, группа пользователей обширная, проект развивается - никаких проблем. Причем, именно этот вариант рекомендуют разработчики ASP по дефолту. Так зачем изобретать интеграцию на уровне хранения данных и протокола доступа к ней, когда в большинстве случаев достаточно интеграции на уровне административного интерфейса? Тем более, что такого охвата, как webmin всё равно достигнуть не получится...

Кстати, про доступ к LDAP - есть софтина, которая называется luma: [luma.sourceforge.net]
Интерфейс мне очень понравился, функциональность тоже радует приятно. У меня с ней, правда затыка получилась непонятная (впрочем как и с модулем webmin Грустный ). Почему-то не хочет она подключаться через TLS иначе, как аноним. А GQ-нормально работает и консольные команды тоже... "Рекбус, кроксворд" (с)
Re: Про LDAP и авторизацию в домене 02.10.2006 19:14DRVTiny ---
Кстати, про доступ к LDAP - есть софтина, которая называется luma: [luma.sourceforge.net]
---
Софтина красивая, но какая-то очень уж глючная... Во всяком случае, у меня с ней незаладилось. А вот GQ более стабилен, на мой взгляд, к тому же позволяет целые ветки Drag&Drop'ать с места на место, схемы показывает в очень удобном виде. Правда, в последней версии (та, что в 20-х числах сентября вышла) есть какой-то глюк с сохранением пароля для авторизации на сервере Грустный

---
Между прочим, webmin уже давно написан. И для тех приложений, которые умеют работать с LDAP, и для многих других и даже для доступа собственно в LDAP
---
И всё равно ни один конфигуратор не даст возможности проконтроллировать абсолютно все параметры. К тому же по собственному опыту я знаю, что при создании программ, читающих/изменяющих конфиги приходится в 80 случаях из 100 закрывать глаза на то, что злокозненный юзер вполне может в эти конфиги залезть своими корявыми админскими ручками и что-нибудь там напортачить, т.е. приходится исходить из того, что конфиг 100%-но "кондиционен". Если конфигурационный файл правится только соотв. утилитой, то проблем никаких не возникает, но если предполагается, что изменения могут вноситься несогласованно пользователем и конфигуратором, тот тут уже приходится строить заумный анализатор синтаксических и пунктуационных ошибок в дополнение к и без того геморойному коду парсера (если конфиг не очень примитивный), что, сами понимаете, можно позволить себе лишь один раз в жизни (первый и последний). Опять же, форматы многих кнфигов постоянно меняются, добавляются новые параметры, анулируются старые и всё это для разработчика конфигуратора становится постоянной головной болью, от которой он чаще всего избавляется очень просто: бросает разработку и занимается более интересными для себя вещами.
С LDAP'ом всё проще: фактически тот же GQ - это аналог **не конфигуратора, а текстового редактора**, при использовании которого в специальных программах-надстройках aka конфигураторах отпадает всякая необходимость: данные и так представлены в очень наглядной форме (чем-то на ежедневник похоже), потенциальная возможность сделать синтаксическую ошибку сведена к минимуму, при чём для редактирования доступны **все** без исключения параметры.
Впрочем, есть у LDAP и очевидные недостатки: это в первую очередь довольно-таки кривая система ACL (я с этим намучался в своё время, да и сейчас мне не больно-то понятно, как эти клятiе ACL работают), искусственно притянутая за уши необходимость организации стека objectClass'ов для привязки к top (которую в большинстве случаев очень легко обойти), совершенно сырая система alias'ов (ссылки на DN'ы).
---
Причем, именно этот вариант рекомендуют разработчики ASP по дефолту
---
Это не критерий. Если бы разработчики Fedora что-то рекомендовали по default'у, это воспринималось бы несколько иначе. Собственно, ASPLinux занимается оказанием услуги по доработке Fedora до юзабельного состояния. Непосредственно с OpenSource-сообществом разработчиков они практически не соприкасаются, потому что это всё-таки дистрибутив "второго звена", а не полностью оригинальный продукт.
---
Вместо того, чтобы другу/знакомому посоветовать "измени в конфиге
таком-то такую-то строчку и перезапусти сервис", вы будете
объяснять, что "нужно скачать патчик к dhcp с этого сайта, а
схему для лдапа с того
---
Не так всё мрачно на самом деле. Разработчикам дистрибутивов никто не мешает собирать бинарники dhcpd с этим патчем (насколько я знаю, в OpenSuSE он уже есть), сам по себе процесс наложения патча здесь не сопряжён с какими-либо трудностями, а упомянутая Вами схема уже в этот патч включена. Парсеры тоже есть комплекте, при чём работают они на мой взгляд просто отлично. Вообще если бы это был не патч, а часть официальной ветки, то я бы сказал, что в dhcpd поддержка LDAP реализована безупречно. Это Вам не утилиты от IDEALX'а, которые при малейшем несоответствии конфигурации, описанной в HOWTO, начинают работать абы как, так что за каждым чихом приходится непосредственно в базу лезть руками.
Re: Про LDAP и авторизацию в домене 02.10.2006 19:25DRVTiny **2dvc**
А как всё-таки у Вас записи компов выглядят? В смысле, стек objectClass'ов какой?
Re: Про LDAP и авторизацию в домене 03.10.2006 09:14dvc Вот урезанный дамп всей базы (сходные записи я почистил). Кое-где по тексту мои комментарии:
---
#ldapsearch -x -b 'o=Teletrade' -D "cn=ldaproot,o=Teletrade" '(objectclass=*)' -H ldap://pdc.tts.loc -W -ZZ
Password:

# extended LDIF
#
# LDAPv3
# base <o=Teletrade> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#

# Teletrade
dn: o=Teletrade
objectClass: organization
o: Teletrade
description: Teletrade Dow Jones International Consulting Ltd.

# SAM, Teletrade
dn: ou=SAM,o=Teletrade
objectClass: organizationalUnit
ou: SAM
description: Teletrade-Samara Ltd.
telephoneNumber: +7 846 270-85-29
telephoneNumber: +7 846 332-10-94
facsimileTelephoneNumber: +7 846 332-10-94
facsimileTelephoneNumber: +7 846 270-85-29

# Users, SAM, Teletrade
dn: ou=Users,ou=SAM,o=Teletrade
objectClass: organizationalUnit
ou: Users

# Groups, SAM, Teletrade
dn: ou=Groups,ou=SAM,o=Teletrade
objectClass: organizationalUnit
ou: Groups

# Computers, SAM, Teletrade (не используется все записи храню в Users - их у меня не так много).
dn: ou=Computers,ou=SAM,o=Teletrade
objectClass: organizationalUnit
ou: Computers

# ldaproot, Teletrade
dn: cn=ldaproot,o=Teletrade
objectClass: organizationalRole
objectClass: top
objectClass: simpleSecurityObject
cn: ldaproot
description: LDAP root account
userPassword:: здесь будет ваш пароль шифрованный в base64

# DSA, SAM, Teletrade
dn: ou=DSA,ou=SAM,o=Teletrade
objectClass: organizationalUnit
objectClass: top
ou: DSA
description: security accounts for LDAP clients

# samba, DSA, SAM, Teletrade
dn: cn=samba,ou=DSA,ou=SAM,o=Teletrade
objectClass: organizationalRole
objectClass: top
objectClass: simpleSecurityObject
cn: samba
userPassword:: здесь будет ваш пароль шифрованный в base64

# nssldap, DSA, SAM, Teletrade
dn: cn=nssldap,ou=DSA,ou=SAM,o=Teletrade
objectClass: organizationalRole
objectClass: top
objectClass: simpleSecurityObject
cn: nssldap
userPassword:: здесь будет ваш пароль шифрованный в base64

# smbldap-tools, DSA, SAM, Teletrade
dn: cn=smbldap-tools,ou=DSA,ou=SAM,o=Teletrade
objectClass: organizationalRole
objectClass: top
objectClass: simpleSecurityObject
cn: smbldap-tools
userPassword:: здесь будет ваш пароль шифрованный в base64

# NextFreeUnixId, SAM, Teletrade
dn: cn=NextFreeUnixId,ou=SAM,o=Teletrade
objectClass: inetOrgPerson
objectClass: sambaUnixIdPool
gidNumber: 10003
cn: NextFreeUnixId
sn: NextFreeUnixId
uidNumber: 10036


# demo-01$, Users, SAM, Teletrade
dn: uid=demo-01$,ou=Users,ou=SAM,o=Teletrade
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: shadowAccount
objectClass: sambaSamAccount
uid: demo-01$
cn: computer demo-01$
sn: demo-01$
userPassword:: здесь будет ваш пароль шифрованный в base64
uidNumber: 10001
gidNumber: 10002
gecos: computer demo-01$
homeDirectory: /var/lib/nobody
loginShell: /bin/false
shadowLastChange: 13355
shadowMax: 99999
shadowWarning: 7
sambaSID: S-1-5-21-941162000-3647038200-3780497556-21002
sambaAcctFlags: [W ]
sambaPwdCanChange: 1158858973
sambaPwdMustChange: 2147483647
sambaNTPassword: Здесь пароль шифрованный самбой
sambaPwdLastSet: 1158858973

# demo, Users, SAM, Teletrade
dn: uid=demo,ou=Users,ou=SAM,o=Teletrade
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: shadowAccount
objectClass: sambaSamAccount
uid: demo
cn: Study clients Account
sn: Account
uidNumber: 10009
gidNumber: 10000
gecos: Study clients Account
homeDirectory: /home/demo
loginShell: /bin/bash
shadowLastChange: 13371
shadowMax: 99999
shadowWarning: 7
sambaSID: S-1-5-21-941162000-3647038200-3780497556-21018
sambaPwdCanChange: 1158857811
sambaPwdMustChange: 2147483647
sambaLMPassword: здесь пароль шифрованный самбой
sambaNTPassword: здесь пароль шифрованный самбой
sambaPasswordHistory: 00000000000000000000000000000000000000000000000000000000
00000000
sambaPwdLastSet: 1158857811
sambaAcctFlags: [U ]
userPassword:: здесь пароль шифрованный в base64

# smb_users, Groups, SAM, Teletrade
dn: cn=smb_users,ou=Groups,ou=SAM,o=Teletrade
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: smb_users
userPassword:: e2NyeXB0fXg=
gidNumber: 10000
sambaSID: S-1-5-21-941162000-3647038200-3780497556-21001
sambaGroupType: 2

# smb_mashines, Groups, SAM, Teletrade
dn: cn=smb_mashines,ou=Groups,ou=SAM,o=Teletrade
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: smb_mashines
userPassword:: e2NyeXB0fXg=
gidNumber: 10002
memberUid: real-01$
memberUid: dlin-02$
memberUid: demo-01$
memberUid: real-08$
memberUid: demo-05$
sambaSID: S-1-5-21-941162000-3647038200-3780497556-21005
sambaGroupType: 2

# root, Users, SAM, Teletrade
dn: uid=root,ou=Users,ou=SAM,o=Teletrade
cn: root
sn: root
objectClass: inetOrgPerson
objectClass: sambaSamAccount
objectClass: posixAccount
objectClass: shadowAccount
gidNumber: 0
uid: root
uidNumber: 0
homeDirectory: /root
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647
sambaHomePath: \\PDC\root
sambaHomeDrive: H:
sambaPrimaryGroupSID: S-1-5-21-941162000-3647038200-3780497556-512
sambaSID: S-1-5-21-941162000-3647038200-3780497556-500
loginShell: /bin/false
gecos: Netbios Domain Administrator
sambaLMPassword: здесь пароль шифрованный самбой
sambaNTPassword: здесь пароль шифрованный самбой
userPassword:: здесь пароль шифрованный base64
sambaPwdMustChange: 2147483647
sambaPasswordHistory: 00000000000000000000000000000000000000000000000000000000
00000000
sambaAcctFlags: [U ]
sambaPwdCanChange: 1158858428
sambaPwdLastSet: 1158858428

# nobody, Users, SAM, Teletrade
dn: uid=nobody,ou=Users,ou=SAM,o=Teletrade
cn: nobody
sn: nobody
objectClass: inetOrgPerson
objectClass: sambaSamAccount
objectClass: posixAccount
objectClass: shadowAccount
gidNumber: 514
uid: nobody
uidNumber: 9999
homeDirectory: /dev/null
sambaPwdLastSet: 0
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647
sambaPwdCanChange: 0
sambaPwdMustChange: 2147483647
sambaHomePath: \\PDC obody
sambaHomeDrive: H:
sambaPrimaryGroupSID: S-1-5-21-941162000-3647038200-3780497556-514
sambaLMPassword: NO PASSWORDXXXXXXXXXXXXXXXXXXXXX
sambaNTPassword: NO PASSWORDXXXXXXXXXXXXXXXXXXXXX
sambaAcctFlags: [NUD ]
sambaSID: S-1-5-21-941162000-3647038200-3780497556-2998
loginShell: /bin/false

# Domain Admins, Groups, SAM, Teletrade (здесь и далее нужные группы для самбы. gid-ы пока неправильные... ничему не соответствующие. Надо поправить на досуге.)
dn: cn=Domain Admins,ou=Groups,ou=SAM,o=Teletrade
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 512
cn: Domain Admins
memberUid: root
description: Netbios Domain Administrators
sambaSID: S-1-5-21-941162000-3647038200-3780497556-512
sambaGroupType: 2
displayName: Domain Admins

# Domain Users, Groups, SAM, Teletrade
dn: cn=Domain Users,ou=Groups,ou=SAM,o=Teletrade
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 513
cn: Domain Users
description: Netbios Domain Users
sambaSID: S-1-5-21-941162000-3647038200-3780497556-513
sambaGroupType: 2
displayName: Domain Users

# Domain Guests, Groups, SAM, Teletrade
dn: cn=Domain Guests,ou=Groups,ou=SAM,o=Teletrade
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 514
cn: Domain Guests
description: Netbios Domain Guests Users
sambaSID: S-1-5-21-941162000-3647038200-3780497556-514
sambaGroupType: 2
displayName: Domain Guests

# Domain Computers, Groups, SAM, Teletrade
dn: cn=Domain Computers,ou=Groups,ou=SAM,o=Teletrade
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 515
cn: Domain Computers
description: Netbios Domain Computers accounts
sambaSID: S-1-5-21-941162000-3647038200-3780497556-515
sambaGroupType: 2
displayName: Domain Computers

# Administrators, Groups, SAM, Teletrade (здесь и далее локальные группы. я их не использую и даже gid-ы правильно привязать еще руки не дошли)
dn: cn=Administrators,ou=Groups,ou=SAM,o=Teletrade
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 544
cn: Administrators
description: Netbios Domain Members can fully administer the computer/sambaDom
ainName
sambaSID: S-1-5-32-544
sambaGroupType: 5
displayName: Administrators

# Account Operators, Groups, SAM, Teletrade
dn: cn=Account Operators,ou=Groups,ou=SAM,o=Teletrade
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 548
cn: Account Operators
description: Netbios Domain Users to manipulate users accounts
sambaSID: S-1-5-32-548
sambaGroupType: 5
displayName: Account Operators

# Print Operators, Groups, SAM, Teletrade
dn: cn=Print Operators,ou=Groups,ou=SAM,o=Teletrade
objectClass: posixGroup
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 550
cn: Print Operators
description: Netbios Domain Print Operators
sambaSID: S-1-5-32-550
sambaGroupType: 5
displayName: Print Operators

# Backup Operators, Groups, SAM, Teletrade
dn: cn=Backup Operators,ou=Groups,ou=SAM,o=Teletrade
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 551
cn: Backup Operators
description: Netbios Domain Members can bypass file security to back up files
sambaSID: S-1-5-32-551
sambaGroupType: 5
displayName: Backup Operators

# Replicators, Groups, SAM, Teletrade
dn: cn=Replicators,ou=Groups,ou=SAM,o=Teletrade
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 552
cn: Replicators
description: Netbios Domain Supports file replication in a sambaDomainName
sambaSID: S-1-5-32-552
sambaGroupType: 5
displayName: Replicators
---

в таком виде уже работает.
Re: Про LDAP и авторизацию в домене 03.10.2006 10:05DRVTiny Спасибо, **dvc**!
Посмотрел Вашу базу... Очень интересно.
А как Вы ею управляете? Вроде не похоже, что Вы активно используете утилиты IDEALX'а (smbldap-tools), хотя у Вас и есть такой DSA-аккаунт.
Честно говоря, больше всего меня заинтересовала вот эта запись:
---
# NextFreeUnixId, SAM, Teletrade
dn: cn=NextFreeUnixId,ou=SAM,o=Teletrade
objectClass: inetOrgPerson
objectClass: sambaUnixIdPool
gidNumber: 10003
cn: NextFreeUnixId
sn: NextFreeUnixId
uidNumber: 10036
---
Как Вы ею пользуетесь? У Вас собственные скрипты для добавления ползователей/машин или smbldap-tool'ы с такой записью тоже могут работать? Дело в том, что у меня следующие gidNumber и uidNumber хранятся вместе с записью самого домена (там, где его SID указывается).
Re: Про LDAP и авторизацию в домене 03.10.2006 10:46dvc С ходу и не вспомнил Улыбка

---
#cat /etc/smbldap-tools/smbldap.conf
...

# Where to store next uidNumber and gidNumber available for new users and groups
# If not defined, entries are stored in sambaDomainName object.
# Ex: sambaUnixIdPooldn="sambaDomainName=${sambaDomain},${suffix}"
# Ex: sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}"
#sambaUnixIdPooldn="sambaDomainName=TTS,${suffix}"
sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}"

...
---

Редактировать записи активно просто не приходилось еще. Только пара тестов. Изначально, для того, чтобы взять LDAP "железным задом" (ну тяжело мне было понять принципы работы этой штуковины, да еще по англоязычным источникам - у каждого на свою тему тормоза), я слово в слово проделал всё по Linux Samba-OpenLDAP Howto с IDEALX... Потом, натолкнувшись на то, что я совершенно не понимаю, что делаю, а соотв., и того, что делаю неправильно, обратился к IBM RedBook "Undestanding LDAP" (есть на [www.ldapzone.spb.ru]). Потом распечатал все, имеющиеся в наличии схемы и подкрасил их маркерами, чтобы нагляднее было. Потом опять вернулся к IDEALX и смог разобраться - где глюки скриптов, а где глючил я. Даже с шифрованием всё сделать получилось. Но ldif-ы доводил руками, чтобы запомнилось лучше. Впрочем, поковырялся и с GQ и с webmin-модулем и с lumа со всеми по чуть-чуть. Явного предпочтения пока не сделал. А GQ у меня оказалась очень старая бетта-версия (соотв. глючная) - сегодня новую качнул, скомпилю на днях и посмотрим.

Самое главное, что основные операции с существующими posix-аккаунтами делаются теми же утилитами, что и обычно... Т.е. прозрачно для большинства юзеров и приложений!
RSS-материал