Размещаем пользовательские бюджеты в LDAP::Журнал СА 1.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 5101
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6343
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7599
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7922
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6978
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Размещаем пользовательские бюджеты в LDAP

Архив номеров / 2007 / Выпуск №1 (50) / Размещаем пользовательские бюджеты в LDAP

Рубрика: Администрирование /  Администрирование

Алексей Барабанов

Размещаем пользовательские бюджеты в LDAP

Часть 1

Эта тема имеет столько способов реализации, сколько авторов. Но типичные ошибки повторяются от раза к разу. Попробуем построить среду для хранения пользовательских бюджетов в LDAP оптимальным образом.

Считается, что в данном вопросе уже нет ничего неясного. Счет вариантов настройки, предлагаемых, например, на www.opennet.ru, давно уже идет на десятки. Все авторы торопливо пробегают базовые элементы установок сервера и клиента и с триумфом подают «главное блюдо» – настройку приложений для работы с LDAP. Но, хотя приложения меняются, но именно основные настройки, копируемые авторами друг у друга, содержат спорные решения, которые никто и не пытается совершенствовать. Не говоря уже о том, что в базовых настройках надо выдержать тот минимум управляющих директив, который ни на йоту не уменьшит безопасность системы, основанной на LDAP, и одновременно не будет содержать каких-либо излишеств.

Рассмотрим все это подробнее.

В качестве рабочей среды выберем openSUSE 10.1 и 10.2, и будем использовать все пакеты, в них включенные. Например, под LDAP далее станем понимать реализацию OpenLDAP, поставляемую в указанных дистрибутивах, а именно openldap2-2.3.19-18.10 для openSUSE 10.1 и openldap2-2.3.27-25 для openSUSE 10.2.

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

Для сравнения предлагаю вам обратиться к одному из самых светлых документов на эту тему [1]. Светлых потому, что это руководство принадлежит к тому небольшому числу работ, где видно, что авторы очень хорошо понимают, о чем идет речь. Но и их мы тоже немножечко по ходу изложения поправим.

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

И вот с этого места начнем работу.

Зачем нужен LDAP

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

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

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

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

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

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

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

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

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

Установка сервера OpenLDAP

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

Это можно сделать следующим образом:

# L="" ; \

P="openldap2 openldap2-client samba-client samba smbldap-tool perl-ldap nss_ldap pam_ldap" ; \

   for i in $P ; \

   do rpm -qa | grep $i || L="$L $i" ; done ; \

   [ -z "$L" ] || echo yast2 -i $L

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

К сожалению, на доступном сейчас openSUSE GM 10.2 нет пока smbldap-tools, и это пакет придется заимствовать из дистрибутива openSUSE версии 10.1 и доставить ортодоксальным способом «rpm -ivh ...».

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

Итак, понадобятся openldap2 и его клиент, библиотеки и модули для настройки работы системной АиА на основе LDAP – nss_ldap, pam_ldap, и samba3 вместе с парой дополнительных пакетов, которые упростят настройку самой базы LDAP и обеспечат дальнейшую интеграцию с samba. Perl-ldap необходим для smbldap-tools.

Бывает так, что ситуация имеет прямо противоположный характер, то есть уже есть и как-то работает LDAP с настройками, которые следует изменить. Тогда надо остановить процесс slapd и удалить старую базу из /var/lib/ldap:

# rcldap stop

# I=/var/lib/ldap ; \

    for i in $(ls -1 $I | grep -v ^DB_CONFIG) ; \

    do rm -f $I/$i ; done

Кстати, то же самое можно сделать, если что-то не понравится после установки, выполненной по рекомендациям настоящей статьи.

Теперь все готово к настройке. Все используемые сервером конфигурационные файлы лежат в /etc/openldap.

Здесь самое время вспомнить о первом требовании к хранилищу бюджетов. Используемая в АиА база данных должна содержать все необходимые для работы поля. То есть надо в перечне включаемых схем указать те, что содержат требуемые структуры.

