Kerberos оглавление
Установка сервера Kerberos
Настройка принципов службы Kerberos
Типы шифрования Kerberos
Настройте вторичный KDC
Базовая аутентификация рабочей станции
Kerberos с бэкэндом OpenLDAP
Сетевая аутентификация пользователя с SSSD
**********************************************************************************
Как установить сервер Kerberos
https://ubuntu.com/server/docs/how-to-install-a-kerberos-server
**********************************************************************************
Для этого обсуждения мы создадим домен MIT Kerberos со следующими характеристиками (отредактируйте их в соответствии с вашими потребностями):
- Первичный KDC: kdc01.example.com
- Вторичный KDC: kdc02.example.com
- Основной пользователь: ubuntu
- Администратор принципал: ubuntu/admin
Предварительные условия
Перед установкой сервера Kerberos необходимо правильно настроить DNS-сервер для вашего домена. Поскольку царство Kerberos (по соглашению) совпадает с именем домена, в этом разделе используется домен EXAMPLE.COM, настроенный в разделе "Основной сервер" документации по DNS
https://ubuntu.com/server/docs/domain-name-service-dns
Кроме того, Kerberos - это протокол, чувствительный ко времени. Если локальное системное время между клиентской машиной и сервером отличается более чем на пять минут (по умолчанию), рабочая станция не сможет пройти аутентификацию. Чтобы устранить эту проблему, все узлы должны синхронизировать время с помощью одного и того же сервера Network Time Protocol (NTP). Подробнее об этом читайте в главе NTP
https://ubuntu.com/server/docs/about-time-synchronisation
Установка пакетов Kerberos
Первым шагом в создании царства Kerberos является установка пакетов krb5-kdc и krb5-admin-server. В терминале введите:
Код: Выделить всё
sudo apt install krb5-kdc krb5-admin-server
В конце установки вас попросят предоставить имя хоста для серверов Kerberos и Admin для области, которая может быть или не быть одним и тем же сервером. Поскольку мы собираемся создать область и, следовательно, эти серверы, введите полное имя хоста этого сервера.
Примечание:
По умолчанию в качестве имени области будет использоваться доменное имя сервера Центра распределения ключей (KDC).
Далее создайте новое царство с помощью kdb5_newrealm utility:
Он попросит вас ввести главный пароль базы данных, который используется для шифрования локальной базы данных. Выберите надежный пароль: его надежность не проверяется.
Настройка сервера Kerberos
Вопросы, заданные во время установки, используются для настройки файлов /etc/krb5.conf и /etc/krb5kdc/kdc.conf. Первый используется библиотеками Kerberos 5, а второй настраивает KDC. Если вам нужно изменить настройки KDC, отредактируйте файл и перезапустите демон krb5-kdc. Если вам нужно переконфигурировать Kerberos с нуля, возможно, изменить имя царства, вы можете сделать это, набрав:
Примечание:
Руководство по krb5.conf находится в пакете krb5-doc.
Давайте создадим нашего первого принципала. Так как пока нет созданного принципала, нам нужно использовать kadmin.local, который использует локальный сокет UNIX для связи с KDC и требует привилегий root:
Код: Выделить всё
$ sudo kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: addprinc ubuntu
WARNING: no policy specified for ubuntu@EXAMPLE.COM; defaulting to no policy
Enter password for principal "ubuntu@EXAMPLE.COM":
Re-enter password for principal "ubuntu@EXAMPLE.COM":
Principal "ubuntu@EXAMPLE.COM" created.
kadmin.local: quit
Чтобы иметь возможность использовать kadmin удаленно, мы должны создать администратора. По правилам, это должен быть экземпляр администратора, так как это также упрощает создание общего списка контроля доступа (ACL). Давайте создадим экземпляр администратора для принципала ubuntu:
Код: Выделить всё
$ sudo kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: addprinc ubuntu/admin
WARNING: no policy specified for ubuntu/admin@EXAMPLE.COM; defaulting to no policy
Enter password for principal "ubuntu/admin@EXAMPLE.COM":
Re-enter password for principal "ubuntu/admin@EXAMPLE.COM":
Principal "ubuntu/admin@EXAMPLE.COM" created.
kadmin.local: quit
Далее новый администратор должен иметь соответствующие разрешения ACL. Разрешения настраиваются в файле /etc/krb5kdc/kadm5.acl:
Вы также можете использовать более общую форму для этого ACL :
Вышеописанное предоставит все привилегии любому экземпляру администратора принципала. Подробности смотрите на странице руководства kadm5.acl.
Теперь перезапустите krb5-admin-сервер, чтобы новый ACL вступил в силу:
Код: Выделить всё
sudo systemctl restart krb5-admin-server.service
Новый пользовательский принцип можно проверить с помощью утилиты kinit:
Код: Выделить всё
$ kinit ubuntu/admin
Password for ubuntu/admin@EXAMPLE.COM:
После ввода пароля воспользуйтесь утилитой klist, чтобы просмотреть информацию о билете (TGT):
Код: Выделить всё
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: ubuntu/admin@EXAMPLE.COM
Valid starting Expires Service principal
04/03/20 19:16:57 04/04/20 05:16:57 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 04/04/20 19:16:55
Где имя файла кэша krb5cc_1000 состоит из префикса krb5cc_ и идентификатора пользователя (UID), который в данном случае равен 1000.
kinit проверит файл /etc/krb5.conf, чтобы узнать, с каким KDC нужно связаться, и соответствующий адрес. KDC также можно найти через DNS-поиск по специальным TXT- и SRV-записям. Вы можете добавить эти записи в DNS-зону example.com:
Код: Выделить всё
_kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc01.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc01.example.com.
_kerberos._udp.EXAMPLE.COM. IN SRV 10 0 88 kdc02.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 10 0 88 kdc02.example.com.
_kerberos-adm._tcp.EXAMPLE.COM. IN SRV 1 0 749 kdc01.example.com.
_kpasswd._udp.EXAMPLE.COM. IN SRV 1 0 464 kdc01.example.com.
Подробные инструкции по настройке DNS см. в главе DNS.DNS
https://ubuntu.com/server/docs/domain-name-service-dns
Очень быстрый и полезный способ диагностики работы kinit - установить переменную окружения KRB5_TRACE в файл или stderr, и она покажет дополнительную информацию. Вывод будет довольно подробным:
Код: Выделить всё
$ KRB5_TRACE=/dev/stderr kinit ubuntu/admin
[2898] 1585941845.278578: Getting initial credentials for ubuntu/admin@EXAMPLE.COM
[2898] 1585941845.278580: Sending unauthenticated request
[2898] 1585941845.278581: Sending request (189 bytes) to EXAMPLE.COM
[2898] 1585941845.278582: Resolving hostname kdc01.example.com
(...)
Ваше новое царство Kerberos теперь готово аутентифицировать клиентов.
**********************************************************************************
Настройка принципов службы Kerberos
https://ubuntu.com/server/docs/how-to-configure-kerberos-service-principals
**********************************************************************************
Конкретные шаги по включению Kerberos для службы могут различаться, но в общем случае необходимо выполнить оба следующих действия:
- Принципал для службы - обычно service/host@REALM
- Ключевая таблица, доступная службе, где бы она ни работала - обычно в файле /etc/krb5.keytab.
Например, давайте создадим принципала для службы LDAP, запущенной на хосте ldap-server.example.com:
Код: Выделить всё
ubuntu@ldap-server:~$ sudo kadmin -p ubuntu/admin
Authenticating as principal ubuntu/admin with password.
Password for ubuntu/admin@EXAMPLE.COM:
kadmin: addprinc -randkey ldap/ldap-server.example.com
No policy specified for ldap/ldap-server.example.com@EXAMPLE.COM; defaulting to no policy
Principal "ldap/ldap-server.example.com@EXAMPLE.COM" created.
Давайте немного разберемся, что здесь происходит:
- Команда kadmin выполняется на машине с ldap-сервером, а не на Центре распределения ключей (KDC). Мы используем kadmin удаленно.
- Она выполняется с правами sudo. Причина этого станет понятна позже.
- Мы входим на сервер под именем ubuntu, но указываем имя администратора ubuntu/admin. Помните, что у принципала ubuntu нет никаких особых привилегий.
- Имя создаваемого нами принципала соответствует шаблону service/hostname.
- Чтобы выбрать случайный секрет, мы передаем параметр -randkey. В противном случае нам будет предложено ввести пароль.
После создания принципала нам нужно извлечь ключ из KDC и сохранить его на хосте ldap-сервера, чтобы служба ldap могла использовать его для аутентификации в KDC. Все еще в той же сессии kadmin:
Код: Выделить всё
kadmin: ktadd ldap/ldap-server.example.com
Entry for principal ldap/ldap-server.example.com with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal ldap/ldap-server.example.com with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Вот почему нам нужно запустить kadmin с помощью sudo: чтобы он мог записать файл /etc/krb5.keytab. Это системный файл keytab, который является файлом по умолчанию для всех ключей, которые могут понадобиться для служб на этом хосте, и мы можем перечислить их с помощью klist. Возвращаемся в оболочку:
Код: Выделить всё
$ sudo klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 ldap/ldap-server.example.com@EXAMPLE.COM
2 ldap/ldap-server.example.com@EXAMPLE.COM
Если на целевом узле нет утилиты kadmin, альтернативой может быть извлечение ключей на другом узле и в другой файл, а затем безопасная передача этого файла на целевой сервер. Например:
Код: Выделить всё
kadmin: ktadd -k /home/ubuntu/ldap.keytab ldap/ldap-server.example.com
Entry for principal ldap/ldap-server.example.com with kvno 3, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/home/ubuntu/ldap.keytab.
Entry for principal ldap/ldap-server.example.com with kvno 3, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/home/ubuntu/ldap.keytab.
Примечание:
Заметили, как в приведенном примере kvno изменился с 2 на 3 при использовании ktadd во второй раз? Это версия ключа, и она сделала недействительным ранее извлеченный ключ с kvno 2. Каждый раз, когда ключ извлекается с помощью ktadd, его версия увеличивается, и это делает недействительными предыдущие!
В этом случае, пока целевое расположение доступно для записи, вам даже не нужно запускать kadmin с sudo.
Затем используйте scp, чтобы перенести его на целевой хост:
Код: Выделить всё
$ scp /home/ubuntu/ldap.keytab ldap-server.example.com:
И скопируйте его в файл /etc/krb5.keytab, убедившись, что он находится в режиме 0600 и принадлежит root:root.
**********************************************************************************
Типы шифрования Kerberos
https://ubuntu.com/server/docs/kerberos-encryption-types
**********************************************************************************
Шифрование лежит в основе Kerberos, и он поддерживает несколько криптографических алгоритмов. Выбор по умолчанию достаточно хорош для большинства развертываний, но в конкретных ситуациях может потребоваться изменить эти настройки.
В этом документе описываются основные параметры конфигурации Kerberos, которые управляют выбором алгоритмов шифрования, используемых в развертывании Kerberos.
Конфигурация на стороне сервера
Существует два основных параметра конфигурации сервера, которые управляют типами шифрования, используемыми на сервере для его базы данных и коллекции или принципалов. Оба они находятся в файле /etc/krb5kdc/kdc.conf в разделе [realms] и выглядят следующим образом:
тип_мастер_ключа
Указывает тип ключа мастер-ключа. Он используется для шифрования базы данных, и по умолчанию используется aes256-cts-hmac-sha1-96.
поддерживаемые_типы
Указывает комбинации ключей/солей по умолчанию для принципалов этого царства. По умолчанию используется aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal, а типы шифрования должны быть перечислены в порядке предпочтения.
Возможные значения для алгоритмов шифрования перечислены в документации MIT по типам шифрования
https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/kdc_conf.html#encryption-types, а типы солей можно посмотреть в списках MIT keysalt
https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/kdc_conf.html#keysalt-lists
Вот пример, показывающий значения по умолчанию (другие настройки удалены для краткости):
Код: Выделить всё
[realms]
EXAMPLE.INTERNAL = {
(...)
master_key_type = aes256-cts
supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal
(...)
}
Мастер-ключ создается один раз для каждого царства, когда царство загружается. Обычно это делается с помощью инструмента krb5_newrealm (подробнее см. в разделе "Как установить сервер Kerberos"
https://ubuntu.com/server/docs/how-to-install-a-kerberos-server). Вы можете проверить тип мастер-ключа с помощью одной из этих команд на сервере KDC:
Код: Выделить всё
$ sudo kadmin.local
kadmin.local: getprinc K/M
Principal: K/M@EXAMPLE.INTERNAL
(...)
Number of keys: 1
Key: vno 1, aes256-cts-hmac-sha1-96
(...)
$ sudo klist -ke /etc/krb5kdc/stash
Keytab name: FILE:/etc/krb5kdc/stash
KVNO Principal
---- --------------------------------------------------------------------------
1 K/M@EXAMPLE.INTERNAL (aes256-cts-hmac-sha1-96)
При создании нового принципала Kerberos через сервис kadmind (с помощью утилит kadmin или kadmin.local), типы ключей шифрования, которые он получит, контролируются с помощью конфигурационного параметра supported_enctypes.
Например, давайте создадим принципала ubuntu и проверим ключи, которые были созданы для него (вывод сокращен):
Код: Выделить всё
$ sudo kadmin.local
Authenticating as principal root/admin@EXAMPLE.INTERNAL with password.
kadmin.local: addprinc ubuntu
No policy specified for ubuntu@EXAMPLE.INTERNAL; defaulting to no policy
Enter password for principal "ubuntu@EXAMPLE.INTERNAL":
Re-enter password for principal "ubuntu@EXAMPLE.INTERNAL":
Principal "ubuntu@EXAMPLE.INTERNAL" created.
kadmin.local: getprinc ubuntu
Principal: ubuntu@EXAMPLE.INTERNAL
(...)
Number of keys: 2
Key: vno 1, aes256-cts-hmac-sha1-96
Key: vno 1, aes128-cts-hmac-sha1-96
(...)
Для принципала ubuntu были созданы два ключа в соответствии с настройками по умолчанию supported_enctypes в kdc.conf для этого царства.
Примечание:
Конфиг сервера supported_enctypes содержит список типов ключей по умолчанию, которые создаются для принципала. Этот список относится к моменту создания принципала в kadmind. Изменение этой настройки постфактум не повлияет на ключи, которые будут у принципала после этого события. В частности, принципалы могут быть созданы с определенными типами ключей, независимо от настройки supported_enctypes. Смотрите параметр -e для команды kadmin add_principal.
Если бы в kdc.conf параметр supported_enctypes был установлен на aes256-sha2:normal aes128-sha2:normal camellia256-cts:normal, то директор ubuntu получил бы три типа ключей:
Код: Выделить всё
kadmin.local: getprinc ubuntu
Principal: ubuntu@EXAMPLE.INTERNAL
(...)
Number of keys: 3
Key: vno 1, aes256-cts-hmac-sha384-192
Key: vno 1, aes128-cts-hmac-sha256-128
Key: vno 1, camellia256-cts-cmac
Примечание:
Загрузка нового царства Kerberos с помощью команды krb5_newrealm также создает некоторые системные принципы, необходимые для Kerberos, такие как kadmin/admin, kadmin/changepw и другие. Все они также получат одинаковое количество ключей: по одному на каждый тип шифрования в supported_enctypes.
Конфигурация на стороне клиента
Когда мы говорим "клиентская сторона", мы на самом деле имеем в виду "приложения, связанные с библиотеками Kerberos". Они тоже находятся на сервере, так что имейте это в виду.
Типы шифрования, поддерживаемые библиотеками Kerberos, определяются в файле /etc/krb5.conf, в секции [libdefaults], с помощью параметра permitted_enctypes.
Пример:
Код: Выделить всё
[libdefaults]
(...)
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
Этот параметр содержит список имен типов шифрования, разделенных пробелами, в порядке предпочтения. Значение по умолчанию: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac.
Возможные значения алгоритмов шифрования перечислены в документации MIT (те же, что и для KDC).
https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/kdc_conf.html#encryption-types
Примечание:
В krb5.conf есть больше параметров, связанных с шифрованием, но большинство из них берут свои значения по умолчанию из permitted_enctypes. Дополнительные сведения см. в документации MIT libdefaults.
https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#libdefaults
Собираем все вместе
Когда клиент выполняет аутентификацию Kerberos и запрашивает билет у KDC, тип шифрования, используемый в этом билете, определяется путем выбора из общего набора:
- Типов шифрования, поддерживаемых сервером для данного принципала
- Типов шифрования, поддерживаемых клиентом.
Если нет общего алгоритма между тем, что принимает клиент, и тем, что может предложить сервер для этого конкретного принципала, то kinit потерпит неудачу.
Например, если принципал на сервере имеет:
Код: Выделить всё
kadmin.local: getprinc ubuntu
Principal: ubuntu@EXAMPLE.INTERNAL
(...)
Number of keys: 2
Key: vno 1, aes256-cts-hmac-sha384-192
Key: vno 1, aes128-cts-hmac-sha256-128
А в krb5.conf клиента есть:
Код: Выделить всё
permitted_enctypes = aes256-sha1 aes128-sha1
Тогда kinit потерпит неудачу, поскольку клиент поддерживает только варианты sha1, а сервер может предложить только sha2 для конкретного принципала, который запрашивает клиент:
Код: Выделить всё
$ kinit ubuntu
kinit: Generic error (see e-text) while getting initial credentials
В журнале сервера (journalctl -u krb5-admin-server.service) можно найти более подробную информацию об ошибке:
Код: Выделить всё
Apr 19 19:31:49 j-kdc krb5kdc[8597]: AS_REQ (2 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) fd42:78f4:b1c4:3964:216:3eff:feda:118c: GET_LOCAL_TGT: ubuntu@EXAMPLE.INTERNAL for krbtgt/EXAMPLE.INTERNAL@EXAMPLE.INTERNAL, No matching key in entry having a permitted enctype
В этом журнале говорится, что был запрос AS-REQ, который принял два типа шифрования, но в базе данных сервера не было подходящего типа ключа для этого принципала.
Изменение типов шифрования
Изменение типов шифрования в существующем царстве Kerberos - задача не из легких. Простое изменение параметров конфигурации не приведет ни к воссозданию существующих ключей, ни к добавлению новых. Изменения должны производиться поэтапно.
В MIT Kerberos есть руководство по обновлению типов шифрования, которое охватывает множество сценариев, включая развертывания с несколькими реплицирующими серверами:
Ссылки
Типы шифрования в MIT Kerberos
https://web.mit.edu/kerberos/krb5-latest/doc/admin/enctypes.html
Опции конфигурации krb5.conf, связанные с шифрованием
https://web.mit.edu/kerberos/krb5-latest/doc/admin/enctypes.html#configuration-variables
Переход от старых типов шифрования
https://web.mit.edu/kerberos/krb5-latest/doc/admin/enctypes.html#migrating-away-from-older-encryption-types
kdc.conf manpage
https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html
krb5.conf manpage
https://manpages.ubuntu.com/manpages/jammy/man5/krb5.conf.5.html
Концепции Kerberos V5
https://web.mit.edu/kerberos/krb5-latest/doc/basic/index.html
**********************************************************************************
Как настроить вторичный KDC
https://ubuntu.com/server/docs/how-to-set-up-a-secondary-kdc
**********************************************************************************
Если в вашей сети есть один центр распределения ключей (Key Distribution Center, KDC), то целесообразно иметь вторичный KDC на случай, если основной станет недоступен.
Кроме того, если клиенты Kerberos находятся в разных сетях (возможно, разделенных маршрутизаторами с использованием NAT), целесообразно разместить вторичный KDC в каждой из этих сетей.
Примечание:
Родной механизм репликации, описанный здесь, полагается на задание cron; по сути, он сбрасывает БД на первичном сервере и загружает ее обратно на вторичный. Возможно, вам стоит обратить внимание на использование бэкенда kldap, который может использовать механизм репликации OpenLDAP. Это объясняется ниже.
Установите необходимы пакеты
Сначала установите пакеты и, когда вас попросят указать имена серверов Kerberos и Admin, введите имя основного KDC:
Код: Выделить всё
sudo apt install krb5-kdc krb5-admin-server
После установки пакетов создайте хост-принципы для обоих KDC. В приглашении терминала введите:
Код: Выделить всё
$ kadmin -q "addprinc -randkey host/kdc01.example.com"
$ kadmin -q "addprinc -randkey host/kdc02.example.com"
Примечание:
Команда kadmin по умолчанию использует принципала типа username/
admin@EXAMPLE.COM, где username - ваш текущий пользователь оболочки. Если вам нужно отменить это, используйте -p <принцип, который вы хотите>.
Извлеките файл ключа для принципала kdc02, который является сервером, на котором мы находимся:
Код: Выделить всё
$ sudo kadmin -p ubuntu/admin -q "ktadd host/kdc02.example.com"
Далее на каждом KDC должен быть файл kpropd.acl, в котором перечислены все KDC для данного царства. Например, на первичном и вторичном KDC создайте файл /etc/krb5kdc/kpropd.acl:
Код: Выделить всё
host/kdc01.example.com@EXAMPLE.COM
host/kdc02.example.com@EXAMPLE.COM
Примечание:
Обычно разрешается использовать оба KDC, поскольку в случае выхода из строя одного из них может возникнуть желание поменять их роли. На такой случай оба KDC уже указаны здесь.
Создайте пустую базу данных на вторичном KDC:
Теперь установите демон kpropd, который прослушивает соединения от утилиты kprop с основного KDC:
Служба будет работать сразу после установки.
С терминала на основном KDC создайте файл дампа основной базы данных:
Код: Выделить всё
$ sudo kdb5_util dump /var/lib/krb5kdc/dump
Все еще находясь на первичном KDC, извлеките его ключ:
Код: Выделить всё
$ sudo kadmin.local -q "ktadd host/kdc01.example.com"
На первичном KDC запустите утилиту kprop, чтобы перенести созданный ранее дамп базы данных на вторичный KDC:
Код: Выделить всё
$ sudo kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.com
Database propagation to kdc02.example.com: SUCCEEDED
Обратите внимание на сообщение SUCCEEDED, которое сигнализирует о том, что распространение прошло успешно. Если появилось сообщение об ошибке, проверьте /var/log/syslog на вторичном KDC для получения дополнительной информации.
Вы также можете создать задание cron для периодического обновления базы данных на вторичном KDC. Например, следующее задание будет обновлять базу данных каждый час:
Код: Выделить всё
# m h dom mon dow command
0 * * * * root /usr/sbin/kdb5_util dump /var/lib/krb5kdc/dump && /usr/sbin/kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.com
Наконец, запустите демон krb5-kdc на вторичном KDC:
Примечание:
На вторичном KDC не работает сервер администратора, так как это копия, доступная только для чтения.
С этого момента вы можете указать оба сервера KDC в файле /etc/krb5.conf для царства EXAMPLE.COM на любом хосте, участвующем в этом царстве (включая kdc01 и kdc02), но помните, что сервер администратора может быть только один, и это тот, который работает на kdc01:
Код: Выделить всё
[realms]
EXAMPLE.COM = {
kdc = kdc01.example.com
kdc = kdc02.example.com
admin_server = kdc01.example.com
}
Теперь вторичный KDC должен иметь возможность выдавать билеты для данного царства. Вы можете проверить это, остановив демон krb5-kdc на первичном KDC, а затем используя kinit для запроса билета. Если все прошло нормально, вы должны получить билет от вторичного KDC. В противном случае проверьте /var/log/syslog и /var/log/auth.log на вторичном KDC.
**********************************************************************************
Как настроить базовую аутентификацию на рабочей станции
https://ubuntu.com/server/docs/how-to-set-up-basic-workstation-authentication
**********************************************************************************
В этом разделе мы рассмотрим настройку системы Linux в качестве клиента Kerberos. Это позволит получить доступ к любым "Kerber-ised" сервисам после того, как пользователь успешно войдет в систему.
Обратите внимание, что одного Kerberos недостаточно для существования пользователя в системе Linux. Мы не можем просто направить систему на сервер Kerberos и ожидать, что все пользователи Kerberos смогут войти в систему Linux, просто потому, что эти пользователи не существуют локально.
Kerberos обеспечивает только аутентификацию: он не знает о группах пользователей, идентификаторах Linux UID и GID, домашних каталогах и т. д. Обычно для получения этой информации используется другой сетевой источник, например, LDAP или сервер Windows, а в старые времена для этого использовался и NIS.
Настройка системы Linux в качестве клиента Kerberos
Если у вас есть локальные пользователи, соответствующие принципалам в царстве Kerberos, и вы просто хотите переключить аутентификацию с локальной на удаленную с помощью Kerberos, вы можете следовать этому разделу. Это не совсем обычный сценарий, но он служит для того, чтобы подчеркнуть разделение между аутентификацией пользователя и информацией о нем (полное имя, UID, GID, домашний каталог, группы и т. д.). Если вы просто хотите иметь возможность получать билеты и использовать их, достаточно установить krb5-user и запустить kinit.
Мы будем использовать sssd с небольшим ухищрением, чтобы он получал информацию о пользователях из локальных системных файлов, а не из удаленного источника, что является более распространенным случаем.
Установите необходимые пакеты
Для установки пакетов введите в приглашение терминала следующее:
Вам будет предложено ввести адреса ваших KDC и серверов администратора. Если вы следовали нашим руководствам по установке сервера Kerberos и настройке вторичного KDC, то KDC будут (через пробел):
И сервер администратора будет:
Помните, что kdc02 - это копия основного KDC, доступная только для чтения, поэтому на нем не работает сервер администратора.
Примечание:
Если вы добавили соответствующие SRV-записи в DNS, ни на одну из этих записей отвечать не нужно.
Настройка Kerberos
Если вы пропустили вопросы ранее, вы можете изменить конфигурацию пакета, чтобы заполнить их снова:
Вы можете проверить конфигурацию Kerberos, запросив билет с помощью утилиты kinit. Например:
Код: Выделить всё
$ kinit ubuntu
Password for ubuntu@EXAMPLE.COM:
Обратите внимание, что kinit не нужно, чтобы принципал существовал в системе как локальный пользователь. Фактически, вы можете указать любого директора. Если вы не укажете его, то инструмент будет использовать имя пользователя того, кто запускает kinit.
Настройка sssd
Единственная оставшаяся настройка - это настройка sssd. Создайте файл /etc/sssd/sssd.conf со следующим содержимым:
Код: Выделить всё
[sssd]
config_file_version = 2
services = pam
domains = example.com
[pam]
[domain/example.com]
id_provider = proxy
proxy_lib_name = files
auth_provider = krb5
krb5_server = kdc01.example.com,kdc02.example.com
krb5_kpasswd = kdc01.example.com
krb5_realm = EXAMPLE.COM
Приведенная выше конфигурация будет использовать Kerberos для аутентификации (auth_provider), но будет использовать локальных пользователей системы для информации о пользователях и группах (id_provider).
Отрегулируйте права доступа в файле конфигурации и запустите sssd:
Код: Выделить всё
$ sudo chown root:root /etc/sssd/sssd.conf
$ sudo chmod 0600 /etc/sssd/sssd.conf
$ sudo systemctl start sssd
Просто установив sssd и его зависимости, PAM уже будет настроен на использование sssd, с возможностью отката к локальной аутентификации пользователя. Чтобы попробовать, если это рабочая станция, просто переключите пользователей (в графическом интерфейсе), или откройте терминал входа (Ctrl-Alt-number), или вызовите оболочку входа с помощью sudo login, и попробуйте войти в систему, используя имя принципала Kerberos. Помните, что этот пользователь должен уже существовать в локальной системе:
Код: Выделить всё
$ sudo login
focal-krb5-client login: ubuntu
Password:
Welcome to Ubuntu Focal Fossa (development branch) (GNU/Linux 5.4.0-21-generic x86_64)
(...)
Last login: Thu Apr 9 21:23:50 UTC 2020 from 10.20.20.1 on pts/0
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_NlfnSX
Default principal: ubuntu@EXAMPLE.COM
Valid starting Expires Service principal
04/09/20 21:36:12 04/10/20 07:36:12 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 04/10/20 21:36:12
Сразу после входа в систему у вас уже будет билет Kerberos.
**********************************************************************************
Как настроить Kerberos с бэкэндом OpenLDAP
https://ubuntu.com/server/docs/how-to-set-up-kerberos-with-openldap-backend
**********************************************************************************
Kerberos поддерживает несколько различных бэкендов баз данных. По умолчанию (который мы использовали в других руководствах по Kerberos до сих пор) называется db2. В документации по типам баз данных показаны все варианты, один из которых - LDAP.
Зачем использовать LDAP?
Есть несколько причин, по которым принципы Kerberos должны храниться в LDAP, а не в локальной базе данных на диске. Есть также случаи, когда это не очень хорошая идея. Каждый сайт должен оценить все плюсы и минусы. Вот некоторые из них:
Репликация OpenLDAP быстрее и надежнее, чем родная Kerberos, основанная на задании cron.
Если вы уже настроили OpenLDAP для других целей, например для хранения пользователей и групп, добавление атрибутов Kerberos может быть полезным, обеспечивая интегрированную историю
Настройка бэкэнда LDAP не является тривиальной задачей, и администраторы без предварительных знаний OpenLDAP не должны пытаться ее выполнить.
Как отмечено в разделе LDAP о типах БД
https://web.mit.edu/kerberos/krb5-latest/doc/admin/dbtypes.html#ldap-module-kldap, поскольку krb5kdc является однопоточным, при использовании бэкенда OpenLDAP может наблюдаться повышенная задержка в обслуживании запросов.
В этом руководстве
В этом разделе мы настроим первичный и вторичный сервер Kerberos для использования OpenLDAP в качестве основной базы данных. Обратите внимание, что начиная с версии 1.18, Центр распределения ключей (KDC) от MIT Kerberos не поддерживает первичный KDC, использующий потребительский (вторичный) LDAP-сервер только для чтения. Здесь нужно учитывать, что первичный KDC работает в режиме чтения-записи, и ему нужен бэкэнд для чтения-записи. Вторичные KDC могут использовать бэкэнд как для чтения-записи, так и только для чтения, поскольку предполагается, что они будут работать только для чтения. Таким образом, существует только несколько возможных схем, которые мы можем использовать:
Первичный KDC подключен к первичному OpenLDAP
Вторичный KDC, подключенный как к первичному, так и к вторичному OpenLDAP
- Расширенный простой случай:
Несколько первичных KDC, подключенных к одному первичному OpenLDAP
Несколько вторичных KDC, подключенных к первичному и вторичному OpenLDAP
- OpenLDAP с мультимастерной репликацией:
Несколько первичных KDC, подключенных ко всем первичным серверам OpenLDAP
В этом руководстве мы не рассматривали мультимастерную репликацию OpenLDAP, поэтому покажем только простой случай. Второй сценарий является расширением: просто добавьте еще один первичный KDC, подключенный к тому же первичному серверу OpenLDAP.
Настройка OpenLDAP
Мы собираемся установить сервер OpenLDAP на том же хосте, что и KDC, чтобы упростить взаимодействие между ними. При такой установке мы можем использовать транспорт ldapi:///, который работает через сокет UNIX, и нам не нужно устанавливать SSL-сертификаты для защиты связи между службами Kerberos и OpenLDAP. Однако обратите внимание, что SSL все еще необходим для репликации OpenLDAP. Подробности смотрите в разделе LDAP с TLS.
Если вы хотите использовать существующий сервер OpenLDAP, это также возможно, но имейте в виду, что в этом случае вы должны использовать SSL для связи между KDC и этим сервером OpenLDAP.
Сначала необходимо загрузить необходимую схему на сервер OpenLDAP, который имеет сетевое подключение к первичному и вторичному KDC. Остальная часть этого раздела предполагает, что у вас также настроена репликация LDAP как минимум между двумя серверами. Информацию о настройке OpenLDAP смотрите в разделе Сервер OpenLDAP.
Примечание:
cn=admin,dc=example,dc=com - это пользователь-администратор по умолчанию, который создается во время установки пакета slapd (сервер OpenLDAP). Компонент домена будет изменен для вашего сервера, поэтому настройте его соответствующим образом.
Установите необходимые пакеты (предполагается, что OpenLDAP уже установлен) :
Код: Выделить всё
sudo apt install krb5-kdc-ldap krb5-admin-server
Затем извлеките файл kerberos.schema.gz:
Код: Выделить всё
sudo cp /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz /etc/ldap/schema/
sudo gunzip /etc/ldap/schema/kerberos.schema.gz
Схема Kerberos должна быть добавлена в дерево cn=config. Перед добавлением этот файл схемы необходимо преобразовать в формат LDIF. Для этого мы воспользуемся вспомогательным инструментом под названием schema2ldif, предоставляемым одноименным пакетом, который находится в архиве Universe:
Чтобы импортировать схему Kerberos, запустите:
Код: Выделить всё
$ sudo ldap-schema-manager -i kerberos.schema
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
executing 'ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/kerberos.ldif'
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=kerberos,cn=schema,cn=config"
Загрузив новую схему, давайте проиндексируем атрибут, часто используемый в поиске:
Код: Выделить всё
$ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// <<EOF
dn: olcDatabase={1}mdb,cn=config
add: olcDbIndex
olcDbIndex: krbPrincipalName eq,pres,sub
EOF
modifying entry "olcDatabase={1}mdb,cn=config"
Давайте создадим записи LDAP для административных сущностей Kerberos, которые будут обращаться к серверу OpenLDAP для выполнения операций. Их две:
- ldap_kdc_dn: должен иметь права на чтение контейнера realm, контейнера principal и поддеревьев realm. Однако если disable_last_success и disable_lockout не установлены, то ldap_kdc_dn должен иметь доступ на запись в контейнер Kerberos, как и администраторский DN ниже.
- ldap_kadmind_dn: должен иметь права чтения и записи на контейнер realm, контейнер principal и поддеревья realm.
Вот команда для создания этих сущностей:
Код: Выделить всё
$ ldapadd -x -D cn=admin,dc=example,dc=com -W <<EOF
dn: uid=kdc-service,dc=example,dc=com
uid: kdc-service
objectClass: account
objectClass: simpleSecurityObject
userPassword: {CRYPT}x
description: Account used for the Kerberos KDC
dn: uid=kadmin-service,dc=example,dc=com
uid: kadmin-service
objectClass: account
objectClass: simpleSecurityObject
userPassword: {CRYPT}x
description: Account used for the Kerberos Admin server
EOF
Enter LDAP Password:
adding new entry "uid=kdc-service,dc=example,dc=com"
adding new entry "uid=kadmin-service,dc=example,dc=com"
Теперь давайте установим для них пароль. Обратите внимание, что сначала инструмент запрашивает пароль для указанного DN пользователя, а затем пароль для DN cn=admin:
Код: Выделить всё
$ ldappasswd -x -D cn=admin,dc=example,dc=com -W -S uid=kdc-service,dc=example,dc=com
New password: <-- password you want for uid-kdc-service
Re-enter new password:
Enter LDAP Password: <-- password for the dn specified with the -D option
Повторите для uid=kadmin-service dn. Эти пароли понадобятся позже.
Вы можете проверить их с помощью ldapwhoami:
Код: Выделить всё
$ ldapwhoami -x -D uid=kdc-service,dc=example,dc=com -W
Enter LDAP Password:
dn:uid=kdc-service,dc=example,dc=com
Наконец, обновите списки контроля доступа (ACL). Это может быть непросто, поскольку сильно зависит от того, что вы уже определили. По умолчанию пакет slapd настраивает вашу базу данных со следующими ACL:
Код: Выделить всё
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
Нам нужно вставить новые правила перед заключительным to * by * read, чтобы контролировать доступ к записям и атрибутам, связанным с Kerberos:
Код: Выделить всё
$ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// <<EOF
dn: olcDatabase={1}mdb,cn=config
add: olcAccess
olcAccess: {2}to attrs=krbPrincipalKey
by anonymous auth
by dn.exact="uid=kdc-service,dc=example,dc=com" read
by dn.exact="uid=kadmin-service,dc=example,dc=com" write
by self write
by * none
-
add: olcAccess
olcAccess: {3}to dn.subtree="cn=krbContainer,dc=example,dc=com"
by dn.exact="uid=kdc-service,dc=example,dc=com" read
by dn.exact="uid=kadmin-service,dc=example,dc=com" write
by * none
EOF
modifying entry "olcDatabase={1}mdb,cn=config"
This will make the existing {2} rule become {4}. Check with sudo slapcat -b cn=config (the output below was reformatted a bit for clarity):
olcAccess: {0}to attrs=userPassword
by self write
by anonymous auth
by * none
olcAccess: {1}to attrs=shadowLastChange
by self write
by * read
olcAccess: {2}to attrs=krbPrincipalKey by anonymous auth
by dn.exact="uid=kdc-service,dc=example,dc=com" read
by dn.exact="uid=kadmin-service,dc=example,dc=com" write
by self write
by * none
olcAccess: {3}to dn.subtree="cn=krbContainer,dc=example,dc=com"
by dn.exact="uid=kdc-service,dc=example,dc=com" read
by dn.exact="uid=kadmin-service,dc=example,dc=com" write
by * none
olcAccess: {4}to * by * read
Теперь ваш каталог LDAP готов к использованию в качестве базы данных принципалов Kerberos.
Первичная конфигурация KDC (LDAP)
Когда OpenLDAP настроен, пришло время настроить KDC. В этом примере мы делаем это на том же сервере OpenLDAP, чтобы воспользоваться преимуществами локальной связи через сокеты UNIX.
При необходимости перенастройте пакет krb5-config, чтобы получить хорошую отправную точку с /etc/krb5.conf:
Теперь отредактируйте файл /etc/krb5.conf, добавив опцию database_module в раздел EXAMPLE.COM realm:
Код: Выделить всё
[realms]
EXAMPLE.COM = {
kdc = kdc01.example.com
kdc = kdc02.example.com
admin_server = kdc01.example.com
default_domain = example.com
database_module = openldap_ldapconf
}
Затем также добавьте эти новые разделы:
Код: Выделить всё
[dbdefaults]
ldap_kerberos_container_dn = cn=krbContainer,dc=example,dc=com
[dbmodules]
openldap_ldapconf = {
db_library = kldap
# if either of these is false, then the ldap_kdc_dn needs to
# have write access
disable_last_success = true
disable_lockout = true
# this object needs to have read rights on
# the realm container, principal container and realm sub-trees
ldap_kdc_dn = "uid=kdc-service,dc=example,dc=com"
# this object needs to have read and write rights on
# the realm container, principal container and realm sub-trees
ldap_kadmind_dn = "uid=kadmin-service,dc=example,dc=com"
ldap_service_password_file = /etc/krb5kdc/service.keyfile
ldap_servers = ldapi:///
ldap_conns_per_server = 5
}
Затем с помощью утилиты kdb5_ldap_util создайте реалм:
Код: Выделить всё
$ sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com create -subtrees dc=example,dc=com -r EXAMPLE.COM -s -H ldapi:///
Password for "cn=admin,dc=example,dc=com":
Initializing database for realm 'EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
Создайте тайник с паролями, используемыми для привязки к серверу LDAP. Запустите ее один раз для каждого ldap_kdc_dn и ldap_kadmin_dn:
Код: Выделить всё
sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f /etc/krb5kdc/service.keyfile uid=kdc-service,dc=example,dc=com
sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f /etc/krb5kdc/service.keyfile uid=kadmin-service,dc=example,dc=com
Примечание:
Файл /etc/krb5kdc/service.keyfile теперь содержит открытые текстовые версии паролей, используемых KDC для связи с сервером LDAP!
Создайте файл /etc/krb5kdc/kadm5.acl для сервера администратора, если вы этого еще не сделали:
Запустите Kerberos KDC и сервер администратора:
Код: Выделить всё
sudo systemctl start krb5-kdc.service krb5-admin-server.service
Теперь вы можете добавить принципалы Kerberos в базу данных LDAP, и они будут скопированы на все другие серверы LDAP, настроенные на репликацию. Чтобы добавить принципала с помощью утилиты kadmin.local, введите:
Код: Выделить всё
$ sudo kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: addprinc ubuntu
WARNING: no policy specified for ubuntu@EXAMPLE.COM; defaulting to no policy
Enter password for principal "ubuntu@EXAMPLE.COM":
Re-enter password for principal "ubuntu@EXAMPLE.COM":
Principal "ubuntu@EXAMPLE.COM" created.
kadmin.local:
Вышеописанное создаст ubuntu principal с DN krbPrincipalName=
ubuntu@EXAMPLE.COM,cn=EXAMPLE.COM,cn=krbContainer,dc=example,dc=com.
Допустим, однако, что у вас уже есть пользователь в каталоге, и он имеет имя uid=testuser1,ou=People,dc=example,dc=com. Как вы можете добавить ему атрибуты Kerberos? Вы используете параметр -x, чтобы указать местоположение. Чтобы ldap_kadmin_dn мог писать на него, нам сначала нужно обновить ACL:
Код: Выделить всё
$ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// <<EOF
dn: olcDatabase={1}mdb,cn=config
add: olcAccess
olcAccess: {4}to dn.subtree=“ou=People,dc=example,dc=com”
by dn.exact=”uid=kdc-service,dc=example,dc=com” read
by dn.exact=”uid=kadmin-service,dc=example,dc=com” write
by * break
EOF
И теперь мы можем указать новое местоположение:
Код: Выделить всё
$ sudo kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: addprinc -x dn=uid=testuser1,ou=People,dc=example,dc=com testuser1
WARNING: no policy specified for testuser1@EXAMPLE.COM; defaulting to no policy
Enter password for principal "testuser1@EXAMPLE.COM":
Re-enter password for principal "testuser1@EXAMPLE.COM":
Principal "testuser1@EXAMPLE.COM" created.
Поскольку указанный DN уже существует, kadmin.local просто добавит необходимые атрибуты Kerberos к этой существующей записи. Если такой записи не существует, она будет создана с нуля, только с атрибутами Kerberos, как в примере с ubuntu выше, но в указанном месте.
Примечание:
DN ldap_kadmin_dn (uid=kadmin-service в нашем примере) не имеет доступа на запись к месту, указанному параметром -x, вы получите ошибку Insufficient access.
Оба места видны для kinit, поскольку при создании царства с помощью kdb5_ldap_util были взяты значения по умолчанию для области поиска и базы: subtree и dc=example,dc=com.
Конфигурация вторичного KDC (LDAP)
Настройка вторичного KDC (и его реплики OpenLDAP) очень похожа. После настройки репликации OpenLDAP повторите эти шаги на вторичной машине:
- Установите krb5-kdc-ldap, ldap-utils. Не устанавливайте krb5-admin-server.
- Загрузите схему Kerberos с помощью schema2ldif.
- Добавьте индекс для krbPrincipalName.
- Первоначально настройте krb5.conf таким же образом. Если вы хотите, и если вы правильно настроили SSL, вы можете добавить ldaps://kdc01.example.com в список ldap_servers после ldapi:///, чтобы вторичный KDC мог иметь в своем распоряжении два бэкенда LDAP.
- НЕ запускайте kdb5_ldap_util. Нет необходимости создавать базу данных, поскольку она реплицируется с первичной.
- Скопируйте следующие файлы с первичного KDC и поместите их в то же место на вторичном:
/etc/krb5kdc/stash
/etc/krb5kdc/service.keyfile
- Запустите KDC: sudo systemctl start krb5-kdc.service
Ресурсы
Конфигурирование Kerberos с бэкэндом OpenLDAP
https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_ldap.html#conf-ldap
Типы бэкэндов MIT Kerberos
https://web.mit.edu/kerberos/krb5-latest/doc/admin/dbtypes.html
**********************************************************************************
Как настроить SSSD с Active Directory
https://ubuntu.com/server/docs/how-to-set-up-sssd-with-active-directory
**********************************************************************************
Как настроить SSSD с Active Directory
В этом разделе описывается использование SSSD для аутентификации входа пользователей в Active Directory с помощью "рекламного" провайдера SSSD. В конце пользователи Active Directory смогут входить на хост, используя свои учетные данные AD. Членство в группах также будет поддерживаться.
Групповые политики для Ubuntu
SSSD управляет аутентификацией пользователей и устанавливает начальные политики безопасности.
ADSys служит клиентом групповой политики для Ubuntu, упрощая настройку систем Ubuntu в среде Microsoft Active Directory. Если вас интересует поддержка групповых политик для Ubuntu, подробную информацию можно найти в документации ADSys.
Предпосылки и допущения
В этом руководстве не рассказывается о Active Directory, о том, как она работает, как ее настроить или как ее поддерживать. Предполагается, что рабочий домен Active Directory уже настроен и у вас есть доступ к учетным данным для подключения машины к этому домену.
- Контроллер домена выполняет:
Действует в качестве авторитетного DNS-сервера для домена.
Первичный DNS-резольвер (проверьте с помощью systemd-resolve --status).
- Системное время корректно и синхронизировано, поддерживается с помощью службы типа chrony или ntp.
- В данном примере используется домен ad1.example.com .
Установите необходимое программное обеспечение
Установите следующие пакеты:
Код: Выделить всё
sudo apt install sssd-ad sssd-tools realmd adcli
Мы будем использовать команду realm из пакета realmd для присоединения к домену и создания конфигурации SSSD.
Убедимся, что домен можно обнаружить через DNS:
Код: Выделить всё
$ sudo realm -v discover ad1.example.com
* Resolving: _ldap._tcp.ad1.example.com
* Performing LDAP DSE lookup on: 10.51.0.5
* Successfully discovered: ad1.example.com
ad1.example.com
type: kerberos
realm-name: AD1.EXAMPLE.COM
domain-name: ad1.example.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
Она выполняет несколько проверок и определяет наилучший стек программного обеспечения для использования с SSSD. SSSD может установить недостающие пакеты через packagekit, но мы уже установили их на предыдущем шаге.
Теперь давайте присоединимся к домену:
Код: Выделить всё
$ sudo realm join ad1.example.com
Password for Administrator:
Все прошло довольно гладко. Если вы хотите посмотреть, что он делал, передайте опцию -v:
Код: Выделить всё
$ sudo realm join -v ad1.example.com
* Resolving: _ldap._tcp.ad1.example.com
* Performing LDAP DSE lookup on: 10.51.0.5
* Successfully discovered: ad1.example.com
Password for Administrator:
* Unconditionally checking packages
* Resolving required packages
* LANG=C /usr/sbin/adcli join --verbose --domain ad1.example.com --domain-realm AD1.EXAMPLE.COM --domain-controller 10.51.0.5 --login-type user --login-user Administrator --stdin-password
* Using domain name: ad1.example.com
* Calculated computer account name from fqdn: AD-CLIENT
* Using domain realm: ad1.example.com
* Sending NetLogon ping to domain controller: 10.51.0.5
* Received NetLogon info from: SERVER1.ad1.example.com
* Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-hUfTUg/krb5.d/adcli-krb5-conf-hv2kzi
* Authenticated as user: Administrator@AD1.EXAMPLE.COM
* Looked up short domain name: AD1
* Looked up domain SID: S-1-5-21-2660147319-831819607-3409034899
* Using fully qualified name: ad-client.ad1.example.com
* Using domain name: ad1.example.com
* Using computer account name: AD-CLIENT
* Using domain realm: ad1.example.com
* Calculated computer account name from fqdn: AD-CLIENT
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Found computer account for AD-CLIENT$ at: CN=AD-CLIENT,CN=Computers,DC=ad1,DC=example,DC=com
* Sending NetLogon ping to domain controller: 10.51.0.5
* Received NetLogon info from: SERVER1.ad1.example.com
* Set computer password
* Retrieved kvno '3' for computer account in directory: CN=AD-CLIENT,CN=Computers,DC=ad1,DC=example,DC=com
* Checking RestrictedKrbHost/ad-client.ad1.example.com
* Added RestrictedKrbHost/ad-client.ad1.example.com
* Checking RestrictedKrbHost/AD-CLIENT
* Added RestrictedKrbHost/AD-CLIENT
* Checking host/ad-client.ad1.example.com
* Added host/ad-client.ad1.example.com
* Checking host/AD-CLIENT
* Added host/AD-CLIENT
* Discovered which keytab salt to use
* Added the entries to the keytab: AD-CLIENT$@AD1.EXAMPLE.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/AD-CLIENT@AD1.EXAMPLE.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/ad-client.ad1.example.com@AD1.EXAMPLE.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/AD-CLIENT@AD1.EXAMPLE.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/ad-client.ad1.example.com@AD1.EXAMPLE.COM: FILE:/etc/krb5.keytab
* /usr/sbin/update-rc.d sssd enable
* /usr/sbin/service sssd restart
* Successfully enrolled machine in realm
По умолчанию realm будет использовать учетную запись "Администратор" домена для запроса присоединения. Если вам нужно использовать другую учетную запись, передайте ее инструменту с помощью опции -U.
Другой популярный способ присоединения к домену - использование токена с одноразовым паролем (OTP). Для этого используйте параметр --one-time-password.
Конфигурация SSSD
Инструмент realm уже позаботился о создании конфигурации SSSD, добавлении модулей PAM и NSS и запуске необходимых служб.
Давайте посмотрим на файл /etc/sssd/sssd.conf:
Код: Выделить всё
[sssd]
domains = ad1.example.com
config_file_version = 2
services = nss, pam
[domain/ad1.example.com]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = AD1.EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = ad1.example.com
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
Примечание:
Очень важно помнить, что этот файл должен иметь права 0600 и принадлежность root:root, иначе SSSD не запустится!
Давайте выделим несколько моментов из этого файла конфигурации:
- cache_credentials: Это позволяет входить в систему, когда сервер AD недоступен
- fallback_homedir: Домашняя директория. По умолчанию это /home/<user>@<domain>. Например, пользователь AD john будет иметь домашний каталог /home/john@ad1.example.com.
- use_fully_qualified_names: Пользователи будут иметь форму user@domain, а не просто user. Этот параметр следует изменять только в том случае, если вы уверены, что никакие другие домены никогда не присоединятся к лесу AD через одно из нескольких возможных доверительных отношений.
Автоматическое создание домашнего каталога
Что инструмент realm не сделал для нас, так это настройку pam_mkhomedir, чтобы пользователи сети могли получить домашний каталог при входе в систему. Этот оставшийся шаг можно выполнить, выполнив следующую команду:
Проверка нашей установки
Теперь вы должны иметь возможность получать информацию о пользователях AD. В этом примере Джон Смит является пользователем AD:
Код: Выделить всё
$ getent passwd john@ad1.example.com
john@ad1.example.com:*:1725801106:1725800513:John Smith:/home/john@ad1.example.com:/bin/bash
Давайте посмотрим на его группы
Код: Выделить всё
$ groups john@ad1.example.com
john@ad1.example.com : domain users@ad1.example.com engineering@ad1.example.com
Примечание:
Если вы только что изменили членство пользователя в группе, может пройти некоторое время, прежде чем SSSD заметит это из-за кэширования.
Наконец, попробуем войти в систему:
Код: Выделить всё
$ sudo login
ad-client login: john@ad1.example.com
Password:
Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-24-generic x86_64)
...
Creating directory '/home/john@ad1.example.com'.
john@ad1.example.com@ad-client:~$
Обратите внимание, что домашний каталог был создан автоматически.
Вы также можете использовать SSH, но обратите внимание, что команда будет выглядеть немного забавно из-за множества знаков @:
Код: Выделить всё
$ ssh john@ad1.example.com@10.51.0.11
Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-24-generic x86_64)
(...)
Last login: Thu Apr 16 21:22:55 2020
john@ad1.example.com@ad-client:~$
Примечание:
В примере SSH использовалась аутентификация с открытым ключом, поэтому пароль не требовался. Помните, что по умолчанию в файле /etc/ssh/sshd_config аутентификация по паролю SSH отключена.
Билеты Kerberos
Если вы установите krb5-user, ваши пользователи AD также получат билет Kerberos при входе в систему:
Код: Выделить всё
john@ad1.example.com@ad-client:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1725801106_9UxVIz
Default principal: john@AD1.EXAMPLE.COM
Valid starting Expires Service principal
04/16/20 21:32:12 04/17/20 07:32:12 krbtgt/AD1.EXAMPLE.COM@AD1.EXAMPLE.COM
renew until 04/17/20 21:32:12
Примечание:
Realm также настроил /etc/krb5.conf для вас, поэтому при установке krb5-user не должно быть дополнительных запросов на настройку.
Давайте протестируем smbclient, используя аутентификацию Kerberos для получения списка общих ресурсов контроллера домена:
Код: Выделить всё
john@ad1.example.com@ad-client:~$ smbclient -k -L server1.ad1.example.com
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
SMB1 disabled -- no workgroup available
Обратите внимание, что теперь у нас есть билет для службы cifs, которая использовалась для списка ресурсов выше:
Код: Выделить всё
john@ad1.example.com@ad-client:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1725801106_9UxVIz
Default principal: john@AD1.EXAMPLE.COM
Valid starting Expires Service principal
04/16/20 21:32:12 04/17/20 07:32:12 krbtgt/AD1.EXAMPLE.COM@AD1.EXAMPLE.COM
renew until 04/17/20 21:32:12
04/16/20 21:32:21 04/17/20 07:32:12 cifs/server1.ad1.example.com@AD1.EXAMPLE.COM
При входе в систему на рабочем столе в списке для выбора отображаются только локальные пользователи, и это сделано специально.
Чтобы впервые войти в систему с пользователем Active Directory, выполните следующие действия:
Нажмите на опцию "Нет в списке?":
Введите имя пользователя, а затем пароль:
При следующем входе в систему пользователь AD будет указан как локальный пользователь:
Известные проблемы
При входе в систему, объединенную с доменом Active Directory, sssd (пакет, отвечающий за эту интеграцию) будет пытаться применить групповые политики по умолчанию. В некоторых случаях, если определенная политика отсутствует, вход в систему будет запрещен.
Это отслеживается в ошибке #1934997
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1934997. Пока исправление не станет доступным, смотрите комментарий #5
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1934997/comments/5 в этом сообщении об ошибке для существующих обходных путей.
Дополнительное чтиво
Проект SSSD на GitHub
https://github.com/SSSD/sssd
Записи зоны DNS Active Directory
https://technet.microsoft.com/en-us/library/cc759550%28v=ws.10%29.aspx
**********************************************************************************
Как настроить SSSD с помощью LDAP
https://ubuntu.com/server/docs/how-to-set-up-sssd-with-ldap
**********************************************************************************
Как настроить SSSD с помощью LDAP
SSSD также может использовать LDAP для аутентификации, авторизации и информации о пользователях/группах. В этом разделе мы настроим хост на аутентификацию пользователей из каталога OpenLDAP.
Необходимые условия и допущения
Для этой настройки нам потребуется:
Существующий сервер OpenLDAP с включенным SSL и использующий схему RFC2307 для пользователей и групп.
Клиентский хост, на котором мы установим необходимые инструменты и войдем в систему как пользователь с LDAP-сервера
Установите необходимое программное обеспечение
Установите следующие пакеты:
Настройка SSSD
Создайте конфигурационный файл /etc/sssd/sssd.conf с правами 0600 и владением root:root и добавьте в него следующее содержимое:
Код: Выделить всё
[sssd]
config_file_version = 2
domains = example.com
[domain/example.com]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap01.example.com
cache_credentials = True
ldap_search_base = dc=example,dc=com
Обязательно запустите службу sssd:
Примечание:
По умолчанию sssd будет использовать START_TLS для запросов аутентификации на LDAP-сервере (auth_provider), но не для id_provider. Если вы хотите также включить START_TLS для id_provider, укажите ldap_id_use_start_tls = true.
Автоматическое создание домашнего каталога
Чтобы включить автоматическое создание домашнего каталога, выполните следующую команду:
Проверьте настройку SSL на клиенте
Клиент должен иметь возможность использовать START_TLS при подключении к LDAP-серверу, с полной проверкой сертификата. Это означает:
- Клиентский хост знает и доверяет CA, подписавшему сертификат сервера LDAP,
- Сертификат сервера был выпущен для правильного хоста (ldap01.example.com в данном руководстве),
- Время корректно на всех узлах, выполняющих TLS-соединение, и
- Ни один из сертификатов (CA или сервера) не истек.
Если используется пользовательский CA, простой способ заставить хост доверять ему - поместить его в /usr/local/share/ca-certificates/ с расширением .crt и выполнить команду sudo update-ca-certificates.
В качестве альтернативы можно отредактировать файл /etc/ldap/ldap.conf и указать TLS_CACERT на файл открытого ключа ЦС.
Примечание:
Возможно, вам придется перезапустить sssd после этих изменений: sudo systemctl restart sssd
Как только это все будет сделано, убедитесь, что вы можете подключиться к серверу LDAP с помощью проверенных соединений SSL :
Код: Выделить всё
$ ldapwhoami -x -ZZ -H ldap://ldap01.example.com
anonymous
и для ldaps (если включено в /etc/default/slapd):
Код: Выделить всё
$ ldapwhoami -x -H ldaps://ldap01.example.com
Параметр -ZZ указывает инструменту использовать START_TLS и не допустить сбоя. Если на сервере включено протоколирование LDAP, то будет показано примерно следующее:
Код: Выделить всё
slapd[779]: conn=1032 op=0 STARTTLS
slapd[779]: conn=1032 op=0 RESULT oid= err=0 text=
slapd[779]: conn=1032 fd=15 TLS established tls_ssf=256 ssf=256
slapd[779]: conn=1032 op=1 BIND dn="" method=128
slapd[779]: conn=1032 op=1 RESULT tag=97 err=0 text=
slapd[779]: conn=1032 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.3
slapd[779]: conn=1032 op=2 WHOAMI
slapd[779]: conn=1032 op=2 RESULT oid= err=0 text=
START_TLS с err=0 и установленным TLS - вот что мы хотим там увидеть, и, конечно же, расширенную операцию WHOAMI.
Окончательная проверка
В этом примере на LDAP-сервере есть следующие записи пользователей и групп, которые мы будем использовать для тестирования:
Код: Выделить всё
dn: uid=john,ou=People,dc=example,dc=com
uid: john
objectClass: inetOrgPerson
objectClass: posixAccount
cn: John Smith
sn: Smith
givenName: John
mail: john@example.com
userPassword: johnsecret
uidNumber: 10001
gidNumber: 10001
loginShell: /bin/bash
homeDirectory: /home/john
dn: cn=john,ou=Group,dc=example,dc=com
cn: john
objectClass: posixGroup
gidNumber: 10001
memberUid: john
dn: cn=Engineering,ou=Group,dc=example,dc=com
cn: Engineering
objectClass: posixGroup
gidNumber: 10100
memberUid: john
Имя пользователя должно быть известно системе:
Код: Выделить всё
ubuntu@ldap-client:~$ getent passwd john
john:*:10001:10001:John Smith:/home/john:/bin/bash
ubuntu@ldap-client:~$ id john
uid=10001(john) gid=10001(john) groups=10001(john),10100(Engineering)
И мы должны быть в состоянии аутентифицироваться как john:
Код: Выделить всё
ubuntu@ldap-client:~$ sudo login
ldap-client login: john
Password:
Welcome to Ubuntu Focal Fossa (development branch) (GNU/Linux 5.4.0-24-generic x86_64)
(...)
Creating directory '/home/john'.
john@ldap-client:~$
**********************************************************************************
Как настроить SSSD с помощью LDAP и Kerberos
https://ubuntu.com/server/docs/how-to-set-up-sssd-with-ldap-and-kerberos
**********************************************************************************
Как настроить SSSD с помощью LDAP и Kerberos
С помощью SSSD мы можем создать систему, очень похожую на Active Directory с точки зрения используемых технологий: использование LDAP для пользователей и групп и Kerberos для аутентификации.
Необходимые условия и допущения
Для этой установки нам понадобятся:
Существующий сервер OpenLDAP, использующий схему RFC2307 для пользователей и групп. Поддержка SSL рекомендуется, но не является обязательной, поскольку аутентификация в этой установке будет осуществляться через Kerberos, а не через LDAP.
Сервер Kerberos. Он не обязательно должен использовать бэкэнд OpenLDAP.
Клиентский хост, на котором мы установим и настроим SSSD.
Установите необходимое программное обеспечение
На клиентском узле установите следующие пакеты:
Код: Выделить всё
sudo apt install sssd-ldap sssd-krb5 ldap-utils krb5-user
Вас могут спросить о стандартном царстве Kerberos. В этом руководстве мы используем EXAMPLE.COM.
На данном этапе вы уже должны иметь возможность получать билеты с вашего сервера Kerberos, если DNS-записи указывают на него:
Код: Выделить всё
$ kinit ubuntu
Password for ubuntu@EXAMPLE.COM:
ubuntu@ldap-krb-client:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: ubuntu@EXAMPLE.COM
Valid starting Expires Service principal
04/17/20 19:51:06 04/18/20 05:51:06 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 04/18/20 19:51:05
Но мы хотим иметь возможность входить в систему как пользователь LDAP, аутентифицированный через Kerberos. Давайте продолжим настройку.
Настройка SSSD
Создайте конфигурационный файл /etc/sssd/sssd.conf с правами 0600 и владением root:root и добавьте в него следующее содержимое:
Код: Выделить всё
[sssd]
config_file_version = 2
domains = example.com
[domain/example.com]
id_provider = ldap
ldap_uri = ldap://ldap01.example.com
ldap_search_base = dc=example,dc=com
auth_provider = krb5
krb5_server = kdc01.example.com,kdc02.example.com
krb5_kpasswd = kdc01.example.com
krb5_realm = EXAMPLE.COM
cache_credentials = True
В этом примере используется два KDC, поэтому необходимо также указать сервер krb5_kpasswd, поскольку второй KDC является репликой и не запускает сервер администратора.
Запустите службу sssd:
Автоматическое создание домашнего каталога
Чтобы включить автоматическое создание домашнего каталога, выполните следующую команду:
Окончательная проверка
В этом примере на сервере LDAP имеются следующие записи пользователей и групп, которые мы будем использовать для тестирования:
Код: Выделить всё
dn: uid=john,ou=People,dc=example,dc=com
uid: john
objectClass: inetOrgPerson
objectClass: posixAccount
cn: John Smith
sn: Smith
givenName: John
mail: john@example.com
uidNumber: 10001
gidNumber: 10001
loginShell: /bin/bash
homeDirectory: /home/john
dn: cn=john,ou=Group,dc=example,dc=com
cn: john
objectClass: posixGroup
gidNumber: 10001
memberUid: john
dn: cn=Engineering,ou=Group,dc=example,dc=com
cn: Engineering
objectClass: posixGroup
gidNumber: 10100
memberUid: john
Обратите внимание, что у пользователя john нет атрибута userPassword.
Пользователь john должен быть известен системе:
Код: Выделить всё
ubuntu@ldap-client:~$ getent passwd john
john:*:10001:10001:John Smith:/home/john:/bin/bash
ubuntu@ldap-client:~$ id john
uid=10001(john) gid=10001(john) groups=10001(john),10100(Engineering)
Давайте попробуем войти в систему под этим пользователем:
Код: Выделить всё
ubuntu@ldap-krb-client:~$ sudo login
ldap-krb-client login: john
Password:
Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-24-generic x86_64)
(...)
Creating directory '/home/john'.
john@ldap-krb-client:~$ klist
Ticket cache: FILE:/tmp/krb5cc_10001_BOrxWr
Default principal: john@EXAMPLE.COM
Valid starting Expires Service principal
04/17/20 20:29:50 04/18/20 06:29:50 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 04/18/20 20:29:50
john@ldap-krb-client:~$
Мы вошли в систему, используя пароль Kerberos и информацию о пользователях/группах с сервера LDAP.
Подмена SSSD и KDC
При использовании SSSD для управления логинами Kerberos на Linux-хосте существует сценарий атаки, о котором следует знать: Подмена KDC.
Цель злоумышленника - войти на рабочую станцию, использующую аутентификацию Kerberos. Допустим, они знают, что на этой машине есть действительный пользователь john.
Сначала злоумышленник развертывает в сети неавторизованный сервер Key Distribution Center (KDC) и создает на нем имя john с паролем по выбору злоумышленника. Теперь злоумышленник должен заставить свой неавторизованный KDC ответить на запрос входа в систему с рабочей станции до (или вместо) настоящего KDC. Если рабочая станция не проверяет подлинность KDC, она примет ответ от неавторизованного сервера и впустит Джона.
Существует параметр конфигурации, который можно установить для защиты рабочей станции от этого типа атак. Он заставит SSSD проверять подлинность KDC и блокировать вход, если KDC не может быть проверен. Этот параметр называется krb5_validate, и по умолчанию он равен false.
Чтобы включить ее, отредактируйте файл /etc/sssd/sssd.conf и добавьте эту строку в раздел домена:
Код: Выделить всё
[sssd]
config_file_version = 2
domains = example.com
[domain/example.com]
id_provider = ldap
...
krb5_validate = True
Второй шаг - создание принципала хоста на KDC для этой рабочей станции. Так проверяется подлинность KDC. Это как "учетная запись машины" с общим секретом, который злоумышленник не может контролировать и воспроизвести в неавторизованном KDC. Принцип хоста имеет формат host/<fqdn>@REALM.
После создания принципала хоста его keytab должна быть сохранена на рабочей станции. Этот двухэтапный процесс можно легко выполнить на самой рабочей станции с помощью kadmin (не kadmin.local) для удаленного обращения к KDC:
Код: Выделить всё
$ sudo kadmin -p ubuntu/admin
kadmin: addprinc -randkey host/ldap-krb-client.example.com@EXAMPLE.COM
WARNING: no policy specified for host/ldap-krb-client.example.com@EXAMPLE.COM; defaulting to no policy
Principal "host/ldap-krb-client.example.com@EXAMPLE.COM" created.
kadmin: ktadd -k /etc/krb5.keytab host/ldap-krb-client.example.com
Entry for principal host/ldap-krb-client.example.com with kvno 6, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/ldap-krb-client.example.com with kvno 6, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.
Затем выйдите из утилиты и убедитесь, что разрешения на файл keytab жесткие:
Код: Выделить всё
sudo chmod 0600 /etc/krb5.keytab
sudo chown root:root /etc/krb5.keytab
Вы также можете сделать это на самом KDC с помощью kadmin.local, но вам придется временно хранить keytab в другом файле и безопасно скопировать ее на рабочую станцию.
После выполнения этих шагов можно перезапустить SSSD на рабочей станции и выполнить вход. Если неавторизованный KDC заметит попытку и ответит, он не пройдет проверку хоста. С помощью отладки мы можем увидеть, как это происходит на рабочей станции:
Код: Выделить всё
==> /var/log/sssd/krb5_child.log <==
(Mon Apr 20 19:43:58 2020) [[sssd[krb5_child[2102]]]] [validate_tgt] (0x0020): TGT failed verification using key for [host/ldap-krb-client.example.com@EXAMPLE.COM].
(Mon Apr 20 19:43:58 2020) [[sssd[krb5_child[2102]]]] [get_and_save_tgt] (0x0020): 1741: [-1765328377][Server host/ldap-krb-client.example.com@EXAMPLE.COM not found in Kerberos database]
И вход в систему запрещен. Однако если реальный KDC принимает его, проверка хоста проходит успешно:
Код: Выделить всё
==> /var/log/sssd/krb5_child.log <==
(Mon Apr 20 19:46:22 2020) [[sssd[krb5_child[2268]]]] [validate_tgt] (0x0400): TGT verified using key for [host/ldap-krb-client.example.com@EXAMPLE.COM].
И логин принят.
**********************************************************************************
Устранение неполадок SSSD
https://ubuntu.com/server/docs/troubleshooting-sssd
**********************************************************************************
Вот несколько советов по устранению неполадок в SSSD.
уровень отладки
Уровень отладки SSSD можно изменить "на лету" с помощью sssctl из пакета sssd-tools:
Код: Выделить всё
sudo apt install sssd-tools
sssctl debug-level <new-level>
Или добавьте его в файл конфигурации и перезапустите SSSD :
Код: Выделить всё
[sssd]
config_file_version = 2
domains = example.com
[domain/example.com]
debug_level = 6
...
Любой из этих подходов запишет больше информации в файлы журналов в /var/log/sssd/*.log и поможет определить, что происходит. Преимущество подхода с использованием sssctl заключается в отсутствии необходимости перезапускать службу.
Кэширование
Кэширование полезно для ускорения работы, но оно может сильно мешать при устранении неполадок. Полезно иметь возможность удалить кэш во время поиска проблемы. Это также можно сделать с помощью инструмента sssctl из пакета sssd-tools.
Вы можете удалить весь кэш:
Код: Выделить всё
# sssctl cache-remove
Creating backup of local data...
SSSD backup of local data already exists, override? (yes/no) [no] yes
Removing cache files...
SSSD= needs to be running. Start SSSD now? (yes/no) [yes] yes
Или только один элемент:
Или же истечь срок годности всего:
DNS
Kerberos довольно чувствителен к проблемам с DNS. Если вы подозреваете, что что-то связано с DNS, вот два предложения:
Убедитесь, что hostname -f возвращает полностью определенное доменное имя (FQDN). При необходимости задайте его в файле /etc/hostname или используйте sudo hostnamectl set-hostname <fqdn>, чтобы задать его во время выполнения.
Вы можете попробовать отключить обратный поиск имен по умолчанию, который выполняют библиотеки krb5, отредактировав (или создав) файл /etc/krb5.conf и установив rdns = false в разделе [libdefaults]: