===== 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~~