Подключение Debian GNU/Linux 8.6 к домену Active Directory с помощью SSSD и realmd

На большом количестве разных интернет-ресурсов можно встретить описание процедуры присоединения серверов на базе ОС Linux к домену Active Directory, и практически везде в таких описаниях в виде неотъемлемой части присутствует установка Samba с последующим использованием Winbind. Мы тоже не стали в этом плане исключением. В этой заметке я хочу рассмотреть пример использования альтернативного средства расширения функционала аутентификации и авторизации в Linux – службы SSSD (System Security Services Daemon), которая будет автоматически настроена с помощью пакета realmd (Realm Discovery). В этом примере нами будет настроена аутентификация и авторизация на сервере Debian GNU/Linux 8.6 (Jessie) с подключением к домену Active Directory (на базе Windows Server 2012 R2).

Общую информацию о SSSD можно получить здесь - FedoraProject Wiki – SSSD и здесь - FedoraHosted Wiki – sssd. На русском языке небольшое описание есть в статье Датавед - Настройка SSSD и интересный комментарий есть в ветке форума Pro-LDAP.ru - Сводка систем аутентификации. Меня же SSSD заинтересовала после того, как я наткнулся на пару интересных статей в блоге Red Hat, где SSSD рассматривается как более продвинутая альтернатива Winbind -Overview of Direct Integration Options и SSSD vs Winbind. Даже не взирая на то, что SSSD имеет некоторые ограничения, такие как, например, отсутствие поддержки NTLM (зачем он нужен, если есть Kerberos), эта штука всё равно выглядит интересно.

Как сказано в документе Configuring_sssd_with_ad_server поддержка Active Directory (AD) появилась в SSSD начиная с версии 1.9.0. Проверим версию доступную нам в репозиториях только что установленной Debian Jessie:

# apt-cache show sssd

Package: sssd
Version: 1.11.7-3
Installed-Size: 42
Maintainer: Debian SSSD Team 
Architecture: amd64
Depends: python-sss (= 1.11.7-3), sssd-ad (= 1.11.7-3), sssd-common (= 1.11.7-3), sssd-ipa (= 1.11.7-3), sssd-krb5 (= 1.11.7-3), sssd-ldap (= 1.11.7-3), sssd-proxy (= 1.11.7-3)
Description-en: System Security Services Daemon -- metapackage
Provides a set of daemons to manage access to remote directories and authentication mechanisms. It provides an NSS and PAM interface toward the system and a pluggable backend system to connect to multiple different account sources. It is also the basis to provide client auditing and policy services for projects like FreeIPA. This package is a metapackage which installs the daemon and existing authentication back ends.
Multi-Arch: foreign
Homepage: https://fedorahosted.org/sssd/
Section: utils
Priority: extra
Filename: pool/main/s/sssd/sssd_1.11.7-3_amd64.deb
Size: 13248
...

Итак, имеющаяся в репозиториях Debian версия имеет поддержку AD, хотя и не является самой актуальной версией.

 

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

Прежде чем приступить к установке и настройке SSSD, убедимся в том, что на нашей Linux-системе корректно настроен DNS клиент, то есть, как минимум, в файле /etc/resolv.conf есть ссылки на DNS-серверы, которые отвечают за разрешение имён в домене Active Directory:

# cat /etc/resolv.conf

search ad.holding.com
nameserver 10.1.0.9
nameserver 10.6.1.8

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

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

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

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

Для автоматизации создания конфигурации SSSD существует очень удобный инструмент – пакет realmd (Realm Discovery). Документацию об использовании этого инструмента можно найти по адресу freedesktop.org - realmd docs. Утилита realm, входящая в этот пакет способна автоматически обнаружить информацию о домене AD и поможет нам простым и удобным способом выполнить присоединение нашей Linux-системы к этому домену с автоматической настройкой системы аутентификации Linux (PAM/NSS) и её интеграцией с SSSD

Установим пакет realmd:

# apt-get install realmd

Проверим как работает обнаружение домена, выполнив realm discover (подробности здесь)