Прежде всего, core.schema и cosine.schema – это минимум-миниморум для работы LDAP, на определения этих схем ссылаются практически все остальные

Далее rfc2307bis.schema, которая, собственно, содержит определения для класса posixAccount, содержащего эквиваленты всем используемым в стандартной АиА полям. Эта схема пришла на смену ранее используемой nis.schema.

Затем то, что позволит добавить дополнительные данные к определениям бюджетов – inetorgperson.schema.

Немного полезного для работы почтового сервера – misc.schema.

И, наконец, поместим в базу поля, требуемые для работы samba3 – samba3.schema, так как далее это позволит с помощью smbldap-tools провести инициализацию базы.

Конечно же, все подключенные схемы должны быть доступны в момент старта сервера, например, размещены в /etc/openldap/schema или в другом месте, что, конечно же, должно быть отражено в файле конфигурации сервера.

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

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

Практически верным следует считать правило выбирать в качестве корня искусственно придуманное имя внутреннего домена. Единственно, это имя должно быть уникальным внутри локальной системы и не иметь аналогов за ее пределами примерно так же, как и всякий внутренний домен DNS не должен пересекаться с внешними, чтобы не маскировать их.Например, очень удобно выбрать для построения корня имя «office.localnet». Тогда суффиксом будет «dc=office,dc=localnet». Некоторыми источниками, особенно описывающими настройку ActiveDirectory, куда LDAP входит как составная часть, предлагается использовать в качестве суффикса реальный домен Интернета, например почтовый – kontora.ru. Это совершенно не верно. Внутренняя среда, определяемая значением корня, должна быть искусственно изолированной от внешней, а все пути трансляции прямо указываться и контролироваться. Такое построение исключит случайности и строго ограничит контакты, что увеличит безопасность внутренней системы. Никаких проблем с приемом почты или с резолвингом доменных имен в таком случае не возникнет. Напротив, предотвратит случайное их пересечение, которое может создать трудно устраняемые ошибки.

Структура дерева LDAP

Структура дерева LDAP

Для разграничения доступа к полям базы LDAP используются специально заданные правила. Эти правила, так же как и права доступа к файлам традиционной системы АиА, таким как /etc/passwd, /etc/shadow и другим, защищают данные от неправомерного доступа. При этом такая система подразумевает, что определение прав происходит по принадлежности запроса определенному пользователю. То есть сначала пользователь пройдет этап аутентификации, и тогда его запрос будет должным образом авторизован.

Но тут заключена логическая проблема. Поскольку сама система LDAP предназначена для использования в механизме АиА, то на начальном этапе, пока база пуста, ни одно заданное правило ограничения доступа не может быть выполнено в принципе. И поэтому для «раскручивания» базы LDAP на этапе инициализации используется так называемый rootdn – псевдопользователь, который имеет абсолютный доступ ко всем полям и всем записям базы вне зависимости от настроек ограничений доступа. Существование этого пользователя «вшито» в бинарные файлы. Его учетную запись не надо специально создавать в базе и его нельзя запретить. Но так как существование подобного абсолютного пользователя является прямым нарушением иерархии разграничения доступа, то есть единственная возможность заблокировать его работу – не указывать его отличительное имя и пароль, чтобы сервер LDAP не смог провести аутентификацию, если даже такой запрос поступит. Но на начальном этапе без rootdn практически не обойтись и пусть его отличительное имя будет «cn=ldaproot,dc=office,dc=localnet».

Поскольку после завершения инициализации rootdn будет заблокирован, то для регулярной работы надо предусмотреть специальные LDAP-бюджеты. Эти бюджеты будут использоваться лишь для организации работы подсистем, запрашивающих данные из базы LDAP, в рамках выделенных для них полномочий. Например, предусмотрим специального искусственного пользователя, от имени которого могут работать утилиты АиА ldapadmin c отличительным именем «cn=ldapadmin,dc=office,dc=localnet», которому дадим права читать и изменять все поля базы, включая парольные хеши.

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

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

