Вопрос или проблема
Я создал новую иерархию PKI 2022 года в нашей среде, из которой я хотел бы начать выдачу сертификатов контроллера домена (шаблоны Kerberos Auth, DirectoryEmailReplication). Проблема в том, что ни один из контроллеров домена не запрашивает сертификаты.
Я создал серверную ферму IIS с новым CEP и CES, которые указывают на новый контроллер домена CA. Вместе с ним я создал CES, который указывает на CA, выдающую сертификаты устройств (шаблоны Workstation и Remote Desktop).
Конфигурация CES, которая выдает сертификаты устройств, работает нормально, и контроллеры домена могут даже запрашивать эти сертификаты, если я даю им разрешения на автоматическую регистрацию. Если я перейду в консоль mmc для ручного запроса сертификата, она будет выводить только шаблоны сертификатов Workstation и Remote Desktop, но не шаблоны DC, даже если я прошу показать все шаблоны, они не отображаются. Сработает ли это, если мой аккаунт технически не является DC. Операционная ли консоль mmc на основе того, что человек, который вошел в систему, запрашивает сертификат, а не сервер или служба, которая будет автоматически запрашивать сертификат в фоновом режиме?
Что я сделал и проверил:
- Разрешения на автоматическую регистрацию и регистрацию на шаблонах DC установлены для контроллеров домена, корпоративных DC и корпоративных RODC
- Я могу успешно выполнить ping до CA и CEP с контроллеров домена
- Групповая политика имеет новую политику регистрации и установлена на автоматическую регистрацию
- Цепочка доверия добавлена в GPO и контейнер NTAuth
- Я дублировал оригинальные Kerb Auth и DirectoryEmailReplication и установил новый DC CA для их выдачи без эффекта
- Удалил один из старых сертификатов с предыдущего CA на DC и запустил certutil -pulse без эффекта
- Проверил журналы на DC, и кажется, что он даже не пытается запросить сертификат
- Проверил журналы на сервере IIS, и много чего не отображается
- Запустил certutil -adtemplate и обнаружил, что есть разрешения на как минимум один из сертификатов DC и что они настроены на автоматическую регистрацию, хотя такие же разрешения есть на каждом из рассматриваемых шаблонов
- Учётная запись службы, которая используется, имеет правильные SPN и права делегирования на CA
Есть ли еще какие-либо проверки, команды или процессы, которые я могу запустить, чтобы выяснить, почему контроллеры домена не запрашивают для себя сертификат?
Ответ или решение
Теория
В вашем случае проблема заключается в том, что доменные контроллеры (DC) не запрашивают сертификаты от нового Удостоверяющего центра (CA), несмотря на настройку автоматического обновления. Возможных причин может быть множество, начиная от ошибок в конфигурации до проблем с сетевой связностью или аутентификацией. Понимание основ функционирования PKI (Public Key Infrastructure) и авто-обновления (auto-enrollment) необходимо для дальнейшей диагностики и решения проблемы.
PKI представляет собой систему, состоящую из программно-аппаратных средств, политик и стандартов, используемых для управлением цифровыми сертификатами и асимметричными ключами. Главной функцией PKI является обеспечение безопасности путем подтверждения личности, обеспечения целостности данных и шифрования. Взаимодействие между доменными контроллерами и CA основано на запросах сертификатов, которые направляются на CA с использованием определённых шаблонов сертификатов (certificate templates).
Пример
Ваш случай включает в себя создание и настройку нового PKI на основе Windows Server 2022. Опыт показывает, что успешная работа PKI зависит от многих факторов, включая корректную настройку разрешений, политик групп, а также цепочки доверия, настроек сертификатов и сетевой связи.
Вы создали серверную ферму IIS с новой CEP (Certificate Enrollment Policy) и CES (Certificate Enrollment Service), которая указывает на новый CA для DC. Тем не менее, DC не запрашивает, и не обновляет сертификаты, используя новые шаблоны (Kerberos Auth, DirectoryEmailReplication).
Применение
-
Проверка сетевого взаимодействия: Вы уже подтвердили, что DC могут пинговать CA и CEP. Следует также удостовериться, что между доменными контроллерами и услугами CES/CEP нет блокировок на уровне фаерволов и других сетевых защитных средств.
-
Проверка разрешений на шаблоны: Убедитесь, что разрешения на шаблоне сертификата настроены правильно. Для этого используйте:
certutil -template. Убедитесь, что ваш компьютерный аккаунт DC имеет разрешения ‘Enroll’ и ‘Autoenroll’.- Проверьте политики группы на наличие правильной конфигурации для авто-обновления сертификатов для DC.
-
Групповые политики: Убедитесь, что групповые политики настроены для авто-обновления сертификатов, и они успешно применены ко всем DC.
- Используйте
gpresult /hдля генерации отчета по политике и убедитесь, что политика с новой настройкой авто-обновления присутствует.
- Используйте
-
Цепочка доверия и NTAuth: Развертывание цепочки доверия критично для того, чтобы CA был признан действительным в доменной среде.
- Проверьте, что все необходимые сертификаты, включая сертификаты корня и промежуточные, находятся в доверенных хранилищах DC.
- Убедитесь, что сертификат нового CA занесен в контейнер NTAuth.
-
Логирование и отладка: Проверьте логи как на стороне DC, так и на стороне CA/IIS серверов.
- Для DC используйте средство Event Viewer и смотрите разделы, касающиеся ключей ‘CertificateServicesClient’ и ‘AutoEnrollment’. Это может дать подсказки о проблемах с получением сертификатов.
- На стороне серверов IIS для CES и CEP проверьте логи IIS и системные журналы на наличие ошибок.
-
Ручное обновление: Попробуйте вручную запустить другие команды диагностики и обновления:
certutil -pulse— инициирует проверку новых сертификатов.- Проверка доступности шаблонов сертификатов через
certutil -store Myиcertutil -dump.
-
Отладка и аудит: Включите аудитирование сертификатов на DC и CA, чтобы проследить за последовательностью запросов и определить,
почему происходит сбой.- Активируйте запись событий для аудита авто-обновления (Directory Service Access audit в групповых политиках).
Ваш случай демонстрирует комплексную проблему на границе настройки CA и клиентской (DC) части. Как видим, методу необходимо уделить внимание на каждую из возможных проблем и упомянутые действия являются частью комплексной проверки. Если проблема сохраняется, следует рассматривать возможность привлечения специализированной поддержки Microsoft или сертифицированных специалистов в областе PKI.