Служба каталога (Directory Service) — это программный комплекс для хранения и каталогизации информации. По своей сути это очень похоже на обычную базу данных, но с «уклоном» скорее на чтение данных, нежели на их добавление или изменение. Обычно служба каталога базируется на клиент-серверной архитектуре. Одна из наиболее известных таких систем — DNS (Domain Name Service): DNS-сервер производит взаимную «трансляцию» имён машин и их IP-адресов. Другие машины в сети могут обращаться к такому серверу за информацией о соответствии имени и адреса. Однако это очень простой пример каталогизации информации. Объекты в такой базе имеют ограниченное количество атрибутов — таких как имя, адрес и ещё несколько дополнительных параметров. Разумеется, служба каталога какого-либо предприятия будет содержать более разнообразные данные и иметь гораздо более сложную структуру.
В общем случае, служба каталога должна предоставлять простой, централизованный доступ к данным, которые могут использоваться различными приложениями. Протокол, по которому могла бы работать такая служба, был разработан в ISO (International Standartization Organization), получил номер X.500 и назывался DAP (Directory Access Protocol). В соответствии с этим протоколом любое приложение может получить доступ к информации в каталоге. Там же была предложена гибкая и легко расширяемая информационная структура, которая позволяла хранить, в принципе, любой тип данных. К сожалению, X.500 имел и ряд ограничений, среди которых зависимость от коммуникационного уровня, который не являлся стандартным протоколом TCP, и запутанность требований к правилам именования объектов. В результате решение на базе этого протокола становилось очень дорогим при обслуживании.
Позже появился протокол LDAP (Lightweight Directory Access Protocol), который позволил реализовать доступ по TCP/IP и мог легко расширяться. В результате появилось решение, позволяющее организовать службу каталога на предприятии любого масштаба.
Сегодня существует несколько реализаций данного протокола от различных фирм. Наиболее известные из них — Netscape Directory Service™, Novell Directory Service™ и Microsoft Active Directory™. Из некоммерческих реализаций LDAP наибольшее распространение получил проект OpenLDAP. Именно его мы и будем рассматривать в дальнейшем, хотя большинство понятий и определений применимо и к другим реализациям сервера LDAP.
Для понимания работы службы каталога необходимо усвоить несколько ключевых терминов.
Данные каталога хранятся в виде объектов или сущностей (от англ. entry), состоящих из специальных полей, называемых атрибутами (attributes). Набор атрибутов, их синтаксис и правила поиска определяются схемой каталога (scheme). Все объекты каталога идентифицируются специальным атрибутом — DN (Distinguished Name).
Данные в каталоге можно представить в виде древовидной структуры — DIT (Directory Information Tree). Это очень похоже на структуру, используемую многими файловыми системами. Вершиной такого дерева является корневой объект (Root Entry). DN корневого объекта одновременно является суффиксом каталога.
Каждый последующий объект в структуре каталога идентифицируется уникальным значением DN, который описывает путь к объекту в каталоге. Если продолжить аналогию с файловой системой, то DN любого объекта так же включает DN всех объектов стоящих выше по иерархии. Отличие в данном случае только в том, что DN формируется не слева направо, как путь к файлу, а наоборот — справа налево.
DN администратора каталога (Root Distinguished Name) — это специальный объект, описывающий администратора каталога. Этот объект указывается в конфигурации сервера, но может отсутствовать в самом каталоге. К такому объекту не применяются списки доступа (ACL). В некоторых реализациях LDAP такой объект может не иметь суффикса.
База поиска (Base Distinguished Name) — объект каталога, начиная с которого производится поиск. Дело в том, что не всегда есть необходимость производить поиск по всему дереву каталога; ограничить область поиска можно указанием в запросе базы поиска. По умолчанию этот параметр соответствует суффиксу.
Серверы LDAP могут поставляться с несколькими вариантами бэкенда (backend). Например, OpenLDAP имеет такие варианты, как LDBM — собственный формат хранения данных в текстовых файлах; SHELL — интерфейс к базе данных, использующий команды UNIX; PASSWD — простейшая база, использующая стандартные файлы /etc/passwd и /etc/group; SQL — интерфейс к любой базе данных, использующей SQL.
Для процедур импорта и экспорта данных всеми серверами LDAP поддерживается единый формат обмена данными — LDIF. Вот пример такого файла с описанием двух объектов:
dn: dc=example,dc=com objectClass: top objectClass: organization o: example.com o: Example Inc. dn: ou=People,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: People description: Example Inc. workers description: Stuff area
Описание каждого объекта в таком файле начинается с атрибута DN. Специальный атрибут objectClass указывает, к каким классам относится данный объект и, следовательно, какие атрибуты он может иметь. В нашем случае принадлежность к классу top означает, что объект обязательно должен иметь атрибут objectClass, а принадлежность к классу organization предполагает наличие нескольких атрибутов, из которых атрибут o является обязательным.
Второй объект находится на одну ступеньку ниже по иерархии и поэтому в его DN включён DN объекта верхнего уровня. Этот объект относится к классу organizationalUnit и поэтому имеет обязательный атрибут ou.
Можно заметить, что некоторые атрибуты (для которых это применимо) могут иметь несколько значений. В данном примере атрибут description имеет два значения. А вот для атрибута dn допустимо только одно значение.
Классы, характеризующие объекты, и атрибуты, составляющие классы, описываются схемой базы. Её пример приведён ниже.
attributetype ( 2.5.4.10 NAME ( 'o' 'organizationName' )
SUP name
)
attributetype ( 2.5.4.13 NAME 'description'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
)
objectclass ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL
MUST o
MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
postalAddress $ physicalDeliveryOfficeName $ st $ l $ description
)
)
В данном фрагменте приводятся описания двух атрибутов и одного класса. Вот что означают эти записи:
Атрибут o (его можно также называть organizationName) является расширением атрибута name.
Атрибут description — это строка длиной до 1024 байт; при поиске в ней регистр символов не учитывается.
Класс organization является расширением класса top и, следовательно, он включает в себя все атрибуты составляющие этот класс плюс дополнительные атрибуты такие как userPassword, businessAddress, street, postOfficeBox и т.д. Кроме того, атрибут o является обязательным.
Много полезной информации о схемах можно найти по ссылкам на сайте OpenLDAP.
Процесс сборки и установки сервера OpenLDAP не отличается от сборки и установки другого программного обеспечения, поставляемого с исходными кодами. Кроме того, практически во всех современных дистрибутивах Linux он поставляется в виде готового пакета. Поэтому уделим больше внимания настройке.
Сервер LDAP состоит из двух серверных процессов: slapd и slurpd. Процесс slapd занимается приёмом и обработкой запросов от клиентов; это основной процесс, который непосредственно работает с базой данных. Сервис slurpd используется в тех случаях, когда данные нужно реплицировать на другие сервера — он контролирует изменения в базе и, при необходимости, пересылает их на подчинённые сервера.
Приведём пример конфигурационного файла:
include /etc/openldap/schema/core.schema include /etc/openldap/schema/nis.schema
В первых строках мы подключаем необходимые схемы; в поставке OpenLDAP их около полутора десятков. Подключите только те, которые будете использовать. В принципе, схемы являются частью конфигурационного файла, но для наглядности они вынесены в отдельные фрагменты.
TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /etc/openldap/ssl/slapd.pem TLSCertificateKeyFile /etc/openldap/ssl/slapd.pem
LDAP можно использовать для централизованной авторизации пользователей сети вместо NIS+. В таких случаях из каталога может запрашиваться конфиденциальная информация — например, пароль. Для предотвращения перехвата этих данных желательно использовать протокол LDAPS (LDAP via SSL/TLS).
database ldbm
В качестве способа хранения используется собственный формат LDBM. Если предполагается обычная конфигурация сервера, то данный формат предпочтителен.
suffix "dc=example,dc=com"
Корнем информационной структуры будет являться объект dc=example,dc=com. В принципе, суффикс для каталога можно взять любой, например, o=Example Inc.,c=RU — это не накладывает абсолютно никаких ограничений на функциональность. Однако последнее время всё чаще используется именно первый вид суффикса, который подчёркивает, что информационная структура данного предприятия тесно связана со структурой его домена.
rootdn "cn=admin,dc=altlinux,dc=ru" rootpw secret
DN, описывающий администратора и его пароль. В данном случае пароль записан в открытом виде, поэтому файл конфигурации сервера должен иметь соответствующие права доступа, ограничивающие его чтение обычными пользователями. Пароль можно записать и в виде хеша DES или MD5 — тогда строка будет иметь следующий вид:
rootpw {MD5}IFJFxyGN3Hap7xsJFBmeTA==
Эти опции нужны только на время первичной настройки базы. После того как структура создана и можно регулировать права доступа с помощью ACL, эти опции рекомендуется отключить.
index objectClass eq
Формат ldbm поддерживает простейшие индексы с целью ускорения операций поиска. Такие индексы желательно создавать по атрибутам, предполагающим наибольшее количество запросов. Последний параметр данной опции указывает по какому критерию создаётся индекс. Это могут быть pres, eq, approx, sub, none. (present, equality, approximate, substring, no index).
access to attr=userPassword by dn=".*,ou=Admins,dc=example,dc=com" write by self write by anonymous auth by * none access to * by * read
Данные каталога не всегда находятся в публичном доступе. Для управления доступом могут использоваться списки доступа (access lists). В данном примере приводятся два списка — в первом из них ограничивается доступ к атрибуту userPassword (полный доступ к нему могут иметь только сам объект либо администраторы базы; для всех остальных доступ запрещён). Второе правило гласит, что всем даётся доступ на чтение любых данных (кроме ограниченного предыдущим правилом).
После настройки можно сразу запустить процесс slapd — например, такой командой:
# slapd -u ldap -h ldap://127.0.0.1/ ldaps://ldap.altlinux.ru/
или, если вы используете пакет из дистрибутивов ALT Linux,
# service slapd start
Первый объект, который нужно создать в базе — корневой элемент (root entry), который указан в конфигурационном файле как suffix.
Одной из важных особенностей LDAP являются встроенные средства репликации данных. Этот механизм реализован в виде отдельного серверного процесса, контролирующего изменения в базе данных и пересылающего эти изменения на другие серверы. Прежде чем включить такую репликацию, необходимо убедиться в том, что соответствующие данные на обоих серверах идентичны. Это связано с тем, что slurpd пересылает именно изменения на текущем сервере — он не проверяет и не анализирует состояние данных на удалённом сервере. Настройки slurpd находятся в том же файле, что и настройки slapd, поэтому перечислим, что нужно добавить к перечисленным выше параметрам:
replica /var/log/slapd.replog
Прежде всего укажем файл, в который slapd будет записывать все свои действия и из которого slurpd будет их читать.
replica uri=ldap://ldap2.example.com bindmethod=simple binddn="cn=slurpd,ou=Apps,dc=example,dc=com" credentials=secret
Реплика такого вида описывается для каждого подчинённого сервера. На подчинённом сервере нужно создать соответствующий объект и указать, что он имеет права на изменение информации. Это делается с помощью соответствующего списка доступа и параметров updatedn и updateref.
Существует огромное количество клиентов, работающих с LDAP. Это могут быть почтовые программы, которые обращаются к каталогу в поисках адреса электронной почты сотрудника или за информацией о маршрутизации почты, FTP-сервер, который берет информацию для авторизации своего клиента и многие другие программы — однако все они имеют схожие настройки. Прежде всего это адрес сервера и порт, на котором работает LDAP (обычно это 389 или, если сервер поддерживает протокол LDAPS, — 636). Вторым важным параметром является база поиска (Base DN) — в большинстве случаев этот параметр соответствует суффиксу сервера, однако иногда имеет смысл сузить область поиска. Например, если мы ищем пользователя чтобы авторизовать его на почтовом сервере, то вряд ли его нужно искать среди групп пользователей или списка компьютеров локальной сети. Третий важный параметр — фильтр поиска, т.е. критерий по которому мы выбираем объект из базы. Кроме того, существуют параметры, позволяющие ограничить поиск снизу — например, только самой базой или базой и её подобъектами первого уровня, параметры управляющие поиском в алиасах (alias) и т.п.
Трёх этих параметров (сервер, база поиска и фильтр) в большинстве случаев достаточно, чтобы выполнить запрос к любому серверу LDAP. Однако, если на сервере существуют ограничения на доступ к данным, может потребоваться авторизация. Авторизоваться в LDAP можно, указав DN одного из объектов базы данных LDAP; пароль для такого объекта будет искаться в его атрибуте userPassword.
Ниже приводится фрагмент настройки почтового сервера Postfix:
virtual_maps = ldap:virtual, hash:/etc/postfix/virtual virtual_server_host = localhost virtual_search_base = ou=People,dc=example,dc=ru virtual_query_filter = (&(objectclass=inetLocalMailRecipient)(cn=%s)) virtual_result_attribute = mailLocalAddress,mailRoutingAddress
В данном фрагменте описывается, что при определении адреса получателя делается запрос в LDAP с целью найти объект, которому это письмо адресовано. Поиск делается по атрибуту cn. Результат берётся из атрибутов mailLocalAddress и mailRoutingAddress. Эти классы и атрибуты описаны схемой misc.
LDAP может использоваться в самых различных ситуациях. Здесь мы рассмотрим несколько наиболее распространённых его применений. Поскольку в LDAP хранится полная информация о сотрудниках предприятия, мы можем брать справочную информацию для почтовых программ прямо оттуда. Для начала настроим сервер:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
loglevel 512
database ldbm
directory /var/lib/ldap/base/example.com
password-hash {MD5}
suffix "dc=example,dc=com"
#rootdn "cn=admin,dc=example,dc=com"
#rootpw secret
access to attr=userPassword
by dn=".*,ou=Admins,dc=example,dc=com"
by anonymous auth
by self write
by * none
access to * by * read
index objectClass,uid,uidNumber,gidNumber eq
index cn,mail,surname,givenname eq,sub
После этого создадим пользователя ldap, от имени которого будет работать наш сервер и запустим процесс slapd следующей командой:
# slapd -u ldap -h 'ldap://127.0.0.1/ ldap//ldap.example.com/ ldaps://ldap.example.com'
Теперь можно создать базу данных — например, с помощью утилиты ldapadd или slapadd:
# ldapadd -xWD cn=admin,ou=Admins,dc=example,dc=com -H ldaps://ldap.altlinux.ru -f initial.ldif или, если сервер не запущен: # slapadd -b dc=example,dc=com -l initial.ldif # chown ldap:ldap /var/lib/ldap/bases/example.com/*
Содержимое файла initial.ldif будет такое:
dn: dc=example,dc=com
objectClass: top
objectClass: organization
o: Exapmle Inc.
o: exapmle.com
dn: ou=Admins,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Admins
description: Administrators
dn: cn=admin,ou=Admins,dc=exapmle,dc=com
objectClass: top
objectClass: person
cn: admin
sn: Bender
givenName: Ostap
userPassword: secret
description: Our smart admin
dn: ou=People,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: People
description: Stuff area
dn: uid=obender,ou=People,dc=example,dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
cn: Ostap Bender
sn: Bender
givenName: Ostap
uid: obender
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/obender
loginShell: /bin/bash
userPassword: {md5}$1$ION4SIII$EYyGEeYt4g2hEe9tjICac.
mail: obender@example.com
mail: obender@attiresandtoes.com
....
dn: ou=Groups,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Groups
description: Groups of users
dn: cn=obender,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: posixGroup
cn: luser
gidNumber: 1000
description: Default group for users presented by LDAP
Проверим, что сервер работает, сделав к нему анонимный запрос:
$ ldapsearch -xLLL "(uid=obender)" dn: uid=obender,ou=People,dc=example,dc=com objectClass: top objectClass: account objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson cn: Ostap Bender sn: Bender givenName: Ostap uid: migor uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/obender loginShell: /bin/bash mail: obender@example.com mail: obender@attiresandtoes.com
Поскольку, согласно нашим настройкам, доступ к атрибуту userPassword имеют только сам пользователь и администратор, то этот атрибут мы не получили. Собственно, он нам и не нужен.
На сегодняшний день почти все популярные почтовые программы поддерживают возможность использовать LDAP как адресную книгу. В качестве примера возьмём пакет для сетевых коммуникаций Mozilla; установите пакеты libldap, mozilla, mozilla-mail и запустите программу. Далее:
откройте окно настройки (->);
выберите слева категорию , подкатегорию ;
справа в опциях «Address Autocompletion» включите «Directory Server» и нажмите кнопку «»;
в новом окне нажмите кнопку «» и на вкладке «General» заполните поля «Name:» ExampleLDAP, «Hostname:»ldap.example.com и «BaseDN:»dc=example,dc=com;
при желании на вкладке «Advanced» можно указать ограничение на количество возвращаемых записей (по умолчанию это 100) и фильтр поиска.
После этого сохраните изменения — и теперь при заполнении поля «To:» можно писать не адрес, а имя получателя из атрибута cn. Программа произведёт соответствующий поиск и предложит варианты атрибута mail, которые найдёт в базе.
Для настройки другого пакета обратитесь к руководству пользователя вашей программы.
Предположим, что наше предприятие не имеет своего POP3/IMAP-сервера, либо для некоторых сотрудников удобнее получать почту через другой сервер. Для этого нам необходимо принять почту пользователя, приходящую в наш домен, и переправить её на тот адрес, который для сотрудника удобнее. Решений для этой задачи существует несколько: в простейшем варианте можно создать в домашнем каталоге пользователя файл .forward, в котором он сам мог бы указать нужный ему адрес. Однако усложним задание — предположим, что на нашем почтовом сервере нет учётной записи для данного пользователя; тогда получается, что этот файл некуда поместить. Второй вариант — настроить пересылку на самом сервере; для этого создаётся файл /etc/postfix/virtual приблизительно такого вида:
obender@example.com obender@attiresandtoes.com
а в конфигурационном файле Postfix указывается
virtual_maps = hash:/etc/postfix/virtual
Теперь остаётся только создать хеш и перезапустить Postfix; однако, если мы имеем много таких пользователей и если почтовых серверов существует несколько, то отслеживать синхронное изменение файлов /etc/postfix/virtual становится нелёгкой задачей.
Немного модифицируем наше последнее решение. Перенесём данные из файла /etc/postfix/virtual в LDAP; для этого модифицируем приведённую выше базу следующим образом: добавим пользователю класс inetLocalMailRecipient и новый атрибут mailRoutingAddress.
$ ldapmodify -WD cn=admin,ou=Admins,dc=example,dc=com dn: uid=obender,ou=People,dc=example,dc=com changetype: modify objectClass: inetLocalMailRecipient mailRoutingAddress: obender@attiresandtoes.com
После этого изменим настройки Postfix:
virtual_maps = ldap:virtual virtual_server_host = ldap.example.com virtual_search_base = ou=People,dc=example,dc=com virtual_query_filter = (&(mail=%s)(objectClass=inetLocalMailRecipient)) virtual_result_attribute = mailRoutingAddress
Теперь почта для данного пользователя будет пересылаться на адрес из атрибута mailRoutingAddress, тем не менее, в адресной книге всё останется без изменений и там будет показываться «официальный» адрес пользователя из атрибута mail.
Разобравшись с почтой, хочется перенести в LDAP и авторизацию. Обычно для этих целей используют NIS+, однако хочется использовать для этого более совершенную технологию — в конце концов, у нас уже есть сервер LDAP, содержащий все необходимые данные по нашим пользователям. Для того чтобы система искала своих пользователей не только в файле /etc/passwd, необходимо установить пакеты nss_ldap и pam_ldap. Оба пакета имеют общий конфигурационный файл /etc/ldap.conf (в других дистрибутивах это могут быть другие файлы, но синтаксис у них одинаковый).
uri ldaps://ldap.example.com ldap_version 3 base dc=example,dc=com tls on
Подправим файл /etc/nsswitch.conf:
passwd: files ldap shadow: tcb ldap group: files ldap
Теперь проверяем, подключены ли пользователи из базы:
$ id obender uid=1000(obender) gid=1000(obender) groups=1000(obender)
Обратите внимание на то, что сейчас мы обращаемся к серверу по защищённому протоколу LDAPS. Поскольку теперь мы берём из базы крайне важную информацию — пароль пользователя — дополнительная степень защиты будет весьма кстати.
Список RFC, регламентирующих LDAP:
RFC 1558: A String Representation of LDAP Search Filters
RFC 1777: Lightweight Directory Access Protocol
RFC 1778: The String Representation of Standard Attribute Syntaxes
RFC 1779: A String Representation of Distinguished Names
RFC 1781: Using the OSI Directory to Achieve User Friendly Naming
RFC 1798: Connectionless LDAP
RFC 1823: The LDAP Application Programming Interface
RFC 1959: An LDAP URL Format
RFC 1960: A String Representation of LDAP Search Filters
RFC 2251: Lightweight Directory Access Protocol (v3)
RFC 2307: LDAP as a Network Information Service