Всем привет!
Термин Microsoft Active Directory Domain Services включает в себя множество технологий, поэтому сразу уточню, в этой статье речь пойдет про использование контроллера домена только для аутентификации пользователей. То есть в финале, нужна возможность любому сотруднику предприятия сесть за любую рабочую станцию Linux, используя свой доменный логин и пароль.
Начиная с Windows 2000 Server для аутентификации пользователей домена используется протокол Kerberos, разработанный еще в 80-х годах прошлого столетия, алгоритм работы которого, ИМХО, являет собой пример отличного инженерного хака, в хорошем (изначальном:) смысле этого слова. В конце статьи есть ссылка на описание его работы, а сейчас надо сказать, что имеется несколько реализаций этого протокола и решение из этой статьи не привязано только к Microsoft Active Directory
Итак, на предприятии уже развернут контроллер домена, вероятнее всего - Microsoft Active Directory и перед нами - рабочая станция Linux (примеры будут для Debian, но работать будет и в других дистрибутивах и, даже, в моей любимой FreeBSD:). Как ввести ее в домен?
Да очень просто:
student@debian:~$ sudo apt install krb5-user -y
В Debian даже не понадобится редактировать, но убедитесь, и, при необходимости укажите эти строки в файле конфигурации Kerberos клиента (достаточно только их)
student@debian:~$ sudo nano /etc/krb5.conf
[libdefaults]
default_realm = CORP.RU
Вместо CORP.RU должно быть имя домена (Kerberos сферы) Вашего предприятия
И все, можно “входить” в домен:
student@debian:~$ kinit ivanovii
Password for ivanovii@CORP.RU:
student@debian:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: ivanovii@CORP.RU
Valid starting Expires Service principal
02/22/2023 00:09:13 02/22/2023 10:09:13 krbtgt/CORP.RU@CORP.RU
renew until 02/23/2023 00:09:09
ivanovii - зарегистрированный в домене логин пользователя, замените его на тот, который есть у Вас, можно, даже, использовать Administrator. В результате работы команды kinit была осуществлена аутентификация пользователя и получен Ticket-Granting Ticket (TGT) “билет на выдачу билетов”, позволяющий, в дальнейшем, получить билеты на доступ к зарегистрированным в домене сервисам, реализуя таким образом технологию единого входа - single sign-on (SSO).
Можно заканчивать статью :)
Постойте, но, например, в оснастке “Active Directory Users and Computers” никакой рабочей станции Linux не появилось, как же так? Да, действительно, контроллер домена по прежнему ничего не знает о нашей рабочей станции, фактически, наоборот, это наша рабочая станция, благодаря параметру default_realm = CORP.RU и соответствующим SRV записям в DNS
student@debian:~$ nslookup -q=SRV _kerberos._udp.corp.ru
...
kdc.corp.ru internet address = A.B.C.D
знает местоположение контроллера домена, и этого достаточно для работы с его Kerberos подсистемой. Для чего может понадобиться регистрация Linux системы в Active Directory и как это сделать - тема отдельной статьи, а сейчас вернемся к нашей задаче - вход доменной учетной записью в Linux систему
За процесс аутентификации пользователей при входе в Linux отвечает библиотека PAM (Pluggable Authentication Modules) использование которой я упоминал в этой статье. В нашем случае добавим в систему модуль, использующий Kerberos аутентификацию:
student@debian:~$ sudo apt install libpam-krb5 -y
В Debian новый модуль добавится в конфигурацию PAM автоматически, сперва логин/пароль будут проверяться в Kerberos, и, в случае неудачи, в локальной базе пользователей:
student@debian:~$ less /etc/pam.d/common-auth
...
auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_unix.so nullok try_first_pas
...
однако, попытка войти в систему доменным пользователем закончится неудачно:
student@debian:~$ sudo login
debian login: ivanovii
Password:
Authentication failure
а в журнале видна причина:
student@debian:~$ sudo tail /var/log/auth.log
...
Feb 22 01:18:43 debian login[1587]: pam_krb5(login:auth): user ivanovii authenticated as ivanovii@CORP.RU
Feb 22 01:18:43 debian login[1587]: pam_unix(login:account): could not identify user (from getpwnam(ivanovii))
...
аутентификация прошла успешно, но дальше, система ничего не знает о нашем пользователе (ни UID, ни GID ни прочих атрибутов)
$ id ivanovii
id: ‘ivanovii’: no such user
Вот теперь мы подошли к этапу, ради которого писалась статья:)
Если начать искать традиционное решение этой задачи, то, скорее всего, Вы узнаете о библиотеке Name Service Switch (NSS) и модулях LDAP, WinBIND или SSSD для нее. Но что если … просто создать учетную запись после успешной аутентификации?
Оказывается, библиотеку PAM можно расширять своими собственными скриптами, используя модуль pam_script. Давайте добавим его в систему:
student@debian:~$ sudo apt install libpam-script -y
Здесь авторы пакета для Debian не угадали наш замысел, расположив модули в таком порядке:
student@debian:~$ less /etc/pam.d/common-auth
...
auth [success=3 default=ignore] pam_krb5.so minimum_uid=1000
auth sufficient pam_script.so
auth [success=1 default=ignore] pam_unix.so nullok try_first_pass
...
Если честно, то такая конфигурация не только не подходит для нашей задачи, но и очень не хороша с точки зрения безопасности, легко довести ее до ситуации, когда будет достаточно знать логин локального пользователя, например root, для подключения к системе, пароль подойдет любой (вот за это любил FreeBSD, она за нас никогда ничего не делает:) Поэтому, поправьте конфигурацию расположив модули так:
student@debian:~$ sudo nano /etc/pam.d/common-auth
auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass
auth requisite pam_deny.so
auth sufficient pam_script.so
auth required pam_permit.so
В этом случае, после успешной аутентификации учтённой записи в Kerberos, выполнение “перепрыгнет” два следующих шага и запустит модуль pam_script. Остается только написать скрипт, который проверит наличие учетной записи, и, в случае ее отсутствия в системе - создаст:
student@debian:~$ sudo nano /usr/share/libpam-script/pam_script_auth
#!/bin/bash
id "$PAM_USER" &>/dev/null || useradd -m -s /bin/bash "$PAM_USER"
student@debian:~$ sudo chmod +x /usr/share/libpam-script/pam_script_auth
Проверяем:
student@debian:~$ sudo login
debian login: ivanovii
Password:
...
ivanovii@debian:~$ id
uid=1001(ivanovii) gid=1001(ivanovii) groups=1001(ivanovii)
ivanovii@debian:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1001_0zzvqR
Default principal: ivanovii@CORP.RU
Valid starting Expires Service principal
02/22/2023 04:14:30 02/22/2023 14:14:30 krbtgt/CORP.RU@CORP.RU
renew until 02/23/2023 04:14:30
Ну вот и все, мы в системе, и TGT у нас в кармане:)
Очевидным недостатком данного решения является то, что после удаления учётной записи пользователя из домена, она останется на всех рабочих станциях, за которыми он работал. Но, поскольку воспользоваться этими учтёнными записями будет невозможно (в локальной базе пользователей они заблокированы), можно пока оставить все как есть.
Спасибо, что дочитали до конца, надеюсь, было интересно, посмотрите ссылки, буду рад комментариям, до новых встреч!
Ссылки:
Комментарии (33)
little-brother
00.00.0000 00:00+9Статья не актуальна /s
Сейчас востребовано как развернуть контроллер домена на Линукс и мигрировать на него с AD :)
valvalva Автор
00.00.0000 00:00+7Да, все так, и у нас на предприятии уже развернуто решение (mit kerberos + ansible-pull + gitlab). Эта статья, небольшой его фрагмент, напишу остальное, если "зайдет" эта часть
Johan_Palych
00.00.0000 00:00+3Нет важных предустановок на клиенте:
Настройка синхронизации времени с контроллером домена(The Kerberos protocol requires the time of the client and server to match: if the system clocks of the client does not match that of the server, authentication will fail) Если разница будет более 5 минут.
Аутентификация в Kerberos
Чтобы аутентифицироваться в области Kerberos, требуются пакеты krb5-user и libpam-krb5, а также некоторые другие, которые не являются необходимыми, но делают жизнь проще:sudo apt-get install krb5-user libpam-krb5 libpam-ccreds auth-client-config Пакет auth-client-config позволяет просто настроить PAM для аутентификации множества сервисов. libpam-ccreds будет кэшировать параметры аутентификации, позволяя вам подключаться когда центр распространения ключей (KDC) недоступен. Этот пакет также полезен для переносных компьютеров, которые могут авторизовываться с использованием Kerberos в корпоративной сети, но также должны быть доступны и вне сети. Для настройки клиента наберите в терминале: sudo dpkg-reconfigure krb5-config
valvalva Автор
00.00.0000 00:00+1Спасибо, за комментарий, действительно синхронизация времени очень важна, а вот FQDN, в данном случае, не играет роли, как и остальное ПО (можно проверить экспериментально). Если эта статья зайдет, продолжу описание решения нашего предприятия, там и правильный FQDN пригодится!
Johan_Palych
00.00.0000 00:00Возможно настроить клиент с rdns в значение false в файле krb5.conf и руками добавить доменный IP сервера в /etc/hosts, но это большая боль.
Из своего опыта:
Основа - сервер kerberos с хранилищем Key Distribution Center (KDC)
Каждый сервер внутри Kerberos realm должен иметь Fully Qualified Domain Name (FQDN)
FQDN сервера является reverse-resolvable(rdns на клиенте)
Время в realm Kerberos должно быть синхронизовано.
Корректно настроены локальные NTP и DNS серверы в домене(доменах)
Создание ключей и сертификатов KDCvalvalva Автор
00.00.0000 00:00Для серверов в домене просто прописываем в DNS записи A и PTR, для рабочих станций в этом нет необходимости. FQDN рабочих станций (без прописывания его в DNS) используем для назначения им нужной конфигурации (через ansible), это другая задача и другая статья
askhats
00.00.0000 00:00На Microsoft Learn есть подробная пошаговая инструкция как ввести хост на линуксе в домен Active Directory.
valvalva Автор
00.00.0000 00:00У нас на предприятии домен не Active Directory. Инструкция, кстати, хорошая, но про сервера "how to join a SQL Server Linux host machine to an Active Directory domain" с рабочими станциями проще
gandjustas
00.00.0000 00:00А в чем разница?
valvalva Автор
00.00.0000 00:00Нет причин для регистрации рабочих станций Linux в домене Microsoft или керберос сфере, это позволяет не указывать их в DNS, короче, с рабочими станциями проще)
avelor
00.00.0000 00:00Мне кажется realmd ощутимо проще (он делает всё вот это вот), да и можно работать автономно без доступа к кд разок залогинившись. Буквально realm join domain.com и всё, остаётся по вкусу разрешить ssh/sudo ну и накидать немношк в sssd.conf как будет выглядеть логин и создаваться домашние папки
valvalva Автор
00.00.0000 00:00Мы на предприятии попробовали все варианты, в том числе и realmd/sssd, остановились на этом. Ансиблу, конечно, все равно, но плейбук получается короче :) И работает не только с AD
vitaly_il1
00.00.0000 00:00+1По моему опыту (около пяти лет назад) sssd был самым простым.
gandjustas
00.00.0000 00:00У меня тупой вопрос: есть ли "стандартный" способ ввода линуксовой машины в домен? Рекомендуемый вендорами и используемый большинством?
vitaly_il1
00.00.0000 00:00Вопрос хороший!
Unix-way - это возможность делать одно и то же как минимум десятком способов. :-)
SSSD и realm на мой взгляд самый простой и надежный.gandjustas
00.00.0000 00:00А какое самое простое решение для керберос сервера на замену АД?
vitaly_il1
00.00.0000 00:00AD - это не только керберос.
ИМХО - FreeIPA. (в общем-то все компоненты в линуксе есть, и настоящих хакер может их настроить, но смысла нет).gandjustas
00.00.0000 00:00Я знаю что такое AD, но меня интересует именно единый вход:
Чтобы пользователи входили на терминал под доменными учетками (в том числе вход без подключения к сети, сброс пароля итд)
Чтобы веб-приложения аутентифицировали пользователей под доменными учетками
Чтобы сервисы (systemd) могли быть запущены под доменными учетками
Чтобы сервисы могли ходить в базу данных под домменными учетками
Чтобы работало делегирование, то есть пользователь обращался к сервису под своей учеткой, а сервис в базу под учеткой пользователя
vitaly_il1
00.00.0000 00:00FreeIPA это наиболее приличный продукт на линуксе для эмуляции насколько знаю.
Я использовал только #1, посмотрите доки-форумы для остального.
sshikov
00.00.0000 00:00Ну пожалуй отвечу и вам тоже — посмотрите на любой хадуп с настроенным керберосом. Там есть все что вы просите. Насчет «без подключения к сети» только сомневаюсь немного. То есть, такое решение возможно. Основа — FreeIPA. Не смогу сказать, просто или сложно это настроить, это не моя компетенция, но такие решения в практике не единичны, а массовы (ну и специалисты которые это умеют, очевидно тоже).
sshikov
00.00.0000 00:00На FreeIPA работают куча хадуп кластеров. Я затрудняюсь сказать, сколько их, но только вокруг меня на работе их сотни. Смысл есть (хотя не всем это конечно нужно).
valvalva Автор
00.00.0000 00:00Тупыми бывают только ответы) Вопросы - это всегда хорошо! Попробую ответить так, надо начать с составления списка того, что нужно пользователям и как им это предоставить, соблюдая требования безопасности. Hапример - использовать один логин и пароль на все сервисы и на любом компьютере предприятия, авторизованный доступ в интернет, без необходимости еще раз вводить пароль, свой рабочий стол на любом компьютере предприятия, общие файловые шары для групп пользователей, возможность легко менять конфигурацию рабочих станций согласно задачам отделов, и так далее. Имея такой список можно подбирать решения, и согласен с Виталием, Unix-way позволяет из небольших компонентов, делающих что-то одно, собрать любое сложное комплексное решение. Противоположный и тоже, по своему хороший подход - Microsoft AD - есть сразу все, что нужно, но только в мире Windows
vitaly_il1
00.00.0000 00:00Как любитель (и профессионал) линукса скажу честно - на линукс (*nix) за 40 лет не придумали ничего сопоставимого с AD по feature-set.
То есть даже если мы уберем требование "сделайте нам AD-compatible", и оставим только технические требования, мы не сможет "закрыть" все вещи, которые решает AD.gandjustas
00.00.0000 00:00Меня только вопросы аутентификации и беспокоят и сертификаты, что-то вроде ad cs
Worky
00.00.0000 00:00А не кажется ли Вам, что сама концепция AD не юникс-вей? Ведь юникс-вей был мейнфрейм+ куча терминалов, там такого не нужно было. Это когда концепция ПЦ победила, то и занялись - а как этим лесом ПЦ централизованно управлять? И придумали!
А нынче опять все возвращается на круги своя, только вместо одного менйфрейма кластер и граф терминал. И возникает вопрос - и зачем тогда AD???
vitaly_il1
00.00.0000 00:00ИМХО, важна не идеология, а потребности пользователей. И в фирмах, который заботятся о безопасности, по-прежнему хотят управлять пользовательскими компьютерами.
gandjustas
00.00.0000 00:00Вот тут описал чего хотелось бы https://habr.com/ru/post/718632/comments/#comment_25262020
Abyss777
00.00.0000 00:00+1Когда-то пользовался PBIS https://github.com/BeyondTrust/pbis-open там всё работало, и доступ к самба шарам и автообновление билета, и обновление dns, и билет на саму машину отдельный, вообще как будто на виндовой машине работаешь - всё прозрачно.
но увы...
Единственный косяк, но он не PBIS, а приложений под линукс... структура домашнего каталога по умолчанию:/home/local/domain/user
её не понимает половина приложений, правила apparmor рассчитаны на плоскую структуру/home/user
но их хоть можно подправить, но мне так и не удалось в хроме заставить работать диалоги открытия/сохранения файлов.
MaxStirlits
Если вынуть сетевой провод из рабочей станции, залогинится скоре всего можно будет.
valvalva Автор
Нет, тут, к сожалению, не получится, не отработает pam_krb5, а с точки зрения pam_unix учетная запись заблокирована. Но ваш вопрос навел на мысль, что можно, например, при создании учетной записи, таки назначить ей локальный пароль, тогда да, будет можно логиниться доменной учеткой без доступа к домену. Но тогда надо обязательно решать вопрос с удалением локальных учеток, при удалении их в домене.