В предыдущей части статьи мы благополучно разобрались с общесистемными настройками авторизации аккаунтов из сервера каталогов . Теперь поговорим о том, как создавать новые группы UNIX в СК и добавлять учётные записи пользователей в составе этих групп. Уточню на всякий случай, что в данном случае, речь идёт не о групповых политиках или о чём-то подобном, а об обычных UNIX-группах, традиционно представленных как односложная плоская структура /etc/group. В LDAP на степень сложности этой структуры ограничений не накладывается, поэтому она может быть представлена более логичным образом - например, в виде дерева.
Разделяемые библиотеки – модули подсистем NSS и PAM, - о которых шла речь в предыдущей части статьи, обычно (если это не переопределено параметрами, указанными в конфигурационном файле /etc/ldap.conf) осуществляют поиск UNIX-группы в СК по objectClass=posixGroup и наличию атрибутов gid и gidNumber. Отличительное имя базы поиска и глубина поиска, как мы уже знаем, задаются параметром nss_base_group в файле /etc/ldap.conf. Таким образом, создание группы в СК технически выглядит как создание объекта класса posixGroup в любой ветке, попадающей в заданную область поиска. Давайте, например, добавим группу FreeUsers в ветку ou=Groups,ou=home,o=Moscow,c=RU. Для этого сформируем узел базы поиска ou=Groups:

dn: ou=Groups,ou=home,o=Moscow,c=RU
objectClass: organizationalUnit
ou: Groups
decsription: UNIX groups here

А затем прикрепим к этому узлу первую группу:

dn: cn=FreeUsers,ou=Groups,ou=home,o=Moscow,c=RU
objectClass: posixGroup
gidNumber: 1000
cn: FreeUsers
description: Free peoples for whom we write our free software

Для того, чтобы система могла «увидеть» добавляемые нами объекты, прежде всего необходимо настроить права доступа к соответствующим записям в СК. Ранее мы уже говорили о том, что доступ на запись ко всем атрибутам объектов, описывающим системные аккаунты и группы UNIX, должны иметь процессы с эффективным пользовательским идентификатором администратора системы. Для того, чтобы эти процессы могли получить соответствующие привилегии на доступ в СК, в файле /etc/ldap.conf указывается соответствующий DN – значение параметра rootbinddn, а пароль для авторизации берётся из файла /etc/ldap.secret
ПРИМЕЧАНИЕ: В файле /etc/ldap.secret не должно быть никаких, в то числе и служебных (перевод строки, ESC-последовательности, которые могут быть вставлены некоторыми устаревшими или неправильно настроенными текстовыми редакторами после нажатия клавиш, не относящихся к алфавитно-цифровому блоку) других символов, кроме собственно пароля. Для того, чтобы гарантированно не ошибиться, а заодно правильно установить маску доступа к файлу, ограничив доступ на чтение пользователю root, автор рекомендует записывать пароль командой

echo -n 'ПАРОЛЬ' > /etc/ldap.secret
chmod 600 /etc/ldap.secret

Поскольку в ldap.secret открытым текстом записан пароль для dn, имеющего право на запись в СК, на этот файл устанавливаетмя маска доступа «rw- --- ---», восьмеричный код 600.
С программами, запускаемыми с EUID=0 (т.е. с правами администратора системы), всё понятно, но как быть с непривилегированными процессами, запрашивающими доступ к виртуальным базам passwd и group? Эти процессы подключаются к СК анонимно,поэтому для того, чтобы учётные записи пользователей в каталоге могли хотя бы по минимуму читать атрибуты необходимые для работы – например, соответствия между uid и uidNumber, gid и gidNumber (в переводе на русский язык: между числовым и символьными идентификаторами пользователя и группы соответственно), - Вам необходимо разрешить чтение при анонимном доступе к соотв. ветвям каталога. Разумеется, из числа атрибутов, доступных на чтение, должны быть исключены пароли пользователей.
Далее нам предстоит создать новую учётную запись пользователя и добавить её в группу FreeUsers. Но здесь перед нами встаёт дилемма: в какую ветвь следует поместить новый объект СК? С одной стороны, все пользователи должны бы размещаться в отдельной ветке, как это часто рекомендуется в специальной литературе, поскольку традиционно структура базы passwd в UNIX - совершенно плоская, а принадлежность пользователей тем или иным группам является скорее средством контроля доступа, нежели логической организации и упорядочения системы, так что из двух учётных записей с одинаковыми именами, но принадлежащим разным группам, будет работать только одна, даже если у них разные значения uidNumber. Но с другой стороны – СК это всё-таки средство, позволяющее идеально отразить иерархический характер отношений и отношений принадлежности, а с этой точки зрения было бы правильным размещать пользователей, принадлежащих группе, в самостоятельной ветке ниже узла-контейнера данной группы. Впрочем, я своего мнения ни в коем разе не навязываю - ваша рука всему владыка, и то, как будет в итоге выглядеть Каталог, решать только вам.
Стандартным объектным классом для хранения авторизационной информации учётной записи пользователя UNIX является posixAccount, описанный в файле nis.schema стандартной поставки OpenLDAP и присутствующий во всех cn=schema,cn=config серверов каталогов, ведущих свою родословную от Netscape iPlanet (Fedora DS, Sun Java System (ONE) DS, OpenDS). Также в учётной записи пользователя должен присуствовать objectClass=shadowAccount, привносящий крайне мало дополнительной информации (например, дополняющий свойства объекта полем срока действия пароля), но необходимый для совместимости с некоторыми приложениями и службами UNIX, которые обращаются за авторизационными данными, минуя NSS, напрямую в сервер каталогов. К числу таких служб, например, относится сервер удалённого входа OpenSSH с патчем поддержки LDAP (подробнее о его настройке читайте в одном из следующих выпусков). В обобщённом виде LDIF-дамп учётной записи пользователя должен выглядеть следующим образом:

dn: uid=ACCOUNT_NAME,BASE_DN
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
uid: ACCOUNT_NAME
cn: FULL_NAME
uidNumber: UID_NUMBER
gidNumber: GID_NUMBER
homeDirectory: $HOME
loginShell: $SHELL
userPassword: PASSWORD
gecos: SOME_INFO
description: SOME_MORE_INFO

Назначение указанных полей приведено в след. таблице:

Поле	Описание
ACCOUNT_NAME	Имя пользователя в том виде, в каком оно будет видно системе. Именно в атрибуте uid следует указывать имя пользователя (логин в систему)
FULL_NAME	Полное имя пользователя. Отображается некоторыми менеджерами входа в систему. На самом деле чаще всего в реальных случаях ACCOUNT_NAME = FULL_NAME
UID_NUMBER	Численный идентификатор пользователя как субъекта системы, наделённого теми или иными полномочиями (правами доступа). Традиционно разрешения на доступ к объектам системы соотносятся именно с численным идентификатором, а не с именем пользователя, которое служит е более, чем hash-ключом для поиска UID_NUMBER.
GID_NUMBER	Численный идентификатор группы. Именно к основной группе, на принадлежность к которой указывает данное поле, относится вторая битовая триада в восьмеричной маске прав доступа пользователя. (Например, r-x в одной из самых распространённых масок: rwxr-x---)
$HOME	Домашний каталог пользователя. Как известно, именно сюда пользователь попадает после регистрации в системе (авторизации).
$SHELL	Оболочка пользователя. Программа, на которую передаётся управление после авторизации пользователя.
PASSWORD	Пароль. В LDAP может храниться как в шифрованном виде, так и открытым текстом. Понятно, что последнее нежелательно.
SOME_INFO	Это так называемое поле GECOS (en.wikipedia.org/wiki/Gecos_field"), в котором содержится информация о пользователе в произвольной подаче. Ограничение – только на длину поля (не более N символов).
SOME_MORE_INFO	Прочая информация о пользователе. Или прогноз погоды на 10 лет вперёд

В класс объектов posixAccount включен исчерпывающий набор атрибутов, достаточный для того, чтобы описать UNIX-аккаунт, но их явно недостаточно для описания собственно объекта – того человека, который под настоящим аккаунтом авторизуется. Например, у реального человека конечно же есть номер телефона и e-mail-адрес – основные контакты, по которым его можно будет найти, например для того, чтобы сообщить о блокировании его учётной записи. Также неплохо было бы знать владельца аккаунта в лицо для того, чтобы успеть вовремя разминуться с ним при случае.Возможность хранить все эти сведения, а также большое количество другой полезной информации о пользователе вместе с его UNIX-аккаунтом, предоставляет стек объектных классов, на вершине которого находится objectClass=inetOrgPerson, а именно:

objectClass: top
objectClass: person
pbjectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount

В данном случае речь идёт, - ни больше ни меньше, - о простой и безболезненной интеграции виртуальных баз passwd-groups-shadow с адресной книгой. Мы ещё не раз будем приводить полезные примеры подобных объединений свойств различных классов объектов – иногда это будет получаться простым и очевидным образом, как это имеет место быть в описанном случае с дополнением стека posixAccount, иногда – понадобится знание устройства схем LDAP – в любом случае для администратора, который до этого имел дело лишь с традиционными базами данных, это будет похоже на магию: LDAP даёт возможность делать многое из того, что и не снилось СУБД, в качестве отличной альтернативы табличным хранилищам данных предлагая фантастически гибкий объектно-ориентированный подход.
Между прочим, небольшую фотографию-аватар, из атрибута jpegPhoto некоторые дистрибутивы (например, SuSE) уже наловчились использовать для визуального представления пользователей на графическом экране входа в систему