Всем привет!

Термин 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)


  1. MaxStirlits
    00.00.0000 00:00
    +1

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


    1. valvalva Автор
      00.00.0000 00:00
      +1

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


  1. little-brother
    00.00.0000 00:00
    +9

    Статья не актуальна /s

    Сейчас востребовано как развернуть контроллер домена на Линукс и мигрировать на него с AD :)


    1. valvalva Автор
      00.00.0000 00:00
      +7

      Да, все так, и у нас на предприятии уже развернуто решение (mit kerberos + ansible-pull + gitlab). Эта статья, небольшой его фрагмент, напишу остальное, если "зайдет" эта часть


    1. a-a
      00.00.0000 00:00

      Zential чем не угодил?


  1. Johan_Palych
    00.00.0000 00:00
    +3

    Нет важных предустановок на клиенте:

    Аутентификация в 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


    1. valvalva Автор
      00.00.0000 00:00
      +1

      Спасибо, за комментарий, действительно синхронизация времени очень важна, а вот FQDN, в данном случае, не играет роли, как и остальное ПО (можно проверить экспериментально). Если эта статья зайдет, продолжу описание решения нашего предприятия, там и правильный FQDN пригодится!


      1. 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 серверы в домене(доменах)
        Создание ключей и сертификатов KDC


        1. valvalva Автор
          00.00.0000 00:00

          Для серверов в домене просто прописываем в DNS записи A и PTR, для рабочих станций в этом нет необходимости. FQDN рабочих станций (без прописывания его в DNS) используем для назначения им нужной конфигурации (через ansible), это другая задача и другая статья


  1. askhats
    00.00.0000 00:00

    На Microsoft Learn есть подробная пошаговая инструкция как ввести хост на линуксе в домен Active Directory.


    1. valvalva Автор
      00.00.0000 00:00

      У нас на предприятии домен не Active Directory. Инструкция, кстати, хорошая, но про сервера "how to join a SQL Server Linux host machine to an Active Directory domain" с рабочими станциями проще


      1. gandjustas
        00.00.0000 00:00

        А в чем разница?


        1. valvalva Автор
          00.00.0000 00:00

          Нет причин для регистрации рабочих станций Linux в домене Microsoft или керберос сфере, это позволяет не указывать их в DNS, короче, с рабочими станциями проще)


  1. avelor
    00.00.0000 00:00

    Мне кажется realmd ощутимо проще (он делает всё вот это вот), да и можно работать автономно без доступа к кд разок залогинившись. Буквально realm join domain.com и всё, остаётся по вкусу разрешить ssh/sudo ну и накидать немношк в sssd.conf как будет выглядеть логин и создаваться домашние папки


    1. valvalva Автор
      00.00.0000 00:00

      Мы на предприятии попробовали все варианты, в том числе и realmd/sssd, остановились на этом. Ансиблу, конечно, все равно, но плейбук получается короче :) И работает не только с AD


      1. vitaly_il1
        00.00.0000 00:00
        +1

        По моему опыту (около пяти лет назад) sssd был самым простым.


        1. gandjustas
          00.00.0000 00:00

          У меня тупой вопрос: есть ли "стандартный" способ ввода линуксовой машины в домен? Рекомендуемый вендорами и используемый большинством?


          1. vitaly_il1
            00.00.0000 00:00

            Вопрос хороший!
            Unix-way - это возможность делать одно и то же как минимум десятком способов. :-)
            SSSD и realm на мой взгляд самый простой и надежный.


            1. gandjustas
              00.00.0000 00:00

              А какое самое простое решение для керберос сервера на замену АД?


              1. vitaly_il1
                00.00.0000 00:00

                AD - это не только керберос.
                ИМХО - FreeIPA. (в общем-то все компоненты в линуксе есть, и настоящих хакер может их настроить, но смысла нет).


                1. gandjustas
                  00.00.0000 00:00

                  Я знаю что такое AD, но меня интересует именно единый вход:

                  1. Чтобы пользователи входили на терминал под доменными учетками (в том числе вход без подключения к сети, сброс пароля итд)

                  2. Чтобы веб-приложения аутентифицировали пользователей под доменными учетками

                  3. Чтобы сервисы (systemd) могли быть запущены под доменными учетками

                  4. Чтобы сервисы могли ходить в базу данных под домменными учетками

                  5. Чтобы работало делегирование, то есть пользователь обращался к сервису под своей учеткой, а сервис в базу под учеткой пользователя


                  1. vitaly_il1
                    00.00.0000 00:00

                    FreeIPA это наиболее приличный продукт на линуксе для эмуляции насколько знаю.
                    Я использовал только #1, посмотрите доки-форумы для остального.


                  1. sshikov
                    00.00.0000 00:00

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


                1. sshikov
                  00.00.0000 00:00

                  На FreeIPA работают куча хадуп кластеров. Я затрудняюсь сказать, сколько их, но только вокруг меня на работе их сотни. Смысл есть (хотя не всем это конечно нужно).


              1. valvalva Автор
                00.00.0000 00:00

                Отличное название для следующей статьи! Принято в работу)


          1. valvalva Автор
            00.00.0000 00:00

            Тупыми бывают только ответы) Вопросы - это всегда хорошо! Попробую ответить так, надо начать с составления списка того, что нужно пользователям и как им это предоставить, соблюдая требования безопасности. Hапример - использовать один логин и пароль на все сервисы и на любом компьютере предприятия, авторизованный доступ в интернет, без необходимости еще раз вводить пароль, свой рабочий стол на любом компьютере предприятия, общие файловые шары для групп пользователей, возможность легко менять конфигурацию рабочих станций согласно задачам отделов, и так далее. Имея такой список можно подбирать решения, и согласен с Виталием, Unix-way позволяет из небольших компонентов, делающих что-то одно, собрать любое сложное комплексное решение. Противоположный и тоже, по своему хороший подход - Microsoft AD - есть сразу все, что нужно, но только в мире Windows


            1. vitaly_il1
              00.00.0000 00:00

              Как любитель (и профессионал) линукса скажу честно - на линукс (*nix) за 40 лет не придумали ничего сопоставимого с AD по feature-set.
              То есть даже если мы уберем требование "сделайте нам AD-compatible", и оставим только технические требования, мы не сможет "закрыть" все вещи, которые решает AD.


              1. gandjustas
                00.00.0000 00:00

                Меня только вопросы аутентификации и беспокоят и сертификаты, что-то вроде ad cs


                1. vitaly_il1
                  00.00.0000 00:00

                  с этим все в порядке


              1. Worky
                00.00.0000 00:00

                А не кажется ли Вам, что сама концепция AD не юникс-вей? Ведь юникс-вей был мейнфрейм+ куча терминалов, там такого не нужно было. Это когда концепция ПЦ победила, то и занялись - а как этим лесом ПЦ централизованно управлять? И придумали!

                А нынче опять все возвращается на круги своя, только вместо одного менйфрейма кластер и граф терминал. И возникает вопрос - и зачем тогда AD???


                1. vitaly_il1
                  00.00.0000 00:00

                  ИМХО, важна не идеология, а потребности пользователей. И в фирмах, который заботятся о безопасности, по-прежнему хотят управлять пользовательскими компьютерами.


            1. gandjustas
              00.00.0000 00:00

              Вот тут описал чего хотелось бы https://habr.com/ru/post/718632/comments/#comment_25262020


  1. Abyss777
    00.00.0000 00:00
    +1

    Когда-то пользовался PBIS https://github.com/BeyondTrust/pbis-open там всё работало, и доступ к самба шарам и автообновление билета, и обновление dns, и билет на саму машину отдельный, вообще как будто на виндовой машине работаешь - всё прозрачно.
    но увы...

    Единственный косяк, но он не PBIS, а приложений под линукс... структура домашнего каталога по умолчанию: /home/local/domain/user её не понимает половина приложений, правила apparmor рассчитаны на плоскую структуру /home/user но их хоть можно подправить, но мне так и не удалось в хроме заставить работать диалоги открытия/сохранения файлов.