Вики IT-KB

Пошаговые руководства, шпаргалки, полезные ссылки...

Инструменты пользователя

Инструменты сайта


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

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

# nano /etc/realmd.conf
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 и домашний каталог

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

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

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

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

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

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


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

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

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

# nano -Y sh /etc/ssh/sshd_config

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

sshd_config
...
# GSSAPI options 
GSSAPIAuthentication yes 
GSSAPICleanupCredentials yes
...

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

# systemctl restart ssh


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)

# ktutil
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 -L kom-srv01

Если записи нет, можем добавить (требуются права уровня доменный администратор)

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.

# hostname KOM-SRV01

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


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


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

Версия ОС
Debian GNU/Linux Stretch 9.4

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

Обсуждение

алексейалексей, 20.07.2022 14:37
Как сделать, чтобы после отключения пользователя в домене.
На linux сервер перестало пускать?

Сейчас пускает...
АлексейАлексей, 20.07.2022 17:01
Очистка кеша sssd на сервере меняет ситуацию?

# systemctl stop sssd.service
# rm /var/lib/sss/db/* /var/lib/sss/mc/* /var/lib/sss/pipes/* \
/var/lib/sss/pipes/private/* /var/lib/sss/pubconf/* \
/var/lib/sss/pubconf/krb5.include.d/*
# systemctl start sssd.service
алексейалексей, 20.07.2022 17:08
да, да но это не совсем удобно
ДенисДенис, 25.08.2022 10:35
Приветствую.
Несколько раз проделал настройки по инструкции. Не могу зайти на сервер Debian под доменным пользователем.
* MS Server 2019
* Debian 10

в логах auth.log
login[3314]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=myuser
login[3314]: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=myuser
login[3314]: pam_sss(login:auth): received for user myuser: 4 (Системная ошибка)
login[3314]: FAILED LOGIN (1) on '/dev/tty1' FOR 'myuser', Authentication failure

Хотя при этом
id myuser выдает
uid=201140(myuser) gid=200512(администраторы домена) группы=200512(администраторы домена),201139(linux_admins)

и getent passwd myuser
myuser:*:201140:200512:myuser:/home/mydomain.loc@myuser:/bin/bash

не подскажите куда смотреть, что искать?
Алексей МаксимовАлексей Максимов, 25.08.2022 10:44
Включать режим дебага в sssd и изучать логи
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sssd-troubleshooting
Алексей МаксимовАлексей Максимов, 25.08.2022 10:46
И ещё один момент. Описанная здесь конфигурация проверялась в связке с контроллерами домена Windows Server 2012 R2/2016. Возможно с WS2019 есть свои нюансы.
Ваш комментарий:
 
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.1568381947.txt.gz · Последнее изменение: 13.09.2019 16:39 — Алексей Максимов

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki