Организуем хранение ключей OpenSSH в центральном сервере OpenLDAP

Виталий Банковский

Организуем хранение ключей OpenSSH в центральном сервере OpenLDAP

Последние обновления операционных систем, брандмауэры... Снаружи наша система – неприступный бастион. А изнутри? Редко меняющиеся и «расползающиеся» пароли, приходящие и уходящие пользователи, пересылка паролей по незащищеным каналам... Знакомо? Тогда эта статья для вас.

Многие системные администраторы, которые назначают пароли системным учетным записям на серверах, а затем раздают их пользователям (например, программистам и дизайнерам), сталкиваются с проблемой «расползания» паролей среди пользователей. И в результате невозможно определить, какие пользователи к какому ресурсу имеют доступ. К тому же, если используются пароли, то их необходимо менять каждые несколько месяцев, и при рассылке обновленных паролей существует опасность их «утечки».

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

Затем я некоторое время использовал инструмент для централизованного управления серверами cfengine для копирования ключей пользователей на сервера. Но при этом возникла проблема, что из-за сложности cfengine системные администраторы 3-го и 4-го уровней не могли управлять аккредитацией пользователей.

К тому же из-за хранения ключей во множественных файлах на множественных серверах бывает проблематично определить, к каким ресурсам имеет доступ тот или иной пользователь, и, например, в случае ухода пользователя или утери приватного ключа есть вероятность «прозевать» какой-либо файл с этим ключом.

Конечно, можно было бы написать несколько простейших скриптов, которые раскладывали бы ключи по серверам и уничтожали бы неизвестные ключи. Но такие «самопальные» скрипты, как показывает практика, требуют немало времени на сопровождение при расширении систем, тестирование, документирование и обучение коллег системных администраторов, которые должны обеспечить работу этих скриптов в случае отсутствия разработчика.

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

После некоторого исследования был обнаружен патч для OpenSSH, который позволяет последнему обращаться к службе каталогов LDAP.

Каждая запись в каталоге состоит из одного или нескольких атрибутов и определяется уникальным именем (DN – Distinguished Name), например, «cn=John Smith, ou=People, dc=example, dc=com».

Уникальное имя состоит из нескольких относительных уникальных имен (RDN – Relative Distinguished Name), разделённых запятой, которые и определяют положение записи в иерархии каталогов LDAP, где на верхнем уровне, например, находится имя страны, где расположена компания, затем название  компании, подразделение и, наконец, список работников.

Для простоты службу каталогов с демоном OpenLDAP будем называть сервер LDAP, что включает в себя:

• сервер с операционной системой;
• базу данных каталога;
• демон, который обрабатывает запросы по протоколу LDAP.

Статья была написана исходя из опыта установки и эксплуатации системы на Linux-дистрибутивах CentOS 4.1, CentOS 4.4, RedHat 7.3, Redhat 8.

В качестве сервера OpenLDAP использовался программный пакет OpenLDAP, полученный по адресу одноименного проекта: http://openldap.org.

На серверах-клиентах использовался пакет OpenSSH, доступ к которому можно получить по адресу проекта: http://openssh.org.

Так как в такие дистрибутивы, как RedHat 7.3, RedHat 8.0, входят устаревшие версии пакетов, то мне пришлось устанавливать их из исходных кодов.

К тому же использование пакетов с «родных» сайтов позволяет оперативно обновлять серверы, не ожидая обновлений от производителей дистрибутивов, что, на мой взгляд, является очень важным преимуществом при использовании таких критических приложений, как openLDAP.

Настройка сертификатов и TLS

Сервер OpenLDAP при условии компиляции поддержки TLS/SSL позволяет создавать шифрованные каналы между демоном OpenLDAP и клиентами.

И хотя в нашей базе данных не хранится потенциально небезопасная информация (например, пароли), но если OpenLDAP-сервер расположен на удаленной площадке, то при прохождении через транзитные узлы существует вероятность утечки имен пользователей и их адресов электронной почты. И эта информация может служить хорошим подспорьем для взлома с использованием социальной инженерии.

Также есть опасность подделки IP-адреса сервера OpenLDAP, захвата IP-адреса сервера OpenLDAP хакером, изменения таблицы ARP на коммутаторе и запуска поддельного сервера OpenLDAP на подконтрольном хакеру сервере, например, на соседнем сервере с вашим. Тогда в этом случае хакер может внести его собственный ключ в директорию для получения доступа к серверу-клиенту.

