Пошаговые руководства, шпаргалки, полезные ссылки...
БлогФорумАвторы
Полезные Online-сервисы
Перечень Бесплатного ПО
Подписка на RSS-канал
Ранее мы рассматривали пример подключения Debian Jessie к домену AD с помощью утилиты realmd, как наиболее простой и удобный вариант. Однако В RHEL6/CentOS6 возможность использования утилиты realmd отсутствует. Подтверждение этому можно найти в документе 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
Устанавливаем репозиторий 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
В процессе присоединения нашего Linux-сервера к домену в системе был создан/обновлён keytab-файл Чтобы ппроверить его содержимое установим Kerberos-клиента (он также нам потребуется для настройки Kerberos-аутентификации для сервера SSH):
# yum install krb5-workstation
Убедимся в том, что в keytab-файле присутсвуют записи типа host/<server fqdn>@<DONAIN FQDN>:
host/<server fqdn>@<DONAIN FQDN>
# 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:
# 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 учитывая ранее описанные особенности:
# 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 для доменных пользователей для простоты воспользуемся ранее упомянутой доменной группой безопасности 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 в контексте доменного пользователя может возникать длительная задержка при первом запросе на ввод пароля. В этом случае можно попробовать воспользоваться включением опции ignore_group_members в секции описания домена в конфигурационном файле sssd.conf
sssd.conf
Если говорить про 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
Дополнительные источники информации:
Автор первичной редакции: Алексей Максимов Время публикации: 05.01.2017 12:28
