===== CentOS Linux 6.6 (SHMZ) - Подключение к домену Active Directory с помощью adcli и настройка аутентификации и авторизации через SSSD =====
{{: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:pasted:20170105-122352.png }}Ранее мы рассматривали [[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 Jessie к домену AD с помощью утилиты realmd]], как наиболее простой и удобный вариант. Однако В **RHEL6**/**CentOS6** возможность использования утилиты **realmd** отсутствует. Подтверждение этому можно найти в документе [[https://access.redhat.com/solutions/2273711|realmd is not available for RHEL 6.x versions]]. В качестве альтернативного варианта предлагается использовать утилиту **adcli**.
В этой статье мы рассмотрим то, как выполнить такую настройку на примере ОС **SHMZ release 6.6** (**Final**) на ядре **2.6.32-642.6.2.el6.x86_64** (по сути это **CentOS 6.6**).
----
\\
==== Подготовительные мероприятия ====
Прежде чем приступить к установке и настройке **SSSD**, убедимся в том, что на нашей Linux-системе корректно настроен **DNS клиент**, то есть, как минимум, в файле **/etc/resolv.conf** есть ссылки на DNS-серверы, которые отвечают за разрешение имён в домене Active Directory:
# nano /etc/resolv.conf
...
nameserver 10.1.0.9
nameserver 10.6.1.8
...
Также, в силу того, что SSSD будет использовать **Kerberos**, нам нужно убедиться в том, что у нас корректно настроен **NTP-клиент** и время синхронизировано с контроллерами домена AD. Настраиваем конфигурационный файл NTP-клиента:
# nano /etc/ntp.conf
В файле меняем строчки указывающие на NTP-сервер. В качестве источника времени указываем контроллеры домена AD:
...
server 10.1.0.9 iburst
server 10.6.1.8 iburst
...
Перезапускаем службу **ntpd** и проверяем статус синхронизации времени:
# service ntpd restart
# ntpq -4 -p
# date -R
----
\\
==== Установка adcli и присоединение к домену Active Directory ====
Устанавливаем репозиторий **EPEL**, если он не был ещё установлен ранее и затем устанавливаем пакет **adcli**:
# yum install epel-release
# yum install adcli
Если по какой-то причине пакет **adcli** не обнаруживается:
No package adcli available.
Error: Nothing to do
То можно попробовать установить этот пакет напрямую по ссылке:
# yum install http://mirror.centos.org/centos/6/os/x86_64/Packages/adcli-0.8.1-1.el6.x86_64.rpm
После того как утилита **adcli** появилась в нашей Linux-системе, выполняем проверочный поиск интересующего нас домена Active Directory:
# adcli info ad.holding.com
...и убеждаемся в том, что информация о домене успешно получается:
[domain]
domain-name = ad.holding.com
domain-short = KOM
domain-forest = holding.com
domain-controller = KOM-DC01.ad.holding.com
domain-controller-site = kom-ad01
domain-controller-flags = gc ldap ds kdc timeserv closest writable full-secret ads-web
domain-controller-usable = yes
domain-controllers = KOM-DC01.ad.holding.com PRM-DC01.ad.holding.com ...
[computer]
computer-site = kom-ad01
Выполняем операцию присоединения к домену, указывая все необходимые реквизиты:
# adcli join --domain=ad.holding.com --domain-controller=kom-dc01.ad.holding.com --computer-name=KOM-PBX02 --host-fqdn=kom-pbx02.ad.holding.com --login-user=petya --domain-ou="OU=Linux Servers,OU=KOMI,DC=ad,DC=holding,DC=com" --os-name="CentOS Linux" --os-version="SHMZ release 6.6 (Final)" --show-details --verbose
Вывод будет примерно таким:
* Using fully qualified name: kom-pbx02.ad.holding.com
* Using domain name: ad.holding.com
* Using computer account name: KOM-PBX02
* Calculated domain realm from name: AD.HOLDING.COM
* Sending netlogon pings to domain controller: cldap://10.1.0.9
* Received NetLogon info from: KOM-DC01.ad.holding.com
* Wrote out krb5.conf snippet to /tmp/adcli-krb5-kjj7cr/krb5.d/adcli-krb5-conf-wRcPkw
Password for petya@AD.HOLDING.COM:
* Authenticated as user: petya@AD.HOLDING.COM
* Looked up short domain name: KOM
* Using fully qualified name: kom-pbx02.ad.holding.com
* Using domain name: ad.holding.com
* Using computer account name: KOM-PBX02
* Using domain realm: ad.holding.com
* Enrolling computer name: KOM-PBX02
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Found computer account for KOM-PBX02$ at: CN=KOM-PBX02,OU=Linux Servers,OU=KOMI,DC=ad,DC=holding,DC=com
* Set computer password
* Retrieved kvno '5' for computer account in directory: CN=KOM-PBX02,OU=Linux Servers,OU=KOMI,DC=ad,DC=holding,DC=com
* Modifying computer account: dNSHostName
* Modifying computer account: userAccountControl
* Modifying computer account: operatingSystem, operatingSystemVersion, operatingSystemServicePack
* Modifying computer account: userPrincipalName
* Discovered which keytab salt to use
* Added the entries to the keytab: KOM-PBX02$@AD.HOLDING.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/kom-pbx02@AD.HOLDING.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/kom-pbx02.ad.holding.com@AD.HOLDING.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/kom-pbx02@AD.HOLDING.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/kom-pbx02.ad.holding.com@AD.HOLDING.COM: FILE:/etc/krb5.keytab
[domain]
domain-name = ad.holding.com
domain-realm = AD.HOLDING.COM
domain-controller = kom-dc01.ad.holding.com
domain-short = KOM
naming-context = DC=ad,DC=holding,DC=com
domain-ou = OU=Linux Servers,OU=KOMI,DC=ad,DC=holding,DC=com
[computer]
host-fqdn = KOM-PBX02.ad.holding.com
computer-name = KOM-PBX02
computer-dn = CN=KOM-PBX02,OU=Linux Servers,OU=KOMI,DC=ad,DC=holding,DC=com
os-name = CentOS Linux
os-version = SHMZ release 6.6 (Final)
[keytab]
kvno = 5
keytab = FILE:/etc/krb5.keytab
----
\\
==== Установка и настройка Kerberos-клиента ====
В процессе присоединения нашего Linux-сервера к домену в системе был создан/обновлён **keytab**-файл
Чтобы ппроверить его содержимое установим **Kerberos-клиента** (он также нам потребуется для настройки Kerberos-аутентификации для сервера **SSH**):
# yum install krb5-workstation
Убедимся в том, что в keytab-файле присутсвуют записи типа ''host/@'':
# klist -kt | grep host/kom
5 12/26/16 19:32:35 host/kom-pbx02.ad.holding.com@AD.HOLDING.COM
5 12/26/16 19:32:35 host/kom-pbx02.ad.holding.com@AD.HOLDING.COM
5 12/26/16 19:32:35 host/kom-pbx02.ad.holding.com@AD.HOLDING.COM
5 12/26/16 19:32:35 host/kom-pbx02.ad.holding.com@AD.HOLDING.COM
5 12/26/16 19:32:35 host/kom-pbx02.ad.holding.com@AD.HOLDING.COM
Настроим основной конфигурационный файл Kerberos-клиента:
# nano /etc/krb5.conf
Пример настроенного файла:
[libdefaults]
default_realm = AD.HOLDING.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
AD.HOLDING.COM = {
kdc = kom-dc01.ad.holding.com
admin_server = kom-dc01.ad.holding.com
}
[AD.HOLDING.COM]
.ad.holding.com = AD.HOLDING.COM
ad.holding.com = AD.HOLDING.COM
----
\\
==== Установка и настройка SSSD ====
Установим пакет **sssd**:
# yum install authconfig sssd
Используем утилиту authconfig чтобы включить поддержку **SSSD** в **NSS** и **PAM**:
# authconfig --enablesssd --enablesssdauth --update
Проверим, что вызов **sss** появился в конфигурационных файлах **NSS** и **PAM**:
# 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 use_first_pass
account [default=bad success=ok user_unknown=ignore] pam_sss.so
password sufficient pam_sss.so use_authtok
session optional pam_sss.so
...
Добавим в конец файла **system-auth** директиву для создания домашнего каталога пользователя в случае его отсутсвия:
...
session required pam_mkhomedir.so umask=0022 skel=/etc/skel
Создадим главный конфигурационный файл 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/|ранее описанные]] особенности:
# touch /etc/sssd/sssd.conf
# chmod 0600 /etc/sssd/sssd.conf
# nano /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 = prm-dc01.ad.holding.com, msk-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
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
access_provider = simple
#debug_level=9
subdomains_provider = none
ldap_idmap_default_domain_sid = S-1-5-21-2599488624-3617735854-14887588928
simple_allow_groups = KOM-SRV-Linux-Admins@ad.holding.com
Настроим автозапуск службы **sssd** в процессе загрузки ОС и выполним её запуск, который должен выполниться без ошибок:
# chkconfig sssd on
# service sssd start
Проверим возможность получения информации о доменных пользователях:
# getent passwd petya
petya@ad.holding.com:*:397447:200513:Петя Резинкин:/home/ad.holding.com/petya:/bin/bash
Проверим возможность получения информации об интересующих нас доменных группах безопасности и их членах:
# getent group "KOM-SRV-Linux-Admins@ad.holding.com"
kom-srv-linux-admins@ad.holding.com:*:396454:vasya@ad.holding.com,petya@ad.holding.com
Попробуем переключиться на доменного пользователя:
# su - petya@ad.holding.com
Creating directory '/home/ad.holding.com/petya'.
Как видим, вход в систему успешно выполнен и домашний каталог пользователя успешно создан.
Командой **id** запросим идентификационную информацию о текущем пользователе (должен быть возвращён список доменных групп, членам которых пользователь является):
[petya@ad.holding.com@kom-pbx02 ~]$ id
uid=397447(petya@ad.holding.com) gid=200513(domain users@ad.holding.com)
groups=200513(domain users@ad.holding.com),396454(kom-srv-linux-admins@ad.holding.com)...
----
\\
==== Доступ к sudo ====
Для добавления возможности повышения привилегий с помощью команды **sudo** для доменных пользователей для простоты воспользуемся ранее упомянутой доменной группой безопасности KOM-SRV-Linux-Admins, хотя можно использовать и любую другую доменную группу, например с более узким составом членов.
Создадим файл, в котором будет описано разрешающее правило для sudo:
# touch /etc/sudoers.d/kom-srv-linux-admins
Обратите внимание на комментарии написанные в файле **/etc/sudoers.d/README**. Имя создаваемого файла не должно заканчиваться знаком «~» и иметь в своём составе точек. В файл добавим всего одну строку вида:
%KOM-SRV-Linux-Admins@ad.holding.com ALL=(ALL) ALL
Установим ограничивающие разрешения на созданный и настроенный файл:
# chmod 0440 /etc/sudoers.d/kom-srv-linux-admins
Проверяем результат. Войдя в систему от имени доменного пользователя, входящего в ранее разрешённую для sudo доменную группу KOM-SRV-Linux-Admins, пробуем выполнить любую команду с повышением привилегий через sudo:
petya@ad.holding.com@kom-pbx02:~$ sudo whoami
[sudo] password for petya@ad.holding.com: {вводим пароль пользователя petya}
root
Как видим, команда выполняется успешно с повышением привилегий.
В некоторых ситуациях при вызове **sudo** в контексте доменного пользователя может возникать длительная задержка при первом запросе на ввод пароля. В этом случае можно попробовать воспользоваться включением опции [[https://blog.it-kb.ru/2024/03/14/sudo-is-slow-when-using-sssd|ignore_group_members]] в секции описания домена в конфигурационном файле ''sssd.conf''
----
\\
==== Настройка SSHD ====
Если говорить про **SSH**, то никакой специальной настройки **sshd** здесь не требуется, так как по умолчанию ssh-сервер уже настроен на использование **PAM**, а тот в свою очередь был ранее настроен нами на использование доменной аутентификации с помощью **sss**.
В файле **/etc/ssh/sshd_config** достаточно раскомментировать и включить параметры **GSSAPI**:
...
# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
...
При этом **AllowGroups** можно не заполнять, так как будет использоваться членство групп описанное ранее в **sssd.conf** с помощью параметра **simple_allow_groups**. После правки перезапускаем службу ssh-сервера и проверяем работу SSO
# service sshd restart
----
\\
**Дополнительные источники информации**:
* [[http://jhrozek.livejournal.com/3581.html|Jakub Hrozek - Enrolling an Active Directory RHEL-6 client machine using adcli]]
* [[https://thornelabs.net/2014/01/30/authenticate-rhel-5-and-6-sssd-using-kerberos-and-ldap-against-active-directory-on-windows-server-2008-r2.html|ThorneLabs - Authenticate RHEL 5 and 6 SSSD Using Kerberos and LDAP Against Active Directory on Windows Server 2008 R2]]
----
{{:user:blogroot.png?50&nolink |}} Автор первичной редакции:\\ [[user:blogroot|Алексей Максимов]] \\ Время публикации: 05.01.2017 12:28
{{tag>Linux CentOS "CentOS 6" RHEL "RHEL 6" SHMZ "SHMZ 6" ntpd NTP resolv "Active Directory" EPEL adcli Domain Join krb5 Kerberos NSS PAM SSSD sss sudo SSH sshd SSO GSSAPI}}
~~DISCUSSION~~