Исходя из этого необходимо включить поддержку SSL/TLS в сервере OpenLDAP, сгенерировать сертификаты и настроить клиентов таким образом, чтобы они обрывали соединение с сервером OpenLDAP в случае получения поддельного сертификата.

Здесь стоит пояснить, как работает проверка. При проверке сертификата клиент проверяет организацию, которая подписала сертификат. Если центр сертификации (certificate authority, CA) неизвестен клиенту (отсутствует сертификат самого CA), то клиент не доверяет этому центру и, как следствие, не доверяет сертификату.

На данный момент существует около 10-12 доверенных центров сертификации (Equifax, Verisign и т. д). Стоимость подписания сертификатов в этих центрах составляет от 50  до 500 долларов США.

Но есть возможность создать собственный CA, для которого мы создадим самоподписанный сертификат, который мы и распространим по клиентам. Таким образом, клиенты будут доверять сертификатам, подписанным нашим CA.

Далее приведены шаги, которые необходимо предпринять для создания собственного CA и подписать сертификаты.

В состав программного пакета openSSL входит скрипт CA.sh, который значительно упрощает создание сертификатов.

Создать директорию, где будут хранится рабочие файлы сертификатов:

mkdir certs; cd certs

Создать файлы, необходимые для нашего собственного CA:

CA.sh -newca

В результате будет создан каталог demoCA, где будет лежать сертификат cacert.pem нашего CA.

Сгенерировать запрос на сертификат:

openssl req -new -nodes -keyout newreq.pem -out newreq.pem

В результате получим файл newreq.pem, состоящий из двух частей: приватный ключ сертификата и запрос (request) на сертификат.

При подписании (следующий шаг) OpenSSL использует часть файла, который содержит запрос (request) на сертификат.

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

Подписываем сертификат с помощью нашего CA. В процессе создания сертификата будет предложено ввести «Common name». Введенное имя должно совпадать с адресом сервера OpenLDAP, указанного в ldap.conf, иначе клиент OpenLDAP откажется работать с этим сертификатом:

CA.sh -newca

В результате будет создан файл newcert.pem, который содержит сертификат нашего сервера OpenLDAP. Здесь обращу ваше внимание на то,  что, хотя оба файла расположены на сервере OpenLDAP, при подключении к серверу OpenLDAP клиентам отдается содержимое только файла newcert.pem.

Результирующие файлы и их описания приведены в таблице 1.

Таблица 1. Файлы сертификации

Далее копируем сертификат и его ключ на сервер OpenLDAP:

cp newreq.pem /usr/local/etc/openldap/certs/slapd.key

cp newcert.pem /usr/local/etc/openldap/certs/slapd.cert

Копируем файл (DemoCA/cacert.pem) сертификата нашего CA на все серверы-клиенты в каталог, содержащий все сертификаты центров сертификации. Текущее расположение каталога можно посмотреть, открыв системный файл ldap.conf и найдя в нем параметр «TLS_CACERTDIR». Если такого параметра еще нет, то его необходимо добавить, как показано ниже:

TLS_CACERTDIR /etc/cacerts/

После копирования сертификата нашего CA следует указать библиотеке OpenSSL на необходимость создания/обновления хэшей сертификатов, находящихся в данном каталоге. Для этого воспользуемся утилитой c_rehash, входящей в состав пакета OpenSSL:

c_rehash /etc/cacets/

Обращаю внимание, что если уже используется параметр TLS_CACERT с указанием корневого сертификата CA, отличного от нашего, то его нужно расположить до параметра TLS_CACERTDIR.

Далее создаем файл openssh-ldap.conf, содержащий настройки LDAP для демона OpenSSH. Ниже приведена базовая конфигурация такого файла, который я использую на своих серверах-клиентах.

# Корневая структура каталога

BASE dc=example,dc=com

# Адреса LDAP-серверов. Указывается главный и запасной OpenLDAP-серверы.

# Подробности установки и использования такой схемы описываются в разделе

# «Репликация и вторичный сервер OpenLDAP»

URI ldap://ldap.example.com ldap://ldap2.example.com

