Я пытаюсь Kerberize Apache-сервера и разрешить созданному серверу-принципалу войти в Active Directory. Я следовал одному из многочисленных руководств, доступных в сети, и, кажется, все работает нормально. Я нахожусь на стороне Linux проекта, а Corporate IT — на стороне Windows.
IT предоставил мне учетную запись службы и принципал службы для нее. В этом примере я буду называть ее HTTP/[email protected]. Они предоставили мне файл keytab для указанного принципала, который включает запуск инструмента под названием ktpass.exe на сервере AD.
Я проверил, что KVNO AD/KDC и keytab-файл совпадают. Все хорошо.
Есть правильная DNS A-запись для имени хоста и правильная PTR-запись для IP. Оба сервера синхронизированы по времени.
Я могу запросить тикет у AD/KDC для вышеупомянутого принципала службы с выпущенным файлом keytab, например так:
kinit -k -t http.keytab HTTP/[email protected]
Это работает. Я получаю билет и могу использовать его для таких вещей, как запрос каталога AD/LDAP. Keytab также отлично работает для запуска сайта Apache Single Signon, что частично является целью этого упражнения.
Проходит полчаса.
Попытки войти в систему с помощью указанной выше команды kinit теперь завершаются неудачей с таким сообщением:
Client not found in Kerberos database
Я не могу пройти аутентификацию в качестве субъекта-службы, как будто субъект был удален на сервере AD.
Теперь это становится странным, по крайней мере для меня:
По запросу администратор AD снова запускает инструмент ktpass.exe, создавая новый файл keytab для моей службы. KVNO (номер версии ключа) увеличивается на сервере, из-за чего наш тестовый сервер Apache прекращает проверку единого входа Kerberos. Это ожидаемо при моей текущей конфигурации. Что удивило всех нас, так это то, что теперь команда kinit снова заработала. Мы выиграли себе еще полчаса, а затем она снова перестала работать.
Наш ИТ-отдел в растерянности, и они предполагают, что это проблема с самим сервером AD. Я думаю, это конфигурация, но, по их словам, нигде в их настройках нет ограничений на полчаса.
Я следилhttp://www.grolmsnet.de/kerbtut/(см. раздел 7), но метод, похоже, один и тот же во всей документации, которую я нашел. Я не нашел никаких ссылок на временные ограничения для принципалов обслуживания.
EDIT: Похоже, это проблема репликации. Хотя в процессе репликации не сообщается об ошибках, значение SPN учетной записи службы изменяется (возвращается?) с "HTTP/[email protected]" к "[email protected]" После 30 минут.
решение1
Спасибо за все ваши вклады, ребята. Мы привлекли Microsoft, и они помогли нам отладить процесс аутентификации на стороне AD. Все работало так, как и должно было, но через тридцать минут все вышло из строя.
Во время сеанса удаленной отладки один из участников заметил, что UPN/SPN учетной записи службы внезапно изменился сHTTP/[email protected]к[email protected]. После МНОГО копаний, включая отладку репликации AD, мы нашли виновника:
Кто-то создал скрипт, который запускался периодически (или, вероятно, по событию, поскольку это происходило ровно через тридцать минут после запуска ktpass.exe), и который обновлял UPN/PSN до«обеспечить подключение к облаку». У меня нет дополнительной информации о причинах этого.
Скрипт был изменен, чтобы разрешить существующим значениям UPN/SPN заканчиваться на@mycorp.com, эффективно решая проблему.
Советы по отладке подобных проблем:
- Убедитесь, что все участники аутентификации поддерживают одинаковые типы шифрования. Избегайте DES — он устарел и небезопасен.
- Обязательно включите шифрование AES-128 и AES-256 в учетной записи службы.
- Имейте в виду, что включение DES в учетной записи службы означает«использовать ТОЛЬКО DES для этой учетной записи», даже если вы включили любое из AES-шифрований. Выполните поискUF_USE_DES_KEY_ONLYдля получения подробной информации по этому вопросу.
- Убедитесь, что значение UPN/SPN является правильным и соответствует значению в выданном файле keytab (например, с помощью поиска LDAP).
- Убедитесь, что KVNO (номер версии ключа) в файле keytab совпадает с номером на сервере.
- Проверьте трафик между сервером и клиентом (например, с помощью tcpdump и/или WireShark)
- Включить отладку аутентификации на стороне AD — проверить журналы
- Включить отладку репликации на стороне AD — проверить журналы
Еще раз спасибо за ваш вклад.
решение2
Я также изучил Kerberos, начав с руководства Ахима Гролмса mod_auth_kerb, действительно хорошего документа.
Файл keytabзаменяет только аутентификацию по паролю. Пароль закодирован в файле, и эти байты используются при проверке подлинности с помощью KDC. Любое изменение пароля в учетной записи службы сделает аутентификацию keytab недействительной, а также увеличит номер kvno.
Чтобы подтвердить доступность SPN-имени учетной записи службы, я часто провожу аутентификацию с паролем учетной записи службы:
kinit HTTP/[email protected]
В случае неудачи, чтобы убедиться, что учетная запись службы не отключена, попробуйте выполнить базовую аутентификацию:
kinit account
Если не удалось пройти аутентификацию, просто удалите учетную запись и создайте новую с другим именем пользователя, чтобы избежать проблем.
Существует высокая вероятность того, что другое программное обеспечение (например, другая система со старым сгенерированным keytab для того же SPN) попытается выполнить аутентификацию в этой учетной записи службы и отключит ее из-за неверного пароля.
При настройке Kerberos SSO слишком быстрые операции могут привести к несоответствиям в Active Directory. Мое общее руководство при застревании в процессе настройки — выполнить следующие шаги:
- удалить «старые» или «неработающие» учетные записи служб для тестовых и производственных систем
- проверьте,
kvnoне существует ли в области SPN, который вы ожидаете настроить - проверьте,
setspn -Xнет ли конфликтующих SPN на нескольких аккаунтах - создать одну учетную запись службы для каждой системы, выделенную для одного полностью квалифицированного имени SPN, с совершенно новым именем входа
- предотвратить изменение пароля и истечение срока действия пароля в учетной записи службы
- давайте немного подождем для синхронизации постоянного тока
- установить пароль как
ktpassопцию при генерации keytab - проверьте FQDN SPN и псевдонимы с помощью
setspn -l account
Вот набор команд для настройки учетной записи службы на DC:
ktpass -princ HTTP/[email protected] -mapuser [email protected]
-crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL
-pass long!$longp2ass3word -out c:\temp\http-mysite-mycorp-com.keytab
setspn -a HTTP/mysite mysiteAccount
setspn -l mysiteAccount
Если операции выполняются слишком быстро на разных DC между MMC и запуском ktpass для генерации keytab в административной командной строке, то синхронизация DC может привести к неожиданным результатам, подобным описанному вами. Так что давайте подождем некоторое время между созданием учетной записи и последующими ktpassдополнительными setspnкомандами.
И команды для запуска в Linux, чтобы проверить, что все работает правильно:
kinit [email protected]
kinit HTTP/[email protected]
kinit -k -t http-mysite-mycorp-com.keytab HTTP/[email protected]
kvno HTTP/mysite.mycorp.com
kvno HTTP/mysite