# SUFFIX="dc=office,dc=localnet" ; \

   LDAPROOT="ldaproot" ; \

   ROOTDN="cn=$LDAPROOT,$SUFFIX" ; \

   ROOTPW="secret" ; \

   LDAPADMIN="ldapadmin" ; \

   ADMINDN="cn=$LDAPADMIN,$SUFFIX" ; \

   ADMINPW="admin" ; \

   SCHEMA='{SSHA}' ; \

   T=$(slappasswd -s $ROOTPW -h $SCHEMA) ; \

    cat >/etc/openldap/slapd.conf<<EOT

include         /etc/openldap/schema/core.schema

include         /etc/openldap/schema/cosine.schema

include         /etc/openldap/schema/inetorgperson.schema

include         /etc/openldap/schema/rfc2307bis.schema

include         /etc/openldap/schema/misc.schema

include         /etc/openldap/schema/samba3.schema

#

schemacheck on

#

pidfile          /var/run/slapd/slapd.pid

argsfile         /var/run/slapd/slapd.args

replogfile     /var/lib/ldap/replica.log

loglevel        0

#

allow bind_v2

#

# Load dynamic backend modules:

modulepath      /usr/lib/openldap/modules

#

# ACL's definitions

access to attrs=userPassword,userPKCS12

        by self write

        by dn="$ADMINDN" write

        by * auth

access to attrs=shadowLastChange

        by self write

        by dn="$ADMINDN" write

        by * read

access to *

        by dn="$ADMINDN" write

        by self write

        by * read

defaultaccess read

#

# BD's definitions

database        bdb

suffix          "$SUFFIX"

checkpoint      1024    5

cachesize       10000

rootdn          "$ROOTDN"

rootpw          $T

directory       /var/lib/ldap

#

# Indices to maintain

index   objectClass     eq

index   cn              pres,sub,eq

index   sn              pres,sub,eq

index   uid             pres,sub,eq

index   displayName     pres,sub,eq

index   uidNumber       eq

index   gidNumber       eq

index   memberUid       eq

index   sambaSID        eq

index   sambaPrimaryGroupSID    eq

index   sambaDomainName eq

index   default         sub

EOT

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

В openSUSE стартовый скрипт использует параметры из файла /etc/sysconfig/openldap. Настроим их так, чтобы сервер LDAP прослушивал лишь внутренний петлевой интерфейс lo:

# LDAPSERVER=127.0.0.1 ; \

   LDAPPORT=389 ; \

   LDAPINT="$LDAPSERVER:$LDAPPORT" ; \

   I=/etc/sysconfig/openldap ; \

   sed "/^OPENLDAP_LDAP_INTERFACES/c\

OPENLDAP_LDAP_INTERFACES=\"$LDAPINT\"" $I >$I.$$.tmp ; \

   mv $I.$$.tmp $I

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

После настройки /etc/sysconfig/openldap проверим правильность настроек, запустив сервер:

# rcldap start

# LDAPSERVER=127.0.0.1 ; \

   LDAPPORT=389 ; \

   LDAPINT="$LDAPSERVER:$LDAPPORT" ; \

  netstat -apn | grep "LISTEN.*slapd" | \

  grep $LDAPINT >/dev/null 2>&1 || echo «увы, не работает!»

Если печальное сообщение не последовало, то можно включать сервер LDAP в режим автоматического запуска «chkconfig --add ldap».

В противном случае надо закомментировать строчку «loglevel 0», произвести перезапуск LDAP и посмотреть, что является причиной неудачи в протоколе /var/log/messages. После исправления ошибок следует снова вернуть параметр loglevel, так как в противном случае протоколы системы будут просто забиваться огромным числом сообщений от сервера LDAP, участвующем в каждом процессе аутентификации.

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

Иначе говоря, ищите опечатки!

Настройка клиента

Теперь, когда в системе есть доступный LDAP-сервер, можно приступить к настройке клиентской части.

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

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