# Переходить в режим шифрования после подсоединения к серверу openLDAP

ssl start_tls

Эта опция указывает клиентским приложениям сервера OpenLDAP обрывать сессию, если с последнего получен сертификат, не подписанный ни одним CA, которым мы доверяем.

Обращаю внимание, что включение этой опции может вызвать неработоспособность уже настроенного локального клиента OpenLDAP, если система обращается к серверам OpenLDAP с поддержкой шифрования, но при этом CA, который подписал сертификаты серверов OpenLDAP, нам неизвестен.

Есть три варианта решения этой проблемы – добавить этот неизвестный CA в /etc/cacerts, переподписать сертификаты нашим CA или скомпилировать библиотеку OpenLDAP для OpenSSH с использованием файла ldap.conf, отличного от системного.

Небольшой совет. При установке клиентских приложений (pam_ldap, Apache, ftp-серверов) зачастую возникает неразбериха с расположением файла ldap.conf. Одни программы пытаются найти его в каталоге /etc, другие – в каталогах /etc/openldap, /usr/local/etc/, /usr/local/etc/openldap и т. д. Для устранения этого недостатка я создал файл в /usr/local/etc/openldap/ и ссылки на него в каталог, в упомянутых выше клиентских приложениях.

Установка и настройка службы OpenLDAP

Раздел посвящен описанию процессов установки и настройки демона OpenLDAP, включения поддержки шифрования, инициализации каталога OpenLDAP, внесения учетных записей пользователей и работе с базой OpenLDAP с помощью скриптов, написанных на языке программирования Perl.

Компиляция и установка OpenLDAP

Получаем исходный код OpenLDAP с сервера http://openldap.org. После этого раскрываем архив, компилируем и устанавливаем:

tar -xzvf openldap-xxx.tgz

./configure --enable-bdb --with-tls –with-threads \

--disable-ipv6

make depend

make

make install

Необходимо включить шифрование TLS (Transport Layer Security, криптографический протокол) с помощью опции --with-tls для возможности установления безопасных соединений с серверов-клиентов к серверам OpenLDAP.

Перед установкой необходимо убедиться, что в системе установлены пакеты Berkeley Database и OpenSSL, включая библиотеки для разработки. Оба пакета можно получить по адресу: http://freshmeat.net или воспользоваться пакетным менеджером операционной системы.

Описание атрибутов записей в OpenLDAP

Служба OpenLDAP позволяет хранить в каталоге данные в различных форматах. Формат каждого типа записи определяется с помощью так называемой «схемы» (Schema). Например, файл nis.schema, входящий в пакет OpenLDAP, описывает такие атрибуты записей, как имя пользователя, пароль, его uid, gid и путь к домашнему каталогу.

Для хранения публичного ключа OpenSSH в записях пользователя необходимо расширить список атрибутов с помощью файла, описывающего атрибут sshPublicKey. Этот файл можно получить с родного сайта проекта по адресу http://dev.inversepath.com/openssh-lpk/openssh-lpk_openldap.schema. Этот файл нужно включить в конфигурационный файл сервера OpenLDAP, как описано в следующем разделе.

Настройка сервера OpenLDAP

По умолчанию, если OpenLDAP собран из исходников, то все настройки будут скопированы в папку /usr/local/etc/openldap. В дальнейшем при упоминании конфигурационных файлов, относящихся к openLDAP, будет подразумеваться, что они расположены в этой папке.

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

Конфигурация сервера OpenLDAP хранится в текстовом файле slapd.conf и состоит из двух или более частей: общие настройки и параметры определения баз данных OpenLDAP.

Далее приведены основные параметры этого файла, на которые необходимо обратить внимание:

Подключение схем, описывающих форматы и структуры данных, хранимых в каталоге OpenLDAP:

include  /usr/local/etc/openldap/schema/cosine.schema

include /usr/local/etc/openldap/schema/nis.schema

Подключить схему, описывающую атрибут «OpenSSH public key»:

include /usr/local/etc/openldap/schema/openssh-lpk_openldap.schema

Далее идут настройки TLS для предоставления шифрованного канала между серверами-клиентами и сервером OpenLDAP. Этот вопрос будет подробнее освещен в разделе «Настройка сертификатов и TLS».

Запрещаем требовать от клиента предоставления сертификата:

