===== CentOS Linux 7 - Присоединение к домену Active Directory средствами realmd/SSSD и настройка аутентификации и авторизации через доменные группы безопасности =====
{{:unix-linux:centos:pasted:20180322-112123.png }} Процедура присоединения **Linux**-системы к домену **Active Directory** с помощью **SSSD** (**System Security Services Daemon**) и **RealmD** (**Realm Discovery**) подробно рассматривалась ранее [[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 для системы на базе **CentOS Linux 7.4**.
\\
==== Предварительные условия ====
На нашей Linux-системе, для успешного присоединения и членства в домене Active Directory, должно быть соблюдено как минимум два условия:
* Настроена синхронизация времени с контроллерами домена. Пример того, как это можно сделать описывался в статье [[:unix-linux:centos:configuring-ntp-client-crony-in-time-synchronization-service-chronyd-on-centos-linux-7-4|Настройка службы синхронизации времени chronyd в CentOS Linux 7.4]]
* Настроено разрешение имён в доменной службе DNS, например через файл ''/etc/resolv.conf'', как это [[:unix-linux:centos:join-rhel-centos-6-6-shmz-to-active-directory-domain-with-sssd-and-adcli-for-authentication-and-configure-ad-domain-security-group-authorization-for-sudo-and-ssh-with-putty-sso|было описано ранее]]
\\
==== Присоединение к домену Active Directory ====
Устанавливаем необходимые для работы пакеты:
# yum install realmd sssd adcli krb5-workstation
Проверяем успешность обнаружения домена:
# realm discover ad.holding.com --verbose
Настраиваем параметры системы, которые будут использованы при присоединении к домену для заполнения атрибутов **operatingSystem** и **operatingSystemVersion**.
# nano /etc/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-клиента ====
Настраиваем конфигурационный файл, ранее установленного клиента **Kerberos**.
Это может быть нужно в случае если мы захотим использовать удалённое** Single sign-on** (**SSO**) подключение через сервер **SSHD** (например через клиент **Putty** с **Windows-системы**, как это [[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/|было описано ранее]])
# nano -Y sh /etc/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 ====
Настраиваем конфигурацию службы **sssd**
# nano -Y sh /etc/sssd/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
\\
==== Проверка взаимодействия с AD ====
Проверяем то, что в системе успешно зарегистрированы модули работы **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 ====
Настроим доступ к возможности вызывать команду **sudo**, основанный на членстве в доменной группе безопасности:
Создадим в каталоге ''/etc/sudoers.d/'' новый файл, в котором будут перчислены группы безопасности:
# nano -Y sh /etc/sudoers.d/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 ====
Насстроим службу **sshd** для того, чтобы можно было использовать **SSO**-подключение.
# nano -Y sh /etc/ssh/sshd_config
Включим опции конфигурационного файла:
...
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
...
Перезапустим службу:
# systemctl restart sshd
\\
==== Ограничение доступа к системе через PAM ====
Чтобы ограничить доступ к **CentOS Linux 7** на базе доменных групп безопасности, создадим новый конфигурационный файл, в котором будут перечислены группы (как локальные так и доменные), которым нужно обеспечить вход в систему:
# nano -Y sh /etc/security/access-groups-to-login
sudo
root
KOM-Linux-Admins@ad.holding.com
Обратите внимание на то, что настраивая ограничение локального входа лучше не забыть добавить локальные группы **root** и **sudo**, иначе с дальнейшем вход в систему под локальными административными учётными записями может стать невозможен.
Ограничим доступ к файлу:
# 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''" вызов проверки нашего файла с группами:
#
# 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''" вызов проверки нашего файла с группами:
#
# 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-сервер, поэтому в ходе дальнейших проверок не закрывайте текущую сесиию, чтобы была возможность исправить возможные ошибки
Теперь попробуем __удалённо подключиться__ к **SSH**-серверу нашей Linux-системы, используя доменные учётные записи (те, которым разрешен вход через группу безопасности и те, которым не разрешён вход). В процессе проверки в отдельной сессии запустим наблюдение за логом безопасности, чтобы видеть то, что происходит в ходе авторизации для разрешённых и неразрешённых для входа пользователей.
# tail -f /var/log/secure
Если дополнительно требуется доменная аутентификация/авторизация в других сервисах CentOS Linux, например в веб-сервере Apache то, в качестве примера можно использовать статью [[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]]
----
Проверено на следующих конфигурациях:
^ Версия ОС ^
| CentOS Linux release 7.4.1708 (Core) |
| CentOS Linux release 7.5.1804 (Core) |
----
{{:user:blogroot.png?50&nolink |}} Автор первичной редакции:\\ [[user:blogroot|Алексей Максимов]] \\ Время публикации: 22.03.2018 10:34
{{tag>Linux CentOS "CentOS 7" Security "Active Directory" SSSD RealmD PAM NSS sudo Kerberos SSH sshd}}
~~DISCUSSION~~