На большом количестве разных интернет-ресурсов можно встретить описание процедуры присоединения серверов на базе ОС 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 TeamArchitecture: 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
<
p align="center">***
Резюмируя, можно сказать, что с помощью realmd и sssd настройка подключения Linux-машины к домену Active Directory несколько упрощается и становится более наглядной по сравнению с ранее описанным вариантом, а также не влечёт за собой необходимости использования Samba со "всеми вытекающими". Поэтому наверняка стоит задуматься об использовании данных инструментов для последующих "джойнов".
Дополнительные источники информации:
- FedoraHosted.org - sssd Wiki - Configuring_sssd_with_ad_server
- Red Hat Enterprise Linux Blog - SSSD-vs-Winbind
- RHEL7 Documentation - System Level Authentication Guide - 7.3. SSSD and Identity Providers (Domains)
- RHEL7 Documentation - System Level Authentication Guide - 7.2. SSSD and System Services
- Андрей Маркелов - Обзор Red Hat Directory Server и RHEL IdM
- jhrozek Blog - Anatomy of SSSD user lookup
- Alan D Moore Blog - Joining Debian 8 to Active Directory
- Датавед - Настройка SSSD
- Форум проекта Pro-LDAP.ru - Сводка систем аутентификации
- Сергей Яремчук - Подключаемся к Active Directory с помощью realmd
RSS - Записи
А для чего вы всё это делали? Что бы заходить через ssh с помощью домена только? Где можно применять данный функционал?
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
Да, Александр. Я видел Ваш комментарий, но ничего не ответил по причине того, что описанная Вами проблема у меня не воспроизводилась.
Это можно использовать для NTLM авторизации если установить squid?
SSSD не имеет поддержки NTLM, поэтому, если для Вас всё ещё актуально использование NTLM, придётся по старинке использовать Winbind.
Жаль, со сквидом и самбой этот вариант не будет работать :(
Подумываю о том, чтобы полностью отказаться от NTLM на прокси. Когда руки дойдут до очередного развёртывания Squid, попробую это дело в связке с SSSD.
было б интересно! ;)
Т.е. всё-же возможна доменная авторизация в squid через sssd?
2Алексей: Вы случайно не планируете описать настройку nfs4 и kerberos? Через sssd или winbind. Интересует для centos и ubuntu. У меня так и не получилось
Не планирую.
Советую еще попробовать PowerBroker Identity Services, Open Edition. Ранее известен как Likewise. Линукс в домен вводится вообще без плясок с бубном. Описание продукта и его возможностей https://habrahabr.ru/post/174407/
Добавил информацию о дополнительном сужении поиска учётных записей в лесу AD с несколькими доменами c помощью параметров subdomains_provider и ldap_idmap_default_domain_sid
Алексей, спасибо за статью.
Подскажите, а настройка сайтов в "AD Сайты и Службы" не решает проблему с выбором оптимального пути?
P. S. Столкнулся недавно с необходимостью изучения механизма выбора оптимального маршрута, а конкретнее каким образом "AD Сайты и Службы" передают этот маршрут клиенту. У меня клиент на windows начинал использовать новый маршрут только по прошествии часа, а то и на следующий день. Так и не нашел ответа на свой вопрос. Так что если есть статейка по глубокому изучению или траблшутингу сервиса "AD Сайты и Службы" буду благодарен.
Дело тут не в настройке AD, а в особенностях работы SSSD. Можете мне поверить на слово, что сайты AD у нас в инфраструктуре настроены в ресурсном поддомене как положено, однако механизм авто-обнаружения SSSD всё равно "ломится" в коневой домен и "бьётся головой" об его контроллеры. Поэтому я и пошёл по пути наименьшего сопротивления - отключил обнаружение доменов. По поводу настройки топологии сайтов AD материалов в интернете навалом, и даже на русском языке, так что не найти ответы на свои вопросы может наверно только ленивый.
Спасибо.
Ну я вроде бы не ленивый, находить находил, но вот почему-то все поверхностные. Поищу еще :)
Обратная ссылка: Дедупликация хранилища резервных копий виртуальных машин oVirt с помощью QUADStor Storage Virtualization на CentOS Linux 7.2 | Блог IT-KB /
Добавил информацию о расширении пула idmap при проблемах извлечения членства в группах в инфраструктурах с большим количеством групп/пользователей в домене ActiveDirectory
Обратная ссылка: Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM | Блог IT-KB /
поддержку NTLM на squid в связке с sssd не реализовать конечно, но вот авторизацию по Kerberos вполне реально через pam_auth и sssd
pam_auth — это хелпер Basic-аутентификации. Описал пример такой настройки в Вики: Xелпер basic_pam_auth для аутентификации пользователей Active Directory через связку PAM с SSSD
Обратная ссылка: Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 10. Аутентификация и авторизация пользователей Active Directory в Icinga Web 2 (Kerberos и SSO) | Блог IT-KB /
Статья хорошая, труда вложено очень много в нее, не понял только зачем в nsswitch.conf в строке shadow: compat sss нужен sss? и в строке netgroup: nis sss зачем нужен nis ? NIS клиент вы же не используете совместно с sssd, а для shadow я никогда не добавлял sss, какой в этом смысл? # getent shadow c sss и без него тот же самый будет.
Евгений, спасибо за отзыв. В содержимое nsswitch.conf, как и указано в статье, никаких правок мной не вносилось. Я лишь показал результирующий файл после того, как отработала команда "realm join".
Обратная ссылка: Обходное решение для ошибки регистрации servicePrincipalName (ATT_OR_VALUE_EXISTS) при подключении Debian GNU/Linux Jessie к домену Active Directory с помощью realm join — Блог IT-KB /
Обратная ссылка: Добавление SPN записей в keytab-файл (на стороне сервера Linux с помощью утилиты ktutil), связанный с учётной записью Computer в домене Active Directory — Блог IT-KB /
Спасибо за статью.
Немного хотелось дополнить по поводу sudo (libsss-sudo).
Указанные вами правило в файле /etc/sudoers.d/kom-srv-linux-admins можно не прописывать
на каждой машине, а указать в AD. В этом случае правила sudo будут централизованы и автоматически доступны для всех компьютеров в домене.
Для этого нужно будет добавить в конфигурацию следующее:
Для /etc/sssd/sssd.conf:
[sssd]
domains = ad.holding.com
config_file_version = 2
services = nss, pam, sodo
default_domain_suffix = ad.holding.com
[domain/ad.holding.com]
id_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://ad.holding.com
ldap_sudo_search_base = ou=sudoers,dc=ad,dc=holding,dc=com
…
Для /etc/nsswitch.conf:
sudoers: files sss
А ldif-файл для вашего правила будет такой:
dn: cn=kom-srv-linux-admins,ou=sudoers,dc=ad,dc=holding,dc=com
cn: kom-srv-linux-admins
objectclass: top
objectclass: sudoRole
sudocommand: ALL
sudohost: ALL
sudorunas: root
sudouser: %KOM-SRV-Linux-Admins@ad.holding.com
Возможно потребуется дополнительную прописать classShema для sudoRole.
как быть с апачем, мне надо добавить в кейтаб туда принципал с HTTP. Нужно отдельно настраивать kerberos, samba? Не получается сделать через SSSD так чтобы апаче аутентифицировал пользователей
Например так https://blog.it-kb.ru/2017/03/12/restricting-access-rights-to-the-linux-system-and-its-services-sshd-and-apache-through-active-directory-domain-security-groups-using-sssd-and-pam-pam_listfile/
Другие примеры можно найти на сайте по тэгу https://blog.it-kb.ru/tag/sssd/
Подскажите пожалуйста по пункту "Однако если вы захотите настроить Single sign-on (SSO)" Я например настроил sssd на ubuntu по вашей статье, а на сервере где стоит centos по вот этой статье https://www.dmosk.ru/instruktions.php?object=ssh-na-centos-7-cherez-active-directory , и там и там в sshd_config сделал# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
но всё равно просит пароля. Возможно на сервере тоже нужно установить krb5-user (workstation) или что-то еще?
LUbuntu 18.04, все отлично работает, но при выходе доменного пользователя из системы, не сохраняется последний логин. Каждый раз приходится вводить лог и пароль по новой. Не сталкивались с этим?
Добрый день!
Подскажите пожалуйста, пытаюсь настроить авторизацию на Debian 9 по вашей статье.
Я могу войти под учёткой администратора домена, но не могу под рядовым пользователем. И это касается и локального входа и SSH. Ограничений не вводил.
Подскажите куда копать?
На этапе "* Set computer password" происходит ошибка
"! Cannot set computer password: Authentication error",
"! Insufficient permissions to join the domain".
Подскажите какие требуется делегировать полномочия для учетной записи? Учетная запись имеет право добавлять машины в домен (создавать объект Компьютер).
Думаю, что этого должно быть достаточно на уровне отдельно взятого OU, в котором выполняется создание учётной записи компьютера или её обновление. Представленные ошибки как-бы говорят сами за себя и предполагают отсутствие таких прав. Возможно в проблеме роль играют какие-то доменные групповые политики, препятствующие выполнению необходимых операций.
Попробовал по Вашей статье настроить. Всё красиво. Но вот при большом количестве групп на учётке пользователя, id -a отрабатывает несколько минут.
В варианте winbind происходит так же, но оно хотя бы кеширует, и при повторном запуске выдаёт список за секунду. А вот sssd нет. Не сталкивались с таким? Есть какой-то способ это победить?
Настроил по вашей статье, все работает отлично, но при попытке войти в сетевую папку на Windows сервере просит ввести логин и пароль, можно ли как то привязать авторизацию для сетевых ресурсов?
Не под скажете как получить информацию о том в каких группах состоит КОМПЬЮТЕР? Ну по аналогии `id` или `getent group`. Информация нужна для выполнения своей реализации групповых политик.
# id ComputerName$
Блин, точно, очевидно же. Спасибо большое!