Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 24
Спасибо за такой проделанный труд. стало больше понимания в этом вопросе.
RC4 не чувствителен к соли – и поэтому скрывает ошибки в AES-записях. Keytab "работает" через RC4, после отключения RC4 в AD ломается – и причина именно в неверной соли AES, которая копилась незаметно.
-pass ABCDF@password
-pass "ABCDF@password"Пароль учетной записи, из которого будет рассчитан ключ. Равнозначные конструкции, кавычки не будут включены в пароль.
-pass 'ABCDF@password'Неправильный вариант, кавычки будут включены в пароль.
как интерпретируются кавычки зависит от оболочки, — если ktpass.exe запускать из PowerShell, то одинарные кавычки не попадут в пароль
Я дочитал очень внимательно. Потому что у меня совсем недавно в рамках проекта по интеграции AD + Kerberos для Оракловских БД возникла такая проблема - как создать 1 аккаунт в AD и 1 keytab, содержащий несколько SPN - и чтобы всё работало. Весь интернет забит примерами "1svc -1keytab-1spn", но нигде-нигде не описана пошаговая стратегия создания РАБОЧЕГО keytab, со множеством SPN. Все предыдушие пробы с многократным запуском ktpass приводили к тому, что рабочим был лишь один SPN, который использовался в последней ktpass команде.
Оракловская поддержка вообще заявила, что сие действо принципиально невозможно. Но это Оракловская поддерждка, им можно так говорить, они 30 000 человек уволили, заменив на какой-то беспробудно тупой AI.
Вот, собирался провести такой эксперимент, используя какой-то мутный метод с помощью "1 раз ktpass, потом запускать ktutil на Mac/Linux, добавляя записи в keyttab". Очень не уверен, что метод сработает. Но вот в Вашей статье очень внятно описан метод создания именно такого keytab, который мне нужен. Если сработает - буду выяснять какой коньяк нравится автору статьи :)
Сейчас скормлю статью своему помощнику в лице Claude Code - пусть он проникется знанием и пишет новый план создания работающей схемы "1 svc AD account -> 1 keytab -> multiple SPNs", потом опробую на тестовом кластере
Если рабочим получался только последний SPN, это скорее всего результат отсутствия ключа -setupn. Буду рад, если всё получится. Добавлю ещё, что в Linux есть утилита ktutil, позволяющая склеивать несколько keytab, удалять отдельные строки. Не очень удобная, но примитивная.
Да, я написал в своём комменте про ktutil - чтобы дать Вам понять всю глубину моего отчаяния :) Потому что перспектива иметь сотни AD аккаунтов с сотнями keytab для сотен БД - ну так себе решение, пусть и рабочее.
Точно, невнимательно читал. Я начал ей пользоваться в основном для склейки keytab из разных realm.
Но.. Что касается примера от Kaspersky, то в Microsoft так не делают. В приведенной конфигурации было бы 3 учетные записи, по одной на узел кластера и общая с именем и SPN кластера. А вот keytab было бы два, server1 + clustername и server2 + clustername. Более того, почти всю эту красоту можно было бы сделать с adcli, подклеив только кластерный SPN. Но где красота, а где Kaspersky )
Написал вам в личку, если хотите сделаем.
ktpass -in many.keytab -out many.keytab каждый раз, а задавать SPN через -princ и -password от той УЗ, которой назначен SPN. Соль соответственно должна быть задана в ‘REALMusername’ если на УЗ стоит флаг AES128/256. Вкратце вся инструкция.
Вкратце так и не заработает, если нужен upn равный spn. А он выглядит не как REALMusername. Для компьютерной учётки тоже не такая соль, но здесь ktpass не промахивается.
а нафига UPN=SPN? Особенно если как ТС написал, что у него много SPN на одной учетке. Реально, НАФИГА его устанавливать во что-то отличное от SAMAccountName@domain.fqdn?
Потому что
Можно при помощи одной строки keytab и расшифровать билет, и аутентифицироваться - получить tgt. Эта возможность часто используется.
некоторый софт, такой как kswts, не принимает upn$
это поведение ktpass по умолчанию, позволяющее выпустить правильный keytab из коробки. К сожалению, разработчики не научили ее брать автоматом upn от -princ
это чёрная магия, которую стоит всеми силами избегать, потому что согласно официальной документации самого MS, в поле UPN должно быть что-то похоже на e-mail, адрес по формату RFC-822:
This attribute contains the UPN that is an Internet-style login name for a user based on the Internet standard RFC 822
Зачем портить UPN, если достаточно задать AES-соль равной ‘REALMusername’? Да, придется каждый раз её именно в таком виде прописывать, но зато оффлайн-генерация будет работать хоть в каком углу (если правильно задать на входе пароль от учетной записи). Не первый раз воюем с одним доменом, где доступ дают по великим праздникам, и проблемой является даже узнать KVNO (как результат, логируем ошибки Kerberos если прилетел неизвестный KVNO и создаем новый кейтаб с полученным номером), и там такая возможность была за большое благо.
Отвечал на это вопрос в статье. Обычно это делается для того, что с одной строкой keytab можно было как расшифровать tgs, так и получать tgt, если сервис куда-то обращается. Но всё верно, можно красивее. Толко, к слову, Kaspersky KWTS принципиально не хочет обращаться к ldap с upn$@REALM. Понятие красоты им неизвестно.
Ну дык получать tgt в большинстве случаев излишество, а ради него править UPN нелогично. Скажем аутентификация на веб-сайте - зачем сервису веб-сайта запрашивать тикеты самому? Юзер получил тикет для SPN HTTP/fqdn@REALM и презентовал его сервису, сервис его корректно расшифровал - профит, зачем куда-то дальше ходить? Может у меня кругозор невелик, и где-то есть веб-сервисы, которые должны от текущего пользователя ещё куд-то ломиться, но во-первых зачем, во-вторых что мешает назначать роли на веб-сервисе вместо какого-то там бэка?
Примеры - Kaspersky web traffic security, Kaspersky secure mail gateway, Kaspersky security center. Всё три сервиса поддерживают аутентификацию в своем веб интерфейсе по Kerberos, и каждый из них может ходить в ldap каталог для синхронизации групп и т.п.
Аналогичная ситуация скорее всего может возникать в linux с ssh gssapi и sssd. Сначала надо извлечь из билета principal, а потом в ldap выяснить применимые к нему политики входа.
Можно как-то выделить tldr по созданию правильных кейтабов?
Заметим, что последней из версий Windows, которая не поддерживала AES-SHA1, была Windows Server 2003.
Сами учётки без AES-SHA1 встречаются даже в свежих доменах на Windows Server 2012 R2 и отвалились после апрельского обновления с отключенным RC4.
Хотел сказать, что каждый делает под свою задачу, но, действительно, попробую свести всю эту писанину примерно к трём вариантам.
TL;DR
Об алгоритмах
Не выпускайте ключи RC4, это уже не актуально. Ориентируйтесь на наиболее криптостойкий алгоритм AES256. Для учетной записи компьютера установите параметр msDS-SupportedEncryptionTypes в 16 (0x10), для учетной записи пользователя установите соответствующую галочку.
О соли и KVNO
Если выпускается ключ для учетной записи компьютера - ktpass сам правильно сформирует соль.
Если выпускаете ключ для пользовательской учетной записи:
Корректная соль формируется ktpass только если вы не используете ключ -setupn или задаете ключ +setupn. В других случаях необходимо вручную задать соль в формате
<login>@REALM, соблюдая регистр.Если вы добавляете ещё один SPN к имеющемуся keytab (ключ -in), используйте соль из первого шага. Её можно дополнительно вывести на первом шаге ключом
+dumpsaltВсегда используйте ключ-setpassи вводите пароль учетной записи из первого шага. Это обеспечит сохранение KVNO. Убедитесь, что фактическое значение KVNO и ключей нового SPN совпадает со значением KVNO ключей на первом шаге.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Самое подробное руководство по использованию утилиты ktpass в среде Active Directory