В качестве подобных ключевых библиотек, которые настраиваются на получение данных из LDAP, очень выгодно применять nss и pam. Две эти подсистемы практически на 100% позволяют воспользоваться преимуществами LDAP, совершенно не изменяя другие аутентификационные подсистемы, входящие в целевые пакеты, например в courier-imap. Иначе говоря, именно nss и pam далее и будут настраиваться.

В openSUSE библиотеки nss и pam читают свои настройки из одного и того же файла /etc/ldap.conf. Что очевидно, так как они фактически предоставляют информацию одним и тем же программам на разных этапах их работы. Путь к этому файлу «зашит» в самих библиотеках. Можно проверить его точное значение в системах, где эта истина не очевидна, например для nss:

# strings $(rpm -ql nss_ldap | grep lib) | grep ldap.conf

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

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

Конфигурацию нашего клиента создадим следующим образом:

# LDAPSERVER=127.0.0.1 ; \

   LDAPPORT=389 ; \

   LDAPINT="$LDAPSERVER:$LDAPPORT" ; \

   SUFFIX="dc=office,dc=localnet" ; \

   cat <<EOT >/etc/ldap.conf

host $LDAPINT

base $SUFFIX

#

# Don't try forever if the LDAP server is not reacheable

bind_policy soft

# RFC2307bis naming contexts

nss_base_passwd ou=People,$SUFFIX?one

nss_base_shadow ou=People,$SUFFIX?one

nss_base_group ou=Group,$SUFFIX?one

nss_base_hosts          ou=Hosts,$SUFFIX?one

nss_base_services       ou=Services,$SUFFIX?one

nss_base_networks       ou=Networks,$SUFFIX?one

nss_base_protocols      ou=Protocols,$SUFFIX?one

nss_base_rpc            ou=Rpc,$SUFFIX?one

nss_base_ethers ou=Ethers,$SUFFIX?one

nss_base_netmasks       ou=Networks,$SUFFIX?one

nss_base_bootparams     ou=Ethers,$SUFFIX?one

nss_base_aliases        ou=Aliases,$SUFFIX?one

nss_base_netgroup       ou=Netgroup,$SUFFIX?one

# attribute/objectclass mapping

# Syntax:

nss_map_attribute       rfc2307attribute        mapped_attribute

nss_map_objectclass     rfc2307objectclass      mapped_objectclass

#

ldap_version    3

ssl     no

#

# pam

pam_password    exop

pam_filter      objectclass=posixAccount

pam_login_attribute     uid

pam_member_attribute    memberUid

EOT

Обращаю внимание – никаких паролей в этом файле не содержится! Всякое упоминание в этом файле специальных пользователей и их паролей свидетельствует о неверной настройке ограничений доступа в LDAP. Часто из-за невозможности работать c установленными правами на объекты базы LDAP от имени обычных пользователей прибегают к использованию или специального пользователя с полными правами на всю базу, или, что еще хуже, просто заставляют клиента соединяться с LDAP-сервером как rootdn, все это лишь от нежелания разобраться в сущности происходящего.

Для того чтобы заставить систему обращаться к LDAP в поиске идентификационных данных, настроим службу nss. Эта служба управляется с помощью своего конфигурационного файла /etc/nsswitch.conf, в котором задаются пути поиска информации в системе.

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

# cat <<EOT >$/etc/nsswitch.conf.tmp

passwd: compat

shadow: files

group:  compat

services:       files ldap

netgroup:       files ldap

aliases:        files ldap

passwd_compat:  ldap

group_compat:   ldap

EOT

# grep -v "^\(#\|$\|passwd\|shadow\|group\|services\|netgroup\|aliases\)" \

   /etc/nsswitch.conf >>/etc/nsswitch.conf.tmp

# mv /etc/nsswitch.conf.tmp /etc/nsswitch.conf

Вот теперь во всех актуальных для нас путях указано искать еще и в LDAP, а для passwd и group назначен специальный совместимый режим, в котором также добавлен путь поиска в LDAP.

Здесь очень важно, что поиск shadow остался только в файловой базе. Это верно, тут нет ошибки. Так как shadow это не просто база, это совершенно конкретный алгоритм хранения хешей. И подменять его на LDAP не следует. Тем более не надо делать такого «винегрета» – shadow: tcb ldap files nisplus nis, как указано в [1]. Пусть все парольные хеши, что доставляются из shadow, останутся оригинальными. Pam сможет и так воспользоваться хешами из LDAP, а применение nss для доступа к хешам заставит использовать самые простейшие из криптоалгоритмов. Подробнее об этом в [2].

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

На этапе проверки механизмов функционирования nss следует отключить кэширование запросов «rcnscd stop». Это позволит проверять работу системы сразу же после ее модификации. В штатном режиме Name Service Cache Daemon будет работать как следует.

Последнее, что осталось в настройке АиА, – переключить pam в режим работы с LDAP. В openSUSE применяется исключительно оригинальный механизм подключения LDAP в pam. Вместо традиционного указания порядка и преимущества использования разных источников АиА-информации применяется композитный модуль pam_unix2, который имеет собственный конфигурационный файл. То есть вместо настройки общих системных файлов в /etc/pam.d используется /etc/security/pam_unix2.conf.

Кроме неявной политики указания очередности поиска, что очень подробно критикуется в [2], такой подход создает еще и лишнюю точку настройки. Самое смешное, что вплоть до релиза 10.1 pam_unix2 искал свой собственный файл настроек, а вот, начиная с openSUSE 10.2, он уже его не ищет, а снова принимает параметры из традиционных файлов /etc/pam.d. Но для управления ими теперь стала применяться утилита pam-config, которая согласно каким-то своим, прописанным в ее бинарном коде, правилам создает конфигурационные файлы для подсистемы pam.

Но и тут не без юмора: эта утилита, которую написал тот же автор, что и pam_unix2 – Thorsten Kukuk, поддерживает pam_unix2.conf, несмотря на то, что сам pam_unix2 уже не имеет этого конфигурационного файла. Изучение исходного текста позволяет узнать, что лишь с целью обратной совместимости. Откровением будет то, что параметр use_ldap для pam_unix2 с помощью этой утилиты не подставить никак. То есть можно предположить, что в самом ближайшем будущем этот ключ пропадет и в самом pam_unix2. Иначе говоря, в SUSE, начиная с версии 10.2, для работы с LDAP предполагается использовать традиционный для остальных дистрибутивов pam_ldap. К сожалению, как и многое в SUSE, это решение не получило грамотного технологического воплощения. Да и вопрос, зачем тогда нужен pam_unix2, если есть опять же традиционный pam_unix, остается открытым.

Итак, для openSUSE 10.1 исправляем настройки pam_unix2 и тем самым решаем все проблемы:

# cat <<EOT >/etc/security/pam_unix2.conf

auth:   use_ldap

account:        use_ldap

password:       use_ldap

session:        none

EOT

Для openSUSE 10.2 можно применить такой же «силовой» вариант и просто дописать в каждую строку вызова pam_unix2 параметр use_ldap :

#!/bin/sh

for i in /etc/pam.d/common-* ; do

    [ -L $i ] || {

      echo $i | grep -v backup$ >/dev/null && {

        grep "pam_unix2" $i >/dev/null && {

          sed '/pam_unix2/s/$/use_ldap/' $i >$i.$$.tmp

          mv $i.$$.tmp $i

          }

        }

      }

done

Можно еще выполнить «pam-config -a --ldap» и получить конфигурацию, которая будет почти работоспособной. И даже воспользоваться такой настройкой ..., если, точнее, когда будут исправлены описки в pam-config. А пока прибегнем к описанному выше способу с использованием параметра use_ldap, так как нашей целью является создание нужной конфигурации оптимальным путем, а не бесконечное исправление ошибок разработчиков. Обладатели дистрибутивов, отличных от openSUSE, могут взять вариант настроек pam из [1], опять же с поправкой на особенности включенных в дистрибуцию утилит.