TLSVerifyClient never

Уровень шифрования. Определяет список алгоритмов шифрования по критерию шифростойкости. Значение «HIGH» указывает на необходимость использования алгоритмов, у которых длина ключа не менее 128 бит. Подробности о способах указания алгоритмов можно найти по адресу: http://www.openssl.org/docs/apps/ciphers.html.

TLSCipherSuite          HIGH

Пути к сертификату и его ключу:

TLSCertificateFile /usr/local/etc/openldap/certs/slapd.cert

TLSCertificateKeyFile  /usr/local/etc/openldap/certs/slapd.key

TLSCACertificateFile /etc/cacert.pem

Далее идут персональные настройки для базы данных. Тип базы данных. В данном случае я использовал Berkeley DB, хотя OpenLDAP поддерживает различные базы данных (MySQL, Oracle) через интерфейс ODBC:

database        bdb

Корневой уровень нашей иерархической базы данных OpenLDAP:

suffix          "dc=example,dc=com"

Имя суперпользователя, который имеет все права для управления базой:

rootdn          "cn=manager,dc=example,dc=com"

Пароль суперпользователя:

rootpw          super-user-pass

Путь к директории, где будет храниться база данных учетных записей:

directory       /var/openldap/unix-accounts

Индексация базы данных для ускорения поиска:

index       uidNumber,gidNumber,uid,cn,objectClass,memberUid eq

Для повышения производительности также необходимо создать файл DB_CONFIG в том же каталоге, где расположены файлы базы данных Berkley DB (в нашем варианте файл должен быть расположен в /var/openldap/unix-accounts). Этот файл содержит параметры кэширования базы данных. Ниже приведен пример такого файла:

# Обьем памяти, выделяемой для кэша:

# первое число – объем в гигабайтах;

# второе число – объем в мегабайтах;

# третье число – количество сегментов кэша.

# Если это число – больше единицы, то кэш будет разбит

# на указанное количество сегментов

set_cachesize   0       52428800        0

# Следующая секция - параметры для лог-файлов.

# Все значения указываются в байтах.

# Объем кэша для кэширования имен файлов, в байтах

set_lg_regionmax        1048576

# Максимальный размер лог-файлов. При превышении

# этого параметра произойдет ротация лог-файлов

set_lg_max              10485760

# Объем кэша для лог-файлов:

set_lg_bsize            2097152

# Путь к директории, где будут хранится лог-файлы

set_lg_dir              /var/log/openldap/

Далее вам необходимо создать каталог /var/log/openldap и поменять владельца этого каталога на пользователя, под которым запущен демон OpenLDAP.

Создание записей в базе OpenLDAP

Перед запуском сервера OpenLDAP необходимо создать запись, описывающую корневую структуру базы данных OpenLDAP.

Для этого создадим текстовый файл в формате LDIF (OpenLDAP Data Interchange Format, формат обмена данными директорий OpenLDAP), описывающий корневую структуру нашего каталога. На верхнем уровне будет располагаться описание нашей компании, на втором – описание группы пользователей.

# Описание компании

dn:   dc=example, dc=com

dc:   example

objectclass: dcObject

objectclass: organizationalUnit

ou: Our company name

# Описание группы пользователей, находящихся на третьем уровне иерархии

dn: ou=people, dc=example, dc=com

ou: people

objectclass: organizationalUnit

Далее нужно проинициализировать базу данных, используя эти первоначальные записи:

slapadd -l startup.ldif -v -f /usr/local/etc/openldap/slapd.conf

Запуск и проверка сервера OpenLDAP

На этом этапе нужно запустить демон службы OpenLDAP и проверить его работу, а также содержимое базы данных:

/usr/local/libexec/slapd

Для поиска записей в сервисе OpenLDAP служит утилита ldapsearch, пример использования которой приведен ниже:

ldapsearch -x -b 'dc=example,dc=com' -ZZ -H ldap://127.0.0.1

Параметры утилиты описаны в таблице 2.

Таблица 2. Параметры утилиты ldapsearch

Если все предыдущие шаги выполнены успешно, то в результате запуска утилиты мы должны увидеть описание нашей компании (уровень I) и описание группы пользователей:

Создание учетных записей

Как и в предыдущем случае, для введения новых записей нужно создать текстовый файл в формате LDIF.

