diff options
Diffstat (limited to 'documentation/content/ru/articles/ldap-auth/_index.adoc')
-rw-r--r-- | documentation/content/ru/articles/ldap-auth/_index.adoc | 703 |
1 files changed, 703 insertions, 0 deletions
diff --git a/documentation/content/ru/articles/ldap-auth/_index.adoc b/documentation/content/ru/articles/ldap-auth/_index.adoc new file mode 100644 index 0000000000..0559e6f0ee --- /dev/null +++ b/documentation/content/ru/articles/ldap-auth/_index.adoc @@ -0,0 +1,703 @@ +--- +authors: + - + author: 'Toby Burress' + email: kurin@causa-sui.net +copyright: '2007-2008 The FreeBSD Documentation Project' +description: 'Руководство по настройке сервера LDAP для аутентификации в FreeBSD' +tags: ["LDAP", "Authentication", "OpenLDAP", "configuration", "guide", "tutorial", "FreeBSD"] +title: 'Аутентификация LDAP' +trademarks: ["freebsd", "general"] +--- + += Аутентификация LDAP +:doctype: article +:toc: macro +:toclevels: 1 +:icons: font +:sectnums: +:sectnumlevels: 6 +:source-highlighter: rouge +:experimental: +:images-path: articles/ldap-auth/ + +ifdef::env-beastie[] +ifdef::backend-html5[] +include::shared/authors.adoc[] +include::shared/mirrors.adoc[] +include::shared/releases.adoc[] +include::shared/attributes/attributes-{{% lang %}}.adoc[] +include::shared/{{% lang %}}/teams.adoc[] +include::shared/{{% lang %}}/mailing-lists.adoc[] +include::shared/{{% lang %}}/urls.adoc[] +:imagesdir: ../../../images/{images-path} +endif::[] +ifdef::backend-pdf,backend-epub3[] +include::../../../../shared/asciidoctor.adoc[] +endif::[] +endif::[] + +ifndef::env-beastie[] +include::../../../../../shared/asciidoctor.adoc[] +endif::[] + +[.abstract-title] +Аннотация + +Этот документ является руководством по настройке сервера LDAP (в основном сервера OpenLDAP) для аутентификации в FreeBSD. Это полезно в ситуациях, когда множество серверов требуют одинаковых учётных записей пользователей, например, в качестве замены NIS. + +''' + +toc::[] + +[[preface]] +== Предисловие + +Этот документ предназначен для того, чтобы дать читателю достаточно знаний о LDAP для настройки сервера LDAP. В документе будет предпринята попытка объяснить использование package:net/nss_ldap[] и package:security/pam_ldap[] для клиентских машин, работающих с сервером LDAP. + +По завершении читатель должен уметь настроить и развернуть сервер FreeBSD, способный размещать каталог LDAP, а также настроить и развернуть сервер FreeBSD, который может проходить аутентификацию с использованием каталога LDAP. + +Эта статья не претендует на исчерпывающее описание вопросов безопасности, надежности или лучших практик настройки LDAP и других обсуждаемых здесь сервисов. Хотя автор старается делать всё правильно, вопросы безопасности рассматриваются лишь в общих чертах. Данная статья должна рассматриваться только как теоретическая основа, а любая реальная реализация должна сопровождаться тщательным анализом требований. + +[[ldap]] +== Настройка LDAP + +LDAP означает "Lightweight Directory Access Protocol" (облегчённый протокол доступа к каталогам) и является подмножеством X.500 Directory Access Protocol. Последние спецификации можно найти в http://www.ietf.org/rfc/rfc4510.txt[RFC4510] и связанных документах. По сути, это база данных, которая предполагает более частые операции чтения, чем записи. + +В примерах в этом документе будет использоваться LDAP-сервер http://www.openldap.org/[OpenLDAP]; хотя принципы, изложенные здесь, должны быть применимы к различным серверам, большая часть конкретных административных действий специфична для OpenLDAP. В портах доступно несколько версий сервера, например package:net/openldap26-server[]. Клиентские серверы потребуют соответствующие библиотеки package:net/openldap26-client[]. + +Существуют (в основном) две области службы LDAP, которые требуют настройки. Первая — настройка сервера для правильного приёма соединений, а вторая — добавление записей в каталог сервера, чтобы инструменты FreeBSD знали, как с ним взаимодействовать. + +[[ldap-connect]] +=== Настройка сервера для подключений + +[NOTE] +==== +Этот раздел относится конкретно к OpenLDAP. Если вы используете другой сервер, вам необходимо обратиться к документации этого сервера. +==== + +[[ldap-connect-install]] +==== Установка OpenLDAP + +Сначала установите OpenLDAP: + +[[oldap-install]] +.Установка OpenLDAP +[example] +==== + +[source, shell] +.... +# cd /usr/ports/net/openldap26-server +# make install clean +.... + +==== + +Это устанавливает бинарные файлы `slapd` и `slurpd`, а также необходимые библиотеки OpenLDAP. + +[[ldap-connect-config]] +==== Настройка OpenLDAP + +Далее мы должны настроить OpenLDAP. + +Вам следует требовать шифрование соединений с сервером LDAP; в противном случае пароли ваших пользователей будут передаваться в открытом виде, что считается небезопасным. Инструменты, которые мы будем использовать, поддерживают два очень похожих типа шифрования: SSL и TLS. + +TLS означает "Transportation Layer Security". Службы, использующие TLS, обычно подключаются к тем же портам, что и аналогичные службы без TLS; таким образом, SMTP-сервер с поддержкой TLS будет ожидать подключений на порту 25, а LDAP-сервер — на порту 389. + +SSL означает «Secure Sockets Layer», и службы, реализующие SSL, _не_ работают на тех же портах, что и их аналоги без SSL. Таким образом, SMTPS использует порт 465 (а не 25), HTTPS — порт 443, а LDAPS — порт 636. + +Причина, по которой SSL использует другой порт, чем TLS, заключается в том, что соединение TLS начинается как обычный текст и переключается на зашифрованный трафик после директивы `STARTTLS`. Соединения SSL зашифрованы с самого начала. Кроме этого, существенных различий между ними нет. + +[NOTE] +==== +Мы настроим OpenLDAP для использования TLS, так как SSL считается устаревшим. +==== + +После установки OpenLDAP через порты следующие параметры конфигурации в [.filename]#/usr/local/etc/openldap/slapd.conf# включат TLS: + +[.programlisting] +.... +security ssf=128 + +TLSCertificateFile /path/to/your/cert.crt +TLSCertificateKeyFile /path/to/your/cert.key +TLSCACertificateFile /path/to/your/cacert.crt +.... + +В этом примере `ssf=128` указывает OpenLDAP требовать 128-битное шифрование для всех соединений, как для поиска, так и для обновления. Этот параметр может быть настроен в соответствии с требованиями безопасности вашего сайта, но ослаблять его требуется редко, так как большинство библиотек LDAP-клиентов поддерживают стойкое шифрование. + +Файлы [.filename]#cert.crt#, [.filename]#cert.key# и [.filename]#cacert.crt# необходимы для аутентификации клиентами _вас_ как действительного LDAP-сервера. Если вам просто нужен работающий сервер, вы можете создать самоподписанный сертификат с помощью OpenSSL: + +[[genrsa]] +.Генерация RSA-ключа +[example] +==== + +[source, shell] +.... +% openssl genrsa -out cert.key 1024 +Generating RSA private key, 1024 bit long modulus +....................++++++ +...++++++ +e is 65537 (0x10001) + +% openssl req -new -key cert.key -out cert.csr +.... + +==== + +На этом этапе вам будет предложено ввести некоторые значения. Вы можете ввести любые значения, какие пожелаете; однако важно, чтобы значение "Common Name" (Общее имя) было полным доменным именем сервера OpenLDAP. В нашем случае и в приведённых примерах сервер называется _server.example.org_. Неправильное указание этого значения может привести к сбоям при подключении клиентов. Это может стать причиной серьёзных проблем, поэтому внимательно следуйте этим шагам. + +Наконец, запрос на подпись сертификата должен быть подписан: + +[[self-sign]] +.Самостоятельная подпись сертификата +[example] +==== + +[source, shell] +.... +% openssl x509 -req -in cert.csr -days 365 -signkey cert.key -out cert.crt +Signature ok +subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd +Getting Private key +.... + +==== + +Это создаст самоподписанный сертификат, который можно использовать для директив в [.filename]#slapd.conf#, где [.filename]#cert.crt# и [.filename]#cacert.crt# представляют собой один и тот же файл. Если вы планируете использовать множество серверов OpenLDAP (для репликации через `slurpd`), рекомендуется ознакомиться с разделом crossref:ldap-auth[ssl-ca, Сертификаты OpenSSL для LDAP], чтобы сгенерировать ключ центра сертификации (CA) и использовать его для подписи индивидуальных сертификатов серверов. + +После этого добавьте следующее в [.filename]#/etc/rc.conf#: + +[.programlisting] +.... +slapd_enable="YES" +.... + +Затем выполните `/usr/local/etc/rc.d/slapd start`. Это должно запустить OpenLDAP. Убедитесь, что он слушает порт 389 с помощью + +[source, shell] +.... +% sockstat -4 -p 389 +ldap slapd 3261 7 tcp4 *:389 *:* +.... + +[[ldap-connect-client]] +==== Настройка клиента + +Установите порт package:net/openldap26-client[] для библиотек OpenLDAP. Клиентские машины всегда будут иметь библиотеки OpenLDAP, так как они содержатся в пакетах package:security/pam_ldap[] и package:net/nss_ldap[], по крайней мере, на данный момент. + +Файл конфигурации для библиотек OpenLDAP — это [.filename]#/usr/local/etc/openldap/ldap.conf#. Отредактируйте этот файл, указав следующие значения: + +[.programlisting] +.... +base dc=example,dc=org +uri ldap://server.example.org/ +ssl start_tls +tls_cacert /path/to/your/cacert.crt +.... + +[NOTE] +==== +Важно, чтобы у ваших клиентов был доступ к [.filename]#cacert.crt#, иначе они не смогут подключиться. +==== + +[NOTE] +==== +Существует два файла с именем [.filename]#ldap.conf#. Первый — это данный файл, предназначенный для библиотек OpenLDAP и определяющий, как взаимодействовать с сервером. Второй — [.filename]#/usr/local/etc/ldap.conf#, используется pam_ldap. +==== + +На этом этапе вы должны быть в состоянии выполнить `ldapsearch -Z` на клиентской машине; `-Z` означает "использовать TLS". Если вы столкнётесь с ошибкой, значит что-то настроено неправильно; скорее всего, проблема в ваших сертификатах. Используйте `s_client` и `s_server` из man:openssl[1], чтобы убедиться, что они правильно настроены и подписаны. + +[[ldap-database]] +=== Записи в базе данных + +Аутентификация в каталоге LDAP обычно выполняется путем попытки привязаться к каталогу как подключающийся пользователь. Это делается путем установки "простой" привязки к каталогу с предоставленным именем пользователя. Если существует запись с `uid`, равным имени пользователя, и атрибут `userPassword` этой записи совпадает с предоставленным паролем, то привязка проходит успешно. + +Первое, что нам нужно сделать, — это определить, где в каталоге будут находиться наши пользователи. + +Базовой записью для нашей базы данных является `dc=example,dc=org`. Стандартное расположение пользователей, которое ожидает большинство клиентов, выглядит примерно как `ou=people,_base_`, поэтому здесь будет использоваться именно это. Однако следует помнить, что это настраивается. + +Таким образом, запись ldif для организационного подразделения `people` будет выглядеть следующим образом: + +[.programlisting] +.... +dn: ou=people,dc=example,dc=org +objectClass: top +objectClass: organizationalUnit +ou: people +.... + +Все пользователи будут созданы как подразделы этой организационной единицы. + +Некоторые размышления стоит посвятить классу объектов, к которому будут принадлежать ваши пользователи. Большинство инструментов по умолчанию используют `people`, что подходит, если вам просто нужно предоставить записи для аутентификации. Однако, если вы также собираетесь хранить информацию о пользователях в базе данных LDAP, вам, вероятно, стоит использовать `inetOrgPerson`, который имеет множество полезных атрибутов. В любом случае, соответствующие схемы должны быть загружены в [.filename]#slapd.conf#. + +Для этого примера мы будем использовать класс объекта `person`. Если вы используете `inetOrgPerson`, шаги практически идентичны, за исключением того, что атрибут `sn` является обязательным. + +Чтобы добавить тестового пользователя с именем `tuser`, ldif-файл должен выглядеть так: + +[.programlisting] +.... +dn: uid=tuser,ou=people,dc=example,dc=org +objectClass: person +objectClass: posixAccount +objectClass: shadowAccount +objectClass: top +uidNumber: 10000 +gidNumber: 10000 +homeDirectory: /home/tuser +loginShell: /bin/csh +uid: tuser +cn: tuser +.... + +Я начинаю UID пользователей LDAP с 10000, чтобы избежать конфликтов с системными учётными записями; вы можете настроить любое число здесь, при условии что оно меньше 65536. + +Также необходимы записи групп. Они настраиваются так же, как записи пользователей, но мы будем использовать стандартные значения, приведённые ниже: + +[.programlisting] +.... +dn: ou=groups,dc=example,dc=org +objectClass: top +objectClass: organizationalUnit +ou: groups + +dn: cn=tuser,ou=groups,dc=example,dc=org +objectClass: posixGroup +objectClass: top +gidNumber: 10000 +cn: tuser +.... + +Чтобы добавить их в вашу базу данных, вы можете использовать `slapadd` или `ldapadd` для файла, содержащего эти записи. Альтернативно, вы можете использовать package:sysutils/ldapvi[]. + +Утилита `ldapsearch` на клиентской машине теперь должна возвращать эти записи. Если это так, ваша база данных правильно настроена для использования в качестве сервера аутентификации LDAP. + +[[client]] +== Конфигурация клиента + +Клиент уже должен иметь библиотеки OpenLDAP из crossref:ldap-auth[ldap-connect-client,Настройка клиента], но если вы устанавливаете несколько клиентских машин, вам потребуется установить package:net/openldap26-client[] на каждой из них. + +Для аутентификации на сервере LDAP в FreeBSD необходимо установить два порта: package:security/pam_ldap[] и package:net/nss_ldap[]. + +[[client-auth]] +=== Аутентификация + +package:security/pam_ldap[] настраивается через [.filename]#/usr/local/etc/ldap.conf#. + +[NOTE] +==== +Это _другой файл_, отличный от файла конфигурации библиотечных функций OpenLDAP, [.filename]#/usr/local/etc/openldap/ldap.conf#; однако он принимает многие из тех же параметров; фактически он является надмножеством этого файла. В оставшейся части этого раздела ссылки на [.filename]#ldap.conf# будут означать [.filename]#/usr/local/etc/ldap.conf#. +==== + +Таким образом, мы захотим скопировать все исходные параметры конфигурации из [.filename]#openldap/ldap.conf# в новый [.filename]#ldap.conf#. После этого нам нужно указать package:security/pam_ldap[], что искать на сервере каталогов. + +Мы идентифицируем наших пользователей с помощью атрибута `uid`. Чтобы настроить это (хотя это значение по умолчанию), укажите директиву `pam_login_attribute` в [.filename]#ldap.conf#: + +[[set-pam-login-attr]] +.Установка `pam_login_attribute` +[example] +==== + +[.programlisting] +.... +pam_login_attribute uid +.... + +==== + +С таким набором, package:security/pam_ldap[] будет искать во всей LDAP-директории под `base` значение `uid=_имя_пользователя_`. Если оно найдёт одну и только одну запись, будет предпринята попытка привязаться к этой записи с использованием предоставленного пароля. Если привязка произойдёт успешно, доступ будет разрешён. В противном случае доступ будет запрещён. + +Пользователи, чья оболочка не указана в [.filename]#/etc/shells#, не смогут войти в систему. Это особенно важно, когда Bash установлен как оболочка пользователя на сервере LDAP. Bash не входит в стандартную установку FreeBSD. При установке из пакета или порта, он располагается в [.filename]#/usr/local/bin/bash#. Убедитесь, что путь к оболочке на сервере указан правильно: + +[source, shell] +.... +% getent passwd username +.... + +Если в последнем столбце вывода указан `/bin/bash`, есть два варианта действий. Первый — изменить запись пользователя на сервере LDAP на [.filename]#/usr/local/bin/bash#. Второй вариант — создать символическую ссылку на клиентском компьютере LDAP, чтобы Bash находился в правильном месте: + +[source, shell] +.... +# ln -s /usr/local/bin/bash /bin/bash +.... + +Убедитесь, что файл [.filename]#/etc/shells# содержит записи для `/usr/local/bin/bash` и `/bin/bash`. После этого пользователь сможет входить в систему с Bash в качестве оболочки. + +[[client-auth-pam]] +==== PAM + +PAM, что означает "Pluggable Authentication Modules" (подключаемые модули аутентификации), является методом, с помощью которого FreeBSD аутентифицирует большинство своих сеансов. Чтобы указать FreeBSD, что мы хотим использовать LDAP-сервер, нам необходимо добавить строку в соответствующий файл PAM. + +В большинстве случаев подходящий файл PAM — это [.filename]#/etc/pam.d/sshd#, если вы хотите использовать SSH (не забудьте установить соответствующие параметры в [.filename]#/etc/ssh/sshd_config#, иначе SSH не будет использовать PAM). + +Чтобы использовать PAM для аутентификации, добавьте строку + +[.programlisting] +.... +auth sufficient /usr/local/lib/pam_ldap.so no_warn +.... + +Строгое место, где эта строка появляется в файле, и какие опции указаны в четвертом столбце, определяют точное поведение механизма аутентификации; см. man:pam[d] + +С такой конфигурацией вы сможете аутентифицировать пользователя в LDAP-каталоге. PAM выполнит привязку с вашими учетными данными, и в случае успеха сообщит SSH разрешить доступ. + +Однако разрешать _каждому_ пользователю в каталоге доступ к _каждой_ клиентской машине — не лучшая идея. При текущей конфигурации пользователю для входа на машину достаточно наличия записи в LDAP. К счастью, есть несколько способов ограничить доступ пользователей. + +[.filename]#ldap.conf# поддерживает директиву `pam_groupdn`; каждая учётная запись, подключающаяся к этой машине, должна быть членом группы, указанной здесь. Например, если у вас есть + +[.programlisting] +.... +pam_groupdn cn=servername,ou=accessgroups,dc=example,dc=org +.... + +в [.filename]#ldap.conf#, тогда только члены этой группы смогут войти в систему. Однако есть несколько моментов, которые следует учитывать. + +Участники этой группы указываются в одном или нескольких атрибутах `memberUid`, и каждый атрибут должен содержать полное отличающееся имя участника. Таким образом, `memberUid: someuser` не сработает; необходимо указать: + +[.programlisting] +.... +memberUid: uid=someuser,ou=people,dc=example,dc=org +.... + +Кроме того, эта директива не проверяется в PAM во время аутентификации, она проверяется во время управления учётными записями, поэтому вам понадобится вторая строка в ваших PAM-файлах в разделе `account`. Это, в свою очередь, потребует, чтобы _каждый_ пользователь был указан в группе, что не обязательно соответствует нашим желаниям. Чтобы избежать блокировки пользователей, не находящихся в LDAP, следует включить атрибут `ignore_unknown_user`. Наконец, следует установить опцию `ignore_authinfo_unavail`, чтобы не оказаться заблокированным на каждом компьютере при недоступности LDAP-сервера. + +Ваш файл [.filename]#pam.d/sshd# может в итоге выглядеть так: + +[[pam]] +.Пример [.filename]#pam.d/sshd# +[example] +==== + +[.programlisting] +.... +auth required pam_nologin.so no_warn +auth sufficient pam_opie.so no_warn no_fake_prompts +auth requisite pam_opieaccess.so no_warn allow_local +auth sufficient /usr/local/lib/pam_ldap.so no_warn +auth required pam_unix.so no_warn try_first_pass + +account required pam_login_access.so +account required /usr/local/lib/pam_ldap.so no_warn ignore_authinfo_unavail ignore_unknown_user +.... + +==== + +[NOTE] +==== +Поскольку мы добавляем эти строки конкретно в [.filename]#pam.d/sshd#, это повлияет только на SSH-сеансы. Пользователи LDAP не смогут войти через консоль. Чтобы изменить это поведение, изучите остальные файлы в [.filename]#/etc/pam.d# и измените их соответствующим образом. +==== + +[[client-nss]] +=== Name Service Switch + +NSS — это служба, которая сопоставляет атрибуты с именами. Например, если файл принадлежит пользователю `1001`, приложение запросит у NSS имя для `1001` и может получить `bob`, `ted` или любое другое имя пользователя. + +Теперь, когда информация о пользователях хранится в LDAP, необходимо указать NSS обращаться туда при запросах. + +Порт package:net/nss_ldap[] выполняет это. Он использует тот же конфигурационный файл, что и package:security/pam_ldap[], и после установки не должен требовать дополнительных параметров. Вместо этого остаётся просто отредактировать [.filename]#/etc/nsswitch.conf#, чтобы воспользоваться преимуществами каталога. Просто замените следующие строки: + +[.programlisting] +.... +group: compat +passwd: compat +.... + +строкой + +[.programlisting] +.... +group: files ldap +passwd: files ldap +.... + +Это позволит сопоставлять имена пользователей с UID и UID с именами пользователей. + +Поздравляем! Теперь у вас должна работать аутентификация через LDAP. + +[[caveats]] +=== Предостережения + +К сожалению, на момент написания этой документации FreeBSD не поддерживал изменение паролей пользователей с помощью man:passwd[1]. В результате большинству администраторов приходится самостоятельно реализовывать решение. Здесь я привожу несколько примеров. Обратите внимание, что если вы пишете собственный скрипт для смены пароля, вам следует учитывать некоторые проблемы безопасности; см. crossref:ldap-auth[security-passwd, Хранение паролей] + +[[chpw-shell]] +.Скрипт оболочки для изменения паролей +[example] +==== + +[.programlisting] +.... +#!/bin/sh + +stty -echo +read -p "Old Password: " oldp; echo +read -p "New Password: " np1; echo +read -p "Retype New Password: " np2; echo +stty echo + +if [ "$np1" != "$np2" ]; then + echo "Passwords do not match." + exit 1 +fi + +ldappasswd -D uid="$USER",ou=people,dc=example,dc=org \ + -w "$oldp" \ + -a "$oldp" \ + -s "$np1" +.... + +==== + +[CAUTION] +==== + +Этот скрипт почти не проверяет ошибки, что более важно, он очень беспечен в том, как хранит ваши пароли. Если вы делаете что-то подобное, по крайней мере измените значение sysctl `security.bsd.see_other_uids`: + +[source, shell] +.... +# sysctl security.bsd.see_other_uids=0 +.... + +==== + +Более гибкий (и, вероятно, более безопасный) подход может быть реализован путем написания собственной программы или даже веб-интерфейса. Ниже приведена часть библиотеки на Ruby, которая позволяет изменять пароли в LDAP. Она используется как в командной строке, так и в вебе. + +[[chpw-ruby]] +.Ruby-скрипт для изменения паролей +[example] +==== + +[.programlisting] +.... +require 'ldap' +require 'base64' +require 'digest' +require 'password' # ruby-password + +ldap_server = "ldap.example.org" +luser = "uid=#{ENV['USER']},ou=people,dc=example,dc=org" + +# get the new password, check it, and create a salted hash from it +def get_password + pwd1 = Password.get("New Password: ") + pwd2 = Password.get("Retype New Password: ") + + raise if pwd1 != pwd2 + pwd1.check # check password strength + + salt = rand.to_s.gsub(/0\./, '') + pass = pwd1.to_s + hash = "{SSHA}"+Base64.encode64(Digest::SHA1.digest("#{pass}#{salt}")+salt).chomp! + return hash +end + +oldp = Password.get("Old Password: ") +newp = get_password + +# We'll just replace it. That we can bind proves that we either know +# the old password or are an admin. + +replace = LDAP::Mod.new(LDAP::LDAP_MOD_REPLACE | LDAP::LDAP_MOD_BVALUES, + "userPassword", + [newp]) + +conn = LDAP::SSLConn.new(ldap_server, 389, true) +conn.set_option(LDAP::LDAP_OPT_PROTOCOL_VERSION, 3) +conn.bind(luser, oldp) +conn.modify(luser, [replace]) +.... + +==== + +Хотя это не гарантирует отсутствия уязвимостей (например, пароль хранится в памяти), данный подход чище и гибче, чем простой скрипт на `sh`. + +[[secure]] +== Безопасность + +Теперь, когда ваши машины (и, возможно, другие службы) проходят аутентификацию через ваш LDAP-сервер, этот сервер необходимо защитить как минимум так же, как [.filename]#/etc/master.passwd# на обычном сервере, а возможно, и лучше, поскольку сломанный или взломанный LDAP-сервер нарушит работу всех клиентских служб. + +Помните, что этот раздел не является исчерпывающим. Вам следует постоянно пересматривать свою конфигурацию и процедуры для улучшений. + +[[secure-readonly]] +=== Установка атрибутов только для чтения + +Некоторые атрибуты в LDAP должны быть доступны только для чтения. Если оставить их доступными для записи пользователем, например, пользователь может изменить свой атрибут `uidNumber` на `0` и получить доступ `root`! + +Для начала атрибут `userPassword` не должен быть доступен для чтения всем. По умолчанию любой, кто может подключиться к LDAP-серверу, может читать этот атрибут. Чтобы отключить это, добавьте следующее в [.filename]#slapd.conf#: + +[[hide-userpass]] +.Скрыть пароли +[example] +==== + +[.programlisting] +.... +access to dn.subtree="ou=people,dc=example,dc=org" + attrs=userPassword + by self write + by anonymous auth + by * none + +access to * + by self write + by * read +.... + +==== + +Это запретит чтение атрибута `userPassword`, но позволит пользователям изменять свои собственные пароли. + +Кроме того, следует запретить пользователям изменять некоторые из своих атрибутов. По умолчанию пользователи могут изменять любые атрибуты (за исключением тех, которые сами схемы LDAP запрещают изменять), такие как `uidNumber`. Чтобы устранить эту уязвимость, измените приведённое выше на + +[[attrib-readonly]] +.Атрибуты только для чтения +[example] +==== + +[.programlisting] +.... +access to dn.subtree="ou=people,dc=example,dc=org" + attrs=userPassword + by self write + by anonymous auth + by * none + +access to attrs=homeDirectory,uidNumber,gidNumber + by * read + +access to * + by self write + by * read +.... + +==== + +Это предотвратит возможность пользователей маскироваться под других пользователей. + +[[secure-root]] +=== Определение учетной записи `root` + +Часто учетная запись `root` или администратора для службы LDAP будет определена в файле конфигурации. Например, OpenLDAP поддерживает это, и это работает, но может привести к проблемам, если файл [.filename]#slapd.conf# будет скомпрометирован. Возможно, лучше использовать это только для первоначальной настройки доступа к LDAP, а затем определить учетную запись `root` там. + +Еще лучше определить учетные записи с ограниченными правами и полностью исключить учетную запись `root`. Например, пользователи, которые могут добавлять или удалять учетные записи, добавляются в одну группу, но сами не могут изменять состав этой группы. Такая политика безопасности поможет снизить последствия утечки пароля. + +[[manager-acct]] +==== Создание группы управления + +Предположим, вы хотите, чтобы ваш IT-отдел мог изменять домашние каталоги пользователей, но не хотите, чтобы все они могли добавлять или удалять пользователей. Способ сделать это — добавить группу для этих администраторов: + +[[manager-acct-dn]] +.Создание группы управления +[example] +==== + +[.programlisting] +.... +dn: cn=homemanagement,dc=example,dc=org +objectClass: top +objectClass: posixGroup +cn: homemanagement +gidNumber: 121 # required for posixGroup +memberUid: uid=tuser,ou=people,dc=example,dc=org +memberUid: uid=user2,ou=people,dc=example,dc=org +.... + +==== + +И затем измените атрибуты прав в [.filename]#slapd.conf#: + +[[management-acct-acl]] +.ACL для группы управления домашним каталогом +[example] +==== + +[.programlisting] +.... +access to dn.subtree="ou=people,dc=example,dc=org" + attr=homeDirectory + by dn="cn=homemanagement,dc=example,dc=org" + dnattr=memberUid write +.... + +==== + +Теперь `tuser` и `user2` могут изменять домашние каталоги других пользователей. + +В этом примере мы предоставили подмножество административных полномочий определённым пользователям, не давая им власти в других областях. Идея заключается в том, чтобы вскоре ни одна учётная запись пользователя не обладала полномочиями учётной записи `root`, но каждое полномочие, которое имел root, было бы у хотя бы одного пользователя. Учётная запись `root` тогда становится ненужной и может быть удалена. + +[[security-passwd]] +=== Хранение паролей + +По умолчанию OpenLDAP сохраняет значение атрибута `userPassword` так же, как и любые другие данные: в открытом виде. В большинстве случаев оно кодируется в base64, что обеспечивает достаточную защиту, чтобы честный администратор не узнал ваш пароль, но не более того. + +Хорошей идеей является хранение паролей в более безопасном формате, таком как SSHA (солёный SHA). Это выполняется любой программой, которую вы используете для изменения паролей пользователей. + +:sectnums!: + +[appendix] +[[useful]] +== Полезные инструменты + +Вот несколько других программ, которые могут быть полезны, особенно если у вас много пользователей и вы не хотите настраивать всё вручную. + +package:security/pam_mkhomedir[] — это модуль PAM, который всегда завершается успешно; его назначение — создавать домашние каталоги для пользователей, у которых их нет. Если у вас есть десятки серверов-клиентов и сотни пользователей, гораздо удобнее использовать этот модуль и настроить скелетные каталоги, чем подготавливать каждый домашний каталог вручную. + +package:sysutils/ldapvi[] — это отличная утилита для редактирования значений LDAP в синтаксисе, подобном LDIF. Каталог (или его подраздел) отображается в редакторе, выбранном переменной окружения `EDITOR`. Это позволяет легко вносить масштабные изменения в каталог без необходимости написания собственного инструмента. + +package:security/openssh-portable[] обладает возможностью обращаться к серверу LDAP для проверки SSH-ключей. Это очень удобно, если у вас много серверов и вы не хотите копировать свои открытые ключи на все из них. + +:sectnums!: + +[appendix] +[[ssl-ca]] +== Сертификаты OpenSSL для LDAP + +Если вы размещаете два или более LDAP-серверов, вам, вероятно, не захочется использовать самоподписанные сертификаты, так как каждый клиент придется настраивать для работы с каждым сертификатом. Хотя это возможно, это не так просто, как создать собственный центр сертификации и подписать сертификаты ваших серверов с его помощью. + +Шаги здесь представлены как есть, без попыток объяснить происходящее — дополнительные пояснения можно найти в man:openssl[1] и связанных справочных страницах. + +Для создания центра сертификации нам просто нужны самоподписанный сертификат и ключ. Шаги для этого следующие + +[[make-cert]] +.Создание сертификата +[example] +==== + +[source, shell] +.... +% openssl genrsa -out root.key 1024 +% openssl req -new -key root.key -out root.csr +% openssl x509 -req -days 1024 -in root.csr -signkey root.key -out root.crt +.... + +==== + +Это будут корневой ключ и сертификат ЦС. Возможно, вы захотите зашифровать ключ и хранить его в прохладном, сухом месте; любой, кто получит к нему доступ, сможет выдавать себя за один из ваших LDAP-серверов. + +Затем, используя первые два шага, описанные выше, создайте ключ [.filename]#ldap-server-one.key# и запрос на подпись сертификата [.filename]#ldap-server-one.csr#. После подписания запроса с помощью [.filename]#root.key# вы сможете использовать [.filename]#ldap-server-one.*# на своих LDAP-серверах. + +[NOTE] +==== +Не забудьте использовать полное доменное имя для атрибута "common name" при создании запроса на подпись сертификата; в противном случае клиенты будут отклонять соединение с вами, и диагностика этой проблемы может быть очень сложной. +==== + +Для подписи ключа используйте `-CA` и `-CAkey` вместо `-signkey`: + +[[ca-sign]] +.Подписывать как Центр Сертификации +[example] +==== + +[source, shell] +.... +% openssl x509 -req -days 1024 \ +-in ldap-server-one.csr -CA root.crt -CAkey root.key \ +-out ldap-server-one.crt +.... + +==== + +Результирующий файл будет представлять собой сертификат, который можно использовать на ваших LDAP-серверах. + +Наконец, чтобы клиенты доверяли всем вашим серверам, распространите файл [.filename]#root.crt# (__сертификат__, а не ключ!) на каждом клиенте и укажите его в директиве `TLSCACertificateFile` в файле [.filename]#ldap.conf#. |