# realm discover ad.holding.com --verbose

 * Resolving: _ldap._tcp.ad.holding.com
 * Performing LDAP DSE lookup on: 10.2.0.8
 * Performing LDAP DSE lookup on: 10.4.5.2
 * Performing LDAP DSE lookup on: 10.2.5.3
 * Successfully discovered: ad.holding.com
ad.holding.com
  type: kerberos
  realm-name: AD.HOLDING.COM
  domain-name: ad.holding.com
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin

Как видим, из службы DNS по служебным SRV-записям успешно получена информация о домене и определён набор пакетов, которые нужно установить и настроить в систему для успешного подключения к домену.

Перед запуском процедуры автоматической установки и настройки пакетов с последующим присоединением к домену, при желании (опционально) мы можем настроить дополнительные параметры для работы утилиты realm. Для этого можно создать и настроить конфигурационный файл realmd.conf: 

# touch /etc/realmd.conf

Информацию о поддерживаемых опциях файла можно найти в онлайн-справке, либо в локальной справке man realmd.conf. Например, зададим произвольные имя и версию ОС, которые будут отправлены в качестве значений атрибутов operatingSystem и operatingSystemVersion при создании учётной записи компьютера в домене AD

[active-directory]
os-name = Debian GNU/Linux
os-version = 8.6 (Jessie)

Теперь перейдём к процедуре присоединения нашего Linux-компьютера к домену с помощью команды realm join. В ходе выполнения этой процедуры будет выполнено несколько действий:

  • Будет установлено ПО необходимое для присоединения и последующей авторизации в домене AD (пакеты adcli, libpam-sss, libnss-sss, sssd, sssd-tools);
  • Будет создана учётная запись компьютера в домене AD;
  • Будет сгенерирован keytab-файл /etc/krb5.keytab для поддержки Kerberos;
  • Будет сконфигурирована и запущена служба sssd
  • Будут настроены конфигурационные файлы PAM/NSS для поддержки доменной аутентификации

Пример выполнения команды:

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

