Со временем количество активного оборудования, количество серверов и сервисов имеет свойство увеличиваться, а технические отделы - расти. В связи с этим все чаще встают вопросы заведения/вынесения сотрудников в/из текущих информационных систем. Данная статья описывает возможную реализации AA (аутентификацию и авторизацию) через ldap на ОС FreeBSD (и, косвенно, на других *nix). Рассмотрение реализации третьего A (аккаунтинга) выходит за рамки данной статьи, хотя и реализуется достаточно легко (например через
).
Краткое описание реализации:
В качестве места хранения данных используется openldap, протокол - ldap+TLS, аутентификация/авторизация при входе в систему/получении sudo-прав происходит по паролям и открытым ключам
Используемое ПО:
Установка серверной части:В первую очередь создадим CA (
certification authority) для выдачи нужного нам для ldap сертификата(ов):
Для этого в базовой системе есть скрипт
CA.pl (/usr/src/crypto/openssl/apps/CA.pl)
В принципе, он работает и out-of-box, однако для удобства можно сделать следующее:
- Исправить путь в $CATOP из скрипта на тот, где планируется держать файлы CA (а это несколько директорий)
- Исправить путь в секции Default_ca файла /etc/ssl/openssl.cnf
- Выставить предпочтительные параметры в секции req_distinguished_name (страну, город, etc..) для упрощения дальнейших выдач сертификатов
Кроме того, для некоторого повышения надежности схемы можно отказаться от использования DNS-имен в настройках. В таком случае стоит использовать опцию
subjectAltName (
rfc 3280) для указания собствеенно IP-адреса сервера в сертификате.
Для этого необходимо дописать примерно следующие строчки в openssl.cnf (на момент выдачи этого сертификата):
[ req ]
...
req_extensions = v3_req
[ v3_req ]
...
subjectAltName = @alt_names
[ alt_names ]
IP.1 =1.2.3.4
Приступим собственно к выдаче:
Создаем CA (инициализация дерева директорий, создание root-сертификата):
central# ./CA.pl -newca
Show output..
Теперь в директории
catest у нас есть root сертификат (cacert.pem) нашего CA, который мы будем выдавать сомневающимся^Wldap-клиентам
Осталось выдать сертификат (точнее, создать request и подписать его) собственно для ldap-сервера:
central# ./CA.pl -newreq
Show output..
central# ./CA.pl -sign
Show output..
В результате мы получили следующие файлы:
- newcert.pem - это собственно сертификат, переименовываем например в central.pem
- newkey.pem - приватный ключ для сертификата
С ключем ситуация интереснее: openssl при генерации не дает указать пустой passthrase, а slapd не умеет ключи в файлах. Поэтому поступаем так, как нас учат в
rsa(1):
central# openssl rsa -in newkey.pem -out central_key.pem
Enter pass phrase for newkey.pem: sometemppassword
writing RSA key
В результате получился нужный нам ключ, не защищенный паролем. На этом часть, непосредственно связанную с openssl можно считать [успешно] законченной и переходить к установке/настройке openldap.
В серверной части нас больше всего интересует bdb бекенд(по умолчанию) и, возможно audit log и access log.
Устанавливаем:
make -C /usr/ports/net/openldap24-server/ install clean
Настраиваем /usr/local/etc/openldap/slapd.conf (например, копируя из /usr/local/etc/openldap/slapd.default). Здесь необходимо выбрать название домена, в котором все будет жить. В данном примере это
dc=roga,dc=ru. Кроме того, необходимо придумать иерархию обьектов в дереве ldap. У автора используется следующая схема:
dc=roga,dc=ru - корень
ou=People - контейнер, в которой находятся все сотрудники
ou=Tech,ou=People - контейнер с эккаунтами технического отдела (обьекты живут именно тут)
ou=Groups - контейнер с posix группами (обьекты живут тут)
ou=SUDOers - контейнер с конфигурацией sudo (обьекты живут именно тут)
Пример конфига с комментариями:Прописываем в автозагрузку:
echo slapd_enable=\"YES\" >> /etc/rc.conf
Пробуем запустить (начать стоит именно с такого способа, т.к. скрипт запуска инициализирует директории из конфига перед запуском):
/usr/local/etc/rc.d/slapd start
В случае необходимости (возможные -d можно посмотреть в slapd.conf(5)):
/usr/local/libexec/slapd -h "ldap:// ldaps://" -u ldap -g ldap -d 256
Для упрощения жизни на сервере с openldap дописываем откуда клиенту брать root сертификат для TLS:
echo TLS_CACERT /usr/local/etc/openldap/cacert.pem >> /usr/local/etc/openldap/ldap.conf
После того как slapd успешно запущен, необходимо добавить в него [придуманную раньше] структуру. Работа с сервером openldap производится утилитами ldapadd, ldapmodify и ldapsearch. Добавить обьекты из файла можно следующим образом:
ldapadd -xWZ -h -D cn=toor,dc=roga,dc=ru -f obj.ldif
(Hint: -x говорит не использовать sasl, -W спрашивает пароль, -Z включает TLS)
Пример obj.ldif для описанной выше структуры с группой и тестовым сотрудником:
Переход на централизованный sudo рассматривается после успешной конфигурации клиентской части, поэтому в данном .ldif нет обьектов sudo.
Если все прошло успешно, можно переходить к настройке клиентской части, которая значительно проще. Если нет - смотрим на ошибки, запускаем клиент/сервер с -vvv, дебагом, etc..
Клиентская часть:Здесь все значительно проще и сводится к следующим вещам:
- [пере]установка портов с заданными опциями
- подкладывание новых конфигов ldap
- возможная схема группы, в которой должен состоять сотрудник для получения доступа
- изменение схемы работы pam для openssh/sudo
- изменение nsswitch.conf
- добавление бекапного эккаунта на случай отказа ldap
- вынос текущих эккаунтов
Почти все пункты вполне себе автоматизируются.
Конечно, всегда есть нюансы: например, в данном скрипте sshd переезжает в /usr/local и не конвертирует старый конфиг. Кроме того, необходимо будет перенести конфигурацию sudo в ldap (подробности ниже) и
Пример скрипта и краткое руководство:
Для реализации нам понадобится http сервер (напр. nginx):
Итак: собственно,
скрипт и необходимые файлыКлиентский конфиг с комментариями:В самом скрипте необходимо заменить
- URL на тот, по которому он доступен.
- заменить пароль в bindpw на securepass0
В остальных файлах:
sed -i '' -e 's/dc=roga,dc=ru/dc=нужный,dc=домен/g' nss_ldap.conf
sed -i '' -e 's/1.2.3.4/ldap.ip.addre.ss/g' nss_ldap.conf openldap.conf
После чего запустить на первом сервере что-то типа fetch http:../pifpaf.sh && sh pifpaf.sh
Убедиться, что скрипт отработал корректно, возможно что-то подкорректировать под нужную конфигурацию и записать придуманный в серверный части serverpass1 в /usr/local/etc/nss_ldap.secret
Настройка sudo:В данном примере будет рассматриваться тривиальная конфигурация, когда все члены определенной группы могут пользоваться sudo (т.е. аналог %wheel ALL=(ALL) ALL).
Более подробно об импорте конфигов можно почитать
тут или в устанавливаемых sudo readme.
Итак,
очередной .ldif (sudoers_base ou=SUDOers,dc=roga,dc=ru) уже указано в распостраненных nss_ldap.conf:
Резюме: Появилась единая точка аутентификации/авторизации для сотрудников, ходящих на сервера. Появилась возможность понемногу перетаскивать аунтентификацию остальных сервисов в LDAP. Исправления/дополнения/комментарии приветствуются
Краткое описание реализации:
В качестве места хранения данных используется openldap, протокол - ldap+TLS, аутентификация/авторизация при входе в систему/получении sudo-прав происходит по паролям и открытым ключам
Используемое ПО:
Установка серверной части:
В первую очередь создадим CA (certification authority) для выдачи нужного нам для ldap сертификата(ов):
Для этого в базовой системе есть скрипт CA.pl (/usr/src/crypto/openssl/apps/CA.pl)
В принципе, он работает и out-of-box, однако для удобства можно сделать следующее:
- Исправить путь в $CATOP из скрипта на тот, где планируется держать файлы CA (а это несколько директорий)
- Исправить путь в секции Default_ca файла /etc/ssl/openssl.cnf
- Выставить предпочтительные параметры в секции req_distinguished_name (страну, город, etc..) для упрощения дальнейших выдач сертификатов
Кроме того, для некоторого повышения надежности схемы можно отказаться от использования DNS-имен в настройках. В таком случае стоит использовать опцию subjectAltName (rfc 3280) для указания собствеенно IP-адреса сервера в сертификате.Для этого необходимо дописать примерно следующие строчки в openssl.cnf (на момент выдачи этого сертификата):
Приступим собственно к выдаче:
Создаем CA (инициализация дерева директорий, создание root-сертификата):
Теперь в директории catest у нас есть root сертификат (cacert.pem) нашего CA, который мы будем выдавать сомневающимся^Wldap-клиентам
Осталось выдать сертификат (точнее, создать request и подписать его) собственно для ldap-сервера:
В результате мы получили следующие файлы:
- newcert.pem - это собственно сертификат, переименовываем например в central.pem
- newkey.pem - приватный ключ для сертификата
С ключем ситуация интереснее: openssl при генерации не дает указать пустой passthrase, а slapd не умеет ключи в файлах. Поэтому поступаем так, как нас учат в rsa(1):В результате получился нужный нам ключ, не защищенный паролем. На этом часть, непосредственно связанную с openssl можно считать [успешно] законченной и переходить к установке/настройке openldap.
В серверной части нас больше всего интересует bdb бекенд(по умолчанию) и, возможно audit log и access log.
Устанавливаем:
Настраиваем /usr/local/etc/openldap/slapd.conf (например, копируя из /usr/local/etc/openldap/slapd.default). Здесь необходимо выбрать название домена, в котором все будет жить. В данном примере это dc=roga,dc=ru. Кроме того, необходимо придумать иерархию обьектов в дереве ldap. У автора используется следующая схема:
dc=roga,dc=ru - корень
ou=People - контейнер, в которой находятся все сотрудники
ou=Tech,ou=People - контейнер с эккаунтами технического отдела (обьекты живут именно тут)
ou=Groups - контейнер с posix группами (обьекты живут тут)
ou=SUDOers - контейнер с конфигурацией sudo (обьекты живут именно тут)
Пример конфига с комментариями:
Пробуем запустить (начать стоит именно с такого способа, т.к. скрипт запуска инициализирует директории из конфига перед запуском):
В случае необходимости (возможные -d можно посмотреть в slapd.conf(5)):
Для упрощения жизни на сервере с openldap дописываем откуда клиенту брать root сертификат для TLS:
После того как slapd успешно запущен, необходимо добавить в него [придуманную раньше] структуру. Работа с сервером openldap производится утилитами ldapadd, ldapmodify и ldapsearch. Добавить обьекты из файла можно следующим образом:
(Hint: -x говорит не использовать sasl, -W спрашивает пароль, -Z включает TLS)
Пример obj.ldif для описанной выше структуры с группой и тестовым сотрудником:
Переход на централизованный sudo рассматривается после успешной конфигурации клиентской части, поэтому в данном .ldif нет обьектов sudo.
Если все прошло успешно, можно переходить к настройке клиентской части, которая значительно проще. Если нет - смотрим на ошибки, запускаем клиент/сервер с -vvv, дебагом, etc..
Клиентская часть:
Здесь все значительно проще и сводится к следующим вещам:
- [пере]установка портов с заданными опциями
- подкладывание новых конфигов ldap
- возможная схема группы, в которой должен состоять сотрудник для получения доступа
- изменение схемы работы pam для openssh/sudo
- изменение nsswitch.conf
- добавление бекапного эккаунта на случай отказа ldap
- вынос текущих эккаунтов
Почти все пункты вполне себе автоматизируются.Конечно, всегда есть нюансы: например, в данном скрипте sshd переезжает в /usr/local и не конвертирует старый конфиг. Кроме того, необходимо будет перенести конфигурацию sudo в ldap (подробности ниже) и
Пример скрипта и краткое руководство:
Для реализации нам понадобится http сервер (напр. nginx):
Итак: собственно, скрипт и необходимые файлы
Клиентский конфиг с комментариями:
В самом скрипте необходимо заменить
- URL на тот, по которому он доступен.
- заменить пароль в bindpw на securepass0
В остальных файлах:После чего запустить на первом сервере что-то типа fetch http:../pifpaf.sh && sh pifpaf.sh
Убедиться, что скрипт отработал корректно, возможно что-то подкорректировать под нужную конфигурацию и записать придуманный в серверный части serverpass1 в /usr/local/etc/nss_ldap.secret
Настройка sudo:
В данном примере будет рассматриваться тривиальная конфигурация, когда все члены определенной группы могут пользоваться sudo (т.е. аналог %wheel ALL=(ALL) ALL).
Более подробно об импорте конфигов можно почитать тут или в устанавливаемых sudo readme.
Итак, очередной .ldif (sudoers_base ou=SUDOers,dc=roga,dc=ru) уже указано в распостраненных nss_ldap.conf:
Резюме:
Появилась единая точка аутентификации/авторизации для сотрудников, ходящих на сервера. Появилась возможность понемногу перетаскивать аунтентификацию остальных сервисов в LDAP. Исправления/дополнения/комментарии приветствуются