Для эффективного управления ИТ инфраструктурой со службой каталогов, необходимо хорошо разбираться в вопросах аутентификации в домене. Это справедливо как для среды MS Active Directory, так и в ALD Pro. Однако, как правило, порог знаний для работы в среде Microsoft Windows несколько ниже чем в среде Linux, что применимо и для службы каталогов. Кроме того, инструменты и средства взаимодействия между контроллером домена и членами домена (служба sssd) совсем не похожи на те, что используются в Microsoft Active Directory и Window.
Способы аутентификации в домене
Служба каталога «ALD Pro» построена на базе FreeIPA и поддерживает три вида аутентификации:
- LDAP Bind
- Kerberos
- Частично NTLM.
---------------------------------------------------------------------------------------------
Аутентификация по протоколу LDAP
- Клиент отправляет запрос BIND, который содержит учетные данные (имя пользователя и пароль в открытом виде).
- Контроллер домена приняв и проверив эти данные пересылает их приложению (BIND ответ).
- Пользователь через приложение отправляет поисковый запрос, опрашивая весь домен.
- Сервер каталогов возвращает приложению результаты поиска. После чего приложение отображает полученную информацию пользователю.
- Клиентское приложение отправляет запрос UNBIND серверу каталогов и закрывает соединение.
Простая аутентификация или привязка (bind) является самым распространенным, но при этом не самым безопасным способом аутентификации, т.к. пароль передается на сервер открытым текстом. Поэтому во избежание разглашения учетных данных при выполнении авторизованных LDAP-запросов с использованием простой аутентификации рекомендуется всегда использовать шифрованный протокол LDAPS (шифрованный канал) или включать StartTLS (шифрование внутри нешифрованного канала):
ldapsearch -H ldaps://dc1.ald.local -D 'uid=admin,cn=users,cn=accounts,dc=ald,dc=local' -W
А также командой с ключом -ZZ (защита с использованием StartTLS):
ldapsearch -H ldap://dc1.ald.local -ZZ -D 'uid=admin,cn=users,cn=accounts,dc=ald,dc=local' -W
где
- параметр -W – запрос пароля привязки
- параметр -H – для указания адреса LDAP-сервера. Параметр позволяет указать нешифрованный протокол ldap или шифрованный ldaps.
- параметр -ZZ – это параметр включения шифрованного соединения, где первая Z означает отправку серверу запроса STARTTLS. Если сервер не поддерживает TLS, соединение продолжится, и оно не будет шифроваться. Вторая Z устанавливает требование использовать только шифрованное соединение, если сервер не поддерживает TLS, соединение прервется. Рекомендуется использовать двойной ключ -ZZ для установления шифрованного соединения.
Для лучшего понимания угрозы посмотрим пример, как делать категорически запрещается:
ldapsearch -H ldap://dc1.ald.local -D 'uid=admin,cn=users,cn=accounts,dc=ald,dc=local' -W
Из программы Wireshark вы можете увидеть, что злоумышленник, у которого будет доступ к просмотру сетевых пакетов, может легко извлечь пароль «P@ssw0rd» из запроса, если канал связи не будет зашифрован:
Для проведения простой аутентификации LDAP-каталог хранит хэш пароля в атрибуте userPassword. Алгоритм проверки аутентичности работает следующим образом:
- Пользователь передает на сервер свое имя и пароль в открытом виде.
- Сервер извлекает из каталога хэш пароля для указанного пользователя.
- Пароль, полученный в запросе на аутентификацию, хэшируется тем же алгоритмом и сравнивается с значением, полученным из каталога. Если значения совпали, аутентификация считается успешной.
Хэширование паролей выполняется автоматически при изменении пароля, по умолчанию используется устойчивый к взлому алгоритм PBKDF2_SHA256
admin@host1:~$ ldapsearch -H ldaps://dc1.ald.local -o ldif-wrap=no -D 'cn=Directory Manager' -W -b 'uid=admin,cn=users,cn=accounts,dc=ald
,dc=local' | grep 'userPassword::' | cut -d" " -f2 | base64 -d
Где:
- опция -o ldif-wrap=no - выводит текст без переноса в одну строку, если она не помещается в 80 символов, что полезно использовать в bash командах и скриптах;
- командой grep мы делаем поиск строки с полем userPassword:: и два символа «:» означает что строка закодирована в base64 кодировке;
- командой cut отрезаем по символу пробел значение пароля во второй колонке;
- командой base64 -d значение из base64 декодируем в текст.
Результат выполнения, это декодированный из base64 пароль пользователя admin:
Если включить режим миграции пользователей, то при создании новых учетных записей в атрибут userPassword можно будет записать хэш пароля, при этом поддерживается целый ряд алгоритмов: CRYPT, CRYPT-MD5, CRYPT-SHA256, CRYPT-SHA512, MD5, SHA, SHA256, SHA384, SHA512, SMD5, SSHA, SSHA256, SSHA384, SSHA512.
sudo ipa config-mod --enable-migration=true
sudo ipa user-add userName --setattr userPassword='{TYPE}HASH' - нужно указать тип хеша
Для завершения миграции пользователю потребуется один раз выполнить простую LDAP-аутентификацию, чтобы сервер смог сгенерировать недостающие ключи. В случае успешной аутентификации по LDAP, контроллер может удостовериться в аутентичности пользователя и имеет пароль в открытом виде, с помощью которого может сгенерировать недостающие ключи krbPrincipalKey и ipaNTHash. Для этого на сервере существует даже специальная страница миграции, доступная по адресу https://dc1.ald.local/ipa/migration/
---------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------
Аутентификация по протоколу Kerberos
Основным протоколом аутентификации в домене является Kerberos V5, который был назван так по имени треглавой собаки, охраняющей по древнегреческой мифологии выход из царства мертвых. Каждая голова Цербера соответствует одному из трех участников процедуры аутентификации:
- Клиент (Client) - субъект, желающий получить доступ к ресурсу.
- Сервер приложения (Application Server, AP) - служба, к ресурсу которой клиент хочет получить доступ.
- Центр распространения ключей (Key Distribution Center, KDC) - доверенная сторона, отвечающая за аутентификацию (Authentication Service, AS) пользователей и выпуск билетов для доступа к сетевым службам в домене (Ticket Granting Server, TGS).
KDC состоит из двух отдельных компонентов, отвечающих за каждую из операций — сервер аутентификации (Authentication Server, AS) и
сервер выдачи билетов (Ticket Granting Server, TGS).
Служба KDC работает по порту 88/TCP и отвечает только за выдачу билетов. Для управления учетными записями Kerberos на сервере устанавливается так же служба kadmin, которая использует порты 464/TCP и 749/TCP.
Для того, чтобы нам с Вами говорить на одном языке, необходимо запомнить ключевые термины и определения системы Kerberos:
Аутентификация - процедура проверки подлинности, т.е. аутентичности пользователя, например, на основании того, что обеим сторонам известен общий секрет.
Авторизация - процесс или процедуры, используемые для проверки того, что пользователь (или служба) имеют право доступа и использования определённых системных/сетевых ресурсов, таким как файлы, приложения, либо возможность отправки электронной почты, выхода в Интернет и тому подобных. Обычно права доступа назначаются не на конкретного
пользователя, а на группу, поэтому информацию об участии пользователя в группах считают авторизационной информацией.
Область действия Kerberos (англ. Realm) - совокупность пользователей и компьютеров, пароли которых хранятся в единой базе данных. Совпадает с DNS-именем домена, но пишется заглавными буквами, например, ALD.COMPANY.LAN.
Принципал (англ. Principal) - это строка, уникально идентифицирующая учетную запись пользователя, компьютера или службы Kerberos. Принадлежность принципала к области Kerberos задается как в адресе электронной почты с помощью символа @, например, admin@ALD.LOCAL. В именах сервисов может указываться адрес хоста, на котором эта служба работает, например HTTP/dc1.ald.local@ALD.LOCAL
- В случае с пользователем имя принципала имеет формат <имя_пользователя>/<имя_экземпляра>, где /<имя экземпляра> является опциональной частью. Эта необязательная часть позволяет одному пользователю иметь несколько принципалов в одной и той же области действия. Пример принципала пользователя admin@ALD.COMPANY.LAN.
- В случае со службой, формат имени принципала имеет вид <имя_службы>/<QDN>, где <QDN> - доменное имя узла, без точки в конце (точку в конце требует формат FQDN), на котором работает служба, например, ldap/dc-1.ald.company.lan@ALD.COMPANY.LAN.
Имя сервиса (англ. Service Principal Name, SPN) — это имя принципала для сервиса, которое уникально идентифицирует учетную запись службы на контроллере домена.
TGT-билет, билет на получение билетов (ticket-granting ticket) — билет, который позволяет клиенту проходить аутентификацию на контроллерах домена без повторного ввода пароля для получения сервисных билетов для аутентификации в керберизированных сервисах.
TGS-билет, сервисный билет, удостоверение или мандат (ticket-granting service ticket) — билет, который позволяет клиенту проходить аутентификацию в керберизированном сервисе, для которого этот билет был выдан.
AS_REQ – запрос к службе аутентификации (AS)
AS_REP – ответ от службы аутентификации (AS)
Сессионный ключ – случайный ключ, который передается клиенту и помещается внутрь Kerberos-билета. Становится общим секретом для следующего этапа Kerberos-взаимодействия.
Kerberos – сетевой протокол аутентификации, который предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними. Kerberos выполняет аутентификацию в качестве службы аутентификации доверенной третьей стороны, используя криптографический ключ, при условии, что пакеты, проходящие по незащищенной сети, могут быть перехвачены, модифицированы и использованы злоумышленником. Kerberos построен на криптографии симметричных ключей и требует наличия центра распространения ключей. Расширения Kerberos могут обеспечить использование криптографии с открытым ключом на определенных этапах аутентификации.
В систему Kerberos входят:
- Клиент - пользователь или служба, которые пытаются получить доступ к службам в области Kerberos.
- Центр распространения ключей (Key Distribution Center, KDC), в состав которого входят:
- Сервер аутентификации (Authentication Server, AS): принимает запросы на аутентификацию от пользователей и выдает им временные билеты (TGT).
- Служба выдачи билетов (Ticket Granting Service, TGS): выдает билеты для доступа к конкретным службам (service ticket) после успешной аутентификации.
- База данных (LDAP каталог): содержит зашифрованные секретные ключи для всех принципалов (пользователей, служб, компьютеров и т.д.) в области Kerberos. Эти ключи используются для первичной аутентификации и создания билетов. Для каждого принципала в базе хранятся следующие данные: имя принципала (principal name), зашифрованный секретный ключ принципала и дополнительные атрибуты принципала (например, какие-то атрибуты политики паролей). Но вообще политика паролей не является атрибутом принципала. Она применяется к паролю только в момент смены пароля. Например, у пользователя есть только срок действия пароля, который вставляется в момент смены пароля в соответствии с политикой паролей, которая на него распространялась в момент этого действия. То есть при добавлении пользователя в группу администраторов, для которых выставлена более строгая политика паролей, пользователь начнет ей соответствовать только после первой смены пароля. База размещается на серверах KDC и реплицируется между ними для обеспечения отказоустойчивости. База защищена мастер-ключом KDC, известным только администраторам Kerberos. Все записи ключей внутри базы зашифрованы с использованием этого мастер-ключа.
Мастер ключом называется только пароль контроллеров домена, которым они шифруют TGT билеты. С помощью команды list_mkeys мы можем посмотреть этот ключ.
- Сервер приложений: службы защищенные Kerberos, к которым клиенты пытаются получить доступ с помощью соответствующих service ticket.
Система аутентификации Kerberos основана на нескольких принципах:
- Kerberos не доверяет сети в которой он работает, и как следствие хэш пароля и тем более пароль в открытом виде никогда не передаются по сети.
- Для повышения безопасности, после первоначальной аутентификации клиента применяются временные сессионные ключи, а хэш пароля клиента удаляется сразу после получения временного сессионного ключа.
- В роли аутентификатора применяется шифруемая метка времени, которая играет ключевую роль в процессе аутентификации (поэтому в системе Kerberos, а как следствие и в домене так важна синхронизация времени).
Использование протокола Kerberos позволяет реализовать единый вход, что позволяет пользователям войти в систему единожды и автоматически получать доступ к другим ресурсам без дополнительной аутентификации.
Если не вдаваться в детали шифрования билетов, то процедура аутентификации по протоколу Kerberos состоит из следующих шагов:
1. Клиент отправляет контроллеру запрос на аутентификацию (AS_REQ)
2. Контроллер выдает клиенту TGT-билет (AS_REP). Билет зашифрован мастер-ключом KDC, поэтому может быть проверен любым контроллером в домене.
3. Клиент отправляет контроллеру запрос на получение сервисного билета для
аутентификации, например, на web сервере (TGS_REQ). Запрос может быть направлен любому контроллеру в домене.
4. Контроллер выдает клиенту TGS-билет (AS_REP). Билет зашифрован паролем сервиса, поэтому может быть проверен им самостоятельно без обращения к кому-либо.
5. Клиент обращается к сервису (AP_REQ).
6. Сервис подтверждает аутентичность пользователя и устанавливает с ним сессию (AP_REP).
Протокол аутентификации Kerberos был разработан для эксплуатации в незащищенных компьютерных сетях, когда сетевые пакеты могут быть подслушаны и изменены злоумышленником. Рассмотрим процесс аутентификации более подробно чем мы рассматривали выше, опуская несущественные детали, такие как фаза предварительной аутентификации, использование nonce и др.
Шаг (1)
Пользователь Алиса через приложение графического входа (Fly Display Manager Greet) передает стеку модулей аутентификации (Pluggable Authentication Modules, PAM) логин и пароль в открытом виде.
За аутентификацию в домене отвечает модуль /usr/lib/x86_64-linux-gnu/security/pam_sss.so, см. файл /etc/pam.d/common-auth:
Строка "auth [success=1 default=ignore] pam_sss.so use_first_pass" говорит о том, что данные аутентификации будут передаваться в том числе модулю pam_sss.so, т.е. будут отправляться в службу sssd.
Шаг (2)
Библиотека libpam загружает клиентскую библиотеку pam_sss.so, через функции которой обращается к Ответчику /usr/lib/x86_64-linux-gnu/sssd/sssd_pam. Ответчик обращается к Бэкенду, который порождает процесс krb5_child для аутентификации в домене по протоколу Kerberos V5. Ответчик и Бэкэнд - это компоненты службы sssd.
Клиент Kerberos рассчитывает долгосрочный ключ Алисы (UPN long-term key) и может удалить из памяти компьютера пароль в открытом виде для повышения устойчивости системы к взлому. При хэшировании используется соль, к паролю добавляется основное имя принципала, включающее логин пользователя и реалм домена. В соответствии с политикой Kerberos для хэширования может использоваться алгоритм AES128_CTS_HMAC_SHA1_96 или AES256_CTS_HMAC_SHA1_96.
Посмотреть мастер ключ можно на контроллере домена командой:
sudo kdb5_util list_mkeys
Шаг (3)
Клиент отправляет запрос службе аутентификации Центра распространения ключей (Key Distribution Center, KDC). В четвертой версии протокола на этом шаге никакие учетные данные не требовались, т. к. ответ будет зашифрован долгосрочным ключом пользователя, и способность расшифровать ответ является подтверждением того, что пользователь является тем, за кого себя выдает. Но с пятой версии протокола сервер отклонит запрос и потребует предварительную аутентификацию. В качестве аутентификатора выступает метка времени на клиенте на момент создания запроса, зашифрованная симметричным алгоритмом с помощью долгосрочного ключа клиента. Такая проверка существенно затрудняет кибератаки, так как лишает злоумышленника возможности запросить TGT-билет на любого пользователя в системе. Сам долгосрочный ключ не передается на контроллер домена, т.к. контроллер домена может сам извлечь долгосрочный ключ пользователя из базы и расшифровать переданные ему данные.
Шаг (4)
KDC (центр распространения ключей) расшифровывает аутентификатор (метка времени на момент создания запроса), используя хэш пароля Алисы из LDAP-каталога, как показано на рисунке выше. Ключи для аутентификации по протоколу Kerberos хранятся в атрибуте krbPrincipalKey, который представляет из себя бинарный объект, зашифрованный мастер-ключом KDC (krbMKey). Если процедура расшифровки завершилась успешно, и полученная временная метка расходится с временем сервера не более, чем на 5 минут, то считается, что предварительная аутентификация пройдена успешно. По этой причине для корректной работы протокола важна синхронизация времени между всеми участниками. Т.е. на 4 шаге происходит 2 проверки:
- Что сервер смог расшифровать аутентификатор.
- Что метка времени расходится с временем сервера не более чем на 5 минут.
Шаг (5)
Для повышения безопасности системы KDC генерирует временный сессионный ключ (S1) для последующей передачи его клиенту, чтобы использовать в дальнейшем для шифрования сообщений между клиентом и KDC вместо хэша пароля пользователя.
Шаг (6)
Несмотря на то, что сессионный ключ был сгенерирован сервером, в домене может быть несколько контроллеров, и клиент вправе обратиться с последующим запросом к любому из них. Учитывая случайный характер сессионного ключа, другой контроллер домена не сможет рассчитать его математически, поэтому сессионный ключ следует передать ему в явном виде. По протоколу Kerberos ответственность за передачу сессионного ключа возлагается на клиента, для чего ему выдается зашифрованный билет на выдачу билетов (Ticket-granting ticket, TGT), который он должен предъявлять в KDC при последующих обращениях.
Внутри TGT-билета содержится имя пользователя, сессионный ключ и информация по сроку действия билета. Билет зашифрован симметричным алгоритмом с помощью долгосрочного ключа KDC (хэш пароля служебной учетной записи KRBTGT, Key Distribution Center Service Account), поэтому расшифровать его можно только на контроллере, и подделать билет на стороне клиента невозможно.
Шаг (7)
Сессионный ключ и билет шифруются симметричным алгоритмом с помощью долгосрочного ключа клиента, поэтому только клиент сможет расшифровать сообщение, подтверждая этим фактом, что является тем, за кого себя выдает. Данная проверка аутентичности считается основной.
Долгосрочный ключ клиента, сессионный ключ и билет могут быть удалены из памяти сервера за ненадобностью для повышения безопасности системы.
Шаг (8)
Клиент расшифровывает сессионный ключ и TGT билет своим долгосрочным ключом, как показано на рисунке выше. Возможность использования этих данных в последующих запросах означает, что Клиент является тем, за кого себя выдает. Если результат расшифровки окажется недействительным, значит ответ получен от подставного Центра распространения ключей. Долгосрочный ключ может быть удален из памяти компьютера за ненадобностью для повышения безопасности системы.
Шаг (9)
Процесс krb5_child сохраняет TGT билет в связке ключей Linux и передает результаты по цепочке Бэкенд — Ответчик — Клиентская библиотека, после чего Клиентская библиотека отправляет запрос на получение сервисного билета на доступ к серверу приложения, в котором содержится имя пользователя (user principal name), имя сервера приложения (service principal name), билет на выдачу билетов (TGT) и аутентификатор. В качестве аутентификатора выступает метка времени, зашифрованная симметричным алгоритмом с помощью сессионного ключа S1. В качестве имени сервиса при входе в компьютер выступает host/pc-fqdn. Внутри TGT билета содержится тот же самый сессионный ключ, что позволяет не передавать его в незашифрованном виде. Доступ к нему может получить только контроллер домена расшифровав TGT билет с помощью долгосрочного ключа KDC. Посмотреть TGT билет можно командой:
klist
На этом шаге TGT билет зашифрован только долгосрочным ключом KDC, но этого достаточно, чтобы злоумышленник, перехвативший сообщение, не смог подделать запросы, т. к. он не располагает сессионным ключом S1.
Шаг (10)
KDC расшифровывает информацию из TGT билета, используя долгосрочный ключ KDC из LDAP-каталога, после чего ему становится доступна следующая информация: имя пользователя, сессионный ключ S1 и срок действия билета, как показано на рисунке выше.
Сервер расшифровывает аутентификатор, используя сессионный ключ из TGT билета, и, если полученное значение расходится с временем сервера не более, чем на 5 минут, то считается, что аутентификация пройдена успешно.
Шаг (11)
Для повышения безопасности протокола KDC генерирует новый сессионный ключ (S2) для последующей передачи его клиенту, чтобы использовать в дальнейшем для шифрования сообщений между клиентом и сервером приложения вместо сессионного ключа S1.
Шаг (12)
После того как ключ S2 был сгенерирован сервером KDC его следует передать серверу приложения. По протоколу Kerberos ответственность за передачу ключа возлагается на клиента, для чего ему выдается зашифрованный сервисный билет (Service ticket, ST), который он должен предъявлять серверу приложения.
Внутри ST-билета содержится имя пользователя, сессионный ключ и информация по сроку действия билета. Билет зашифрован симметричным алгоритмом с помощью долгосрочного ключа сервера приложения, поэтому расшифровать его сможет только сервер приложения, и подделать билет на стороне Клиента невозможно.
У приложения может быть отдельная учетная запись, но может использоваться и учетная запись компьютера, на котором это приложение работает. В нашем случае это пароль компьютера, в который мы хотим войти.
Шаг (13)
После передачи сервисного билета клиенту информация о ключах больше не требуется и может быть удалена для повышения безопасности системы.
Шаг (14)
Клиент расшифровывает сессионный ключ S2 и сервисный билет ST известным ему сессионным ключом S1. Возможность использования этих данных в последующих запросах означает, что клиент является тем, за кого себя выдает. Если результат расшифровки окажется недействительным, значит ответ получен подставного Центра распространения ключей.
Шаг (15)
Клиент отправляет серверу приложения запрос на аутентификацию, в котором содержится имя пользователя, сервисный билет (ST) и аутентификатор. В качестве аутентификатора выступает метка времени, зашифрованная симметричным алгоритмом с помощью сессионного ключа S2.
На этом шаге ST билет закодирован только долгосрочным ключом сервера приложения, но этого достаточно, чтобы злоумышленник, перехвативший сообщение, не смог подделать запросы.
Шаг (16)
Сервер приложения, в роли которого выступает служба SSSD на пользовательском компьютере, извлекает хэш пароля компьютера из файла /etc/krb5.keytab для расшифровки запроса. Используя этот долгосрочный ключ, служба SSSD может расшифровать информацию из сервисного билета (ST), после чего ей становится доступна следующая информация: имя пользователя, сессионный ключ S2 и срок действия билета. SSSD расшифровывает аутентификатор, используя сессионный ключ S2 из сервисного билета, и, если полученное значение расходится с временем компьютера не более, чем на 5 минут, то считается, что аутентификация пройдена успешно.
Получив подтверждение, что вход в компьютер хочет выполнить действительно Алиса, приложение Display Manager запускает рабочий стол (Fly Windows Manager, fly-wm) от имени этого пользователя.
Сервисный билет на доступ к хосту более не требуется, поэтому он не сохраняется в связке ключей, и вы не увидите его в выводе команды klist, но на контроллере в журнале /var/log/auth.log вы можете найти подтверждение, что такой билет запрашивался и был предоставлен рабочей станции.
Сессионный ключ S1 будет сохранен на клиенте на протяжении всей жизни TGT билета. TGT билет нужен чтобы постоянно не обращаться к контроллеру домена, а сразу обращаться к сервисам, поэтому время его жизни - 24 часа для ALD Pro (значение настраивается), в MS AD время жизни TGT-билета 10 часов. Срок жизни TGS билета в ALD Pro тоже измеряется часами. А вот срок жизни аутентификатора, той самой метки времени, которая зашифрована ключом S2 составляет 5 минут. Поэтому, если злоумышленник перехватит запрос на аутентификацию в сервисе, то у него будет только 5 минут на то, чтобы совершить свою атаку.
Важно понимать, что аутентификация и авторизация (в основном авторизация) на разных сервисах работает по разному. Например в Windows авторизационная информация извлекается из самого Kerberos билета. Но сам протокол Kerberos, хоть и имеет поле для данных авторизации, структуру и содержание этого не регламентирует и отдает это на откуп самим приложениям и их клиентам.
Управление Kerberos-аутентификацией
Для работы с Kerberos-билетами на компьютере Linux используются утилиты из пакета krb5-user, такие как kinit, klist, kdestroy, kvno, kpasswd и другие.
Аутентификация
Для выполнения аутентификации по протоколу Kerberos, т.е. для получения TGT-билета используется утилита kinit. Если обратиться к утилите без параметров, то она будет использовать имя пользователя по умолчанию из текущего кэша учетных данных системы, а если в кэше ничего нет, то воспользуется именем текущего пользователя Linux.
kinit
Имя конкретного пользователя можно указать следующим параметром:
kinit ald-user1
При этом вы можете использовать как короткое, так и полное имя пользователя. Система будет автоматически дополнять короткие имена значением реалма по умолчанию (default_realm) из файла /etc/krb5.conf.
Реалм необходимо указывать заглавными буквами!
kinit ald-user1@ALD.LOCAL
С помощью утилиты kinit вы можете выполнить аутентификацию не только по паролю, но и по keytab-файлу, в котором хранятся уже хеши ключей. Для этого используется ключ -k. По умолчанию утилита будет использовать файл /etc/krb5.keytab, но с помощью ключа -t вы можете задать путь к файлу явным образом.
sudo kinit -kt /etc/krb5.keytab
Обратите внимание, что при выполнении аутентификации ранее выданные билеты удаляются.
Просмотр билетов
Для просмотра полученных Kerberos-билетов используется утилита klist. При обращении к утилите без параметров она отобразит информацию о билетах из кэша по умолчанию.
klist
С помощью ключа -с можно прочитать билеты из кэша, который хранится в файле:
sudo klist -c /var/lib/sss/db/ccache_ALD.LOCAL
Утилита klist позволяет читать не только файлы кешей учетных данных, но и keytab-файлы. Для того, чтобы указать имя keytab-файла, нужно воспользоваться ключом -k (keytab). Полезно так же использовать ключи -e (encryption) и -t (timestamp), чтобы увидеть дату выдачи и используемые
алгоритмы шифрования.
sudo klist -ket /etc/krb5.keytab
Удаление билетов
Для того, чтобы удалить билеты Kerberos из кэша, воспользуйтесь утилитой kdestroy без параметров. Проверим, что билеты есть в кэше:
Выполним удаление билетов и проверим кэше еще раз:
kdestroy
Получение сервисных билетов
Для аутентификации в керберизированных сервисах приложения автоматически запрашивают сервисные билеты через GSSAPI. Все проходит без участия пользователя, поэтому такой метод аутентификации называют прозрачным. Например, если вы зайдете на портал управления с
аутентификацией по Kerberos, в связке ключей появится билет на доступ к службе HTTP.
Однако во время отладки, особенно при работе с доверительными отношениями, нам иногда требуется получить билет на какой-то конкретный сервис вручную. Сделать это можно, например, с помощью утилиты kvno (англ. key version number — номер версии ключа).
Основное назначение этой утилиты состоит в том, чтобы получить билет на указанный сервис и показать номер версии пароля, который хранится на сервере KDC. Это позволяет, например, быстро установить, что keytab-файл был взят из старой резервной копии и там хранятся неактуальные ключи. Но каким бы ни было изначальное назначение утилиты, она очень удобна
для отладки.
Чтобы получить билет на требуемый сервис его название нужно передать утилите kvno в качестве параметра. После выполнения команды в связке ключей появится соответствующий билет:
kinit admin
vno HTTP/dc1.ald.local@ALD.LOCAL
klist
Работа с коллекцией ключей
Выполняя Kerberos-аутентификацию под новым пользователем, вы не удалете ранее полученные билеты, а просто переключаетесь на другое хранилище в рамках вашей коллекции ключей.
Посмотреть все билеты в вашей коллекции можно командой klist с ключом -A (all):
kinit admin
kinit ald-user1
klist -A
Это позволяет вам быстро вернуться к нужному кэшу ключей без повтороного ввода пароля. Для переключения между хранилищами используют команду kswitch, которой нужно передать имя пользователя ключом -p (principal). Вы можете использовать короткое имя пользователя без указания Kerberos-реалма.
kswitch -p admin
Если вам потребуется очистить все хранилища коллекции сразу, воспользуйтесь утилитой kdestroy с ключом -A (all). После этого klist с ключом -A не покажет никаких данных.
kdestroy -A
Администрирование учетных записей Kerberos
Сервер Kerberos может не только выдавать билеты, но и предоставляет интерфейс для управления учетными записями. За это отвечает служба kadmind, которая обрабатывает запросы на портах 464/TCP и 749/TCP.
На контроллерах домена FreeIPA служба не имеет собственной базы данных и взаимодействует с общим LDAP-каталогом через специальный плагин, поэтому при выполнении через нее любых административных действий выполняются все проверки прав доступа, предусмотренные службой каталога в соответствии с настройками инструкций доступа.
Служба kadmind принимает удаленные запросы от таких программ, как kadmin, kpasswd и др.
Через нее работает утилита fly-passwd, и даже Windows компьютеры в составе домена ALD Pro (FreeIPA) могут с ее помощью предоставить доменному пользователю возможность сменить пароль штатными средствами через <CTRL> + <ALT> + <DEL>.
Например, если вам потребуется сменить пароль пользователя из командной строки, вы можете воспользоваться утилитой kpasswd. При вызове утилиты без параметров она использует текущее имя. Чтобы задать имя пользователя явным образом, передайте его в качестве параметра:
kpasswd ald-user2
Для выполнения расширенных задач администрирования вам нужно будет воспользоваться утилитами kadmin или kadmin.local.
---------------------------------------------------------------------------------------------
Аутентификация по протоколу NTLM
Для интеграции с Active Directory служба каталога FreeIPA использует компоненты Samba, в которых реализована в том числе NTLM-аутентификация.
Служба каталога FreeIPA тесно интегрирована с сервером Samba (т.е. это не файловый сервер Samba, а контроллер домена Samba), в котором реализована поддержка NTLM-протокола для возможности аутентификации пользователей по логину/паролю, например, если подключение выполняется не по доменному имени сервера, а по его IP адресу. Для этого у пользователей в каталоге есть атрибут ipaNTHash, который обновляется плагином ipa_pwd_extop каждый раз при смене пароля.
На рисунке ниже представлена диаграмма аутентификации по протоколу NTLM в упрощенном виде:
- Клиент обращается к Сервису с запросом на аутентификацию (1) и получает в ответ случайное число длиной 8 байт, которое ему нужно подписать, используя свой пароль, для подтверждения аутентичности (2).
- Клиент подписывает сообщение и передает его Сервису (3), который пересылает подпись вместе с исходным сообщением на контроллер домена (4).
- Контроллер проверяет подпись и возвращает PAC сертификат, если проверка аутентичности пройдена успешно (5).
Для возможности NTLM-аутентификации у пользователей в каталоге FreeIPA есть атрибут ipaNTHash, который обновляется плагином ipa_pwd_extop каждый раз при смене пароля. Служба Samba через ipadb плагин извлекает из LDAP-каталога значение ipaNTHash и самостоятельно выполняет все необходимые проверки аутентичности.
Текущие настройки службы Samba можно получить командой testparm. ROLE_DOMAIN_PDC означает, что параметр security равен USER, т.е. Samba работает в режиме NT4-контроллера.
sudo testparm
Для проверки работы NTLM-аутентификации на контроллере можно воспользоваться утилитой ntlm_auth. За обработку запросов NTLM-аутентификации отвечает Winbind.
sudo ntlm_auth --debuglevel=10 --domain=ALD --username=admin --password=P@ssw0rd