Осталось добавить специальные разделители в те файловые базы, которые, как было указано выше, работают в режиме совместимости (compat):

# grep "^+:::" /etc/passwd >/dev/null || echo "+::::::" >>/etc/passwd

# grep "^+:::" /etc/group >/dev/null || echo "+:::" >>/etc/group

Все, теперь настройка клиента завершена.

Инициализация базы LDAP

Как уже было сказано ранее, в этом процессе нам поможет пакет smbldap-tools. Безусловно, можно обойтись и без него. Но так мы сократим работу за счет автоматизации части операций.

Пакет smbldap-tools представляет собой набор программ, которые помогают манипулировать учетными записями, размещенными в LDAP. Все эти программы используют единый конфигурационный файл /etc/smbldap-tools/smbldap.conf, который надо перед началом работы отредактировать или создать заново, что в данном случае проще. Параметры, важные в настройке, определяют сетевой адрес, на котором доступен сервер LDAP, суффикс базы и некоторые параметры, специфичные для PDC, который можно организовать в случае необходимости с помощью samba3 и той базы LDAP, что будет проинициализирована. Кроме уже ранее обсуждавшихся параметров добавились: имя домена NT, имя сервера, почтовый домен (кстати, опять же не имеющий никакого отношения к реально получаемой почте) и так называемый SID, который используется в построении учетных номеров домена NT. Если далее не планируется использовать samba на этом хосте, то все перечисленные параметры можно назначить достаточно произвольно. Итак, сделаем это:

# NT4DOM="Office" ; \

   LDAPSERVER=127.0.0.1 ; \

   LDAPPORT=389 ; \

   SUFFIX="dc=office,dc=localnet" ; \

   NBTNAME="SERVER" ; \

   MAILDOM="office.localnet" ; \

   LOCALSID=$(net getlocalsid | awk 'BEGIN{FS="is: "}{print $2}') ; \

   cat >/etc/smbldap-tools/smbldap.conf <<EOT

# main

SID="$LOCALSID"

sambaDomain="$NT4DOM"

# ldap

slaveLDAP="$LDAPSERVER"

slavePort="$LDAPPORT"

masterLDAP="$LDAPSERVER"

masterPort="$LDAPPORT"

ldapTLS="0"

#verify="require"

cafile="/etc/smbldap-tools/ca.pem"

clientcert="/etc/smbldap-tools/smbldap-tools.pem"

clientkey="/etc/smbldap-tools/smbldap-tools.key"

suffix="$SUFFIX"

usersdn="ou=People,\${suffix}"

computersdn="ou=Hosts,\${suffix}"

groupsdn="ou=Group,\${suffix}"

idmapdn="ou=Idmap,\${suffix}"

sambaUnixIdPooldn="sambaDomainName=$NT4DOM,\${suffix}"

scope="sub"

hash_encrypt="SSHA"

# accounts

userLoginShell="/bin/false"

userHome="/home/%U"

userHomeDirectoryMode="700"

userGecos="Office User"

defaultUserGid="513"

defaultComputerGid="515"

skeletonDir="/etc/skel"

defaultMaxPasswordAge="99"

# samba

userSmbHome="\\\\$NBTNAME\\homes\%U"

userProfile="\\\\$NBTNAME\\profiles\%U"

userHomeDrive="H:"

userScript="%U.cmd"

mailDomain="$MAILDOM"

# misc

with_smbpasswd="0"

smbpasswd="/usr/bin/smbpasswd"

with_slappasswd="0"

slappasswd="/usr/sbin/slappasswd"

EOT

И после настройки конфигурации smbldap-tools добавим к ней еще один маленький файлик, в котором укажем учетные данные, с которыми утилиты из пакета smbldap-tools будут обращаться к LDAP:

