Записки импортозамещенца: как обеспечить централизованную аутентификацию в Linux, серверная часть для SSSD

Привет, Хабр! Меня зовут Никита, и я являюсь инженером ИБ-компании «Экстрим безопасность». В предыдущей статье мы обсудили, что для централизованной аутентификации в Linux чаще всего используют службу SSSD, которая изначально разрабатывалась для FreeIPA, но поддерживает и другие бэкенды. Давайте познакомимся теперь внимательнее со всеми этими возможностями.

1. Централизация с помощью LDAP

Сервис LDAP на отечественных операционных системах можно поднять на старом добром OpenLDAP или с помощью 389 Directory Server, на котором работает FreeIPA. Оба решения имеют общего предка из Мичигана, но разошлись еще в лихие 90-е, поэтому кодовая база у них сейчас существенно отличается. Можно долго дискутировать о преимуществах и недостатках каждого из решений, но достаточно сказать, что Red Hat и SUSE уже списали проект OpenLDAP в утиль и не включают его пакеты в свои дистрибутивы, предлагая мигрировать на 389ds. И, если уж выбирать OpenLDAP, то лучше обратить внимание на отечественный форк ReOpenLDAP, в котором основательно переработан механизм репликации, да и много чего еще.

Отдельно сервер LDAP из российских разработчиков больше никто не разрабатывает, но как сервис он доступен в составе продуктов Мультифактор (Multidirectory) и Аванпост (Avanpost DS). В качестве LDAP-сервера можно использовать еще Samba, но в этом случае лучше и SSSD переключить на бэкенд AD. Поэтому, как видите, альтернатив особо и нет.

Для работы с бэкендом LDAP в секции domain конфигурационного файла sssd.conf следует указать следующие параметры:

• id_provider = ldap — указывает поставщика идентификационных данных, который используется так же для аутентификации пользователей и смены пароля с помощью утилиты passwd, если иное не определено параметрами auth_provider и chpass_provider;

• ldap_uri = ldap://ldap-1.company.lan, ldap://ldap-2.company.lan — определяет список LDAP-серверов, через которые служба SSSD будет взаимодействовать с доменом;

• ldap_id_use_start_tls = True — указывает, что при обмене данными по протоколу LDAP следует вызывать команду STARTTLS для шифрования данных;

• ldap_tls_cacert = /etc/ipa/ca.crt — указывает путь к файлу, в котором находится корневой сертификат домена для переключения на шифрованный канал связи при подключении по LDAP;

• ldap_search_base = cn=users,cn=accounts,dc=company,dc=lan — указывает, где находятся учетные записи пользователей;

• ldap_group_search_base = cn=groups,cn=accounts,dc=company,dc=lan — указывает, где находятся учетные записи групп пользователей;

• cache_credentials = True — указывает, что хеши паролей нужно сохранять в локальном кэше для возможности аутентификации пользователей в автономном режиме без доступа к серверу.

Дополнительно рекомендуется настроить файл /etc/ldap/ldap.conf, чтобы упростить работу с утилитами ldapsearch, ldapmodify и др.

В сравнении  с локальными учетными записями бэкенд LDAP имеет следующие преимущества:

• информация о пользователях и группах извлекается из LDAP-каталога, поэтому не нужно настраивать локальные записи на каждом хосте;

• средствами LDAP-сервера могут быть реализованы вложенные группы, в то время как участниками локальных групп могут быть только пользователи;

• для обеспечения отказоустойчивости можно использовать сразу несколько LDAP-серверов с репликацией между ними;

• аутентификация пользователей выполняется централизованно через сервер по протоколу LDAP + STARTTLS;

• служба SSSD гарантирует возможность автономного входа пользователя, даже когда нет соединения с сервером.

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

• потребуется включить анонимный доступ к LDAP-серверу, что увеличивает поверхность атак;

• аутентификация по протоколу LDAP не позволяет обеспечить прозрачную авторизацию при обращении к другим сетевым ресурсам компании;

• в настройках службы SSSD требуется указывать адреса конкретных LDAP-серверов, что походит только для небольших инфраструктур.

2. Централизация с помощью KDC