Все доступные к использованию опции можно посмотреть в онлайн-документации. В рассматриваемом нами примере Linux-компьютер с именем хоста KOM-APP31 будет присоединяться к домену AD.HOLDING.COM, а в процессе присоединения для создаваемой в домене учётной записи компьютера будет использоваться Organizational Unit (OU) Linux Servers\KOM\ad.holding.com. Присоединение к домену будет выполняться с использованием подключения к ближайшему к нам контроллеру домена kom-dc01.ad.holding.com. Обратите внимание на то, что если в качестве последнего параметра явно указан контроллер домена, то он и будет в дальнейшем использоваться в качестве источника проверки учётных данных. Если же вместо имени конкретного контроллера домена указать имя домена, то для определения контроллеров домена используемых для аутентификации в дальнейшем будет использоваться механизм авто-обнаружения по SRV-записям в DNS, что не всегда является желательной конфигурацией, хотя и сводит к минимуму возможные дополнительные правки конфигурационных файлов после "джойна". Помимо этого при вызове команды нами используется ряд опций:

  • user – логин доменного пользователя с правами, достаточными для ввода компьютера в домен AD. От имени этого пользователя будет выполняться присоединение компьютера к домену и модификация атрибутов доменной учётной записи компьютера. В классической ситуации - это пользователь с правами администратора домена, так как именно администраторы домена по умолчанию в AD могут обновлять значение атрибута servicePrincipalName. Однако я не очень люблю для "попсовых" задач использовать привилегии такого уровня, поэтому здесь я использую рядового доменного пользователя, у которого есть права на создание и модификацию объектов типа Computer в OU указанном в опции computer-ou;
  • user-principal – строка регистрации принципала Kerberos, которая будет использоваться для генерации keytab-файла и регистрации значений атрибута userPrincipalName в свойствах учётной записи компьютера в домене AD.
    Теперь о том, зачем мы здесь используем эту опцию.
    Указывать в явном виде такое значение, как используется в нашем примере, вовсе не обязательно, так как по сути утилита adcli, которая используется в фоновом режиме в процессе "джойна" должна сама регистрировать значение вида
    host/serverfqdn@REALM. Однако в нашем случае из репозиториев Debian автоматически устанавливается устаревшая версия (0.7.5-1) этой утилиты, которая имеет проблему описанную в статье adcli creates wrong kerberos keytab entry with uppercase HOST, то есть при генерации keytab-файла записи типа host/* создаются в верхнем регистре, то есть HOST/*. А это, в свою очередь, может в дальнейшем привести к проблеме использования keytab-файла такими службами как, например, sshd. Судя по документу Red Hat Bugzilla - Bug 1267319 этот баг исправлен в adcli версии 0.8.0-1, но так как у нас нет этого обновления, мы используем обходное решение, то есть в явном виде задаём нужный нам формат записи в опции user-principal.;
  • computer-ou – имя OU, в котором мы хотим создать учётную запись компьютера в домене. Если учётная запись уже существует, то она будет обновлена.
  • verbose – понятное дело, подразумевает расширенный вывод информации о всех происходящих действиях.

Пример выполнения команды в моём конкретном случае:

 * Resolving: _ldap._tcp.kom-dc01.ad.holding.com
 * Resolving: kom-dc01.ad.holding.com
 * Performing LDAP DSE lookup on: 10.1.0.9
 * Successfully discovered: ad.holding.com
Password for petya:{здесь введём пароль пользователя}
 * Unconditionally checking packages
 * Resolving required packages
 * Installing necessary packages: adcli, libpam-sss, libnss-sss, sssd, sssd-tools
 * LANG=C /usr/sbin/adcli join --verbose --domain ad.holding.com --domain-realm AD.HOLDING.COM --domain-controller 10.1.0.9 --computer-ou OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com --login-type user --login-user petya --stdin-password
 * Using domain name: ad.holding.com
 * Calculated computer account name from fqdn: KOM-APP31
 * With user principal: host/kom-app31.ad.holding.com@AD.HOLDING.COM
 * Using domain realm: ad.holding.com
 * Sending netlogon pings to domain controller: ldap://10.1.0.9
 * Received NetLogon info from: KOM-DC01.ad.holding.com
 * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-hRFuGh/krb5.d/adcli-krb5-conf-5nYX3C
 * Authenticated as user: petya@AD.HOLDING.COM
 * Looked up short domain name: KOM
 * Using fully qualified name: KOM-APP31
 * Using domain name: ad.holding.com
 * Using computer account name: KOM-APP31
 * Using domain realm: ad.holding.com
 * Calculated computer account name from fqdn: KOM-APP31
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * Using fully qualified name: KOM-APP31
 * Using domain name: ad.holding.com
 * Using computer account name: KOM-APP31
 * Using domain realm: ad.holding.com
 * Looked up short domain name: KOM
 * Computer account for KOM-APP31$ does not exist
 ! Couldn't find a computer container in the ou, creating computer account directly in: OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com
 * Calculated computer account: CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com
 * Created computer account: CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com
 * Set computer password
 * Retrieved kvno '2' for computer account in directory: CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com
 * Modifying computer account: dNSHostName
 * Modifying computer account: userAccountControl
 * Modifying computer account: operatingSystem, operatingSystemVersion, operatingSystemServicePack
 * Modifying computer account: userPrincipalName
 ! Couldn't set service principals on computer account CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com: 00002083: AtrErr: DSID-03151785, #1:
        0: 00002083: DSID-03151785, problem 1006 (ATT_OR_VALUE_EXISTS), data 0, Att 90303 (servicePrincipalName)

 ! Couldn't authenticate with keytab while discovering which salt to use: KOM-APP31$@AD.HOLDING.COM: Client 'KOM-APP31$@AD.HOLDING.COM' not found in Kerberos database
 * Added the entries to the keytab: KOM-APP31$@AD.HOLDING.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: host/kom-app31.ad.holding.com@AD.HOLDING.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: HOST/KOM-APP31@AD.HOLDING.COM: FILE:/etc/krb5.keytab
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: HOST/KOM-APP31@AD.HOLDING.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM: FILE:/etc/krb5.keytab
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM: FILE:/etc/krb5.keytab
 * /usr/sbin/update-rc.d sssd enable
 * /usr/sbin/service sssd restart
 * Successfully enrolled machine in realm

В моём примере видно, что процесс ввода в домен завершился успешно, однако с заполнением атрибута servicePrincipalName в свойствах учётной записи компьютера в домене возникла проблема, так как указанному в опции --user пользователю petya банально не хватило прав на это действие. Об этом я в общем-то и писал выше, то есть проблему эту я создал себе сам для большего контроля над процессом. Чтобы исправить это, я выполню данное действие в домене вручную с помощью утилиты setspn с любой доменной Windows-машины уже с правами доменного администратора:

C:\> setspn -A HOST/kom-app31.ad.holding.com kom-app31

Проверка домена DC=ad,DC=holding,DC=com
Регистрация ServicePrincipalNames для CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com
        HOST/kom-app31.ad.holding.com
Обновленный объект

Проверяем результат:

C:\> setspn -L kom-app31

Зарегистрирован ServicePrincipalNames для CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com:
        HOST/kom-app31.ad.holding.com

Теперь можем приступить к проверке результатов работы realm join, хотя по большому счёту делать это имеет смысл только в случае "траблшутинга" или необходимости внесения в конфигурационные файлы дополнительных правок, чтобы учесть собственную специфику, как в нашем случае.

 

Проверяем результат работы realm join

В ходе присоединения к домену утилита realm автоматически выполнила установку нужных пакетов - adcli, libpam-sss, libnss-sss, sssd, sssd-tools. При этом, наша Linux-система осталась свободной от монструозной Samba с её Winbind, и это, в некоторой степени, не может не радовать. Более того, в системе мы даже не обнаружим классически привычного для Kerberos пакета krb5-user. Поэтому если мы, по какой-то причине, всё-таки заходим заглянуть внутрь сгенерированного keytab-файла, то нам придётся таки установить соответствующий пакет (по крайней мере другого способа посмотреть keytab я не знаю):

# apt-get install krb5-user
# klist -e -k -t /etc/krb5.keytab

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   2 10/13/2016 10:52:10 KOM-APP31$@AD.HOLDING.COM (des-cbc-crc)
   2 10/13/2016 10:52:10 KOM-APP31$@AD.HOLDING.COM (des-cbc-md5)
   2 10/13/2016 10:52:10 KOM-APP31$@AD.HOLDING.COM (arcfour-hmac)
   2 10/13/2016 10:52:10 KOM-APP31$@AD.HOLDING.COM (aes128-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 KOM-APP31$@AD.HOLDING.COM (aes256-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 host/kom-app31.ad.holding.com@AD.HOLDING.COM (des-cbc-crc)
   2 10/13/2016 10:52:10 host/kom-app31.ad.holding.com@AD.HOLDING.COM (des-cbc-md5)
   2 10/13/2016 10:52:10 host/kom-app31.ad.holding.com@AD.HOLDING.COM (arcfour-hmac)
   2 10/13/2016 10:52:10 host/kom-app31.ad.holding.com@AD.HOLDING.COM (aes128-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 host/kom-app31.ad.holding.com@AD.HOLDING.COM (aes256-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 HOST/KOM-APP31@AD.HOLDING.COM (des-cbc-crc)
   2 10/13/2016 10:52:10 HOST/KOM-APP31@AD.HOLDING.COM (des-cbc-md5)
   2 10/13/2016 10:52:10 HOST/KOM-APP31@AD.HOLDING.COM (arcfour-hmac)
   2 10/13/2016 10:52:10 HOST/KOM-APP31@AD.HOLDING.COM (aes128-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 HOST/KOM-APP31@AD.HOLDING.COM (aes256-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM (des-cbc-crc)
   2 10/13/2016 10:52:10 RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM (des-cbc-md5)
   2 10/13/2016 10:52:10 RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM (arcfour-hmac)
   2 10/13/2016 10:52:10 RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM (aes128-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM (aes256-cts-hmac-sha1-96)

Как видим, в нашем keytab-файле присутствуют записи. которые мы ранее указывали в опции --user-principal.

***

Проверим наличие настроенного утилитой realm файла /etc/sssd/sssd.conf. При необходимости можно сразу подправить файл, чтобы разрешить аутентификацию по коротким именам, например petya, то есть, без указания доменного суффикса в формате petya@ad.holding.com. Для этого можно либо убрать параметр "use_fully_qualified_names = True" либо в глобальную секцию "[sssd]" добавить доменный суффикс по умолчанию. Я выбираю второй вариант. Помимо этого мы можем добавить нужные нам дополнительные серверы аутентификации - контроллеры домена, расширив значение параметра ad_server и добавив, при необходимости, параметр ad_backup_server (подробнее здесь). Указывать в явном виде конкретные контроллеры домена может быть полезно в случае, если в домене много контроллеров и автоматический механизм обнаружения по SRV-записям в DNS возвращает далеко расположенные контроллеры, что может вызвать дополнительные задержки в процессе аутентификации. В итоге файл примет следующий вид:

[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 = msk-dc01.ad.holding.com, msk-dc02.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 = ad

Практика показала, что даже в случае явного указания контроллеров домена, в случае если в лесу AD несколько доменов, возможна ситуация, при которой поиск доменных пользователей не будет возвращать результатов. В таком случае в секцию [domain/ad.holding.com] можно попробовать добавить дополнительные параметры, ограничивающие поиск:

[domain/ad.holding.com]
...
subdomains_provider = none
ldap_idmap_default_domain_sid = S-1-5-21-xxx-xxx-xxx

Первый параметр отключает запросы к другим поддоменам внутри леса, а второй параметр определяет SID домена, в котором должен выполняться поиск. SID всех доменов в лесу AD можно легко получить на любом доменном Windows-компьютере с помощью PowerShell:

(Get-ADForest).Domains | %{Get-ADDomain -Server $_} | Select name, domainsid

***

Дополнительно пришлось столкнуться с ситуацией, когда при определении членства в группах безопасности для пользователя возвращался неполный перечень групп. Например команда id petya выводила только информацию об основной группе пользователя (например domain users). Обнаружилось и описание этой проблемы: sssd ticket 2667 - id_provider = ad requires ldap_use_tokengroups = False to see secondary groups. В качестве обходного решения этой проблемы предполагается отключение параметра ldap_use_tokengroups в секции домена:

[domain/ad.holding.com]
...
ldap_use_tokengroups = False
...

***

Ещё одна ситуация, с которой можно столкнуться в доменах Active Directory с большим количеством групп и пользователей – исчерпание пула idmap, используемого по умолчанию в SSSD. В таком случае команда типа getent group <имя группы> может не возвращать членство группы, а команда типа id <имя пользователя> может возвращать неполный список доменных групп пользователя. При этом, если запустить sssd интерактивно (службу предварительно нужно остановить) с расширенным дебагом…

# service sssd stop
# sssd -i --debug-level=3

…то в результате выполнения выше обозначенных команд можно обнаружить ошибку типа:

[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [SID пользователя/группы] to a UNIX ID

Для решения этой проблемы можно попробовать расширить используемый в SSSD по умолчанию размере пула idmap с 200000 до, например, 2000000. Делается это в секции описания домена в sssd.conf:

[domain/ad.holding.com]
...
ldap_idmap_range_size = 2000000
...

Подробнее об idmap и его границах в sssd можно почитать в man sssd-ad

***

Чтобы внесённые в sssd.conf изменения вступили в силу, перезапускаем службу sssd с очисткой кэшей sss:

# service sssd stop
# rm -f /var/lib/sss/db/*
# rm -f /var/lib/sss/mc/*
# service sssd start

Убедимся в том, что служба sssd успешно запущена и настроена на автоматический запуск:

 

# service sssd status

● sssd.service - System Security Services Daemon
   Loaded: loaded (/lib/systemd/system/sssd.service; enabled)
   Active: active (running)  since Tue 2016-10-14 23:10:13 MSK; 4s ago
  Process: 10310 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS)
 Main PID: 10311 (sssd)
   CGroup: /system.slice/sssd.service
           ├─10311 /usr/sbin/sssd -D -f
           ├─10312 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain ad.holding.com --debug-to-files
           ├─10313 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --debug-to-files
           └─10314 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --debug-to-files
...

***

Проверить то, что SSSD успешно прописан в качестве NSS/PAM провайдера можно, заглянув в ряд системных файлов - /etc/nsswitch.conf и /etc/pam.d/common-*. Файл nsswitch.conf привожу информативно без внесения в него каких-либо правок и убрав из вывода его комментарии, чтобы показать, что в нём появились вызовы sss:

passwd:         compat sss
group:          compat sss
shadow:         compat sss
gshadow:        files
hosts:          files dns
networks:       files
protocols:      db files
services:       db files sss
ethers:         db files
rpc:            db files
netgroup:       nis sss

Проверим файл /etc/pam.d/common-session. Внесём в этот файл дополнительную правку  - в конец файла добавим строку определяющую директиву создания домашнего каталога в случае его отсутствия. Таким образом, для вновь подключаемых к серверу доменных пользователей автоматически будут создаваться домашние каталоги по шаблону указанному в параметре fallback_homedir в конфигурации sssd.conf. Результирующий файл (без вывода комментариев) получится следующий:

session [default=1]     pam_permit.so
session requisite       pam_deny.so
session required        pam_permit.so
session required        pam_unix.so
session optional        pam_sss.so
session optional        pam_systemd.so
session required        pam_mkhomedir.so umask=0022 skel=/etc/skel

Другие файлы, также без вывода комментариев, привожу чисто информативно, так как их правка не требуется, и нам лишь можно убедиться в том, что в указанных файлах есть вызовы библиотеки pam_sss.so.

Файл /etc/pam.d/common-auth :

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_sss.so use_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Файл /etc/pam.d/common-account :

account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so
account requisite                       pam_deny.so
account required                        pam_permit.so
account sufficient                      pam_localuser.so
account [default=bad success=ok user_unknown=ignore]    pam_sss.so

Файл /etc/pam.d/common-password :

password        requisite                       pam_pwquality.so retry=3
password        [success=2 default=ignore]      pam_unix.so obscure use_authtok try_first_pass sha512
password        sufficient                      pam_sss.so use_authtok
password        requisite                       pam_deny.so
password        required                        pam_permit.so

 

Проверяем доступ к пользователям и группам Active Directory

Теперь можно проверить возможность получения информации о пользователе из домена AD. При желании можно проверить разные форматы представления учётной записи (с NetBIOS-именем домена, с доменным суффиксом в виде UPN):

# getent passwd petya
petya@ad.holding.com:*:1668597447:1668100510:Петя Резинкин:/home/ad.holding.com/petya:/bin/bash

# getent passwd KOM\\petya
petya@ad.holding.com:*:1668597447:1668100510:Петя Резинкин:/home/ad.holding.com/petya:/bin/bash

# getent passwd petya@ad.holding.com
petya@ad.holding.com:*:1668597447:1668100510:Петя Резинкин:/home/ad.holding.com/petya:/bin/bash

По аналогии проверяем то, что из домена нам возвращается информация об интересующей нас группе безопасности и входящих в эту группу доменных пользователях:

# getent group "KOM-SRV-Linux-Admins@ad.holding.com"

kom-srv-linux-admins@ad.holding.com:*:1668876454:petya@ad.holding.com,vovan@ad.holding.com

Как видим, всё в порядке. И при этом SSSD очень шустро и без граблей, с которыми мне ранее приходилось сталкиваться в Winbind, возвращает требуемые объекты каталога AD.

 

Ограничение доступа через доменные группы безопасности

Теперь нам нужно подумать о том, как ограничить доступ доменных пользователей для входа на наш Linux-сервер, так как в конфигурации по умолчанию все доменные пользователи, успешно прошедшие аутентификацию, смогут войти в нашу Linux-систему. Это подтвердит команда realm list, в которой нам нужно обратить внимание на строчку login-policy

# realm list

ad.holding.com
  type: kerberos
  realm-name: AD.HOLDING.COM
  domain-name: ad.holding.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U@ad.holding.com
  login-policy: allow-realm-logins

Разрешим вход только для конкретной доменной группы, например KOM-SRV-Linux-Admins, с помощью команды realm permit:

# realm permit --groups KOM-SRV-Linux-Admins@ad.holding.com

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

...
[domain/ad.holding.com]
...
access_provider = simple
simple_allow_groups = KOM-SRV-Linux-Admins@ad.holding.com

Проверим то, как изменился вывод realm list:

# realm list

ad.holding.com
...
  login-policy: allow-permitted-logins
  permitted-logins:
  permitted-groups: KOM-SRV-Linux-Admins@ad.holding.com

Как видим, политика login-policy изменилась, и теперь присутствует явное указание разрешённой доменной группы доступа.

***

После настройки ограничения доступа совсем не лишним будет выполнить ряд простых тестов, чтобы убедиться в том, что эти ограничения действительно работают так как мы этого ожидаем. Например, сначала можно проверить возможность входа с доменным пользователем, включённым в группу доступа, затем другим доменным пользователем, но уже не входящим в группу доступа, затем локальным пользователем Linux-сервера и т.д. При проверке доменной аутентификации обратите внимание на то, что первый вход пользователя, ранее не обращавшегося к Linux-серверу может сопровождаться незначительной задержкой, однако все последующие входы будут выполняться молниеносно. Это связано с тем, что sssd имеет собственный механизм кэширования успешно проверенных учётных данных пользователя и способен выполнить аутентификацию даже в случае временной недоступности контроллеров домена.

 

Доступ к 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-APP31:~$ sudo whoami
[sudo] password for petya@ad.holding.com: {вводим пароль пользователя petya}

root

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

В некоторых источниках, как например здесь приводится пример того, что для совместной работы sudo и sssd нужно устанавливать пакет libsss-sudo, хотя я такой пакет не устанавливал и sudo при этом работает, отталкиваясь от членства доменной группы безопасности. Поэтому надобность libsss-sudo для меня пока остаётся загадкой.

 

Удалённый доступ по протоколу SSH

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

Однако если вы захотите настроить Single sign-on (SSO) из Putty при подключении c Windows-машины по ранее описанной методике, то здесь без установки пакета kerb5-user, как я понял, опять же не обойтись.

# apt-get install krb5-user

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

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

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

# service ssh restart

***

Резюмируя, можно сказать, что с помощью realmd и sssd настройка подключения Linux-машины к домену Active Directory несколько упрощается и становится более наглядной по сравнению с ранее описанным вариантом, а также не влечёт за собой необходимости использования Samba со "всеми вытекающими". Поэтому наверняка стоит задуматься об использовании данных инструментов для последующих "джойнов".

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

Всего комментариев: 23 Комментировать

  1. Alexander /

    А для чего вы всё это делали? Что бы заходить через ssh с помощью домена только? Где можно применять данный функционал?

  2. Александр /

    2Alexander: например, можно это использовать при реализации системы "безопасный интернет". Я немного написал об этом на http://alexnur.ru/?page_id=7 . В будущем дополню, т.к. планируется несколько ssh-серверов и необходим балансировщик нагрузки (коммутатор) и общая файловая система. В общем, даже хотя бы для ssh - вполне себе обоснованная необходимость для подключения к домену.
    Автору спасибо, интересно было на родном языке почитать про подключение к домену без winbind.
    ЗЫ: Автору: не знаю как с sssd, а с использованием winbind и krb5user, после входа на ssh-сервер использоваалась SSO-аутентификация (gssapi), однако в домене такой пользователь был не авторизован (приходилось делать kinit), являясь по сути локальным пользователем линукс. Решение - включение делегирования на контроллере AD. Если же авторизовываться вручную на sshd, без SSO, то билет пробрасывался. Я об этом писал в комментарии к Вашей статье об использовании SSO к SSHD на ubuntu 14.04

    1. Алексей Максимов / Автор записи

      Да, Александр. Я видел Ваш комментарий, но ничего не ответил по причине того, что описанная Вами проблема у меня не воспроизводилась.

  3. Emil Gazizov /

    Это можно использовать для NTLM авторизации если установить squid?

    1. Алексей Максимов / Автор записи

      SSSD не имеет поддержки NTLM, поэтому, если для Вас всё ещё актуально использование NTLM, придётся по старинке использовать Winbind.

  4. Дмитрий /

    Жаль, со сквидом и самбой этот вариант не будет работать :(

    1. Алексей Максимов / Автор записи

      Подумываю о том, чтобы полностью отказаться от NTLM на прокси. Когда руки дойдут до очередного развёртывания Squid, попробую это дело в связке с SSSD.

      1. Дмитрий /

        было б интересно! ;)

      2. Emil Gazizov /

        Т.е. всё-же возможна доменная авторизация в squid через sssd?

  5. Александр /

    2Алексей: Вы случайно не планируете описать настройку nfs4 и kerberos? Через sssd или winbind. Интересует для centos и ubuntu. У меня так и не получилось

    1. Алексей Максимов / Автор записи

      Не планирую.

  6. Andrey /

    Советую еще попробовать PowerBroker Identity Services, Open Edition. Ранее известен как Likewise. Линукс в домен вводится вообще без плясок с бубном. Описание продукта и его возможностей https://habrahabr.ru/post/174407/

  7. Алексей Максимов / Автор записи

    Добавил информацию о дополнительном сужении поиска учётных записей в лесу AD с несколькими доменами c помощью параметров subdomains_provider и ldap_idmap_default_domain_sid

  8. AlektroNik /

    Алексей, спасибо за статью.
    Подскажите, а настройка сайтов в "AD Сайты и Службы" не решает проблему с выбором оптимального пути?

    P. S. Столкнулся недавно с необходимостью изучения механизма выбора оптимального маршрута, а конкретнее каким образом "AD Сайты и Службы" передают этот маршрут клиенту. У меня клиент на windows начинал использовать новый маршрут только по прошествии часа, а то и на следующий день. Так и не нашел ответа на свой вопрос. Так что если есть статейка по глубокому изучению или траблшутингу сервиса "AD Сайты и Службы" буду благодарен.

    1. Алексей Максимов / Автор записи

      Дело тут не в настройке AD, а в особенностях работы SSSD. Можете мне поверить на слово, что сайты AD у нас в инфраструктуре настроены в ресурсном поддомене как положено, однако механизм авто-обнаружения SSSD всё равно "ломится" в коневой домен и "бьётся головой" об его контроллеры. Поэтому я и пошёл по пути наименьшего сопротивления - отключил обнаружение доменов. По поводу настройки топологии сайтов AD материалов в интернете навалом, и даже на русском языке, так что не найти ответы на свои вопросы может наверно только ленивый.

      1. AlektroNik /

        Спасибо.
        Ну я вроде бы не ленивый, находить находил, но вот почему-то все поверхностные. Поищу еще :)

  9. Обратная ссылка: Дедупликация хранилища резервных копий виртуальных машин oVirt с помощью QUADStor Storage Virtualization на CentOS Linux 7.2 | Блог IT-KB /

  10. Алексей Максимов / Автор записи

    Добавил информацию о расширении пула idmap при проблемах извлечения членства в группах в инфраструктурах с большим количеством групп/пользователей в домене ActiveDirectory

  11. Обратная ссылка: Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM | Блог IT-KB /

  12. Олег /

    поддержку NTLM на squid в связке с sssd не реализовать конечно, но вот авторизацию по Kerberos вполне реально через pam_auth и sssd

    1. Алексей Максимов / Автор записи

      pam_auth — это хелпер Basic-аутентификации. Описал пример такой настройки в Вики: Xелпер basic_pam_auth для аутентификации пользователей Active Directory через связку PAM с SSSD

  13. Обратная ссылка: Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 10. Аутентификация и авторизация пользователей Active Directory в Icinga Web 2 (Kerberos и SSO) | Блог IT-KB /

  14. Евгений /

    Статья хорошая, труда вложено очень много в нее, не понял только зачем в nsswitch.conf в строке shadow: compat sss нужен sss? и в строке netgroup: nis sss зачем нужен nis ? NIS клиент вы же не используете совместно с sssd, а для shadow я никогда не добавлял sss, какой в этом смысл? # getent shadow c sss и без него тот же самый будет.

Добавить комментарий