# SUFFIX="dc=office,dc=localnet" ; \

   LDAPADMIN="ldapadmin" ; \

   ADMINDN="cn=$LDAPADMIN,$SUFFIX" ; \

   ADMINPW="admin" ; \

   cat >/etc/smbldap-tools/smbldap_bind.conf <<EOT

slaveDN="$ADMINDN"

slavePw="$ADMINPW"

masterDN="$ADMINDN"

masterPw="$ADMINPW"

EOT

Все параметры, использованные в скрипте, как и ранее, перечислены в самом начале. Они должны совпадать с ранее использованными и меняться в случае их модификации. Кстати сказать, это единственное место, где пароль администратора LDAP указывается в открытом виде. И это неизбежность. Фактически это чрезвычайно ослабляет защищенность PDC, построенного на основе samba3. В нашем случае использование smbldap-tools носит вспомогательный характер. И более того, можно обойтись без этого пакета, но тогда надо будет написать собственную программу инициализации LDAP и собственную программу, устанавливающую парольные хеши, размещенные в LDAP, от суперпользователя. То есть отказ от smbldap-tools противоречит основному принципу системного администрирования – максимально использовать уже созданные средства. Опираясь на smbldap-tools, можно быть всегда уверенным, что разработчики этого пакета правильно модифицируют свои программы для работы со следующей версией LDAP и samba, так что нам останется лишь исправить мелкие ошибки.

Но если не планируется использовать из smbldal-tools ничего, кроме утилиты smbldap-populate, то /etc/smbldap-tools/smbldap_bind.conf можно и не настраивать. Или настроить непосредственно перед вызовом, а потом удалить.

Теперь можно воспользоваться инструментарием smbldap-tools для создания ldiff, которым далее проинициализируем базу LDAP:

# I=/tmp/tmp.ldif ; \

   smbldap-populate -e $I -a Administrator -k 0 -m 0 -u 2000 -g 2000 ; \

   sed '/^#/s/#//' $I | sed '/^objectClass: posixGroup/i\

objectClass: nisNetgroup' >init.ldiff ; \

   rm -f $I

Все в полученном файле хорошо, кроме того, что ряд записей закомментирован – поправим, уберем комментарий, да еще забыт очень важный для создания групп класс nisNetgroup – поправим, добавим. Полученный файл сохраним. Если что-то еще не устраивает, его можно отредактировать вручную. Рекомендую его обязательно просмотреть и сравнить с тем, что предлагается в [1]. Можно сказать так, в [1] минимальный вариант, а тот, что создает smbldap-populate – предпочтительный.

Вот самый важный момент, после которого номинально LDAP начинает работать – загрузка базы:

# SUFFIX="dc=office,dc=localnet" ; \

   LDAPROOT="ldaproot" ; \

   ROOTDN="cn=$LDAPROOT,$SUFFIX" ; \

   ROOTPW="secret" ; \

   ldapmodify -v -a -D "$ROOTDN" -H ldap://localhost -x -w $ROOTPW -f init.ldiff

Таким образом, база проинициализирована, корневой объект LDAP, соответствующий выбранному суффиксу «dc=office,dc=localnet», создан, и можно приступить к её наполнению.

Первым делом добавим учетную запись служебного пользователя – администратора LDAP:

# SUFFIX="dc=office,dc=localnet" ; \

   LDAPROOT="ldaproot" ; \

   ROOTDN="cn=$LDAPROOT,$SUFFIX" ; \

   ROOTPW="secret" ; \

   LDAPADMIN="ldapadmin" ; \

   ADMINDN="cn=$LDAPADMIN,$SUFFIX" ; \

   ADMINPW="admin" ; \

   SCHEMA='{SSHA}' ; \

   cat <<EOT | ldapmodify -v -a -D "$ROOTDN" -H ldap://localhost -x -w $ROOTPW

dn: $ADMINDN

cn: $LDAPADMIN

sn: $LDAPADMIN

objectClass: person

objectClass: top

description: LDAP Administrator stuff

userPassword: $(slappasswd -s $ADMINPW -h $SCHEMA)

