Вики IT-KB

Процедура присоединения Linux-системы к домену Active Directory с помощью SSSD (System Security Services Daemon) и RealmD (Realm Discovery) подробно рассматривалась ранее на примере Debian GNU/Linux 8.6. Данная статья является «выжимкой» основных этапов присоединения к домену Active Directory для системы на базе CentOS Linux 7.4.

На нашей Linux-системе, для успешного присоединения и членства в домене Active Directory, должно быть соблюдено как минимум два условия:

• Настроена синхронизация времени с контроллерами домена. Пример того, как это можно сделать описывался в статье Настройка службы синхронизации времени chronyd в CentOS Linux 7.4
• Настроено разрешение имён в доменной службе DNS, например через файл /etc/resolv.conf, как это было описано ранее

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

# yum install realmd sssd adcli krb5-workstation

Проверяем успешность обнаружения домена:

# realm discover ad.holding.com --verbose

Настраиваем параметры системы, которые будут использованы при присоединении к домену для заполнения атрибутов operatingSystem и operatingSystemVersion.

# nano /etc/realmd.conf

realmd.conf

[active-directory]
os-name = CentOS Linux
os-version = 7.4.1708 (Core)

Выполняем присоединение к домену (в ходе присоединения будет запрошен пароль доменного пользователя с правами на ввод в домен, указанного в опции –user):

# realm join --verbose --user=volodya \
 --user-principal="host/kom-vm01.ad.holding.com@AD.HOLDING.COM" \
 --computer-ou="OU=Linux Servers,OU-KOM,DC=ad,DC=holding,DC=com" \
 kom-dc01.ad.holding.com

Настраиваем конфигурационный файл, ранее установленного клиента Kerberos. Это может быть нужно в случае если мы захотим использовать удалённое Single sign-on (SSO) подключение через сервер SSHD (например через клиент Putty с Windows-системы, как это было описано ранее)

# nano -Y sh /etc/krb5.conf

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

krb5.conf

# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/
 
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
 
[libdefaults]
     dns_lookup_kdc = no
     dns_lookup_realm = false
     ticket_lifetime = 24h
     renew_lifetime = 7d
     forwardable = true
     rdns = false
     default_ccache_name = KEYRING:persistent:%{uid}
     default_realm = AD.HOLDING.COM
 
[realms]
    AD.HOLDING.COM = {
        kdc = kom-dc01.ad.holding.com
        kdc = kom-dc02.ad.holding.com
        admin_server = kom-dc01.ad.holding.com
        default_domain = ad.holding.com
    }
 
[domain_realm]
    ad.holding.com = AD.HOLDING.COM
    .ad.holding.com = AD.HOLDING.COM

Настраиваем конфигурацию службы sssd

# nano -Y sh /etc/sssd/sssd.conf

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

sssd.conf

[sssd]
domains = ad.holding.com
config_file_version = 2
services = nss, pam
default_domain_suffix = ad.holding.com
 
[domain/ad.holding.com]
ad_server = kom-dc01.ad.holding.com, kom-dc02.ad.holding.com
ad_backup_server = msk-dc01.ad.holding.com, spb-dc01.ad.holding.com
ad_domain = ad.holding.com
krb5_realm = AD.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-2955347524-3617349964-1548486448
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

Очищаем кэш sss и перезапускаем службу sssd:

# systemctl stop sssd
# ( rm -f /var/lib/sss/db/* ) && ( rm -f /var/lib/sss/mc/* )
# systemctl start sssd

Проверяем то, что в системе успешно зарегистрированы модули работы SSSD с PAM/NSS:

# cat /etc/nsswitch.conf | grep sss

passwd:     files sss
shadow:     files sss
group:      files sss
services:   files sss
netgroup:   files sss

# cat /etc/pam.d/system-auth | grep sss

auth        sufficient    pam_sss.so forward_pass
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
password    sufficient    pam_sss.so use_authtok
session     optional      pam_sss.so

Проверяем успешность получения информации о пользователе из AD по логину:

# getent passwd petya

petya@ad.holding.com:*:398447:200613:Петя Резинкин:/home/petya@ad.holding.com:/bin/bash

Проверяем успешность получения информации о пользователе из AD по UPN:

# getent passwd petya@ad.holding.com

