Для упрощения добавления Ubuntu или Debian в домен Active Directory вместо связки samba+winbind можно использовать пакет realmd (Realm Discovery), который позволяет автоматически настроить службу SSSD (System Security Services Daemon) в Linux. Эта статья применима для Ubuntu 20.04/22.04 и Debian 10/11.
Прежде всего обновите пакеты на вашем хосте Linux:
$ sudo apt -y update
Выведите текущее имя хоста:
$ hostnamectl
Если нужно, измените имя хоста:
$ sudo hostnamectl set-hostname ubnt22.vmblog.ru
Проверьте, что в Linux корректно настроен клиент DNS и он указывает на ваши контроллеры домена AD:
# cat /etc/resolv.conf
nameserver 192.168.42.10 nameserver 192.168.142.10 search vmblog.ru
Т.к. пакет SSSD используется Kerberos для аутентификации, убедиться, что у вас корректно настроен NTP клиент и настроена синхронизация времени с контроллерами домена AD. Можно настроить так:
$ sudo systemctl status systemd-timesyncd
$ sudo nano /etc/systemd/timesyncd.conf
NTP=192.168.42.10
$ sudo systemctl restart systemd-timesyncd
Установите необходимые пакеты:
$ apt -y install realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin oddjob oddjob-mkhomedir packagekit
Проверьте, что ваш хост может обнаружить домен AD:
$ realm discover vmblog.ru --verbose
vmblog.ru type: kerberos realm-name: VMBLOG.RU domain-name: vmblog.ru configured: no server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: libnss-sss required-package: libpam-sss required-package: adcli required-package: samba-common-bin
Вы можете задать атрибуты вашего хоста Linux, которые нужно сохранить в учетной записи компьютера в Active Directory (атрибуты operatingSystem и operatingSystemVersion):
$ nano /etc/realmd.conf
[active-directory] os-name = Ubuntu GNU/Linux os-version = 22.04 (Jammy Jellyfish)
Для добавления Linux хоста в домен Active Directory вам понадобится учетная запись AD с правами администратора домена (или пользователь, которому делегированы права на добавление компьютеров в домен).
В самом простом случае для добавления хоста Ubuntu/Debian в домен достаточно выполнить команду:
$ sudo realm join -U apetrov vmblog.ru
Введите пароль доменного пользователя.
По умолчанию для вашего хоста Linux будет создана учетная запись компьютера AD в корневом OU (Organizational Unit) с именем Computers. Вы можете сразу поместить вам хост в нужную OU. Для этого используйте другую команду добавления в домен:
$ sudo realm join --verbose --user=apetrov --computer-ou="OU=Linux Servers,OU=HQ,DC=vmblog,DC=ru" vmblog.ru
Проверьте, что ваш хост теперь находится в домене AD:
$ sudo realm list
type: kerberos realm-name: VMBLOG.RU domain-name: vmblog.ru configured: kerberos-member server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: libnss-sss required-package: libpam-sss required-package: adcli required-package: samba-common-bin login-formats: %U@vmblog.ru login-policy: allow-realm-logins
Чтобы автоматически создавать домашний каталог пользователям, выполните:
sudo bash -c "cat > /usr/share/pam-configs/mkhomedir" <<EOF
Name: activate mkhomedir
Default: yes
Priority: 900
Session-Type: Additional
Session:
required pam_mkhomedir.so umask=0022 skel=/etc/skel
EOF
$ sudo pam-auth-update
Выберите пункт activate mkhomedir.
Проверьте конфигурацию sssd в файле:
$ cat /etc/sssd/sssd.conf
Чтобы применить изменения из файла sssd.conf, нужно перезапустить службу:
$ systemctl status sssd
Теперь вы может выполнить аутентификацию в Linux с помощью учетной записи Active Directory (указывается в формате UPN: user@vmblog.ru).
Проверьте, что вы можете получить информацию о пользователе AD:
$ id apetrov@vmblog.ru
Можно переключиться на пользователя:
su - apetrov@vmblog.ru
Creating directory '/home/apetrov@vmblog.ru'. apetrov@vmblog.ru@ubnt22:~$
Чтобы разрешить доменным пользователям вход на хост Linux (консоль+SSH), выполните:
$ realm permit apetrov1@vmblog.ru ivanov2@vmblog.ru
Или разрешить доступ для пользователей доменных групп безопасности:
$ ream permit -g LinuxAdmins@vmblog.ru
Чтобы разрешить, запретить доступ всем пользователям домена:
$ sudo realm permit --all
$ sudo realm deny --all
Вы можете разрешить определенным пользователям и группам повышать привилегии с помощью sudo. Создайте файл:
$ sudo nano /etc/sudoers.d/linux-admins
Добавьте в него пользователей и/или группы, которым разрешено sudo:
%LinuxAdminx@vmblog.ru ALL=(ALL) ALL aivanov@vmblog.ru ALL=(ALL) ALL
Измените права на файл:
$ chmod 0440 /etc/sudoers.d/linux-admins
Теперь попробуйте аутентифицироваться на вашем Linux хосте с доменной учетной записью.
Процесс добавления rpm-based дистрибутивов (CentOS/Rocky Linux/RHEL/Fedora) в домен Active Directory немного отличается и описан в отдельной статье.
Joining a Debian Client to Active Directory
Note: This walkthrough was taken almost entirely from https://help.ubuntu.com/community/ActiveDirectoryWinbindHowto. A few configuration changes in the PAM section and verbiage used are the only differences. More work is required to make this Debian-specific.
Required Software/Packages
Name |
Version |
MS Server 2003 w/AD and DNS |
2003 Standard |
GNU/Linux |
(Debian 6.0 or later) |
Winbind |
2:3.6.6-3 |
Samba |
2:3.6.6-3 |
Krb5-user |
1.10.1+dfsg-2 |
Libpam-krb5 |
4.6-1 |
libpam-winbind |
|
libnss-winbind |
Time settings
Kerberos requires that the device time be within a few minutes of the server time. See NTP to find out how to keep clocks up-to-date.
FQDN
A valid FQDN is necessary for Kerberos and AD. Edit the local host file so that it is resolvable.
Location: /etc/hosts
127.0.0.1 linux.test.server.com localhost linux
Configure Kerberos
Use apt-get install to install the following packages:
krb5-user libpam-krb5
krb5 template Location: /etc/krb5.conf
[logging] Default = FILE:/var/log/krb5.log [libdefaults] ticket_lifetime = 24000 clock-skew = 300 default_realm = test.server.com # dns_lookup_realm = false # dns_lookup_kdc = true [realms] test.example.com = { kdc = example.test.server.com:88 admin_server = example.test.server.com:464 default_domain = test.server.com } [domain_realm] .server.com = test.server.com server.com = test.server.com
Test your configuration by requesting a ticket
root@linux:~# kinit Administrator@test.server.com Password for Administrator@test.server.com : ****
Use klist to verify request worked
root@linux:~# klist Ticket cache: File: /tmp/krb5cc_0 Default principal: Administrator@test.server.com Valid starting Expires Service principal 05/16/07 10:30:42 05/16/07 20:30:01 Krbtgt/test.server.com@test.server.com renew until 05/16/07 10:30:42
Join the Domain
Use apt-get install to install the following packages:
winbind samba
Join Location: /etc/samba/smb.conf
[global] security = ads realm = test.server.com password server = 10.0.0.1 workgroup = test # winbind separator = + idmap uid = 10000-20000 idmap gid = 10000-20000 winbind enum users = yes winbind enum groups = yes template homedir = /home/%D/%U template shell = /bin/bash client use spnego = yes client ntlmv2 auth = yes encrypt passwords = yes winbind use default domain = yes restrict anonymous = 2 domain master = no local master = no preferred master = no os level = 0
Restart services
root@linux:~# /etc/init.d/winbind stop root@linux:~# /etc/init.d/samba restart root@linux:~# /etc/init.d/winbind start
Request Kerberos TGT for an account
root@linux:~# net ads join Using short domain name – test Joined ‘Linux’ to realm ‘test.server.com’
Test
# wbinfo -u
Setup Authentication
nsswitch Location: /etc/nsswitch.conf
passwd: compat winbind group: compat winbind shadow: compat
Test
root@linux:~# getent passwd root:x:0:0:root:/root:/bin/bash . . . test+administrator:x:10000:10000:Administrator:/home/test/administrator:/bin/b… test+gast:x:10001:10001:Gast:/home/LAB/gast:/bin/bash . . .
root@linux:~#: getent group root:x:0: daemon:x:1: bin:x:2: . . . test+organizations-admins:x:10005:administrator test+domain-admins:x:10006: user, administrator . . .
PAM
Location: /etc/pam.d/common-account
account sufficient pam_winbind.so account required pam_unix.so
Location: /etc/pam.d/common-auth
auth sufficient pam_winbind.so auth sufficient pam_unix.so nullok_secure use_first_pass auth required pam_deny.so
Location: /etc/pam.d/common-session
session required pam_unix.so session required pam_mkhomedir.so umask=0022 skel=/etc/skel
Location: /etc/pam.d/sudo
Auth sufficient pam_winbind.so Auth sufficient pam_unix.so use_first_pass Auth required pam_deny.so @include common-account
Final Config
Each domain needs a directory in home
root@linux:~# mkdir /home/test Login login: test+user password: **** . . . test+user@linux:~$
unix-linux:debian:buster:join-debian-linux-10-buster-to-active-directory-domain-with-sssd-realmd-with-ad-security-group-authorization-in-pam-for-console-login-and-ssh-sso-putty-and-apache-kerberos-auth
Содержание
Подключение Debian GNU/Linux 10 (Buster) к домену Active Directory с помощью SSSD/realmd и настройка PAM для аутентификации и авторизации sshd/Apache
Подробное описание процедуры присоединения компьютера с Debian GNU/Linux к домену Active Directory с помощью SSSD и realmd можно найти здесь. Рекомендуется предварительно ознакомится с этим материалом, а также с замечаниями по настройке SSSD в Debian GNU/Linux.
Здесь приведён сокращённый план действий по присоединению Debian GNU/Linux 10 (Buster) к домену Active Directory с помощью SSSD и realmd.
Подготовка
В первую очередь необходимо обеспечить правильную работу DNS-клиента и настроить синхронизацию времени с источниками, используемыми в Active Directory. Эти моменты важны для правильной работы протокола Kerberos.
Соответствующие настройки описаны в статьях:
Выполним команду присвоения полного доменного имени в качестве имени хоста, так как по умолчанию в Debian 10 в качестве hostname используется имя узла без доменной части. Это позволит избежать некоторых проблем при вводе компьютера в домен с помощью realmd:
# hostname KOM-SRV01.sub.holding.com
Дополнительно необходимо отредактировать файл /etc/hosts
и указать там в качестве IP адреса хоста адрес одного из сетевых интерфейсов.
То есть, строку вида:
- hosts
-
... 127.0.1.1 KOM-SRV01 ...
заменяем на строку вида:
- hosts
-
... 10.1.0.3 KOM-SRV01.sub.holding.com KOM-SRV01 ...
Если требуется, предварительно создаём в домене учётную запись компьютера
Установка realmd/SSSD и ввод в домен
Устанавливаем пакеты необходимые для ввода в домен:
# apt-get install realmd sssd-tools sssd libnss-sss libpam-sss adcli packagekit -y
Выполняем обнаружение информации о домене, которое должно отработать без ошибок:
# realm discover sub.holding.com --verbose
Настраиваем информацию о компьютере, которая будет передана в каталог Active Directory при присоединении к домену.
- realmd.conf
-
[active-directory] os-name = Debian GNU/Linux os-version = 10.1 (Buster)
Выполняем присоединение компьютера к домену Active Directory:
# realm join --verbose --user=adm-petya \ --user-principal="host/kom-srv01.sub.holding.com@SUB.HOLDING.COM" \ --computer-ou="OU=Linux Servers,OU=KOM,DC=sub,DC=holding,DC=com" \ kom-dc01.sub.holding.com
Поддержка Kerberos
Устанавливаем клиентское ПО поддержки Kerberos:
# apt-get install krb5-user -y
Проверяем наличие и содержимое keytab-файла. В нём, как минимум, должны быть записи типа host/*
# klist -e -k -t /etc/krb5.keytab
Настраиваем конфигурацию клиента Kerberos:
# nano -Y sh /etc/krb5.conf
Пример настроенного файла:
- krb5.conf
-
[libdefaults] dns_lookup_kdc = no dns_lookup_realm = no ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false default_realm = SUB.HOLDING.COM # for Windows 2008 with AES default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 [realms] SUB.HOLDING.COM = { kdc = kom-dc01.sub.holding.com kdc = kom-dc02.sub.holding.com admin_server = kom-dc01.sub.holding.com default_domain = sub.holding.com } [domain_realm] .sub.holding.com = SUB.HOLDING.COM sub.holding.com = SUB.HOLDING.COM
Конфигурация SSSD
Настраиваем конфигурацию SSSD:
# nano /etc/sssd/sssd.conf
Пример настроенной конфигурации:
- sssd.conf
-
[sssd] domains = sub.holding.com config_file_version = 2 services = nss, pam default_domain_suffix = sub.holding.com [domain/sub.holding.com] ad_server = kom-dc01.sub.holding.com, kom-dc02.sub.holding.com ad_backup_server = prm-dc01.sub.holding.com, ekb-dc02.sub.holding.com ad_domain = sub.holding.com ad_gpo_access_control = disabled krb5_realm = SUB.HOLDING.COM realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True ldap_idmap_default_domain_sid = S-1-5-21-2599488624-3617735854-14887588928 ldap_idmap_range_size = 2000000 ldap_use_tokengroups = False use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad subdomains_provider = none dyndns_update = False debug_level = 0
Перезапускаем службу с очисткой кеша sssd:
# ( systemctl stop sssd ) && \ ( rm -f /var/lib/sss/db/* ) && ( rm -f /var/lib/sss/mc/* ) && \ ( systemctl start sssd )
Выполняем проверку возможности извлечения информации из каталога Active Directory.
Получаем информацию о любой доменной группе безопасности:
# getent group kom-servers-admins@sub.holding.com
Получаем информацию о любом доменной пользователе:
# id adm-petya # getent passwd adm-petya
PAM и домашний каталог
PAM и доступ на консоль
Создадим свой файл для перечисления учётных записей (доменных и локальных), которым будет разрешёно подключение к консоли компьютера:
# nano -Y sh /etc/security/access-groups-to-login
- access-groups-to-logi
-
sudo root kom-servers-admins@sub.holding.com
Ограничим доступ к файлу:
# chown root:root /etc/security/access-groups-to-login # chmod 600 /etc/security/access-groups-to-login
Отредактируем модуль PAM, определяющий права доступа к консоли компьютера:
# nano -Y sh /etc/pam.d/login
Вставляем перед блоком со строкой @include common-account
ссылку на вызов авторизации через созданный нами файл (access-groups-to-login
)
- login
-
... # Restricted access to service from local and domain groups account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/security/access-groups-to-login ...
Выполняем проверку входа в систему, используя разрешённую и неразрешённую доменную учётную запись. При этом отслеживаем происходящее в механизмах аутентификации/авторизации через системный лог auth.log
# tail -f /var/log/auth.log
PAM и доступ к SSH
Отредактируем PAM-модуль, отвечающий за настроку авторизации при подключении через службу сервера SSH
# nano -Y sh /etc/pam.d/sshd
Вставляем перед блоком со строкой @include common-account
ссылку на вызов авторизации через созданный нами файл (access-groups-to-login
)
- sshd
-
... # Restricted access to service from local and domain groups account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/security/access-groups-to-login ...
Выполняем проверку входа в систему через SSH, используя разрешённую и неразрешённую доменную учётную запись. При этом отслеживаем происходящее в механизмах аутентификации/авторизации через системный лог auth.log
# tail -f /var/log/auth.log
PAM и доступ к Apache
Пример создания собственного PAM-модуля для других служб, например, для организации доменной аутентфикации/авторизации в веб-сервере Apache:
Создадим свой файл для перечисления учётных записей (доменных и локальных), которым будет разрешёно подключение к веб-серверу:
# nano -Y sh /etc/security/access-groups-to-web
- access-groups-to-web
-
kom-servers-admins@sub.holding.com kom-web-admins@sub.holding.com
Создадим конфигурационный файл — PAM-модуль
# nano -Y sh /etc/pam.d/apache2
- apache2
-
auth required pam_sss.so account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/security/access-groups-to-web account required pam_sss.so
Ограничим доступ к файлам:
# chown root:root /etc/pam.d/apache2 # chmod 644 /etc/pam.d/apache2 # chown root:root /etc/security/access-groups-to-web # chmod 600 /etc/security/access-groups-to-web
SSHD и PuTTy
SUDO
Разрешаем sudo для доменных учётных записей.
Создадим отдельный файл для выдачи прав выполнять sudo доменным учётным записям:
# nano -Y sh /etc/sudoers.d/kom-srv-linux-admins
Пример содержимого файла с одной доменной группой доступа, которой разрешено выполнять sudo без ограничений:
- kom-srv-linux-admins
-
%kom-servers-admins@sub.holding.com ALL=(ALL) ALL
Ограничим доступ к файлу
# chmod 0440 /etc/sudoers.d/kom-srv-linux-admins
Расширение keytab
В случае необходимости настроки Kerberos аутентификациии в домене Active Directory, возможно потребуется дополнительная настройка keytab-файла на Linux системе.
Пример команд добавления SPN-записи типа HTTP/*
(для поддержки доменной аутентификации Kerberos на веб-сервере)
Подключаемся к keytab-файлу и получаем информацию о SPN-запиях в нём и текущем номере kvno (нужен для ключа -k
)
read_kt /etc/krb5.keytab list -k -e
Добавляем записи поддержки Kerberos для веб-сервера (при запросе хешей указываем те же, что указаны для уже существующих SPN-записей)
add_entry -key -p HTTP/kom-srv01.sub.holding.com@SUB.HOLDING.COM -k 3 -e aes256-cts-hmac-sha1-96 add_entry -key -p HTTP/kom-srv01.sub.holding.com@SUB.HOLDING.COM -k 3 -e aes128-cts-hmac-sha1-96 add_entry -key -p HTTP/kom-srv01.sub.holding.com@SUB.HOLDING.COM -k 3 -e des3-cbc-sha1 add_entry -key -p HTTP/kom-srv01.sub.holding.com@SUB.HOLDING.COM -k 3 -e arcfour-hmac add_entry -key -p HTTP/kom-srv01.sub.holding.com@SUB.HOLDING.COM -k 3 -e des-cbc-md5 add_entry -key -p HTTP/kom-srv01.sub.holding.com@SUB.HOLDING.COM -k 3 -e des-cbc-crc
Перечиваем результат и записываем изменения в keytab-файл:
list -k -e write_kt /etc/krb5.keytab exit
Проверяем результат:
# klist -e -k -t /etc/krb5.keytab
Проверяем есть ли нужная SPN-запись в домене (на Windows-машине, присоединённой к домену)
Если записи нет, можем добавить (требуются права уровня доменный администратор)
setspn -A HTTP/kom-srv01.sub.holding.com sub.holding.com\kom-srv01
Apache и PAM с Kerberos
Более подробно описанный пример настройки можно найти в статье Настройка Kerberos аутентификации с SSO на веб-сервере Apache с помощью SSSD
Настраиваем конфигурацию Apache для поддержки аутентификации Kerberos
Установка пакетов поддержки PAM/Kerberos в Apache:
# apt-get install libapache2-mod-auth-kerb libapache2-mod-authnz-pam
Включение модулей Apache:
# apache2ctl -M | grep -E "kerb|pam"
Пример файла конфигурации Apache:
# nano -Y sh /etc/apache2/sites-available/000-default.conf
В данном примере в Apache для доступа к веб-серверу Apache вызывается настроенный нами ранее PAM-модуль apache2
(через файл /etc/pam.d/apache2
)
PAM-модуль в свою очередь вызывает для процедуры аутентификации SSSD и выполняет авторизацию через файл /etc/security/access-groups-to-web
- 000-default.conf
-
... ServerAdmin webmaster@localhost DocumentRoot /var/www/html <Directory "/var/www/html"> AuthType Kerberos AuthName "Kerberos Login" Krb5Keytab /etc/krb5.keytab KrbMethodK5Passwd off Require pam-account apache2 </Directory> …
Не забываем на строне Linux-сервера настроить доступ к keytab-файлу
# chown root:www-data /etc/krb5.keytab # chmod 640 /etc/krb5.keytab
Перезепускаем службу веб-сервера и проверяем результат:
# systemctl restart apache2 # systemctl status apache2
Финиш
По завершении всех процедур настройки можно вернуть имя хоста в исходное состояние, «привычное» для Debain.
После завершения настройки перезагружаем Linux-сервере, чтобы убедиться в успешном автоматическом запуске SSSD и последующей корректной работы аутентификации/авторизации на базе доменных учётных записей.
Дополнительные источники информации:
Проверено на следующих конфигурациях:
Версия ОС |
---|
Debian GNU/Linux 10.1 (Buster) |
Автор первичной редакции:
Алексей Максимов
Время публикации: 13.09.2019 16:43
Уровень сложности
Средний
Время на прочтение
5 мин
Количество просмотров 22K
Всем привет!
Термин 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 у нас в кармане:)
Очевидным недостатком данного решения является то, что после удаления учётной записи пользователя из домена, она останется на всех рабочих станциях, за которыми он работал. Но, поскольку воспользоваться этими учтёнными записями будет невозможно (в локальной базе пользователей они заблокированы), можно пока оставить все как есть.
Спасибо, что дочитали до конца, надеюсь, было интересно, посмотрите ссылки, буду рад комментариям, до новых встреч!
Ссылки:
-
Kerberos за 5 минут: знакомство с сетевой аутентификацией
-
Зачем вводить системы Linux в домен Microsoft?
Содержание статьи:
- 1 Подготовка системы
- 2 Настройка синхронизации времени
- 3 Настройка Kerberos
- 4 Установка\настройка Samba и вход в домен
- 5 Настройка Winbind
- 6 Авторизация в системе через пользователей домена
Ниже опишу как ввести linux систему Debian 10 в домен Windows с помощью Kerberos, Samba, Winbind.
Исходные данные:
- Контроллер домена (DC1) на Windows Server 2019, домен SYSOS.LOCAL
- Linux система (datastore1) на Debian 10 Buster
Подготовка системы
Перед началом выполнения ниже описанных действий обновляем систему до актуального состояния:
apt-get update && apt-get upgrade -y
Указываем FQDN (Fully Qualified Domain Name) имя системы, в файле (/etc/hostname):
datastore1.sysos.local
Так же файл (/etc/hosts) приводим к виду таким образом, чтобы в нём была запись с полным доменным именем компьютера и с коротким именем, ссылающаяся на один из внутренних IP:
127.0.0.1 localhost 127.0.1.1 datastore1.sysos.local datastore1
Настройка синхронизации времени
Если разница будет более 5 минут, то будет не возможно получить билет от Kerberos. Настраиваем синхронизацию времени с контроллером домена, выполняем установку NTP:
apt-get install ntp ntpdate
В файле конфигурации /etc/ntp.conf, добавляем в него информацию о вашем сервере времени (в моем случае указываю контролер домена):
# You do need to talk to an NTP server or two (or three). server dc1.sysos.local
Перезапускаем службу времени:
/etc/init.d/ntp restart
Для единовременной синхронизации можно воспользоваться командой:
ntpdate dc1.sysos.local
Рекомендую ознакомится подробней о синхронизации времени на Linux системах можно почитать в этой статье и выполнить его настройку.
Установка пакетов для поддержки аутентификации Kerberos:
apt-get install krb5-user
В ходе установки может появится запрос указать область по-умолчанию для Kerberos, область необходимо его указать в заглавном виде (прим. SYSOS.LOCAL)
Файл конфигурации Kerberos (/etc/krb5.conf), приводим к виду:
[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = SYSOS.LOCAL dns_lookup_kdc = false dns_lookup_realm = false forwardable = true ticket_lifetime = 24h [realms] SYSOS.LOCAL = { kdc = dc1.sysos.local default_domain = SYSOS.LOCAL admin_server = dc1.sysos.local } [domain_realm] .sysos.local = SYSOS.LOCAL sysos.local = SYSOS.LOCAL
Соответственно подставляем название своего домена вместо sysos.local/SYSOS.LOCAL
Проверка работы Kerberos, выполним авторизацию в Active Directory (kinit jakonda@SYSOS.LOCAL):
kinit jakonda@SYSOS.LOCAL Password for jakonda@SYSOS.LOCAL:
Обращаю внимание на строгость соблюдения синтаксиса команды, имя пользователя нужно указывать именно так — jakonda@SYSOS.LOCAL
Проверить можно получен ли билет или нет, можно командой (klist):
klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: jakonda@SYSOS.LOCAL Valid starting Expires Service principal 10/27/21 11:24:00 10/27/21 21:24:00 krbtgt/SYSOS.LOCAL@SYSOS.LOCAL renew until 10/28/21 11:23:56
Все отлично, можно удалить полученный билет:
kdestroy
Установка\настройка Samba и вход в домен
Устанавливаем необходимые пакеты:
apt-get install samba cifs-utils winbind libnss-winbind libpam-winbind -y
Конфигурационный файл Samba (/etc/samba/smb.conf) приводим к виду:
[global] # ОБЩИЕ ПАРАМЕТРЫ СЕТЕВОЙ ШАРЫ realm = SYSOS.LOCAL workgroup = SYSOS security = ads encrypt passwords = yes netbios name = datastore1 server string = %h server domain master = no local master = no preferred master = no os level = 0 domain logons = no dns proxy = no socket options = TCP_NODELAY unix charset = UTF-8 dos charset = 866 # Конфигурация для домена SYSOS.LOCAL и его пользователей и групп idmap config * : backend = tdb idmap config * : range = 3000-7999 idmap config SYSOS : backend = rid idmap config SYSOS : range = 10000-999999 # ПАРАМЕТРЫ WINBIND winbind enum users = yes winbind enum groups = yes winbind refresh tickets = yes winbind use default domain = yes winbind offline logon = yes winbind cache time = 300 template shell = /bin/bash # ОТКЛЮЧЕНИЕ ПОДДЕРЖКИ СЕТЕВЫХ ПРИНТЕРОВ load printers = no show add printer wizard = no printcap name = /dev/null disable spoolss = yes # ПАРАМЕНТЫ ЛОГИРОВАНИЯ log level = 0 vfs:1
Обращаю внимание что в параметрах realm, workgroup указываем название своего домена. Подробное описание используемых параметров можно по этой ссылке. А так же в параметрах idmap config в место SYSOS, указываем свой домен.
Так как в Linux по-умолчанию установлен лимит на 1024 одновременно открытых файлов, а в Windows он 16384, поэтому увеличим лимит в Debian до значения 16384.
В файле (/etc/security/limits.conf) дописываем в самый конец строки:
* - nofile 16384 root - nofile 16384
Перезагружаем систему для применения изменений!.
Выполним проверку конфигурации на ошибки, командой:
testparm
Load smb config files from /etc/samba/smb.conf Loaded services file OK. Server role: ROLE_DOMAIN_MEMBER Press enter to see a dump of your service definitions
Проверка заданной конфигурации Samba правильная, ошибок и предупреждений нет, а поэтому можно вводить систему в домен, выполняем команду:
net ads join -U jakonda@sysos.local
Вывод об успешном присоединении к домену:
Enter jakonda@sysos.local's password: Using short domain name -- SYSOS Joined 'DATASTORE1' to dns domain 'sysos.local'
Настройка Winbind
Теперь чтобы мы могли видеть и использовать в системе Linux доменных пользователей и группы, то нам необходимо настроить winbind в файле (/etc/nsswitch.conf). К параметрам passwd, group добавляем параметр winbind:
# Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc-reference' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: files winbind group: files winbind shadow: files gshadow: files hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis
Перезапускаем службы Samba и Winbind для применения изменений:
/etc/init.d/smbd restart /etc/init.d/winbind restart
Проверим, что Winbind установил доверительные отношения с Active Directory, выполним команду:
wbinfo -t checking the trust secret for domain SYSOS via RPC calls succeeded
Для проверки видит ли Winbind пользователей и группы из Active Directory, выполним команды:
wbinfo -u wbinfo -g
Если в ходе выполнения данных команд в консоль были выведены пользователи и группы из Active Directory, то это значит что Winbind работает правильно.
Авторизация в системе через пользователей домена
После проделанных выше операций, возможность входа в систему под доменной учетной записью будет возможна, но для того чтобы при входе в систему создавался домашний каталог для пользователя, необходимо в файле /etc/pam.d/common-session после строки session optional pam_systemd.so добавляем следующую строку:
session required pam_mkhomedir.so umask=0022 skel=/etc/skel
В итоге файл должен получится следующий (без вывода комментариев):
session [default=1] pam_permit.so session requisite pam_deny.so session required pam_permit.so session required pam_unix.so session optional pam_winbind.so session optional pam_systemd.so session required pam_mkhomedir.so umask=0022 skel=/etc/skel
Для централизованного назначения определенным доменным пользователями возможность выполнения sudo (Административных действий в Linux-системе), создадим отдельный файл в котором укажем доменную группу безопасности в которую уже будут входить нужные пользователи.
Создаем файл /etc/sudoers.d/admins со следующим содержанием:
%ServerAdmins ALL=(ALL) ALL
ИНФОРМАЦИЯ: Обращая внимание что вместо ServerAdmins, указываем соответственно свою существующую группу безопасности.
Так же хочу заместить если ваша группа безопасности содержит пробелы, например — Domain admins, то указывать ее нужно в формате — %Domain\admins
Если есть желание разрешить доступ к авторизации в систему только определенным доменным пользователям, то можно указать возможность авторизации на основе членства доменной группе безопасности.
Для этого в файле конфигурации /etc/pam.d/common-auth в строку описывающую вызов pam_winbind.so добавляем дополнительный параметр require_membership_of, в котором указываем имя доменной группы безопасности в формате SYSOS\ServerAdmins
auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass require_membership_of=SYSOS\ServerAdmins
В итоге файл должен получится следующий (без вывода комментариев):
auth [success=2 default=ignore] pam_unix.so nullok_secure auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass require_membership_of=SYSOS\ServerAdmins auth requisite pam_deny.so auth required pam_permit.so
ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОБЛАГОДАРИ АВТОРА