EOT

После добавления бюджета «cn=ldapadmin,dc=office, dc=localnet» можно использовать его отличительное имя для дальнейшей модификации базы LDAP и, значит, встроенный бюджет rootdn более не понадобится, и его отличительное имя и пароль можно безбоязненно удалить из конфигурационного файла:

# I=/etc/openldap/slapd.conf ; \

   grep -v "root\(dn\|pw\)" $I >$I.tmp ; \

   mv $I.tmp $I

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

Здесь уже возникают соображения совсем не тривиального характера и свойственные, скорее всего, лишь для среды openSUSE. Дело в том, что создание пользовательских бюджетов сопровождается регистрацией в соответствующих группах. При использовании smbldap-tools пользовательские бюджеты будут размещаться в группах, характерных для samba окружения. А при использовании «useradd ...» будут использоваться те параметры, которые записаны в /etc/default/useradd:

# cat /etc/default/useradd

GROUP=100

HOME=/home

INACTIVE=-1

EXPIRE=

SHELL=/bin/bash

SKEL=/etc/skel

GROUPS=video,dialout

CREATE_MAIL_SPOOL=no

То есть, согласно этим настройкам, каждый пользователь будет регистрироваться в группах video и dialout. Можно, конечно, их модифицировать, но тогда надо забыть о принципе прозрачности представления сервиса LDAP, не говоря уже о том, что это может создать трудности, поскольку на принадлежности к группам строится традиционная иерархия прав в UNIX. Значит, указанные группы необходимо тоже разместить в базе LDAP. Чтобы не создавать проблем на будущее, проще ВСЕ группы продублировать в LDAP. Воспользуемся для этого вот таким простеньким скриптом:

#!/bin/bash

SUFFIX="dc=office,dc=localnet"

LDAPADMIN="ldapadmin"

ADMINDN="cn=$LDAPADMIN,$SUFFIX"

ADMINPW="admin"

cat /etc/group | grep -v ^+ | awk -F: '{print $1, $3}' | while read GNAME GID ; do

cat <<EOT

dn: cn=$GNAME,ou=Group,$SUFFIX

objectClass: posixGroup

objectClass: nisNetgroup

objectClass: top

cn: $GNAME

gidNumber: $GID

description: Unix group "$GNAME"

userPassword: {crypt}x

-- пустая строка --

EOT

done | ldapmodify -v -a -D "$ADMINDN" -H ldap://localhost -x -w $ADMINPW

Все группы, кроме «users», добавятся без ошибок, а ошибка добавления «users» не должна привести в замешательство, так как это очевидно, поскольку она уже создана как «Users».

Состояние базы LDAP можно посмотреть с помощью утилиты slapcat или через интерфейс консольного клиента:

# SUFFIX="dc=office,dc=localnet" ; \

   LDAPADMIN="ldapadmin" ; \

   ADMINDN="cn=$LDAPADMIN,$SUFFIX" ; \

   ADMINPW="admin" ; \

   ldapsearch -LLL -w "$ADMINPW" -D "$ADMINDN" \

   -v -H ldap://localhost -x -b "$SUFFIX" "(objectClass=*)" >dump.ldiff

Проверяется работа LDAP с помощью утилиты getent. Эта программа позволяет вывести содержимое любой системной базы из nsswitch.conf так, как она «видится» системе. В базах passwd и group должны присутствовать объекты, размещенные в LDAP.

Например, проверим group:

# strings $(rpm -ql nss_ldap | grep lib) | grep ldap.conf

video:x:33:alekseybb

video:*:33:

Первая строка из файловой базы, а вторая из LDAP. Иначе говоря, работает!

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

  1. Настройка OpenLDAP и его клиентов – http://www.freesource.info/wiki/ALTLinux/Dokumentacija/OpenLDAP?v=1845.
  2. Барабанов А. LDAP и Все-Все-Все. Черновик версии 2 – http://www.barabanov.ru/arts/LDAPremarks-draft-2.pdf.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru