Сетевая аутентификация

1.6.3. Тестирование

Как только репликация стартует, вы можете отслеживать ее запустив:

ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base contextCSN

dn: dc=example,dc=com

contextCSN: 20120201193408.178454Z#000000#000#000000

как на Поставщике, так и на Потребителе. Как только вывод

(20120201193408.178454Z#000000#000#000000в примере выше) на обеих машинах

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

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

Если contextCSN Потребителя отсутствует или не совпадает со значением Поставщика, вы должны остановиться и понять причину проблемы перед тем как продолжить. Попробуйте проверить slapd (syslog — системный журнал) и файлы журналов аутентификации Поставщика, чтобы увидеть удачны ли были запросы аутентификации Потребителя и не возвращались ли ошибки в ответ на запросы данных (они будут видны как множество записей ldapsearch).

Чтобы проверить, что всё работает, просто запросите на Потребителе DN из базы:

sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com dn

Вы должны увидеть пользователя 'john' и группу 'miners', также как ноды

'People' и 'Groups'.

1.7. Управление доступом

Управление тем, какой тип доступа пользователей (чтение, запись и пр.) должен быть предоставлен к ресурсам, известно как контроль доступа. Используемые для этого директивы называются списками контроля доступа (access control lists, или ACL).

Когда мы устанавливали пакет slapd, различные ACL были установлены автоматически. Мы рассмотрим некоторые важные следствия этих

120

Сетевая аутентификация

умолчаний и, занимаясь этим, мы поймём идею того, как работают ACL и как их настраивать.

Для получения эффективных ACL для запроса LDAP нам надо посмотреть на ACL записи запрашиваемой базы данных также как и на записи специального экземпляра базы данных переднего плана. По умолчанию используются ACL, полученные последним действием, в случае, если они не совпадают с правилами из предыдущего варианта. База данных переднего плана опрашивается во вторую очередь и применяется ACL по первому совпадению среди этих двух источников ACL. Следующие команды покажут соответственно ACL базы hdb ("dc=example,dc=com") и они же из базы переднего плана:

sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={1}hdb)' olcAccess

dn: olcDatabase={1}hdb,cn=config

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * none

olcAccess: {1}to dn.base="" by * read

olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=com" write by * read

rootDN всегда имеет полный доступ к своей базе данных. Добавление их к ACL обеспечивает полную конфигурацию, но при этом становится причиной снижения быстродействия slapd.

sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={-1}frontend)' olcAcc

dn: olcDatabase={-1}frontend,cn=config

olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred, cn=external,cn=auth manage by * break

olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=Subschema" by * read

Самый первый ACL очень важен:

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * none

Это может быть представлено по-другому для лучшего понимания:

to attrs=userPassword by self write

by anonymous auth

by dn="cn=admin,dc=example,dc=com" write

121

Сетевая аутентификация

by * none

to attrs=shadowLastChange by self write

by anonymous auth

by dn="cn=admin,dc=example,dc=com" write by * none

Этот составной ACL (их два) предписывает следующее:

•Анонимный 'auth' доступ обеспечивается к атрибуту userPassword для осуществления изначального соединения. Возможно потребуется counterintuitively для 'by anonymous auth' даже когда анонимный доступ к DIT

не требуется. Как только удаленное соединение установлено, требуется аутентификация (см. следующий пункт).

•Должна пройти аутентификация, поскольку все пользователи имеют доступ на чтение (вследствие 'by self write') к атрибуту userPassword.

•Атрибут userPassword не доступен для всех других пользователей за исключением rootDN, который имеет полный доступ.

•Для того чтобы пользователи могли менять собственные пароли, используя passwd или иные утилиты, атрибут shadowLastChange должен быть доступен как только пользователь авторизовался.

Поиск по этому DIT может быть проведен анонимно из-за 'by * read' в данном ACL:

to *

by self write

by dn="cn=admin,dc=example,dc=com" write by * read

Если это нежелательно, то вам потребуется изменить набор ACL. Для принуждения к аутентификации в процессе связывающего (bind) запроса в качестве альтернативы (или в комбинации с измененным ACL) вам надо использовать директиву 'olcRequire: authc'.

Как указывалось ранее, для базы slapd-config не создаётся никаких административных пользователей. Однако существует идентификация SASL, которая обеспечивает полный доступ к ней. Она подобна суперпользователю для localhost (root/sudo). Вот она:

dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

Следующая команда покажет ACL базы slapd-config:

sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={0}config)' olcAccess

122

Сетевая аутентификация

dn: olcDatabase={0}config,cn=config

olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred, cn=external,cn=auth manage by * break

Поскольку это SASL идентификация, нам потребуется механизм SASL, когда запрашивается LDAP утилита, о которой идет речь и мы увидим это много раз в данном руководстве. Это внешний (EXTERNAL) механизм. Смотрите предыдущую команду в качестве примера. Обратите внимание:

1.Вы должны использовать sudo для идентификации как root, чтобы ACL сработали.

2.Механизм EXTERNAL работает через IPC (доменные сокеты UNIX). Это означает, что вы должны использовать ldapi формат адресации (URI).

Короткий путь для получения всех ACL выглядит следующим образом:

sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcAccess=*)' olcAccess olcSuffix

Есть ещё много что сказать по контролю доступа. Смотрите страницу руководства по slapd.access4.

1.8. TLS

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

Здесь мы организуем свой собственный Центр сертификации (Certificate Authority — CA) и затем создадим и подпишем сертификат нашего

LDAP сервера от имени этого CA. Поскольку slapd скомпилирован с использованием библиотеки gnutls, мы будем использовать для выполнения этих задач утилиту certtool.

1.Установите пакеты gnutls-bin и ssl-cert:

sudo apt-get install gnutls-bin ssl-cert

2.Создайте секретный ключ для центра сертификации

sudo sh -c "certtool --generate-privkey > /etc/ssl/private/cakey.pem"

3.Создаём временный файл /etc/ssl/ca.info для определения CA:

cn = Example Company

4 http://manpages.ubuntu.com/manpages/en/man5/slapd.access.5.html

123

Сетевая аутентификация

ca cert_signing_key

4.Создаём самоподписанный сертификат центра:

sudo certtool --generate-self-signed \ --load-privkey /etc/ssl/private/cakey.pem \ --template /

5.Создайте секретный ключ для сервера:

sudo certtool --generate-privkey \ --bits 1024 \ --outfile /etc/ssl/private/ldap01_slapd_key.pe

Замените ldap01 в имени файла на имя вашего сервера (hostname). Имена сертификата и ключа для узла и сервиса, которые будут их использовать, помогут сохранять ясность понимания.

6.Создайте файл /etc/ssl/ldap01.info, содержащий:

organization = Example Company cn = ldap01.example.com tls_www_server

encryption_key signing_key expiration_days = 3650

Данный сертификат будет действителен 10 лет. Вы можете выбрать другое значение.

7.Создайте сертификат для сервера:

sudo certtool --generate-certificate \ --load-privkey /etc/ssl/private/ldap01_slapd_key.pem \ -

Создайте файл certinfo.ldif со следующим содержимым (подставляйте свои значения, наш пример предполагает использование https://www.cacert.org):

dn: cn=config

add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem

-

add: olcTLSCertificateFile

olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem

-

add: olcTLSCertificateKeyFile

olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem

Используйте команду ldapmodify, чтобы сообщить slapd о работе нашего

TLS через базу данных slapd-config:

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ssl/certinfo.ldif

124