Файл учетной записи chat-example-com:

dn: uid=chat-domain-com,ou=People,dc=example,dc=com

objectclass: top

objectclass: person

objectclass: organizationalPerson

objectclass: posixAccount

objectclass: ldapPublicKey

description: John Doe Account

userPassword: x

cn: John

sn: Doe

uid: chat-domain-com

uidNumber: 65535

gidNumber: 65535

homeDirectory: /home/chat-domain-com

sshPublicKey: ssh-rsa AAA...

sshPublicKey: ssh-rsa BBB...

В полях sshPublicKey нужно прописать публичные ключи пользователей, имеющих аккредитацию для данного ресурса, как в примере ниже:

ssh-rsa  AAAAB3NzaC1yc2EAAAADAQABAAABAQDxZpHyn4DqM5T6lxI/p4caUvf84cAXcqFkedbptW

TBpK4ADSMrCXNpiivZ5f5ZRDP6WcFmWfvnIPgfC/860xgXhU9I2n/fA+epxc6RqYOXZN3J

kBn0JhYWEt6GYpcBPVwV1ShoyA6oqKwx2PAzYaGwRpTTf7I3Ndxlkz2p4gBDwpN61V759O

/kWgrRg2kDwPxEDhmkKbMHTSZS3pt10U86bSVWMfr4Q9WqVc4AxrkaAiTZB6GCm2TUvYiM

MWQybnhTM2sx7KdihWiY31bIROcPiT+z5+oS/kCoy40gIlaHdGW7W2RPApeTzZxOZcflaN

d1myjHHkooDDByVbktPxfP info@example.com

Сгенерировать такой ключ можно с использованием утилиты ssh-keygen, входящей в состав пакета OpenSSH:

ssh-keygen -t rsa|dsa

В результате генерации ключа будет создан файл id_rsa.pub или id_dsa.pub, в котором будет находиться публичный ключ, который и заносится в файл LDIF. Пояснения к наиболее значимым параметрам записи приведены в таблице 3.

Таблица 3. Поля учетной записи в формате LDIF

После создания этого файла LDIF нужно добавить эту запись с помощью утилиты ldapadd, входящей в состав пакета OpenSSH:

ldapadd -f user1.ldif -x -D "cn=Manager,dc=example,dc=com"  \

-H ldap://127.0.0.1 -w 'super-user-pass'

Параметр -D содержит описание суперпользователя, как он был определен в файле ldap.conf. Параметр -w содержит пароль суперпользователя. После запуска, если файл создан верно, мы должны увидеть следующее сообщение:

Установка и настройка демона OpenSSH

По умолчанию демон OpenSSH работает с ключами, расположенными в текстовых файлах на локальном сервере. Для того чтобы демон OpenSSH обращался к серверу OpenLDAP, нужно применить специальный патч, который расположен по домашнему адресу проекта: http://dev.inversepath.com/trac/openssh-lpk. Если в состав дистрибутива уже входит пакет OpenSSH с поддержкой OpenLDAP, то можно его и использовать.

Итак, получаем исходный код openssh с адреса http://openssh.org и раскрываем архив.

Далее необходимо скачать версию патча, которая совпадает с вашей версией openSSH, в каталог с исходными кодами OpenSSH и наложить патч:

tar -xzvf openssh-xxx.tgz

cp  openssh-lpk-xxx.patch

cd openssh-xxx

patch -p 2 < openssh-lpk-xxx.patch

./configure --sysconfdir=/usr/local/etc/openssh-ldap \

–prefix=/usr/local/openssh-ldap –with-ldap

make

make install

Параметр -ldap включает поддержку OpenLDAP для демона OpenSSH.

Весь пакет за исключением конфигурационных файлов будет установлен в /usr/local/openssh-ldap.

Рекомендуется прописать запуск OpenSSH с поддержкой OpenLDAP в отдельном файле /etc/init.d/openssh-ldap.

Эти две особенности установки рекомендуется применить для исключения замены стандартным демоном OpenSSH в случае обновления системы.

Далее нужно изменить конфигурационный файл /usr/local/etc/openssh-ldap/sshd_config и добавить строки, описывающие взаимодействие демона OpenSSH со службой OpenLDAP:

# Использовать LPK

UseLPK yes

