Здравствуйте, ошибка сертификата KDC для Hello for Business. Проблема решена после переиздания списка отозванных сертификатов. Пытаюсь понять, почему.

Я исследовал проблему, которая возникла неожиданно на моем ноутбуке, когда вход с использованием учетных данных Hello for Business перестал работать и началась выдача ошибки. Мне удалось решить эту проблему после нескольких недель устранения неполадок, но я не знаю, почему мне пришлось исправить это именно так и есть ли лучший способ.

У нас есть двухуровневая иерархия для нашего Центра сертификации Active Directory и отдельный сервер IIS для публикации нашего списка отозванных сертификатов. Мы используем гибридно присоединенные устройства, и WHfB настроен с использованием доверия к ключам.

Проблема началась с ошибки входа при использовании учетных данных WHfB:

Не удалось войти. Свяжитесь с вашим системным администратором и сообщите ему, что сертификат KDC не удалось подтвердить. Дополнительная информация может быть доступна в системном журнале событий.

Я просмотрел несколько онлайн блогов и статьи Microsoft, которые охватывают обычные моменты, такие как недействительность сертификата контроллера домена или отсутствие конфигурации использования расширенного ключа (т.е. аутентификация KDC). Все было в порядке.

В системных журналах событий на моем ноутбуке была зафиксирована эта ошибка:

Идентификатор события 9, Источник: Security-Kerberos.

Клиент не смог подтвердить сертификат контроллера домена для <контроллер домена>. Возвращена следующая ошибка из процесса проверки сертификата: Функция отзыва не смогла проверить отзыв, так как сервер отзыва был недоступен.

Я проверил конфигурацию нашего центра сертификации, настройки отзыва и настройки CRL на IIS, чтобы подтвердить, что они работают, и CRL были разрешимы и доступны. Все работало при тестировании в браузере, поэтому казалось, что CRL в сети. Вопреки тому, что говорилось в идентификаторе события 9.

Я начал делать захваты пакетов и блокировал ноутбук, пытаясь выполнить аутентификацию WHfB. Я смог увидеть, как ноутбук пытался получить CRL:

GET /CertEnroll/CertAuthorityRoot.crl HTTP/1.1

Сервер IIS, хранящий CRL, возвращал ответ 304 Not Modified:

HTTP/1.1 304 Not Modified

Мое понимание заключается в том, что 304 — это то, что сервер IIS возвращает, если файл не изменился, и направляет запрашивающее устройство посмотреть кэшированные файлы.

Таким образом, вывод, который я сделал, состоит в том, что мой ноутбук пытался получить CRL при входе, но сервер IIS говорил моему ноутбуку, что он не нужен, поскольку не был изменен. Поэтому мой ноутбук предположил, что он не может связаться с сервером.

Мое решение заключалось в том, чтобы запустить наш автономный CA, опубликовать новый файл CRL и поместить его на наш сервер CRL IIS. Когда мой ноутбук снова попытался аутентифицироваться, сервер IIS любезно предоставил его.

Мне действительно хотелось бы понять, почему мой ноутбук внезапно снова нуждался в файле CRL после долгого времени работы, а затем почему сервер IIS отказался позволить моему ПК загрузить его снова.

Только после повторной выдачи файла CRL я нашел команду certutil для перечисления кэшированных URL

certutil -urlcache CRL

Интересно, не было ли какого-то поврежденного CRL, но теперь уже нет возможности это проверить.

У кого-то еще была похожая ситуация?

Наиболее очевидная причина — истекший CRL.

1. У вас есть автономный корневой CA (который не может автоматически публиковать CRL в точки распределения)
2. Все начало работать после загрузки автономного CA и публикации CRL

Это указывает на то, что предыдущий CRL истек. Истекшие CRL вызывают то же сообщение об ошибке (отзыв недоступен).

Чтобы избежать этой проблемы в будущем, вам необходимо установить мониторинг и оповещение CRL для автономного CA, чтобы заранее получать уведомления об истечении срока действия CRL и реализовать процесс, который вы будете выполнять для обновления CRL в точках распределения.