Вопрос или проблема
Я исследовал проблему на своем ноутбуке, когда вход с использованием моих учетных данных Hello for Business перестал работать и начал выдавать ошибку. Я смог решить это после нескольких недель устранения неполадок, но не знаю, почему мне пришлось исправить это таким образом и есть ли более простой способ.
У нас есть двухуровневая служба сертификатов Active Directory и отдельный сервер IIS для публикации нашего списка отозванных сертификатов. Мы используем смешанные устройства и WHfB настроен с использованием доверия к ключам.
Проблема началась с ошибки входа при использовании учетных данных WHfB:
Не удалось войти в систему. Свяжитесь с вашим системным администратором и сообщите им, что сертификат KDC не может быть проверен. Дополнительная информация может быть доступна в системном журнале событий.
Я просмотрел онлайн-блоги и статьи Microsoft, которые касаются обычных моментов, связанных с недействительным сертификатом контроллера домена или отсутствием конфигурации расширенного использования ключей (т.е. аутентификация KDC). Все было в порядке.
Также были системные журналы событий на моем ноутбуке с этой ошибкой:
Идентификатор события 9, Источник: Security-Kerberos.
Клиент не смог проверить сертификат контроллера домена для <контроллер домена>. Следующая ошибка была возвращена из процесса проверки сертификата: Функция отзывов не смогла проверить отзыв, так как сервер отзывов был недоступен.
Я проверил нашу конфигурацию CA, настройки отзыва и настройки CRL IIS, чтобы подтвердить, что они работают, и что CRL была разрешима и доступна. Все работало при тестировании в браузере, поэтому казалось, что CRL была в сети. Вопреки тому, что говорил Идентификатор события 9.
Я начал запускать захват пакетов и блокировал ноутбук, пытаясь выполнить аутентификацию WHfB. Я смог увидеть, как ноутбук пытается получить CRL:
GET /CertEnroll/CertAuthorityRoot.crl HTTP/1.1
Сервер IIS, размещающий CRL, возвращал ответ 304 Не изменено:
HTTP/1.1 304 Не изменено
Я понимаю, что 304 – это то, что сервер IIS возвращает, если файл не изменился и направляет запрашивающее устройство смотреть на кэшированные файлы.
Мой вывод в том, что мой ноутбук пытался получить CRL при входе, но сервер IIS говорил моему ноутбуку, что он не нуждается в этом, потому что он не был изменен. Поэтому мой ноутбук предположил, что не может связаться с сервером.
Мое решение заключалось в том, чтобы запустить нашу офлайн CA, опубликовать новый файл CRL и разместить его на нашем сервере CRL IIS. Когда мой ноутбук снова попытался аутентифицироваться, сервер IIS с радостью предоставил его.
Я хотел бы понять, почему мой ноутбук вдруг снова понадобился файл CRL после того, как он работал так долго, а затем почему сервер IIS отказался позволить моему ПК снова скачать его.
После повторной выдачи файла CRL я нашел команду certutil для перечисления кэшированных URL:
certutil -urlcache CRL
Интересно, не было ли какой-то поврежденной CRL, но сейчас нет возможности это проверить.
У кого-то еще была что-то подобное?
Самая очевидная причина – истекший CRL.
- У вас есть офлайн корневая CA (которая не может автоматически публиковать CRL в точках распространения)
- Ситуация начала исправляться после перезагрузки офлайн CA и публикации CRL
Это предполагает, что предыдущий CRL истек. Истекшие CRL вызывают то же сообщение об ошибке (отзыв не доступен).
Чтобы избежать этой проблемы в будущем, вам необходимо установить мониторинг и оповещение о CRL офлайн CA, чтобы заранее получать уведомления о CRL, которые вот-вот истекут, и внедрить процесс, который вы будете выполнять для продления CRL в точках распространения.
Я видел эту проблему из-за того, что ноутбук меняет сеть (DirectAccess VPN), и в течение короткого периода времени список CRL не будет работать из-за прерывания сети. Если конечный пользователь подождет немного, пока DA не будет в сети, все будет работать.
Ответ или решение
Проблема с проверкой KDC сертификата в Hello for Business: причины и решение
Введение
Недавний инцидент с использованием Windows Hello для бизнеса (WHfB) привел к возникновению ошибки при авторизации: "Не удалось войти. Свяжитесь с вашим системным администратором и сообщите, что сертификат KDC не может быть проверен." Данная проблема была решена после переиздания списка отзыва сертификатов (CRL), однако необходимо разобраться, почему это произошло и как избежать подобных ситуаций в будущем.
Контекст проблемы
Вы используете модель гибридного присоединения устройств к Active Directory с настроенной системой ключевого доверия (key trust). В вашей инфраструктуре развернута двухуровневая структура Центров сертификации (CA), и вы используете отдельный IIS сервер для публикации CRL. Проблема возникла, когда на ноутбуке была зафиксирована ошибка при аутентификации с использованием WHfB. Сообщение об ошибке указывало на невозможность проверки сертификата KDC и ссылалось на журнал событий.
Анализ проблемы
-
Ошибка в журнале событий: Журнал событий на ноутбуке фиксировал ошибку:
Event ID 9, Source: Security-Kerberos. The client has failed to validate the domain controller certificate for <domain controller>. The following error was returned from the certificate validation process: The revocation function was unable to check revocation because the revocation server was offline.Это указывает на то, что система не могла проверить статус сертификата, так как не могла обратиться к CRL.
-
Проблемы с CRL: Проведенный вами анализ показал, что IIS сервер публиковал CRL, и доступ к нему был возможен через браузер. Однако во время аутентификации ноутбук получал ответ 304 Not Modified от IIS, что могло означать, что CRL не был обновлен, а значит, кэшированный статус мог оказаться устаревшим.
-
Обновление CRL: После переиздания CRL и его размещения на IIS сервере, ноутбук смог успешно выполнить аутентификацию. Это подтверждает, что прежний CRL истек и система не обнаружила его в актуальном состоянии.
Возможные причины
- Истечение сроков действия CRL: Наиболее вероятная причина данной проблемы — это истечение срока действия CRL. Оффлайн корневой CA не мог автоматически обновлять CRL, что и привело к необходимости ручного вмешательства.
- Проблемы с сетью: Часто бывает, что при изменении сети (например, при использовании DirectAccess или VPN) происходит сбой в доступе к CRL. Это может вызвать временные проблемы, когда пользователь не может аутентифицироваться до восстановления сетевого соединения.
Рекомендации по предотвращению проблем
-
Мониторинг и уведомления: Настройте систему мониторинга и алертинга для отслеживания сроков действия CRL на вашем оффлайн CA. Это позволит вам заранее получать уведомления об истечении сроков и принимать меры.
-
Процедуры планирования обновления: Разработайте четкую процедуру обновления CRL на всех точках распространения. Это должно включать в себя регулярные проверки и автоматизацию, где это возможно.
-
Проверка кэша CRL: Регулярно проверяйте кэшированный статус CRL на устройствах с помощью команды:
certutil -urlcache CRLЭто может помочь в обнаружении поврежденных или устаревших кэшей до возникновения проблем.
Заключение
Проблема с аутентификацией при использовании WHfB связана с истечением срока действия CRL и необходимостью его переиздания. Принятые меры по мониторингу и обновлению CRL помогут предотвратить подобные инциденты в будущем, что позволит обеспечить бесперебойную работу вашей инфраструктуры. Важно помнить о регулярном обслуживании и проверке сертификационных систем для минимизации рисков.