# Взять параметры работы с сервером OpenLDAP из внешнего файла

LpkLdapConf /etc/openssh-ldap.conf

Репликация и вторичный сервер OpenLDAP

Как упоминалось в разделе «Установка и настройка демона OpenSSH», демон OpenSSH поддерживает обращение ко вторичным серверам OpenLDAP, если главный сервер недоступен. Для поддержки этой технологии необходимо установить вторичный сервер(ы) OpenLDAP. Для синхронизации данных вторичного сервера с главным сервером пакет OpenLDAP имеет встроенные средства репликации. Процесс настройки репликации и будет описан в этом разделе.

Перед настройкой репликации необходимо предпринять следующие шаги:

• Установить пакет OpenLDAP на вторичные серверы.
• Создать ключи с Common Name, совпадающим с адресом вторичного сервера OpenLDAP (например, ldap2.example.com).

Эти шаги уже были описаны, что дает нам возможность сосредоточиться на самом процессе настройки репликации. Сам процесс включает в себя 4 шага:

• Копирование текущей базы.
• Описание вторичного сервера на главном сервере OpenLDAP.
• Запуск демона репликации.
• Тестирование.

Копирование заключается в копировании каталога /var/openldap/unix-accounts с главного сервера в такой же каталог на вторичном сервере. Убедитесь что владелец каталога совпадает с именем пользователя, под которым запущен демон OpenLDAP.

Перед началом необходимо остановить демон OpenLDAP на главном сервере, чтобы гарантировать целостность базы.

Для того чтобы описать вторичный сервер на главном сервере, необходимо добавить следующие строчки в конфигурационный файл slapd.conf на главном сервере:

replica host=ldap2.example.com  starttls=yes binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials='super-user-pass'

replogfile /var/log/openldap/ldap_replica.log

Параметр binddn должен содержать имя суперпользователя, как указано в определении базы данных в файле slapd.conf.

Параметр credentials содержит пароль суперпользователя.

Параметр replogfile содержит путь к лог-файлу, в котором демон OpenLDAP будет сохранять изменения в базе данных.

Очень важно, чтобы этот файл не попадал под периодическую очистку (например, ротация лог-файлов).

Далее нам необходимо разрешить вторичному серверу OpenLDAP принимать обновления базы данных OpenLDAP. Для этого нужно добавить следующую строку в конфигурационный файл slapd.conf на вторичном сервере:

updatedn        cn=manager,dc=example,dc=com

Для синхронизации данных между главным и вторичным серверами служит демон slurpd, который вычитывает изменения файла ldap_replica.log и передает изменения демону OpenLDAP на вторичном сервере. Необходимо запустить демон slurpd:

/usr/local/libexec/slurpd

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

ldapsearch -x -b 'dc=example,dc=com'  -v   -H ldaps://ldap2.example.com

Если процесс настройки репликации прошел удачно, то этот запрос покажет наличие только что добавленной учетной записи на вторичном сервере.

И, конечно, необходимо добавить запуск демонов slapd и slurpd на главном сервере и демонов slapd на вторичных серверах в процесс запуска служб при загрузке серверов.

Управление учетными записями OpenLDAP из приложений

Многие языки программирования содержат инструменты для работы с демоном OpenLDAP. В разделе мы рассмотрим, как управлять записями в каталоге OpenLDAP из программ, написанных на языке программирования Perl.

Для этого нам понадобится пакет perl-ldap, который можно установить из исходного кода, предварительно получив по адресу: http://search.cpan.org, или обратиться к пакету CPAN:

perl -MCPAN -e 'install Net::LDAP'

Далее приведен пример скрипта на языке Perl, который добавляет нового пользователя, параметры которого определены в начале файла:

#!/usr/bin/perl

use strict;

use Net::LDAP;

# Адрес сервера OpenLDAP. Адрес указывается в качестве параметра при запуске этого скрипта

my $ldaphost = $ARGV[0];

# Имя учетной записи

my $uid = 'chat-example-com;

# Имя пользователя и фамилия пользователя

my $cn  = 'John';

my $sn  = 'Smith';

# Расположение учетной записи в иерархии базы LDAP

my $dn  = 'ou=People,dc=example,dc=com';

# Путь к домашнему каталогу

my $homedir = '/home/chat-domain-com';

