Вики IT-KB

Подробное описание процедуры присоединения компьютера с Debian GNU/Linux к домену Active Directory с помощью SSSD и realmd можно найти здесь. Рекомендуется предварительно ознакомится с этим материалом, а также с замечаниями по настройке SSSD в Debian GNU/Linux.

Здесь приведён сокращённый план действий по присоединению Debian GNU/Linux 12 (Bookworm) к домену Active Directory с помощью SSSD и realmd.

В первую очередь необходимо обеспечить правильную работу DNS-клиента и настроить синхронизацию времени с источниками, используемыми в Active Directory. Эти моменты важны для правильной работы протокола Kerberos. Соответствующие настройки описаны в статьях:

• Настройка кеширующего DNS-клиента systemd-resolved
• Настройка службы синхронизации времени systemd-timesyncd

Выполним команду присвоения полного доменного имени в качестве имени хоста, так как по умолчанию в Debian 12 в качестве hostname используется имя узла без доменной части. Это позволит избежать некоторых проблем при вводе компьютера в домен с помощью realmd:

# hostname KOM-SRV01.sub.holding.com

Дополнительно необходимо проверить файл /etc/hosts на предмет того, что там в качестве IP адреса хоста присутсвует адрес основного сетевого интерфейса:

hosts

...
127.0.0.1       localhost
10.1.0.3    KOM-SRV01.sub.holding.com    KOM-SRV01
...

Если требуется, предварительно создаём в домене учётную запись компьютера

Устанавливаем пакеты необходимые для ввода в домен:

# apt-get install realmd sssd-tools sssd libnss-sss libpam-sss adcli packagekit -y

Выполняем обнаружение информации о домене, которое должно отработать без ошибок:

# realm discover sub.holding.com --verbose

 * Resolving: _ldap._tcp.sub.holding.com
 * Performing LDAP DSE lookup on: 10.5.1.4
 * Performing LDAP DSE lookup on: 10.6.0.4
 * Successfully discovered: sub.holding.com
sub.holding.com
  type: kerberos
  realm-name: SUB.HOLDING.COM
  domain-name: sub.holding.com
  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

Настраиваем информацию о компьютере, которая будет передана в каталог Active Directory при присоединении к домену.

# nano /etc/realmd.conf

realmd.conf

[active-directory]
os-name = Debian GNU/Linux
os-version = 12.0 (Bookworm)

Выполняем присоединение компьютера к домену 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

...
 * /usr/sbin/update-rc.d sssd enable
 * /usr/sbin/service sssd restart
 * Successfully enrolled machine in realm

Устанавливаем клиентское ПО поддержки Kerberos:

# apt-get install krb5-user -y

Проверяем наличие и содержимое keytab-файла. В нём, как минимум, должны быть записи типа host/*

# klist -e -k -t /etc/krb5.keytab

Настраиваем конфигурацию клиента Kerberos:

# nano /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
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
 
[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:

# nano /etc/sssd/sssd.conf

Пример настроенной конфигурации:

sssd.conf

[sssd]
domains = sub.holding.com
config_file_version = 2
#services = nss, pam
implicit_pac_responder = false
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:

# sss_cache -E
# ( 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

Предварительно рекомендуется ознакомится со статьёй Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM, где более подробно описан смысл всех производимых далее настроек системы.

Настраиваем базовую конфигурацию PAM

Правим файл common-session:

# nano /etc/pam.d/common-session

В конец файла добавим строку, позволяющую создать домашний каталог в случае его отсутствия:

common-session

...
session required        pam_mkhomedir.so umask=0022 skel=/etc/skel

Создадим свой файл для перечисления учётных записей (доменных и локальных), которым будет разрешёно подключение к консоли компьютера:

# nano /etc/security/access-groups-to-login

access-groups-to-login

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 /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
...

Выполняем проверку локального входа в систему, используя разрешённую и неразрешённую доменную учётную запись. При этом в реальном режиме времени отслеживаем происходящее в механизмах аутентификации/авторизации через вывод journalctl

# journalctl -f | grep login

Отредактируем PAM-модуль, отвечающий за настроку авторизации при подключении через службу сервера SSH

# nano /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, используя разрешённую и неразрешённую доменную учётную запись. При этом в реальном режиме времени отслеживаем происходящее в механизмах аутентификации/авторизации через вывод лога службы sshd

# journalctl -f -u ssh.service

Подробно про пример настройки сквозной проверки подлинности при использовании PuTTY читаем в статье SSO-подключение к серверу Ubuntu Server 14.04 LTS по протоколу SSH с помощью PuTTY с компьютера на базе Windows в домене Active Directory

Включаем сквозную проверку подлинности для прозрачного подключения с PuTTY

# nano /etc/ssh/sshd_config

Включим опции:

sshd_config

...
# GSSAPI options
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
...

Перезапустим службу сервера

# systemctl restart ssh.service

Разрешаем sudo для доменных учётных записей.

Создадим отдельный файл для выдачи прав выполнять sudo доменным учётным записям:

# nano /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

В некоторых ситуациях при вызове sudo в контексте доменного пользователя может возникать длительная задержка при первом запросе на ввод пароля. В этом случае можно попробовать воспользоваться включением опции ignore_group_members в секции описания домена в конфигурационном файле sssd.conf

Теперь можно вернуть имя хоста в исходное состояние, «привычное» для Debain.

# hostname KOM-SRV01

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

Дополнительные источники информации:

• Подключение Debian GNU/Linux 8.6 к домену Active Directory с помощью SSSD и realmd
• Рекомендации по настройке SSSD в Debian GNU/Linux
• Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM
• Настройка Kerberos аутентификации с SSO на веб-сервере Apache с помощью SSSD
• Добавление SPN записей в keytab-файл (на стороне сервера Linux с помощью утилиты ktutil), связанный с учётной записью Computer в домене Active Directory

Проверено на следующих конфигурациях:

Автор первичной редакции:
Алексей Максимов
Время публикации: 11.07.2023 12:42