Назад | Перейти на главную страницу

RDP представляет самоподписанный сертификат вместо сертификата центра сертификации

Несколько дней назад я стал свидетелем странной проблемы в моем домене:

Эта проблема вездесуща - я сталкиваюсь с ней на разных рабочих станциях и на разных серверах, включая Windows Server 2012R2 | 2008R2, Windows 7 и Windows 10.

Об инфраструктуре ЦС: один автономный корневой ЦС и один ЦС уровня домена. pkiview.msc сообщает, что все в порядке: и корень, и эмитент имеют действующие сертификаты, CDP, IAI и DeltaCRL (только эмитент). Я обновил корневые списки отзыва сертификатов и повторно опубликовал их в AD, потому что думал, что это может быть так, но не повезло.

Пользовательский шаблон сертификата с клиентом | сервером | аутентификацией RDP все еще существует, и я могу подтвердить, что рассматриваемые серверы имеют такие сертификаты в личной папке в апплете сертификатов MMC (и могут запрашивать новые оттуда), хотя в RDP присутствует только самозаверяющий сертификат. папка.

Используя апплет MMC Certificates, я также вижу, что и корневые сертификаты, и сертификаты эмитента являются доверенными.

Итак ... я действительно не знаю, что делать и как это исправить, и почему он вообще сломан. Любая помощь приветствуется.

PS. Также некоторое время назад я изменил GPO домена по умолчанию, установив диапазоны IP-адресов частной сети. Может в этом причина? В любом случае, я вернул их к значениям по умолчанию, и мне тоже не повезло.

ОБНОВИТЬ Некоторые картинки, чтобы немного прояснить:

1) Предупреждение о безопасности

2) ... потому что серверы представляют самоподписанный сертификат

3) Однако мы видим правильный CA-сертификат в личном хранилище на рассматриваемом сервере.

4) В хранилище сертификатов удаленного рабочего стола я вижу только самоподписанный сертификат. Я скопировал туда и нужный, но никакого эффекта. И если я удалю оттуда Self-Signed Cert, я вообще не смогу подключиться к серверу по RDP.

5) Также вы можете видеть, что моим локальным центрам сертификации доверяет сервер:

6) И это ошибка, которую я получаю, когда пытаюсь подключиться к серверу с поддержкой NLA по RDP. Таким образом, клиент по какой-то причине не может или не хочет использовать CredSSP. Он работал неделю назад, поэтому я думаю, что это связано с проблемой сертификата.

7) Наконец, несколько скриншотов из выдающего CA. Вроде бы нормально.

Примените все патчи к серверу и клиентам, и это исправит вашу ошибку credssp.

ОК, я решил. Михал Соколовски был прав, когда указал на майское обновление CredSSP 2018 года. Видимо, все, что я видел, было из-за этого. Как только я изменил локальный GPO на клиентской рабочей станции, все прошло хорошо.

Итак, решение:

1) запустите gpedit.msc на клиенте

2) откройте Конфигурация компьютера -> Административные шаблоны -> Система -> Делегирование учетных данных

3) включите Encryption Oracle Remediation и установите для него значение Vulnerable

4) запустите gpupdate / force

И все возвращается в норму.

Иногда RDS теряет привязку к статическим сертификатам (которые не назначаются через GPO). Возможно, вам потребуется выполнить следующую команду:

$path = (Get-WmiObject "Win32_TSGeneralSetting" -ComputerName "<RDS Server Name>" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path
Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash="<Thumbprint>"}

Заменить <RDS Server Name> с фактическим именем сервера (если выполняется удаленно) и <Thumbprint> с фактическим отпечатком сертификата. Отпечаток большого пальца должен быть указан в шестнадцатеричном формате без пробелов, например F02B346CDC02165543936A37B50F2ED9D5285F62.

Для внутренних компьютеров (которые являются частью леса AD и доступны через внутренние имена) рекомендуется использовать сертификаты RDS, назначенные GPO: Настройка сертификатов удаленного рабочего стола