# Получаем из файла public_keys.txt ключи пользователей, имеющих аккредитацию для данного ресурса

open(F, “public_keys.txt”);

my @ssh_keys=<F>;

close(F);

# Параметры суперпользователя и адрес главного сервера OpenLDAP

my $suser_name = 'cn=manager, dc=example, dc=com';

my $suser_pass = 'super_user_passw';

# Подключение к серверу OpenLDAP с аккредитацией суперпользователя

my $ldap = Net::LDAP->new( $ldaphost );

my $mesg = $ldap->bind( $suser_name, password => $suser_pass);

# Добавить учетную запись

my $result =

    $ldap->add( "uid=$uid,$dn",

    attr => [

           'cn'   => $cn,

           'sn'   => $sn,

           'uid'  => $uid,

           'userPassword' => "x",

           'uidNumber' => 65535,

           'gidNumber' => 65535,

           'homeDirectory' => $homedir,

           'sshPublicKey'  => @ssh_keys,

           'objectclass' => ['top', 'person', 'posixAccount', 'ldapPublicKey' ],

           ]

    ) || die "error in installing new account\n";

    $result->code && warn "failed to add entry: ", $result->error ;

Аналогичны примеры для модификации и удаления учетных записей:

#

# Пример для модификации учетной записи

#

# Поиск записи и получение дескриптора

$mesg = $ldap->search(filter => "(uid=$user->{username})", base=>$dn);

$mesg->code && die $mesg->error;

my $entry = $mesg->entry(0);

# Замена параметров учетной записи

$entry->replace(sn=>$sn);

# Занесение обновленных данных обратно в сервер OpenLDAP

my $result = $entry->update($ldap);

#

# Пример для удаления учетной записи

#

my $result= $ldap->delete( "uid=$uid,$dn");

print "error: in ldap trying to delete $uid $result->error" if($result->code);

Управление аккредитациями

В этой части я расскажу о процедуре управления аккредитациями пользователей конкретными ресурсами и как она используется в нашей компании.

Каждый проект у нас имеет уникальное имя пользователя на серверах. Например, проект chat.example.com имеет имя пользователя chat-example-com на сервере, обслуживающем данный ресурс (или на всех серверах в случае кластерного решения).

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

Также существует таблица проектов. Каждая запись о проекте включает в себя несколько параметров, включая имя пользователя (username, напиример chat-example-com) на сервере.

И наконец, есть таблица MySQL, которая содержит записи в виде:

(project_id, member_id)

Эта таблица управляется из простейшей веб-панели системными администраторами. При обновлении таблицы (добавление или удаление пользователя) запускается скрипт на языке Perl, который обновляет базу данных OpenLDAP по протоколу OpenLDAP.

Приложение

Вторичный демон OpenSSH

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

Я использую параметр:

PermitRootLogin without-password

в конфигурацинном файле демона OpenSSH. Эта опция позволяет входить пользователю «root» только с использованием ключей OpenSSH.

Репликация MySQL

Я также использовал несколько другую схему репликации баз данных OpenLDAP.

В нашей компании существует сервер, который максимально защищен из вторжения извне. На нем находится сервер MySQL, который реплицирован на два вторичных сервера. На этом же сервере находится панель управления аккредитациями пользователей.

На вторичных серверах находятся скрипты на языке Perl, которые отслеживают изменения в таблицах пользователей и перестраивают базу данных OpenLDAP в случае изменения. Это позволило уменьшить количество репликаций (только MySQL вместо MySQL и OpenLDAP).

К тому же, как показывает практика, отношение системных администраторов к данным репликации MySQL значительно более аккуратное, чем к лог-файлам репликаций в /var/log/openldap/.

Использование схемы «один центральный и два вторичных OpenLDAP-сервера»

При использовании такой схемы появляется возможность балансировки загрузки вторичных серверов с помощью Cisco Content Switch. Об использовании данного устройства для балансировки и построения отказоустойчивых систем будет рассказано в одной из моих следующих статей.

1. http://google.com.
2. http://openldap.org.
3. http://openssh.org.
4. http://dev.inversepath.com/trac/openssh-lpk.
5. http://wikipedia.org.
6. http://www.openssl.org/docs/apps/ciphers.html.

Комментарии могут оставлять только зарегистрированные пользователи