Пойдем дальше. Центр распространения ключей Kerberos можно поднять на эталонном решении от MIT, созданном в рамках проекта Athena, или устаревшем альтернативном проекте от Heimdal, который был запущен для обхода ограничений США на экспорт криптографии. С отменой запретов в начале нулевых необходимость в «теневом флоте» отпала, но Heimdal успел обосноваться в FreeBSD и macOS, поэтому дотянул до наших дней. Тем не менее, если учесть, что macOS Server вместе с их Open Directory отдали свои цифровые души в 2022, а система FreeBSD окончательно отказалась от Heimdal в прошлом году, судьба проекта выглядит незавидной. Можно было бы вспомнить про еще одну попытку клонирования Цербера «GNU Shishi», но похоже, что разработчики не нашли, на какие shishi инвестиции его делать, поэтому проект так и не выбрался из песочницы. Одним словом, с открытыми альтернативами KDC у нас тоже не очень.

Для работы с бэкендом KRB5 в секции domain конфигурационного файла sssd.conf следует указать следующие параметры:

• id_provider = files — указывает, что в качестве поставщика идентификационных данных следует использовать локальные файлы;

• auth_provider = krb5 — указывает, что для аутентификации пользователей следует использовать поставщика Kerberos; данный поставщик используется так же для смены пароля с помощью утилиты passwd, если иное не определено параметром chpass_provider;

• krb5_server = dc-1.company.lan, dc-2.company.lan — определяет список KDC-серверов, через которые служба SSSD сможет взаимодействовать с доменом;

• krb5_kpasswd = dc-1.company.lan — определяет сервер, через который пользователь сможет сменить пароль;

• krb5_realm = COMPANY.LAN — указывает область Kerberos, которая используется по умолчанию;

• cache_credentials = True — указывает, что хеши паролей нужно сохранять в локальном кэше для возможности аутентификации пользователей в автономном режиме без доступа к серверу;

• krb5_store_password_if_offline = True — указывает, что при отсутствии связи с сервером пароль пользователя в открытом виде можно хранить в связке ключей Linux для получения TGT-билета, когда это подключение станет возможно.

Дополнительно рекомендуется настроить библиотеку libkrb5 в файле /etc/krb5.conf для возможности использования утилит kinit, kvno и др.

Использование службы SSSD с бэкендом KDC имеет следующие преимущества:

• учетные данные пользователей хранятся централизованно на Kerberos-сервере;

• для обеспечения отказоустойчивости можно использовать несколько подчиненных реплик, которые будут периодически синхронизировать базу с главным сервером (см. kprop от Kerberos Propagate);

• аутентификация пользователей выполняется по протоколу Kerberos, поэтому в связке ключей остается TGT-билет, с помощью которого пользователи могут получить авторизованный доступ к любым сетевым ресурсам компании, поддерживающим Kerberos;

• служба SSSD гарантирует возможность автономного входа пользователя, даже когда нет соединения с сервером.

Однако, недостатки бэкенда KDC довольно значительны, чтобы его можно было рекомендовать:

• информация о пользователях и группах не может быть получена напрямую из KDC, поэтому в данном сценарии используются локальные базы, что требует создания одноименных локальных учетных записей;

• у компьютера нет собственной учетной записи, поэтому аутентификацию пользователя невозможно защитить с помощью сессионных ключей хоста по технологии Kerberos Armoring (FAST);

• возможен только один мастер-сервер, через который возможно вносить изменения в базу данных, а остальные реплики используются только для аутентификации;

• служба SSSD позволяет настраивать поиск KDC-серверов по SRV-записям, но этот поиск будет выполняться без учета принадлежности компьютера к сайту, что походит только для небольших инфраструктур.

3. Централизация с помощью LDAP + KDC

Как вы могли заметить, служба SSSD позволяет использовать любое сочетание бэкендов, поэтому вы можете настроить ее так, чтобы идентификационную информацию она получала через LDAP, а для аутентификации пользователей использовала Kerberos:

[domain/COMPANY.LAN]id_provider = ldapauth_provider = krb5chpass_provider = krb5access_provider = simple...

Такой способ настройки даст вам возможность сочетать преимущества LDAP и Kerberos: вам не потребуется создавать локальные учетные записи для доменных пользователей, при этом вы сможете обеспечить прозрачную авторизацию пользователей без ввода паролей при обращении к сетевым ресурсам компании. Например, именно так настраиваются Linux-клиенты в домене Avanpost DS. Однако, более комплексные бэкенды могут дать вам дополнительные преимущества, от которых не стоит отказываться. Например, бэкенд KRB5 выполняет простую Kerberos-аутентификацию, в ходе которой не используется учетная запись компьютера, а комплексные бэкенды IPA и AD позволяют использовать Kerberos Armoring для защиты канала, когда в момент аутентификации пользователя информация сетевых пакетов дополнительно шифруется сессионным ключом из TGT-билета, полученного на имя компьютера.

4. Сетевой домен Active Directory

И вот мы дошли до бэкенда AD. Концепция сетевого домена впервые была представлена компанией Microsoft в 1987 году в рамках операционной системы LAN Manager и получила дальнейшее развитие в линейке Windows NT. Тогда это был домен с одним мастером возможностью использования резервных контроллеров, в котором разрешение имен выполнялось с помощью засоряющего сеть широковещательного протокола NetBIOS, а для аутентификации пользователей использовался неустойчивый к Relay-атакам новейший протокол NT(LM). Учётные записи доменных пользователей хранились просто в реестре в собственной иерархической базе, но это не было проблемой, так как пределом мечтаний Microsoft в то время было 640 Килобайт 40 тысяч пользователей.

Домен Active Directory вышел в 2000 году в составе Win2k и стал уже второй попыткой Microsoft, которая произвела настоящую революцию в системном администрировании. Если с доменом NT компания Microsoft дышала в корму в спину лидеру тех лет — службе каталога eDirectory от Novell, то с выходом Active Directory она нацепила желтую майку лидера и не отдает ее никому до сих пор. Разработчикам Microsoft удалось настолько удачно интегрировать несколько перспективных технологий UNIX, таких как LDAP, DNS, Kerberos и NTP, что этот шедевр инженерной мысли уже третий десяток лет кормит своих создателей востребован на рынке.

Оспаривать лидерство Microsoft за это время пытались многие — Novell (eDirectory), IBM (SecureWay Directory Server), Apple (Open Directory), но они делали ставку на том, чтобы продавать за дорого; с такой предвыборной программой массовый Enterprise не захватить, поэтому они проиграли эту гонку, по-хорошему, ещё на старте.

Учитывая, что для работы в домене MS AD службе SSSD нужна собственная учетная запись, присоединение компьютера к домену AD не сводится к настройке конфигурационных файлов, поэтому для решения этой задачи рекомендуется использовать вспомогательные инструменты, например, утилиту realm из пакета realmd. Все конфигурационные файлы будут настроены автоматически, но для порядка прокомментируем ключевые параметры из секции domain конфигурационного файла sssd.conf:

• id_provider = ad — указывает поставщика идентификационных данных, который используется так же для аутентификации пользователей и смены пароля с помощью утилиты passwd;

• access_provider = ad — указывает, что для авторизации доступа нужно использовать параметры групповых политик MS AD, такие как «Allow/deny log on locally»;

• ad_domain = win.company.lan — указывает имя домена Active Directory, в котором работает компьютер;

• krb5_realm = WIN.COMPANY.LAN — указывает область Kerberos, которая используется по умолчанию;

• ldap_id_mapping = True — указывает, что в домене у пользователей и групп нет POSIX-идентификаторов и их значения нужно получить из идентификаторов безопасности Windows (SID);

• cache_credentials = True — указывает, что хеши паролей нужно сохранять в локальном кэше для возможности аутентификации пользователей в автономном режиме без доступа к серверу;

• krb5_store_password_if_offline = True — указывает, что при отсутствии связи с сервером пароль пользователя в открытом виде можно хранить в связке ключей Linux для получения TGT-билета, когда это подключение станет возможно;

• use_fully_qualified_names = True — определяет, что нужно использовать полные имена пользователей с указанием реалма домена;

• default_shell = /bin/bash — указывает, какую оболочку нужно использовать для терминала;

• fallback_homedir = /home/%u@%d — указывает путь к домашней директории.

Бэкенд AD объединяет возможности LDAP и Kerberos, поэтому предоставляет следующие преимущества:

• информация о пользователях и группах извлекается из LDAP-каталога, поэтому не нужно настраивать локальные записи на каждом хосте;

• средствами LDAP-сервера реализованы вложенные группы, в то время как участниками локальных групп могут быть только пользователи;

• для обеспечения отказоустойчивости можно использовать сразу несколько контроллеров домена с репликацией между ними. Служба SSSD обеспечивает быстрый поиск активного контроллера в домене для предоставления централизованных сервисов;

