Вики IT-KB

Пошаговые руководства, шпаргалки, полезные ссылки...

Инструменты пользователя

Инструменты сайта


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

CentOS Linux 6.6 (SHMZ) - Подключение к домену Active Directory с помощью adcli и настройка аутентификации и авторизации через SSSD

Ранее мы рассматривали пример подключения 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
resolv.conf
...
nameserver 10.1.0.9
nameserver 10.6.1.8
...

Также, в силу того, что SSSD будет использовать Kerberos, нам нужно убедиться в том, что у нас корректно настроен NTP-клиент и время синхронизировано с контроллерами домена AD. Настраиваем конфигурационный файл NTP-клиента:

# nano /etc/ntp.conf

В файле меняем строчки указывающие на NTP-сервер. В качестве источника времени указываем контроллеры домена AD:

ntp.conf
...
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/<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

Пример настроенного файла:

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
nsswitch.conf
...
passwd: files sss
shadow: files sss
group: files sss
services: files sss
netgroup: files sss
...
# cat /etc/pam.d/system-auth | grep sss
system-auth
...
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 директиву для создания домашнего каталога пользователя в случае его отсутсвия:

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.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
%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

Как видим, команда выполняется успешно с повышением привилегий.



Настройка SSHD

Если говорить про SSH, то никакой специальной настройки sshd здесь не требуется, так как по умолчанию ssh-сервер уже настроен на использование PAM, а тот в свою очередь был ранее настроен нами на использование доменной аутентификации с помощью sss.

В файле /etc/ssh/sshd_config достаточно раскомментировать и включить параметры GSSAPI:

sshd_config
...
# GSSAPI options 
GSSAPIAuthentication yes 
GSSAPICleanupCredentials yes
...

При этом AllowGroups можно не заполнять, так как будет использоваться членство групп описанное ранее в sssd.conf с помощью параметра simple_allow_groups. После правки перезапускаем службу ssh-сервера и проверяем работу SSO

# service sshd restart


Дополнительные источники информации:


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

Обсуждение

АндрейАндрей, 19.05.2017 13:37
Отличная инструкция!
Проблема возникает при первом подключении пользователя.
Если делать так
#su - petya@ad.holding.com
То создается домашний каталог для petya и пользователь прекрасно работает.

Если же сам пользователь petya попытается подключится к машине по SSH или GUI, то получает ошибки.
Could not chdir to home directory /home/ad.holding.com/petya: No such file or directory
/usr/bin/xauth: error in locking authority file /home/ad.holding.com/petya/.Xauthority

На каталог /home/ad.holding.com права только у root
drwxr-xr-x. 3 root root 4096 Май 19 15:20 ad.holding.com

как это побороть? понимаю что надо дать пермишины для группы KOM-SRV-Linux-Admins но как это сделать?
Алексей МаксимовАлексей Максимов, 19.05.2017 14:03
Встречался с чем-то похожим после того, как каталог профиля был сделан руками. Удалите каталог пользователя сделанный ранее и он должен автоматически быть создан при входе в систему с нужными правами.
АндрейАндрей, 19.05.2017 14:07
Так и сделал.
Первый раз вход через X, неудачно.
удалил каталог
Второй вход через ssh, то же неудачно (лог привел выше.)
Третий вход рутом, и переключения на пользователя. Вход выполнен, каталог создан.

ОС CentOS 6.9
Алексей МаксимовАлексей Максимов, 19.05.2017 14:38
А Вы случайно не забыли в /etc/pam.d/system-auth добавить инструкцию создания домашнего каталога?

session required pam_mkhomedir.so umask=0022 skel=/etc/skel
АндрейАндрей, 19.05.2017 16:33
Добавил. Делал в соответствии с инструкции, за исключением имени домена, пользователя и групп.
Возможно проблема в том что добавлял пользователя состоящего в группе доменных администраторов.
А линукс не очень корректно работает с именами через пробел, как в случае с группой доменных администраторов.
АндрейАндрей, 22.05.2017 11:28
В качестве "бонуса", после перезагрузки сервера подключится доменными уч.записи к серверу не получается ни через GUI ни по ssh (в случае ssh - ошибка "Connection closed by foreign host").
Проблема решается только через удаление базы sssd
# service sssd stop
# rm -f /var/lib/sss/db/*
# rm -f /var/lib/sss/mc/*
# service sssd start
ошибок в журналах 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.txt · Последние изменения: 05.01.2017 12:44 — Алексей Максимов