aboutsummaryrefslogtreecommitdiff
path: root/documentation/content/ru/articles/ldap-auth/_index.adoc
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/content/ru/articles/ldap-auth/_index.adoc')
-rw-r--r--documentation/content/ru/articles/ldap-auth/_index.adoc703
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#.