Установка SSSD/realmd и подключение к домену Active Directory

В целом процедура подключения компьютера под управлением GNU/Linux к домену Active Directory с помощью SSSD и realmd схожа с ранее описанной в статье, но с некоторыми исключениями и оговорками.

Предварительные требования

Настраиваем DNS-клиента, чтобы правильно разрешались доменные имена.

# cat /etc/resolv.conf

search ad.holding.com nameserver 10.1.0.9 nameserver 10.6.1.8

Настраиваем и проверяем синхронизацию времени с контроллерами домена.

# apt-get install ntp
# nano /etc/ntp.conf

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

ntp.conf

...
server 10.1.0.9 iburst
server 10.6.1.8 iburst
...

Перезапускаем службу ntp и проверяем статус синхронизации времени:

# service ntp restart
# ntpq -4 -p
# date -R

Установка SSSD/realmd и проблема присоединения к домену Active Directory

Устанавливаем необходимые пакеты из официальных репозиториев Ubuntu Xenial:

# apt-get install realmd sssd-tools sssd libnss-sss libpam-sss adcli krb5-user

При необходимости опционально правим realmd.conf.

# nano /etc/realmd.conf

realmd.conf

[active-directory]
os-name = GNU/Linux

Пробуем подключить компьютер к домену Active Directory:

# realm join --verbose --user=adm-vasya \ 
--user-principal="host/kom-ad01-vm40.ad.holding.com@AD.HOLDING.COM" \ 
--computer-ou="OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com" \ 
kom-ad01-dc01.ad.holding.com

Однако, несмотря на то, что предварительно мы установили все нужные пакеты, в можем получить ошибку, говорящую о том, что необходимые пакеты не установлены:

* Resolving: _ldap._tcp.kom-ad01-dc01.ad.holding.com * Resolving: kom-ad01-dc01.ad.holding.com * Performing LDAP DSE lookup on: 10.1.0.9 * Successfully discovered: ad.holding.com Password for adm-vasya: * Unconditionally checking packages * Resolving required packages ! Necessary packages are not installed: sssd-tools sssd libnss-sss libpam-sss adcli realm: Couldn’t join realm: Necessary packages are not installed: sssd-tools sssd libnss-sss libpam-sss adcli

Решить эту проблему можно, воспользовавшись обходным решением предложенным здесь, а именно добавить к команде realm join дополнительный параметр –install=/

# realm join --verbose --user=adm-vasya \ 
--user-principal="host/kom-ad01-vm40.ad.holding.com@AD.HOLDING.COM" \ 
--computer-ou="OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com" \ 
kom-ad01-dc01.ad.holding.com \
--install=/

Проверяем результат работы realm join, а также проверяем доступ к пользователям и группам Active Directory согласно ранее упомянутой статьи.

Проблема авторизации из-за ошибки механизма кеширования GPO

На этапе проверки доменной авторизации в Ubuntu 16.04 можем обнаружить ещё одну проблему.При попытке войти в систему, аутентификация пользователя проходит успешно, а попытка последующей авторизации завершается ошибкой типа:

auth.log

login[29223]: pam_sss(login:auth): authentication success; 
logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=vasya
login[29223]: pam_sss(login:account): Access denied for user vasya: 4 (System error)
login[29223]: System error

Чтобы понять корень проблемы, останавливаем службу sssd, затем запускаем sssd в интерактивном режиме с включённой опцией отладки следующей командой:

# ( service sssd stop ) && ( sssd -i --debug-level=3 )

Пробуем воспроизвести проблему — выполнить процедуру авторизации, и если на консоли видим ошибки типа:

… [sssd[be[ad.holding.com]]] [ad_gpo_store_policy_settings] (0x0020): [/var/lib/sss/gpo_cache/ad.holding.com/Policies/ {хххх-ххх-ххх-ххх-ххх}/Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf]: ini_config_parse failed [5][Ошибка ввода/вывода]…

Значит мы столкнулись с багом, имеющимся в версии sssd, которая на данный момент доступна в официальных репозиториях . В качестве решения этой проблемы предлагается создать каталог кеша доменных групповых политик, если его ещё нет. Если этот каталог существует, то установить на него права:

# rm -R /var/lib/sss/gpo_cache/ad.holding.com
# mkdir -p /var/lib/sss/gpo_cache/ad.holding.com
# chown -R sssd:sssd /var/lib/sss/gpo_cache

Если это не помогло, можно вообще выключить попытки обработки доменных политик в конфигурации /etc/sssd/sssd.conf в секции, описывающей домен:

sssd.conf

[domain/ad.holding.com]
...
ad_gpo_access_control = disabled

scratchpads.ru