для чего нужен keytab файл
Настройки авторизации
Данные типы авторизации используются, когда необходимо авторизовать пользователей AD. Авторизация будет выполнена прозрачно, без запроса логина и пароля. Использование данных типов предполагает прямое указание прокси в браузере или других программах, которые их поддерживают.
Для открытия модуля перейдите в меню Пользователи и статистика > Настройки авторизации.
В модуле расположены следующие вкладки с соответствующими настройками:
Kerberos
Данная вкладка предназначена для подключения к контроллеру домена по протоколу сетевой аутентификации Kerberos.
Пример создания Keytab-файла
Для удобства команда создания Keytab-файла указана в веб-интерфейсе на вкладке «Kerberos». Она изменяется в соответствии с введенными значениями полей.
Внимание! При интеграции ИКС с LDAP-сервером FreeIPA команда для генерации keytab-файла, подходящего для настройки Kerberos, будет отличаться. Команда также выводится для удобства на вкладке «Kerberos» и изменяется в соответствии с введенными значениями полей.
Пример создания Keytab-файла (FreeIPA)
В случае удачной настройки ИКС сообщит соответствующую информацию: «А-запись», «PTR-запись», «Попытка авторизации» должны иметь статус «Ок».
Если попытка прошла неудачно, ИКС выдаст рекомендации по их устранению.
Внимание! При подключении по протоколу Kerberos имя системы будет изменено на «имя.домен».
Настроить авторизацию на прокси с использованием Kerberos
Важно! Если пользователь не прошел Kerberos-авторизацию, ему будет предложено ввести логин и пароль для LDAP-авторизации. При этом если не используется LDAPS (с сертификатом), пароль при LDAP-авторизации будет передаваться в открытом виде.
Если Kerberos не настроен, то авторизация в VPN, связанная с Kerberos, будет недоступна.
Данные полей вкладки синхронизируются с формой импорта из LDAP.
Внимание! Начиная с версии 8.4, пользователи, импортированные из FreeIPA, могут авторизоваться в веб-интерфейсе, на прокси-сервере (с использованием Kerberos) и почтовом сервере. Подключение по VPN таких пользователей на данный момент недоступно.
Для импорта пользователей необходимо указать логин пользователя как DN пользователя в LDAP-каталоге (например, uid=admin,cn=users,cn=accounts,dc=ipa,dc=test ).
Выбираемый сертификат должен быть установлен на LDAP-сервере. При создании сертификата на ИКС укажите значения полей: «Тип сертификата» — «Конечный сертификат», «Шаблон» — «Сервер».
Внимание! В ИКС не хранятся пароли доменных пользователей. При попытке задать доменному пользователю пароль для него перестанет работать доменная авторизация — пользователь сможет авторизовываться на ИКС только по логину и паролю, заданным на ИКС.
Внимание! Чтобы избежать сложностей в совместимости с Microsoft, рекомендуется использовать LDAPS. При возникновении проблем с подключением к LDAPS импортированному сертификату необходимо установить параметр «Добавить в доверенные сертификаты».
Добавление SPN записей в keytab-файл (на стороне сервера Linux с помощью утилиты ktutil), связанный с учётной записью Computer в домене Active Directory
Изменение учётной записи компьютера в AD
Снова проверим полный список зарегистрированных SPN-записей:
Порядок. Теперь можно переходить к правке keytab-файла на стороне Linux-сервера.
Правка keytab-файла на Linux-сервере
Войдём в режим работы с утилитой ktutil:
Выполним команду list, которая покажет, какими данными оперирует утилита (пока там пусто):
Следующей командой add_entry добавим в массив данных, с которыми оперирует утилита, нужную нам дополнительную запись принципала Kerberos. При этом будем использовать ключи:
Таким образом мы можем добавить аналогичные записи для всех необходимых типов шифрования по аналогии с записями типа HOST/ :
Проверим, что у нас получилось в конечном итоге (вывод утилиты усечён):
По завершению добавления записей командой write_kt сохраняем получившийся массив данных в новый keytab-файл и выходим из интерактивного режима работы утилиты:
Таким образом мы получили keytab-файл, записи которого соответствуют SPN, зарегистрированным для учётной записи Linux-сервера в каталоге AD.
Проверка Kerberos аутентификации с SSO на стороне клиента
Перейдём на клиентскую Windows-машину и с правами пользователя, имеющего доступ к только что настроенному веб-сайту Apache, обратимся к этому сайту через веб браузер. Но перед тем как открыть сайт, закроем клиентский браузер и очистим кэш билетов Kerberos командой:
После этого откроем веб-сайт Apache с настроенной Kerberos аутентификацией и проверим то, как изменилось состояние кэша билетов на клиентской машине:
Как видим, Kerberos-билет, связанный с веб-сервером на Linux, успешно получен.
Kerberos
Содержание
Kerberos
Этот раздел раскрывает установку и настройку сервера Kerberos, а также некоторые примеры клиентских настроек.
Обзор
Если вы новичок в Kerberos, есть несколько терминов, которые хорошо понять до установки сервера Kerberos. Большинство терминов связаны с вещами, которые могут быть вам знакомы по другим окружениям:
Требования (Instances): используются для сервисных и специальных административных учетных записей.
Области (Realms): уникальная область управления, обеспечиваемая установкой Kerberos. Представляйте ее себе как домен или группу ваших компьютеров и пользователей, ей принадлежащих. По умолчанию Ubuntu использует имя DNS домена в верхнем регистре (EXAMPLE.COM) в качестве имени области.
Центр распространения ключей (KDC): состоит из трех частей: базы данных всех учетных записей, сервера аутентификации и сервера предоставления билетов. Для каждой области должен быть хотя бы один KDC.
Билет для получения билета (TGT): изданный сервером аутентификации, TGT зашифровывается на пароле пользователя, который известен только пользователю и KDC.
Сервер распространения билетов (TGS): выпускает сервисные билеты для клиентов по запросу.
Файлы ключей (Keytab Files): файлы, извлеченные из базы учетных записей KDC и содержащие ключ шифрования для сервиса или компьютера.
Чтобы сложить все вместе: Область содержит как минимум один KDC, лучше больше для обеспечения безотказности, которые содержат базу данных учетных записей. Когда пользователь под учетной записью заходит на рабочую станцию, которая настроена на Kerberos аутентификацию, KDC выпускает билет для получения билетов (TGT). Если пользователь предоставляет совпадающие параметры, он считается аутентифицированным и может запрашивать билеты для сервисов, поддерживающих Kerberos, на сервере распространения билетов (TGS). Сервисные билеты позволяют пользователю аутентифицироваться на сервисах без ввода имени и пароля.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
В прошлой части нашего цикла мы рассмотрели работу протоколов семейства NTLM, отметив ряд их существенных недостатков, которые невозможно решить в рамках протокола. Поэтому вместе с Active Directory на смену им пришел более совершенный протокол Kerberos, который продолжает успешно применяться до сих пор. В данном материале мы рассмотрим общие принципы функционирования данного протокола, что позволит получить начальные знания в этой области самым широким массам читателей.
Протокол Kerberos был разработан в Массачусетском технологическом институте (MIT) в рамках проекта «Афина» в 1983 году и долгое время использовался в качестве образовательного, пока версия 4 не была сделана общедоступной. В настоящий момент принята в качестве стандарта и широко используется следующая версия протокола Kerberos 5.
Основным недостатком протокола NTLM служит то, что он не предусматривает взаимную аутентификацию клиента и сервера, это во многом обусловлено тем, что протокол изначально разрабатывался для небольших сетей, где все узлы считаются легитимными. Несмотря на то, что в последних версиях протокола сделаны серьезные улучшения безопасности, но направлены они в основном на усиление криптографической стойкости, не устраняя принципиальных недостатков.
В доменных сетях протоколы NTLM вызывают повышенную нагрузку на контроллеры домена, так как всегда обращаются к ним для аутентификации пользователя. При этом также отсутствует взаимная идентификация узлов и существует возможность накопления пакетов для последующего анализа и атаки с их помощью.
В отличии от NTLM Kerberos изначально разрабатывался с условием, что первичная передача информации будет производиться в открытых сетях, где она может быть перехвачена и модифицирована. Также протокол предусматривает обязательную взаимную аутентификацию клиента и сервера, а взаимное доверие обеспечивает единый удостоверяющий центр, который обеспечивает централизованную выдачу ключей.
Центр распространения ключей содержит долговременные ключи для всех принципалов, в большинстве практических реализаций Kerberos долговременные ключи формируются на основе пароля и являются так называемым «секретом для двоих». С помощью такого секрета каждый из его хранителей может легко удостовериться, что имеет дело со своим напарником. При этом долговременные ключи не при каких обстоятельствах не передаются по сети и располагаются в защищенных хранилищах (KDC), либо сохраняются только на время сеанса.
Для принципалов, которые не являются членами домена AD, могут использоваться специальные keytab-файлы, которые содержат сведения о клиенте, домене и его долговременный ключ. В целях безопасности keytab-файл нельзя передавать по незащищенным каналам, а также следует обеспечить его безопасное хранение у принципала.
В структуре Active Directory центр распространения ключей располагается на контроллере домена, но не следует путать эти две сущности, каждая из них является самостоятельной и выполняет свои функции. Так Kerberos отвечает только за аутентификацию клиентов, т.е. удостоверяет, что некто является именно тем, за кого себя выдает. Авторизацией, т.е. контролем прав доступа, занимается контроллер домена, в свою очередь разрешая или ограничивая доступ клиента к тому или иному ресурсу.
Рассмотрим каким образом происходит аутентификация клиента по протоколу Kerberos.
Получив эти данные KDC извлекает долговременный ключ данного пользователя и расшифровывает метку времени, которую сравнивает с собственным текущим временем, если оно отличается не более чем на 5 минут (значение по умолчанию), то метка считается действительной. Эта проверка является дополнительной защитой, так как не позволяет использовать для атаки перехваченные и сохраненные данные.
Убедившись, что метка времени действительна KDC выдает клиенту сеансовый ключ и билет (тикет) на получение билета (ticket granting ticket, TGT), который содержит копию сеансового ключа и сведения о клиенте, TGT шифруется с помощью долговременного ключа KDC и никто кроме него билет расшифровать не может. Сеансовый ключ шифруется с помощью долговременного ключа клиента, а полученная от клиента метка времени возвращается обратно, зашифрованная уже сеансовым ключом. Билет на получение билета является действительным в течении 8 часов или до завершения сеанса пользователя.
Клиент в первую очередь расшифровывает сеансовый ключ, затем при помощи этого ключа метку времени и сравнивает ее с той, что он отправил KDC, если метка совпала, значит KDC тот, за кого себя выдает, так как расшифровать метку времени мог только тот, кто обладает долговременным ключом. В этом случае клиент принимает TGT и помещает его в свое хранилище.
Чтобы лучше понять этот механизм приведем небольшой пример. Если злоумышленник перехватил посланный KDC запрос, то он может на основе открытых данных послать клиенту поддельный сеансовый ключ и TGT, но не сможет расшифровать метку времени, так как не обладает долговременным ключом. Точно также, он может перехватить отправленные клиенту TGT и сеансовый ключ, но также не сможет расшифровать последний, не имея долговременного ключа. Перехватить долговременный ключ он не может, так как они по сети не передаются.
Успешно пройдя аутентификацию, клиент будет располагать сеансовым ключом, которым впоследствии он будет шифровать все сообщения для KDC и билетом на получение билета (TGT).
Теперь рассмотрим ситуацию, когда клиент хочет обратиться к серверу.
Для этого он снова обращается к KDC и посылает ему билет на получение билета, зашифрованную сеансовым ключом метку времени и имя сервера. Прежде всего KDC расшифровывает предоставленный ему TGT и извлекает оттуда данные о клиенте и его сеансовый ключ, обратите внимание, что сам KDC сеансовые ключи не хранит. Затем сеансовым ключом он расшифровывает данные от клиента и сравнивает метку времени с текущим. Если расхождения нет, то KDC формирует общий сеансовый ключ для клиента и сервера.
Теоретически теперь данный ключ следует передать как клиенту, так и серверу. Но KDC имеет защищенный канал и установленные доверительные отношения только с клиентом, поэтому он поступает по-другому. Экземпляр сеансового ключа для клиента он шифрует сессионным ключом, а копию сеансового ключа для сервера он объединяет с информацией о клиенте в сеансовый билет (session ticket), который шифрует закрытым ключом сервера, после чего также отправляет клиенту, дополнительно зашифровав сессионным ключом.
Таким образом клиент получает сессионный ключ для работы с сервером и сессионный билет. Получить содержимое билета, как и TGT, он не может, так как не располагает нужными долговременными ключами.
Теперь, имея новый ключ и билет, клиент обращается непосредственно к серверу:
Он предъявляет ему сеансовый билет и метку времени, зашифрованную сессионным ключом. Сервер расшифровывает билет, извлекает оттуда свой экземпляр ключа и сведения о клиенте, затем расшифровывает метку времени и сравнивает ее с текущим. Если все нормально, то он шифрует полученную метку своим экземпляром сессионного ключа и посылает назад клиенту. Клиент расшифровывает ее своим сеансовым ключом и сравнивает с тем, что было послано серверу. Совпадение данных свидетельствует о том, что сервер тот, за кого себя выдает.
Как можно заметить, сеансовые ключи никогда не передаются по незащищенным каналам и не передаются узлам, с которыми нет доверительных отношений. У KDC нет доверительных отношений с сервером, и он не может передать ему сессионный ключ, так как нет уверенности, что ключ будет передан кому надо. Но у него есть долговременный ключ этого сервера, которым он шифрует билет, это гарантирует, что никто иной не прочитает его содержимое и не получит сессионный ключ.
Клиент имеет билет и свой экземпляр ключа, доступа к содержимому билета у него нет. Он передает билет серверу и ждет ответ в виде посланной метки времени. Сервера, как и KDC, не хранят сеансовые ключи, а, следовательно, расшифровать метку времени сервер может только в том случае, если сможет расшифровать билет и получить оттуда сеансовый ключ, для чего нужно обладать долговременным ключом. Получив ответ и расшифровав его, клиент может удостоверить подлинность сервера, так как прочитать аутентификатор и извлечь из него метку времени сервер сможет только при условии расшифровки билета и получения оттуда сеансового ключа.
Несмотря на то, что мы рассмотрели крайне упрощенную модель протокола Kerberos, надеемся, что данная статья поможет устранить пробелы и получить первоначальные знания, которые затем можно расширить и углубить уже осмысленно подойдя к прочтению более серьезных материалов.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Аутентификация Kerberos
# Термины и определения
| термин | описание | пример |
| DOMAIN_NAME | название домена | test.com |
| REALM | для Active Directory это всегда DOMAIN_NAME в верхнем регистре | TEST.COM |
| SERVER_NAME | название компьютера, где установлен RunaWFE Server | runaserver |
| SERVER_USER | логин пользователя, под которым работает RunaWFE Server | runauser |
| SERVER_SPN | SPN (Service principal name), который соответствует SERVER_USER |
Формат FQDN для Windows2008: HTTP/
Формат NetBIOS для Windows2008: HTTP/
Формат NetBIOS для Windows2003: HTTP/
# Инструменты
| название | описание | расположение | комментарии |
| kinit | Получение тикета TGT из контроллера домена | JDK bin, есть альтернативные реализации | пользователь может быть задан в виде |
| klist | Просмотр полученных тикетов и возможность их удаления из локального кеша | JDK bin, есть альтернативные реализации | |
| setspn | Создаёт SPN и назначает его пользователю | входит в Windows Server 2008+, ранее доступен в пакете Windows Server support tools | |
| ktpass | Меняет логин пользователя на SPN или формирует keytab файл | входит в Windows Server 2008+, ранее доступен в пакете Windows Server support tools | |
| ktab | Формирует keytab файл | JDK bin | |
| ADSIEdit | Просмотр свойств пользователя в контроллере домена | Windows Server | |
| WireShark | Анализатор траффика | https://www.wireshark.org/ |
# Описание
| этап | протокол | описание | данные запроса | данные ответа | примечания |
| 0 | KRB | аутентификация пользователя клиента | логин пользователя | тикет TGT | при входе в систему |
| 1 | HTTP | вход в систему | без HTTP заголовка Authorization | HTTP 401 | http:// |
| 2 | KRB | получение сервисного тикета для сервера | сервисный тикет | шаг выполняется если тикета ещё нет в кеше клиента | |
| 3 | HTTP | продолжение входа в систему | HTTP заголовок Authorization = YIIV… | HTTP 200 | http:// |
| 4 | KRB | аутентификация пользователя сервера | тикет TGT | выполняется при отсутствии TGT во время взаимодействия с клиентом, происходит до возврата ответа 3 клиенту |
# Типы шифрования
Выбранный тип шифрования зависит от участников взаимодействия — версии ПО домена (Windows Server), настроек домена, настроек пользователя, настроек ПО клиента.
В ранних версиях (Windows 2000, 2003) настраивали DES, в поздних (Windows 2008, 2012) рекомендуют использованием AES.
Настройки пользователя, оказывающие влияние на поведение Kerberos:
(TODO — при невключённых чекбоксах всё равно использовался AES128)
# krb5.ini
Файл не является обязательным, но может влиять на поведение процесса аутентификации.
Пример файла krb5.ini
# Настройка сервера
Данная инструкция сделана в окружении Windows Server2008R2 (контроллер домена), Windows Server2012R2 (RunaWFE Server), Windows7 (RunaWFE client).
В данном разделе регистр может иметь значение, хотя опытным путём было выяснено что логин пользователя, название компьютера сервера и SPN не являются регистрозависимыми.
# Создание пользователя для сервера
На контроллере домена нужно создать пользователя
Проверка: kinit должен успешно получить тикет.
# Создание SPN
На контроллере домена нужно выполнить команды:
Проверка: через ADSIEdit можно увидеть что свойство пользователя servicePrincipalName установлено либо посмотреть св-во servicePrincipalName с помощью команды Get-ADUser
Если планируется использовать SPN на основании NetBIOS имени — то нужно зарегистрировать и его (https://msdn.microsoft.com/en-us/library/ms677949.aspx)
# Привязка SPN к пользователю сервера
На контроллере домена нужно выполнить команду:
Можно игнорировать предупреждение «WARNING: pType and account type do not match. This might cause problems».
Для обхода бага со сбросом пароля https://support.microsoft.com/en-us/kb/939980 рекомендуют вписать пароль вместо звёздочки. А если выполнить данную команду без пароля — то почему-мо возникает ошибка 24 с некорректным salt.
Проверка: в свойствах пользователя User logon name стал равен SPN либо посмотреть св-во UserPrincipalName с помощью команды Get-ADUser
Проверка: kinit должен успешно получить тикет.
# Создание keytab для SPN
Выполнить команду из
Этот файл также можно получить в результате вызова команды ktpass на контроллере домена.
# Настройка kerberos.properties
Создайте файл kerberos.properties в директории
# Команды для выполнения по вышеперечисленным пунктам
На контроллере домена:
# Настройка браузера
Для того чтобы браузер пытался использовать Kerberos для аутентификации:
Во время запроса на сервере формируется в логе Request Authorization:
Если по нажатию на ссылке Сквозная аутентификация (kerberos) будет выведено окно с вводом логина/пароля — то это значит что браузер не получил сервисный тикет в контроллере домена или даже не пытался это сделать. При возникновении такой ситуации самым действенным оказывается использование WireShark для прослушивания траффика по порту 88 с контроллером домена.
# Настройка оповещателя
На сервере должна быть корректно настроена аутентификация.
# Настройка для получения заданий
Настроить kerberos.properties если authentication.type установлено в kerberos (для sspiKerberos это не требуется):
# Настройка для браузера
Настройку login.relative.url установить в /krblogin.do.
# Типичные проблемы
| ошибка | описание | что делать |
| Неправильный пароль либо несовпадение информации по логину (UserPrincipalName изменён?). Обратите внимание на атрибут salt в пакете KRB Error: KRB5KDC_ERR_PREAUTH_FAILED, он должен совпадать с principal, для которого вы получаете тикет; если не совпадает — то в БД kerberos что-то не так, попробуйте вновь воспользоваться командой ktpass Message stream modified (41) | Некорректно задано имя | Задать имя корректно — как оно задано на контроллере домена с учётом регистра |
| Пользователь заблокирован | В настройках пользователя снять галочку Account is disabled | |
| Заголовок превышает разрешённый максимум в Jboss, по умолчанию = 8Кб (https://access.redhat.com/solutions/1173073, http://www.novell.com/support/kb/doc.php?id=7005181) | Увеличить разрешённый максимум в Jboss с помощью настройки org.apache.coyote.http11.Http11Protocol.MAX_HEADER_SIZE в standalone.xml | |
| Настройка appName=com.sun.security.jgss.accept является устаревшей — для старых версий JDK | Изменить на com.sun.security.jgss.krb5.accept в kerberos.properties | |
| Нет поддержки типа шифрования AES-256 в JDK | Изменить тип шифрования (https://blogs.msdn.microsoft.com/openspecification/2011/05/30/windows-configurations-for-kerberos-supported-encryption-type/) или установить «Unlimited Strength Java(TM) Cryptography Extension Policy Files». |
Включение аудита на контроллере домена иногда помогает понять проблему (логирование происходит в журнале событий, категория Безопасность.