• аутентификация пользователей выполняется по протоколу Kerberos, поэтому в связке ключей остается TGT-билет, с помощью которого пользователи могут получить авторизованный доступ к любым сетевым ресурсам компании, поддерживающим Kerberos;

• служба SSSD гарантирует возможность автономного входа пользователя, даже когда нет соединения с сервером.

Недостатками бэкенда AD в сравнении с FreeIPA являются:

• Отсутствие в LDAP-каталоге POSIX-идентификаторов и необходимость их пересчета на стороне клиентов. У Microsoft когда-то было решение Identity Management for Unix (IDMU), но оно не поддерживается со времен Windows Server 2012.

• Отсутствие поддержки нативных технологий Linux (HBAC-правила, SUDO-правила, SSH-ключи, карты автоматического монтирования сетевых ресурсов).

• Полная зависимость от зарубежного вендора из недружественного государства.

Правда, последний из недостатков можно обойти, если обратиться к открытой реализации протоколов SMB и Active Directory для Linux и UNIX-подобных систем от Samba.

5. Сетевой домен AD на Samba

Проект Samba долгое время развивался как служба общего доступа к файлам по протоколу SMB (Server Message Block) и финансировался производителями систем хранения данных. Но учитывая, что аутентификация в домене NT работала по тому же протоколу, что и обмен файлами, во второй версии продукта добавили возможность использовать Samba в качестве контроллера домена для Windows-компьютеров. Но все эти успехи достигались потом и кровью реверс-инжинирингом, а ренессанс проекта случился только когда в 2004 году Европейская комиссия нагнула приняла решение по антимонопольному делу Microsoft и обязало ИТ-гиганта предоставить конкурентам информацию, которая необходима для реализации совместимости с Windows.

На разработку функций AD потребовалось еще 8 лет, но в 2012 году Samba4 все-таки увидела свет. По словам одного из разработчиков, архитектура Active Directory предполагала, что одни и те же данные должны быть доступны сразу по нескольким протоколам (LDAP, Kerberos, DCE RPC), для чего нескольким открытым проектам нужно было стать единым целым с точки зрения координации изменений и выпуска версий. Достичь таких договоренностей не получилось, поэтому Эндрю Триджелл принял решение написать свой собственный LDAP-сервер, а в качестве Kerberos выбрал реализацию от Heimdal, которая позволяла интегрировать этот KDC в свое приложение как библиотеку.

В то же время, ведущие дистрибутивы RedHat и SUSE уже давно отказались от Heimdal и сделали ставку на эталонную реализацию Kerberos от MIT, ибо экспортных ограничений уже давно нет, а поддерживать сразу два технически сложных продукта крайне расточительно; поэтому вопрос о переходе на MIT был поставлен уже в первый день рождения Samba4. Набор исправлений для перехода на MIT в итоге содержал более ста патчей, и потребовалось еще пять лет, чтобы встроить их в основные ветки продуктов и отладить их совместную работу. В итоге в 2017 году Samba стала поддерживать в экспериментальном режиме работу контроллера домена AD c MIT Kerberos. По презентации Александра Бокового с конференции SambaXP 2023 года можно понять, что к настоящему моменту практически все доработки уже сделаны, и для Fedora скоро выйдет продуктивная сборка на MIT Kerberos.

Что же касается функциональных возможностей службы SSSD с бэкендом AD, то Samba для SSSD ничем ни лучше и ни хуже MS AD. Вы получаете те же данные, только в профиль с другого сервера.

Из российских разработчиков на Samba строят свои службы каталогов сразу несколько компаний: T1 (Эллес), Ред Софт (Ред АДМ) и Базальт (Альт Домен). Можно добавить, что Эллес и Ред АДМ в качестве KDC используют Heimdal, в то время как Альт Домен допускает развертывание как на Heimdal, так и на MIT. Очевидно, что Heimdal является потенциальным кандидатом на вылет, но в Samba он пока еще рекомендуется по умолчанию, поэтому такой выбор не вызывает вопросов. Можно надеяться, что большую часть доработок, которые будут сделаны в Samba для Heimdal, получится в дальнейшем переложить на MIT.

6. Сетевой домен FreeIPA

