 |
|
|
|
Размещаем пользовательские бюджеты в 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 используются специально заданные правила. Эти правила, так же как и права доступа к файлам традиционной системы АиА, таким как /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:
Первая строка из файловой базы, а вторая из LDAP. Иначе говоря, работает! Таким образом, все составные части системы аутентификации и авторизации подготовлены для использования LDAP в качестве хранилища учетных записей. В следующей части статьи будет проведена детальная проверка этой схемы, выявлены ее недостатки и указаны преимущества. Пытливые читатели могут, не дожидаясь следующего номера, испробовать все, здесь описанное, в работе. Приведенные выше скрипты не будут подвергаться переделке в ходе дальнейшего обсуждения. А вот впечатления от их использования можно сравнить с теми, что послужили материалом для второй части статьи.
|
Алексей Барабанов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
