Я пытаюсь керберизовать Apache-сервер и разрешить созданному участнику сервера войти в Active Directory. Я следил за одним из многочисленных руководств, доступных в Интернете, и, похоже, он работает нормально. Я работаю на стороне Linux, а корпоративные ИТ - на стороне Windows.
ИТ-служба предоставила мне учетную запись службы и принципала службы для нее. В этом примере я буду называть его HTTP/mysite.mycorp.com@MYCORP.COM. Они предоставили мне файл keytab для указанного принципала, который включает запуск инструмента под названием ktpass.exe на сервере AD.
Я проверил, что KVNO AD / KDC и файла keytab совпадают. Все хорошо.
Есть правильная A-запись DNS для имени хоста и правильная запись PTR для IP. Оба сервера синхронизированы по времени.
Я могу запросить билет в AD / KDC для вышеупомянутого принципала службы с выданным файлом keytab, например:
kinit -k -t http.keytab HTTP/mysite.mycorp.com@MYCORP.COM
Это работает. Я получаю билет и могу использовать его для таких вещей, как запрос каталога AD / LDAP. Keytab также отлично подходит для работы с сайтом единой регистрации Apache, что отчасти является целью этого упражнения.
Проходит полчаса.
Попытки войти в систему с помощью указанной выше команды kinit теперь завершаются ошибкой с этим сообщением:
Client not found in Kerberos database
Я не могу пройти аутентификацию в качестве субъекта-службы, как если бы субъект был удален на сервере AD.
Теперь это становится странным, по крайней мере, для меня:
По запросу администратор AD снова запускает инструмент ktpass.exe, создавая новый файл keytab для моей службы. KVNO (номер версии ключа) увеличивается на сервере, в результате чего наш тестовый сервер Apache перестает проверять единый вход Kerberos. Это ожидается с моей нынешней конфигурацией. Что удивило всех, так это то, что теперь команда kinit снова заработала. Купили себе еще полчаса, а потом опять перестало работать.
Наш ИТ-отдел здесь в растерянности, и они предполагают, что это проблема самого сервера AD. Я думаю, это конфигурация, но, по их словам, в их настройках нет ограничений на полчаса.
Я следил http://www.grolmsnet.de/kerbtut/ (см. раздел 7), но этот метод кажется одинаковым во всей документации, которую я нашел. Я не нашел никаких ссылок на ограничения по времени для принципалов обслуживания.
РЕДАКТИРОВАТЬ: похоже, это проблема репликации. Хотя в процессе репликации ошибок не сообщается, значение SPN учетной записи службы изменяется (возвращается?) С «HTTP/mysite.mycorp.com@MYCORP.COM» на «name-of-service-account@mycorp.com. " После 30 минут.
Спасибо за ваш вклад, ребята. У нас есть Microsoft, и они помогли нам отладить процесс аутентификации на стороне AD. Все заработало как положено, но через тридцать минут вышло из строя.
Когда мы выполняли сеанс удаленной отладки, один из участников заметил, что UPN / SPN учетной записи службы внезапно изменилось с HTTP/mysite.mycorp.com@MYCORP.COM к service-account@mycorp.com. После долгих поисков, включая отладку репликации AD, мы обнаружили виновника:
Кто-то создал сценарий, который запускался периодически (или, вероятно, по событию, поскольку это было ровно через тридцать минут после запуска ktpass.exe), который обновлял UPN / PSN до "обеспечить подключение к облаку". У меня нет дополнительной информации о причинах этого.
Сценарий был изменен, чтобы разрешить существующие значения UPN / SPN, оканчивающиеся на @ mycorp.com, эффективно решая проблему.
Советы по устранению подобных проблем:
Еще раз спасибо за ваш вклад.
Я также выучил Kerberos, начиная с Ахима Гролмса. mod_auth_kerb учебник, действительно хорошая документация.
В keytab файл только заменяет аутентификацию по паролю. Пароль закодирован в файле, и эти байты используются при проверке подлинности с помощью KDC. Любое изменение пароля для учетной записи службы приведет к аннулированию аутентификации keytab, а также увеличит число квно.
Чтобы подтвердить, что SPN сервисной учетной записи доступен, я часто аутентифицируюсь с паролем сервисной учетной записи:
kinit HTTP/mysite.mycorp.com@MYCORP.COM
В случае неудачи, чтобы подтвердить, что учетная запись службы не отключена, попробуйте обычную аутентификацию:
kinit account
Если не удается пройти аутентификацию, просто удалите учетную запись и создайте новую с другим именем для входа, чтобы избежать проблем.
Существует высокая вероятность того, что другая часть программного обеспечения - например, другая система со старой сгенерированной ключевой таблицей для того же SPN - попытается пройти аутентификацию в этой учетной записи службы и отключит ее из-за неверного пароля.
При настройке единого входа Kerberos слишком быстрые операции могут привести к несогласованности в Active Directory. Когда я застреваю в процессе настройки, я рекомендую выполнить следующие действия:
kvno имя участника-службы, которое вы ожидаете настроить, больше не существует в областиsetspn -X на нескольких аккаунтах нет конфликтных SPNktpass опция при генерации keytabsetspn -l accountВот набор команд для настройки учетной записи службы на DC:
ktpass -princ HTTP/mysite.mycorp.com@MYCORP.COM -mapuser mysiteAccount@MYCORP.COM
-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
Если операции выполняются слишком быстро на разных контроллерах домена между MMC и запущенным ktpass для генерации keytab в административной командной строке, то синхронизация контроллеров домена может привести к неожиданным результатам, подобным описанному вами. Итак, давайте немного подождем между созданием учетной записи, а затем ktpass и любые дополнительные setspn команды.
И команды для запуска в Linux, чтобы проверить, что все работает правильно:
kinit mysiteAccount@MYCORP.COM
kinit HTTP/mysite.mycorp.com@MYCORP.COM
kinit -k -t http-mysite-mycorp-com.keytab HTTP/mysite.mycorp.com@MYCORP.COM
kvno HTTP/mysite.mycorp.com
kvno HTTP/mysite