petya@ad.holding.com:*:398447:200613:Петя Резинкин:/home/petya@ad.holding.com:/bin/bash

Проверяем успешность получения информации из AD о членах доменной группы безопасности:

# getent group KOM-Linux-Admins@ad.holding.com

kom-linux-admins@ad.holding.com:*:396844:petya@ad.holding.com,vova@ad.holding.com

Пробуем войти в сессию доменного пользователя:

# su - petya@ad.holding.com

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

$ id


uid=398447(petya@ad.holding.com) gid=200613(domain users@ad.holding.com) 
groups=200613(domain users@ad.holding.com),445177(internet-users@ad.holding.com),
396844(kom-linux-admins@ad.holding.com)

Настроим доступ к возможности вызывать команду sudo, основанный на членстве в доменной группе безопасности: Создадим в каталоге /etc/sudoers.d/ новый файл, в котором будут перчислены группы безопасности:

# nano -Y sh /etc/sudoers.d/kom-linux-admins

Наполним файл (каждая отдельная группа с правилами доступа в отдельной строчке. в нашем примере используется одна группа с полным доступом):

kom-linux-admins

%KOM-Linux-Admins@ad.holding.com ALL=(ALL) ALL

Войдём в сесcию доменного пользователя, входящего в группу, которой мы разрешили выполять sudo:

# su - petya@ad.holding.com

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

$ sudo whoami

[sudo] password for petya@ad.holding.com: ******
root

Как видим, работает. Осталось ограничить доступ на редактирование файла, в котором описаны правила предоставления доступа к sudo:

# chmod 0440 /etc/sudoers.d/kom-linux-admins

Насстроим службу sshd для того, чтобы можно было использовать SSO-подключение.

# nano -Y sh /etc/ssh/sshd_config

Включим опции конфигурационного файла:

sshd_config (фрагмент)

...
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
...

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

# systemctl restart sshd

Чтобы ограничить доступ к CentOS Linux 7 на базе доменных групп безопасности, создадим новый конфигурационный файл, в котором будут перечислены группы (как локальные так и доменные), которым нужно обеспечить вход в систему:

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

access-groups-to-login

sudo
root
KOM-Linux-Admins@ad.holding.com

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

# chown root:root /etc/security/access-groups-to-login
# chmod 600 /etc/security/access-groups-to-login

Настроим в системном конфиге /etc/pam.d/login правила PAM таким образом, чтобы в ходе авторизации при локальном входе на консоль нашей Linux-системы использдвался созданный нами выше файл со списком разрешённых групп:

# nano -Y sh /etc/pam.d/login

Вставляем перед строкой «account include system-auth» вызов проверки нашего файла с группами:

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
#

Теперь попробуем подключиться на консоль нашей Linux-системы, используя доменные учётные записи (те, которым разрешен вход через группу безопасности и те, которым не разрешён вход). В процессе проверки в отдельной сессии запустим наблюдение за логом безопасности, чтобы видеть то, что происходит в ходе авторизации для разрешённых и неразрешённых для входа пользователей.

# tail -f /var/log/secure

Теперь аналогичным образом настроим в конфиге, относящемся к обработке авторизации в SSHD (/etc/pam.d/sshd) правила PAM таким образом, чтобы в ходе авторизации при удалённом входе через SSH-сервер использовался созданный нами выше файл со списком разрешённых групп (в нашем примере используется тот же файл, что и для локального входа, хотя это могут быть разные файлы и группы доступа):

# nano -Y sh /etc/pam.d/sshd

Вставляем перед строкой «account include password-auth» вызов проверки нашего файла с группами:

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-серверу нашей Linux-системы, используя доменные учётные записи (те, которым разрешен вход через группу безопасности и те, которым не разрешён вход). В процессе проверки в отдельной сессии запустим наблюдение за логом безопасности, чтобы видеть то, что происходит в ходе авторизации для разрешённых и неразрешённых для входа пользователей.

# tail -f /var/log/secure

Если дополнительно требуется доменная аутентификация/авторизация в других сервисах CentOS Linux, например в веб-сервере Apache то, в качестве примера можно использовать статью Настройка Kerberos аутентификации с SSO на веб-сервере Apache с помощью SSSD

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

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