Бэкенд IPA предназначен для службы каталога FreeIPA, которая была создана по мотивам MS Active Directory, но специально для Linux-компьютеров. Это собственный проект сообщества Linux и в его создании приняли участие те же люди, кто работал над Samba. Почему эти люди не захотели костылить дорабатывать Samba для удовлетворения потребностей Linux, явно нигде не обсуждается; но от программного кода Samba никто не отказался и он используется в FreeIPA для интеграции с лесами MS AD. Таким образом сейчас FreeIPA — это основной домен для Linux-компьютеров, а Samba AD — домен для Windows-компьютеров, в котором Linux-компьютеры могут работать, но только с рядом ограничений.

В ходе присоединения компьютера к домену IPA, также как и в случае MS AD,  компьютеру создается учетная запись и регистрируются DNS-записи, поэтому для решения этой задачи предлагается использовать утилиту ipa-client-install. Прокомментируем ключевые параметры из секции domain конфигурационного файла sssd.conf:

• id_provider = ipa — указывает поставщика идентификационных данных, который используется так же для аутентификации пользователей и смены пароля с помощью утилиты passwd, если иное не определено параметрами auth_provider и chpass_provider;

• access_provider = ipa — указывает, что для авторизации доступа нужно использовать HBAC-правила службы каталога FreeIPA;

• ipa_server = srv, dc-1.ipa.company.lan — указывает, что нужно выполнять поиск контроллеров домена по SRV-записям и добавить к этому списку дополнительно сервер dc-1.

• ipa_domain = ald.company.lan — указывает имя домена FreeIPA, в котором работает компьютер;

• ldap_tls_cacert = /etc/ipa/ca.crt — указывает путь к файлу, в котором находится корневой сертификат домена для переключения на шифрованный канал связи при подключении по LDAP;

• cache_credentials = True — указывает, что хеши паролей нужно сохранять в локальном кэше для возможности аутентификации пользователей в автономном режиме без доступа к серверу.

• krb5_store_password_if_offline = True — указывает, что при отсутствии связи с сервером пароль пользователя в открытом виде можно хранить в связке ключей Linux для получения TGT-билета, когда подключение станет возможно.

Бэкенд IPA со службой каталога FreeIPA могут дать вам следующие преимущества:

• Поддержка POSIX-идентификаторов: каждому пользователю и группе назначаются собственные идентификаторы UID/GID из диапазонов, которые закреплены за доменом. Служба SSSD берет значение идентификатора из LDAP, что гарантирует согласованность этой информации во всем домене;

• Поддержка HBAC-правил, которые позволяют настраивать права доступа пользователей на запуск приложений, использующих PAM-контекст для авторизации доступа. Например, вы можете установить на сервер XRDP, но разрешить его использование только для ограниченной группы лиц;

• Поддержка SUDO-правил, которые позволяют передавать пользователям права на выполнение отдельных команд от имени root. С помощью этих правил вы сможете расширить полномочия рядовых сотрудников ИТ-отдела, чтобы они могли выполнять отдельные задачи администрирования на рабочих станциях или серверах;

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

• Поддержка карт автоматического монтирования сетевых ресурсов, с помощью которых на Linux-компьютерах можно централизованно настраивать пространство имен распределенной файловой системы;

• Поддержка пользовательских карт SELinux; в Astra Linux вместо них поддержка встроенных механизмов МКЦ/МРД, которые обеспечивают дополнительный уровень защиты.

Из российских разработчиков основным локомотивом, двигающим FreeIPA в массы, является Астра (ALD Pro). Такой же подход использует РОСА (Dynamic Directory). Довольно много инсталляций даже у крупных компаний сейчас на ванильной сборке FreeIPA. Например, на Хабре есть статья от руководителя bigdata в Сбере, в которой он рассказывает о преимуществах использования FreeIPA в своей инфраструктуре.

7. Заключение

Как видите, если ориентироваться на «трушное» импортозамещение, после которого в инфраструктуре заказчика не должно остаться серверов и рабочих станций на Windows, то в качестве службы каталога нужно ориентироваться в первую очередь на FreeIPA. Однако, в больших организациях администраторы, отвечающие за серверную группировку, и те, в чьей зоне ответственности находятся рабочие станции — это совершенно разные люди с разными KPI; поэтому каждый пытается решать эту задачу независимо от других участников, в связи с чем у ребят, отвечающих за домен, может возникать большой соблазн потанцевать самба-румбу. В итоге каждый тянет бюджет одеяло на себя, и получается классическая упряжка, в которой лебедь, рак и щука усиленно имитируют полезную деятельность.

А вы в своей работе часто сталкиваетесь с ситуациями, когда технические решения принимаются, исходя из нетехнических факторов?