В настоящее время я работаю над внедрением центра сертификации предприятия для клиента, сеть которого не полностью подключена; он охватывает несколько географических сайтов, и некоторые из них не имеют маршрутизации к сайту, где расположен центр сертификации.
Чтобы обойти это, я использовал Веб-служба регистрации сертификатов, что позволяет регистрировать сертификаты через HTTPS; служба предоставляется через общедоступное имя и IP-адрес, и компьютеры на удаленных сайтах могут получить к ней доступ.
Решение отлично работает со всеми видами сертификатов; однако контроллеры домена на удаленных сайтах не могут получить сертификат с использованием шаблона «Проверка подлинности Kerberos» (который последние контроллеры домена пытаются использовать при включенной автоматической регистрации); ошибка общего характера "сервер RPC недоступен", но это происходит на самом CA, попадая в неудавшиеся запросы.
Это озадачило меня некоторое время, пока я не решил взглянуть на сетевой трафик; о чудо, кажется, что когда делается запрос на сертификат с использованием шаблона «Проверка подлинности Kerberos», ЦС пытается подключиться обратно к контроллеру домена, который сделал запрос. Это невозможно в клиентской сети, и, похоже, это причина сбоя запроса.
Я предполагаю, что ЦС пытается проверить, действительно ли компьютер, запрашивающий сертификат, является контроллером домена; однако я не смог найти для этого никакой документации, и такой «обратный вызов» кажется противоречащим клиент-серверной логике запросов сертификатов.
Это поведение где-нибудь задокументировано?
Можно его выключить?
O.S. в ЦС стоит Windows Server 2019.
В лесу AD есть четыре домена; ЦС находится в корневом домене леса.
Поведение одинаково для всех контроллеров домена во всех доменах: всякий раз, когда делается запрос на сертификат «аутентификации Kerberos», вручную или через автоматическую регистрацию, центр сертификации пытается связаться с запрашивающим контроллером домена через порты 445 и 139 (как ни странно, существует нет фактического трафика LDAP, Kerberos или RPC); когда это не удается, запрос отклоняется с ошибкой «отказано модулем политики» и кодом состояния «сервер RPC недоступен».
Это происходит только для сертификатов «Проверка подлинности Kerberos»; все остальные сертификаты могут быть успешно зарегистрированы через CES, включая «Аутентификацию контроллера домена» и «Репликацию электронной почты каталога».
Я также протестировал это для контроллеров домена, которые действительно могут взаимодействовать с центром сертификации: если трафик от контроллера домена к центру сертификации заблокирован, что вынуждает запрос использовать CES, но не наоборот, запросы завершаются успешно; если трафик от CA к DC заблокирован, запрос не выполняется.
Согласно документации, поведение, с которым вы столкнулись, является ожидаемым и не может быть отключено. Kerberos Authentication требуется RPC-соединение от CA к DC. Какие варианты для вас:
Domain Contoller Authentication шаблон сертификата вместо Kerberos Authentication шаблон. Domain Contoller Authentication шаблон не требует подключения RPC обратно к DC.На самом деле, я не запомнил всех деталей и похвал за то, что вы провели хорошее расследование и указали на неудачный обратный вызов RPC, это действительно уменьшило количество возможных причин. Подробная информация о том, почему это происходит, приводится ниже.
В первую очередь о шаблонах сертификатов: оба, Domain Controller Authentication и Kerberos Authentication шаблоны используются для поддержки LDAPS (LDAP через TLS) и взаимная проверка подлинности при входе в систему с сертификатом / смарт-картой.
Разница между двумя состоит в том, как строится предмет или что в него входит. Domain Controller Authentication включает полное доменное имя контроллера домена только в расширение SAN. Kerberos Authentication добавляет еще два имени: FDQN и NetBIOS-имена домена. К тому же, Kerberos Authentication добавляет KDC Authentication ЭКУ. Конфигурация шаблона по умолчанию определяется в [MS-CRTD], Приложение A. Чтобы быть более ясным:
Domain Controller Authentication имя субъекта имеет комбинацию флагов 134217728 (0x8000000), которая преобразуется только в флаг: CT_FLAG_SUBJECT_ALT_REQUIRE_DNS
Kerberos Authentication имя субъекта имеет комбинацию флагов 138412032 (0x8400000), которая переводится в два флага: CT_FLAG_SUBJECT_ALT_REQUIRE_DNS и CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS.
Флаги имени субъекта хранятся в msPKI-Certificate-Name-Flag атрибут ([MS-CRTD] §2.28).
Проблема в вашем вопросе вызвана требованием в SAN включать полное доменное имя домена и имена NetBIOS. Kerberos Authentication шаблон - единственный шаблон по умолчанию, который использует CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS флаг.
Windows CA использует [MS-WCCE] спецификация протокола для обработки запросов и выдачи сертификатов. Этот протокол полностью определяет поведение клиента и небольшую часть взаимодействия и поведения Windows CA. [MS-WCCE] §3.2.2.1.3 определяет специальное поведение для клиентов, которые являются контроллерами домена и подготавливают свое имя для подготовки к RPC-соединению, добавляя перед своим именем «\\».
Центр сертификации Windows обрабатывает CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS как указано в [MS-WCCE] §3.2.2.6.2.1.4.5.9.
Если
CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNSустановлен флаг, ЦС ДОЛЖЕН:
- ЦС ДОЛЖЕН получить дескриптор информационной политики с помощью метода LsarOpenPolicy ([MS-LSAD] раздел 3.1.4.4.2), с
SystemNameпараметр установлен какdNSHostNameатрибута из компьютерного объекта запрашивающей стороны, все поляObjectAttributesустановлен вNULL, аDesiredAccessпараметр установлен наPOLICY_VIEW_LOCAL_INFORMATION.- ЦС ДОЛЖЕН получить информацию о домене DNS компьютера запрашивающей стороны с помощью
LsarQueryInformationPolicyметод ([MS-LSAD] раздел 3.1.4.4.4), сPolicyHandleпараметр установлен на значение, полученное на предыдущем шаге, аInformationClasпараметр s установлен наPolicyDnsDomainInformation.- ЦС ДОЛЖЕН добавить значение
NameиDNSDomainNameполе в возвращенной информации о домене DNS с предыдущего шага на расширение альтернативного имени субъекта выданного сертификата.
Как вы видете, LsarOpenPolicy Вызов действительно является вызовом RPC и в случае успеха возвращает дескриптор соединения RPC. В вашем случае этот вызов не выполняется, и CA не может позвонить LsarQueryInformationPolicy (это снова вызов RPC!), чтобы получить требуемые имена для вставки в сертификат.
Может возникнуть желание отключить полное доменное имя домена и NetBIOS имя домена в Kerberos Authentication шаблон, но я бы не рекомендовал это. Не пытаюсь добавить KDC Authentication ЭКУ в Domain Controller Authentication, потому что первый строго зависит от наличия полного доменного имени домена и NetBIO, что вызывает проблемы в вашей среде.
Чтобы обойти обратный вызов RPC на ваш DC, вы можете продублировать шаблон Kerberos и добавить SAN вручную. Затем включите автопродление.
Вот шаги -
Настроить шаблон:
продублируйте шаблон Kerberos
настройте имя темы новых шаблонов на «предоставить в запросе»
На вашем WES:
iisreset, чтобы обновить список шаблонов
Зарегистрируйте сертификат:
На изолированном контроллере домена зарегистрируйте сертификат и добавьте доменные имена в расширение SAN (это не приведет к обратному вызову RPC из центра сертификации в контроллер домена).
(Если вы не видите шаблон, очистите локальный кеш WES в C: \ ProgramData \ Microsoft \ Windows \ X509Enrollment)
Включите автоматическое продление (через GPO):
Параметры Windows> Параметры безопасности> Политики открытого ключа> Клиент служб сертификации - Автоматическая регистрация. Достаточно отметить только «Продлить просроченные сертификаты, обновить ожидающие сертификаты и удалить отозванные сертификаты».
Тестирование автоматического продления:
В новом шаблоне щелкните правой кнопкой мыши и выберите «Повторно зарегистрировать всех держателей сертификатов». Это увеличит основную версию шаблона и приведет к принудительному обновлению сертификата при следующем цикле автоматической регистрации (один раз в 8 часов).
Если не хотите ждать - сбросьте WES, удалите локальную папку x509enrollment и запустите certutil -pulse.
Удачи