Этот пост я хочу посвятить кейсу с крупного ИТ-проекта, который делала наша компания. В рамках проекта внедрялось большое количество сервисов, и для них нужно было обеспечить LDAP-аутентификацию при следующих операциях:
Доступ в GUI-интерфейсы сервисов.
Доступ по SSH на серверы, где функционируют сервисы, с ограничением доступа на основании членства пользователей в группах LDAP-каталога.
У заказчика уже была развернута служба каталогов Microsoft Active Directory. Требованием проекта было отсутствие прямого доступа между внедряемыми сервисами и AD. На стороне сервисов не должны были прописываться параметры сервисных учетных записей AD. Кроме того, сетевой доступ к контроллеру MS AD был разрешен только для одного хоста.
Под катом — подробности о том, как мы решили эту задачу.
Для решения данной задачи был выбран OpenLDAP в режиме проксирования аутентификационных запросов в сторону контроллеров MS AD. Для входа на серверы был использован модуль SSSD, обрабатывающий LDAP(S)-запросы с дополнительной фильтрацией по группам MS Active Directory.
Задача проксирования запросов через OpenLDAP не выглядит чем-то сложным. В Интернете достаточно информации на эту тему. Загвоздка была в том, что в основном они описывают выполнение конфигурации OpenLDAP через файл sladp.conf. Однако начиная с версии OpenLDAP 2.4 настройка происходит не с помощью slapd.conf, а через конфигурационный контекст LDAP cn=config. Вариант настройки через slapd.conf устарел и более не поддерживается. В свободном доступе крайне мало похожих примеров настроек через cn=config.
В статье я постарался максимально подробно описать технику настройки OpenLDAP 2.6 и SSSD через cn=config на Rocky Linux 8.5 и рассказать, как мы решали возникающие в процессе проблемы.
Установка OpenLDAP
Для установки OpenLDAP нужно выполнить следующие действия:
1. Установить зависимости:
# dnf install wget vim cyrus-sasl-devel libtool-ltdl-devel openssl-devel libdb-devel make libtool autoconf tar gcc perl perl-devel -y
2. Подключить репозиторий Symas, чтобы скачать из него OpenLDAP:
#wget -q https://repo.symas.com/configs/SOFL/rhel8/sofl.repo -O /etc/yum.repos.d/sofl.repo
3. Установить серверную и клиентскую части OpenLDAP:
#dnf install symas-openldap-clients symas-openldap-servers -y
4. Добавить OpenLDAP (slapd.service) в автозагрузку и включить службу:
#systemctl enable slapd
#systemctl start slapd
Настройка OpenLDAP
На сервере OpenLDAP (в нашем примере opld.test.local) нужно выполнить следующие действия:
1. Внести информацию о BASE и URI в файл /etc/openldap:
BASE dc=test,dc=local
URI ldap://opld.test.local ldaps://opld.test.local:6362. При работе OpenLDAP в режиме проксирования контроллер домена Microsoft Active Directory будет являться для OpenLDAP backend-базой данных LDAP-типа. Для возможности подключения OpenLDAP к контроллеру домена необходимо загрузить модуль back_ldap.
Для этого:
a. Убедиться в наличии файла back_ldap.la на сервере OpenLDAP. Если его нет, то на сервер OpenLDAP необходимо загрузить данную библиотеку.
b. Создать файл ldif в виде:
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib64/openldap
olcModuleLoad: back_ldap.lac. Загрузить back_ldap.ldif файл в конфигурацию сервера OpenLDAP:
#ldapadd -Y EXTERNAL -H ldapi:/// -f back_ldap.ldif
3. Создать backend-базу типа ldap, в качестве которой будет выступать Active Directory:
a. Создать файл ldap_db.ldif в виде:
dn: olcDatabase=ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: ldap
olcDbIDAssertBind: bindmethod="simple" binddn="CN=tech_test_local,OU=Tech
Accounts,DC=test,DC=local" credentials="password"
olcDbURI: ldaps://dc01.test.local
olcReadOnly: TRUE
olcRootDN: cn=openldap,dc=test,dc=local
olcRootPW: password
olcSuffix: dc=test,dc=local
olcDbChaseReferrals: FALSEolcDbIDAssertBind: Указание метода подключения, distinguishedName и пароля УЗ для подключения к контроллеру MS Active Directory.
olcDbURI: URI контроллера AD.
olcReadOnly: Режим работы (чтение/запись) с MS Active Directory.
olcRootDN: Сервисная УЗ OpenLDAP. С помощью нее к OpenLDAP будут подключаться сервисы.
olcRootPW: Пароль от сервисной УЗ OpenLDAP.
olcSuffix: Суффикс домена.
olcDbChaseReferrals: Определяет возможность использования механизма отсылок.
Чтобы зашифровать пароль olcRootPW, выполнить команду:
# slappasswd -s password
и сгенерированное хэш-значение указать в атрибут olcRootPW.
b. На сервере OpenLDAP выполнить команду:
#ldapadd -Y EXTERNAL -H ldapi:/// -f ldap_db.ldif
4. Настроить защищенное TLS-соединение между OpenLDAP и AD.
Должны быть предоставлены цепочки сертификатов удостоверяющих центров, которые выпустили сертификаты для контроллера домена:
a. Положить цепочку сертификатов (cacerts.pem) на сервер OpenLDAP (например, в /etc/openldap/certs).
b. В файле /etc/openldap/ldap.conf указать путь к сертификату:
TLS_CACERT /etc/openldap/certs/cacerts.pem
5. Обеспечить возможность подключения сервисов к OpenLDAP по LDAPS:
a. Выпустить ключ и сертификат для сервера OpenLDAP. Положить сертификат (oldap.crt) и ключ (oldap.key) на сервер OpenLDAP (например, в /etc/openldap/certs).
b. Создать opldcert.ldif файл:
dn: cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: cn=config
changetype: add
olcTLSCertificateFile: /etc/openldap/certs/oldap.crt
olcTLSCertificateFileKey: /etc/openldap/certs/oldap.key
olcTLSVerifyClient: neverc. Выполнить команду:
#ldapadd -Y EXTERNAL -H ldapi:/// -f opldcert.ldif
На этом конфигурация OpenLDAP в режиме проксирования завершена. После завершения этой настройки сервер может обрабатывать LDAP/LDAPS входящие запросы от клиентов, производить проксирование запросов на контроллер домена MS Active Directory. Mежду сервером OpenLDAP и контроллером домена MS Active Directory настроено защищенное соединение.
Ниже опишу реализацию настройки модуля SSSD в части SSH-аутентификации на клиентские серверы с учетом фильтрации согласно членству в группах MS Active Directory.
Настройка службы SSSD
1. Установить пакеты SSSD:
# sudo yum install sssd-tools sssd oddjob oddjob-mkhomedir samba-common-tools
2. Настроить файл ldap.conf на клиентских серверах. Загружаем сертификат сервера OpenLDAP и прописываем путь к нему:
URI ldap://opld.test.local ldaps://opld.test.local:636
BASE dc=test,dc=local
TLS_CACERT /etc/openldap/certs/oldap.crt
TLS_CACERTDIR /etc/openldap/certs
<![if !supportLineBreakNewLine]>
<![endif]>3. Создать файл sssd.conf. (etc/sssd/sssd.conf):
[domain/test.local]
ldap_schema = ad
id_provider = ldap
autofs_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://opld.test.local:636
ldap_search_base = dc=test,dc=local
ldap_id_use_start_tls = True
ldap_tls_cacertdir = /etc/openldap/certs
cache_credentials = False
ldap_tls_reqcert = allow
ldap_default_bind_dn = cn=openldap,dc=test,dc=local
ldap_default_authtok_type = obfuscated_password
ldap_default_authtok = #зашифровать и ввести в следующем шаге
ldap_access_order = filter
ldap_id_mapping = True
ldap_referrals = False
access_provider = ldap
ldap_access_filter = (|(memberOf= CN=Admins,DC=test,DC=local)(memberOf=CN=Support,DC=test,DC=local))
use_fully_qualified_names = False
# Object Mappings
ldap_user_object_class = user
ldap_user_name = sAMAccountName
ldap_group_object_class = group
ldap_group_name = cn
# ID Mappings
ldap_user_objectsid = objectSid
ldap_group_objectsid = objectSid
ldap_idmap_range_size = 1048576
ldap_user_primary_group = primaryGroupID
override_homedir = /mnt/home/%u
default_shell = /bin/bash
fallback_homedir = /home/%u@%d
[sssd]
config_file_version = 2
services = nss, pam,autofs
domains = test.local
[nss]
homedir_substring = /homeВ примере ниже я использовал параметр ldap_acсess_filter с группами AD (Admins, TechSupport). Подключиться к серверу смогут только те пользователи, кто состоит в этих MS AD группах.
4. Дать права файлу sssd.conf:
# chmod 600 /etc/sssd/sssd.conf
5. Чтобы пароль не хранился в открытом в виде, зашифровать его:
# sss_obfuscate -d test.local
6. Внести в файл /etc/hosts или настроить адрес OpenLDAP на вашем DNS-сервере:
# (IP OpenLDAP) opld.test.local
7. Перезапустить sssd, проверить работу службы с помощью команды id:
# systemctl restart sssd.service
#id {username}
#User Found (id=1234567) # Пример вывода строки, найденного пользователя
8. Переключить профиль входа в Linux на использование sssd (LDAP-аутентификация):
# authselect select sssd --force
9. Настроить sudo права для доменных УЗ:
# echo "sudoers: files sss" >> /etc/nsswitch.conf
10. Обеспечить создание домашних директорий для доменных пользователей:
# systemctl enable --now oddjobd
# echo "session optional pam_oddjob_mkhomedir.so skel=/etc/skel/ umask=0022" >> /etc/pam.d/system-auth # systemctl restart oddjobd
11. Проверить работу SSSD:
# sssctl domain-status test.local
12. Если вы получаете вывод подобного рода, то SSSD настроен корректно, можно попробовать аутентифицироваться на сервер:
# sssctl domain-status test.local
Online status: Online
Active servers:
LDAP: test.local
Discovered LDAP servers:
- test.local
Если вы получаете статус Offline, значит, на каком-то этапе выше вы допустили ошибку, проверяйте заново.
Проблемы и решение
После подключения одной из систем и настройки LDAP-аутентификации обнаружили проблему, что аутентификация в Web UI не проходила. Такая же проблема была замечена при попытке аутентификации по SSH. Сессия на аутентификацию отваливалась по тайм-ауту. Такое поведение обнаруживалось, если осуществлялся поиск по всему домену. При этом, если мы сужали границы поиска, например, на уровень только определенной OU, то проблема уходила, и пользователи могли аутентифицироваться.
Были сняты дампы обращений клиента к OpenLDAP и OpenLDAP к MS AD. Из них выяснили, что при поиске по всему домену, помимо ответа на запрос, было обращение к DomainDNSZones с помощью механизма отсылок (Referrals).
Отсылка — это процесс, посредством которого LDAP-сервер, вместо того чтобы вернуть результат запроса, возвращает ссылку (отсылку, referral) на другой LDAP-сервер или, в нашем случае, домен-контроллер, который может содержать дополнительную информацию. Получая referral на DomainDNSZones, OpenLDAP выполнял запрос контроллерам домена MS AD, к которым не было сетевого доступа. В связи с этим висела сессия от сервера OpenLDAP к MS AD, и далее она обрывалась по тайм-ауту.
Соответственно, для решения проблемы нужно было найти способ управления рефералами. В основном все статьи, связанные с данной проблемой, описывали настройки с помощью конфигурационного файла slapd.conf, а не cn=config.
Исследуя схему OpenLDAP, был найден параметр olcDbChaseReferrals, который как раз и отвечал за отсылки при обращении к MS AD. Если использовать значение olcDbChaseReferrals=FALSE, то LDAP, получая referral на DomainDNSZones, игнорирует это и не обращается к прочим контроллерам домена.
В документации к SSSD мы также обнаружили параметр, отвечающий за отсылки — ldap_referrals. После применения этого параметра со значением FALSE SSSD перестал падать и терять соединение с контроллером домена.
Еще один интересный момент, который мы заметили, был связан с настройкой фильтрации доступа на основе членства в группах AD. Мы увидели, что после настройки фильтра пользователи не могли получить доступ к серверу. Проблема заключалась в том, что при вычитывании объектов из SSSD им не назначался корректный уникальный ID. ID генерировался самой Linux-машиной, а должен был быть получен в атрибуте objectSID из MS Active Direсtory. Таким образом, SSSD не мог получить корректный список AD-групп, в которые входит пользователь (SSSD должен сопоставлять идентификаторы пользователей и групп из атрибутов ldap_user_objectsid и ldap_group_objectsid вместо того, чтобы полагаться на сгенерированные Linux’ом ID). Решением проблемы стало использование параметр ldap_id_mapping со значением TRUE.
Надеюсь, этот пост был полезным и помог решить задачи быстрее. Если у кого-то есть подобный опыт в настройках, делитесь вашими знаниями, буду готов обновить и дополнить статью свежей информацией.
Автор поста: старший пресейл-инженер Владислав Алешин