Вики IT-KB

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
===== Подключение Debian GNU/Linux 13 (Trixie) к домену Active Directory с помощью SSSD и настройка PAM для доменной аутентификации и авторизации в SSHD =====

{{:unix-linux:debian:stretch:pasted:20190625-091314.png }} Подробное описание процедуры присоединения компьютера с **Debian GNU**/**Linux** к домену **Active Directory** с помощью **SSSD** и **realmd** можно найти [[https://blog.it-kb.ru/2016/10/15/join-debian-gnu-linux-8-6-to-active-directory-domain-with-sssd-and-realmd-for-authentication-and-configure-ad-domain-security-group-authorization-for-sudo-and-ssh-with-putty-sso/|здесь]]. Рекомендуется предварительно ознакомится с этим материалом, а также с [[https://blog.it-kb.ru/2017/11/18/recommendations-for-configuring-sssd-in-debian-gnu-linux-about-dns-kerberos-and-active-directory-dc-search/|замечаниями по настройке SSSD в Debian GNU/Linux]].

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


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

  * [[unix-linux:debian:bookworm:configuring-systemd-resolved-caching-dns-client-on-debian-12|Настройка кеширующего DNS-клиента systemd-resolved]]
  * [[unix-linux:debian:bookworm:configuring-the-systemd-timesyncd-time-synchronization-service-on-debian-linux-12|Настройка службы синхронизации времени systemd-timesyncd]]

Выполним команду присвоения полного доменного имени в качестве имени хоста, так как по умолчанию в **Debian 13** в качестве **hostname** используется имя узла без доменной части. Это позволит избежать некоторых проблем при вводе компьютера в домен с помощью **realmd**: 
 
<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># hostname KOM-SRV01.sub.holding.com</pre></HTML>

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

<file bash hosts>...
127.0.0.1       localhost
10.1.0.3    KOM-SRV01.sub.holding.com    KOM-SRV01
...</file>

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

\\
==== Установка realmd/SSSD и ввод в домен ====

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># apt install realmd sssd-tools sssd libnss-sss libpam-sss adcli packagekit -y</pre></HTML>

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># realm discover sub.holding.com --verbose
</br><font style="color:#B2B2B2;"> * 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
</font>
</pre></HTML>

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># nano /etc/realmd.conf</pre></HTML>

<file bash realmd.conf>[active-directory]
os-name = Debian GNU/Linux
os-version = 13.1 (Trixie)</file>

Выполняем присоединение компьютера к домену Active Directory:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># 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
</br><font style="color:#B2B2B2;">...
 * /usr/sbin/update-rc.d sssd enable
 * /usr/sbin/service sssd restart
 * Successfully enrolled machine in realm</font></pre></HTML>


\\
==== Поддержка Kerberos ====


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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># apt install krb5-user -y</pre></HTML>

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># klist -e -k -t /etc/krb5.keytab</pre></HTML>

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># nano /etc/krb5.conf
</pre></HTML>

Пример настроенного файла:

<file bash 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
</file>


\\
==== Конфигурация SSSD ====

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># nano /etc/sssd/sssd.conf
</pre></HTML>

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

<file bash 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
</file>

Перезапускаем службу с очисткой кеша **sssd**:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># sss_cache -E
# ( systemctl stop sssd ) && \
 ( rm -f /var/lib/sss/db/* ) && ( rm -f /var/lib/sss/mc/* ) && \
 ( systemctl start sssd )
</pre></HTML>

Выполняем проверку возможности извлечения информации из каталога Active Directory.

Получаем информацию о любой доменной группе безопасности:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># getent group kom-servers-admins@sub.holding.com
</pre></HTML>

Получаем информацию о любом доменной пользователе:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># id adm-petya
# getent passwd adm-petya
</pre></HTML>

\\
==== PAM и домашний каталог =====

Предварительно рекомендуется ознакомится со статьёй [[https://blog.it-kb.ru/2017/03/12/restricting-access-rights-to-the-linux-system-and-its-services-sshd-and-apache-through-active-directory-domain-security-groups-using-sssd-and-pam-pam_listfile|Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM]], где более подробно описан смысл всех производимых далее настроек системы.

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

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># nano /etc/pam.d/common-session
</pre></HTML>

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

<file bash common-session>...
session required        pam_mkhomedir.so umask=0022 skel=/etc/skel</file>

\\
==== PAM и доступ на консоль =====


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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># nano /etc/security/access-groups-to-login</pre></HTML>

<file text access-groups-to-login>sudo
root
kom-servers-admins@sub.holding.com</file>

Ограничим доступ к файлу:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># chown root:root /etc/security/access-groups-to-login
# chmod 600 /etc/security/access-groups-to-login</pre></HTML>


Отредактируем модуль **PAM**, определяющий права доступа к консоли компьютера:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># nano /etc/pam.d/login</pre></HTML>

Вставляем перед блоком со строкой ''@include common-account'' ссылку на вызов авторизации через созданный нами файл (''access-groups-to-login'')

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

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># journalctl -f | grep login</pre></HTML>



\\
==== PAM и доступ к SSHD =====


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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># nano /etc/pam.d/sshd</pre></HTML>

Вставляем перед блоком со строкой ''@include common-account'' ссылку на вызов авторизации через созданный нами файл (''access-groups-to-login'')

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

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># journalctl -f -u ssh.service</pre></HTML>


\\
==== PAM и комбинирование доступа для групп и пользователей =====

В двух выше обозначенных примерах мы используем файл ''/etc/security/access-groups-to-login'' для настройки доступа к консоли сервера и службе SSHD. Предполагается, что в этот файл должны вписываться только названия групп доступа (локальных или доменных). Но в некоторых ситуациях может потребоваться настройка дополнительного доступа для отдельно взятой учётной записи пользователя (локальной или доменной). В этом случае мы можем комбинировать правила PAM. На примере **PAM**-модуля, отвечающего за настройку авторизации при подключении через службу сервера **sshd** (''/etc/pam.d/sshd''), ранее рассмотренную строку проверки доступа по файлу с группами дополним строкой предварительной проверки доступа по дополнительному файлу с логинами:

<file bash sshd>...
# Restricted access to service from local and domain groups
account sufficient pam_listfile.so onerr=fail item=user sense=allow file=/etc/security/access-users-to-login
account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/security/access-groups-to-login
...</file>

Файл ''/etc/security/access-users-to-login'' в этом случае должен иметь формат, аналогичный ранее упомянутому файлу ''access-groups-to-login'':

<file text access-users-to-login>petya
vasya@sub.holding.com</file>

И не забываем про ограничение доступа к файлу:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># chown root:root /etc/security/access-users-to-login
# chmod 600 /etc/security/access-users-to-login</pre></HTML>



\\
==== SSHD и PuTTy =====

Подробно про пример настройки сквозной проверки подлинности при использовании **PuTTY** читаем в статье [[https://blog.it-kb.ru/2014/07/06/single-sign-on-sso-server-connection-ubuntu-server-14-04-lts-via-ssh-using-putty-from-windows-based-active-directory/|SSO-подключение к серверу Ubuntu Server 14.04 LTS по протоколу SSH с помощью PuTTY с компьютера на базе Windows в домене Active Directory]] 

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># nano /etc/ssh/sshd_config</pre></HTML>

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

<file bash sshd_config>...
# GSSAPI options
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
...
</file>

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># systemctl restart ssh.service</pre></HTML>


\\
==== SUDO =====

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

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># nano /etc/sudoers.d/kom-srv-linux-admins</pre></HTML>

Пример содержимого файла с одной доменной группой доступа, которой разрешено выполнять **sudo** без ограничений:

<file bash kom-srv-linux-admins>%kom-servers-admins@sub.holding.com ALL=(ALL) ALL
</file>

Ограничим доступ к файлу

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># chmod 0440 /etc/sudoers.d/kom-srv-linux-admins</pre></HTML>

В некоторых ситуациях при вызове **sudo** в контексте доменного пользователя может возникать длительная задержка при первом запросе на ввод пароля. В этом случае можно попробовать воспользоваться включением опции [[https://blog.it-kb.ru/2024/03/14/sudo-is-slow-when-using-sssd|ignore_group_members]] в секции описания домена в конфигурационном файле ''sssd.conf''  

\\
==== Финиш =====


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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;"># hostname KOM-SRV01</pre></HTML>

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


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

  * [[https://blog.it-kb.ru/2016/10/15/join-debian-gnu-linux-8-6-to-active-directory-domain-with-sssd-and-realmd-for-authentication-and-configure-ad-domain-security-group-authorization-for-sudo-and-ssh-with-putty-sso/|Подключение Debian GNU/Linux 8.6 к домену Active Directory с помощью SSSD и realmd]]
  * [[https://blog.it-kb.ru/2017/11/18/recommendations-for-configuring-sssd-in-debian-gnu-linux-about-dns-kerberos-and-active-directory-dc-search/|Рекомендации по настройке SSSD в Debian GNU/Linux]]
  * [[https://blog.it-kb.ru/2017/03/12/restricting-access-rights-to-the-linux-system-and-its-services-sshd-and-apache-through-active-directory-domain-security-groups-using-sssd-and-pam-pam_listfile/|Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM]]
  * [[https://blog.it-kb.ru/2016/10/26/configuring-basic-and-kerberos-authentication-with-sso-single-sign-on-for-the-apache-web-server-using-sssd-and-pam-service-for-authorization/|Настройка Kerberos аутентификации с SSO на веб-сервере Apache с помощью SSSD]]
  * [[https://blog.it-kb.ru/2017/10/26/adding-spn-entries-in-keytab-on-linux-server-using-ktutil-associated-with-computer-account-in-active-directory-domain/|Добавление SPN записей в keytab-файл (на стороне сервера Linux с помощью утилиты ktutil), связанный с учётной записью Computer в домене Active Directory]]

----
Проверено на следующих конфигурациях:
^ Версия ОС  ^ Версия пакета sssd ^
|Debian GNU/Linux 13.1 (Trixie) | 2.10.1-2+b1 |



----
{{:user:blogroot.png?50&nolink |}} Автор первичной редакции:\\ [[user:blogroot|Алексей Максимов]] \\ Время публикации: 01.10.2025 13:09
{{tag>Linux Debian "Debian 13" "Debian Trixie" SSH sshd sudo PAM Authorization Authentication SSSD realmd "Active Directory" Kerberos}}
~~DISCUSSION~~