Внутренний сертификат транспорта для локального сервера поврежден или отсутствует в active directory

Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом

Как проявляется проблема: пользователь пытается авторизоваться на рабочей станции или сервере под своей учетной запись и после ввода пароля появляется ошибка:

The trust relationship between this workstation and the primary domain failed.

Не удалось восстановить доверительные отношения между рабочей станцией и доменом.

Также ошибка может выглядеть так:

The security database on the server does not have a computer account for this workstation trust relationship.

База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станцией.

Общий план развёртывания

Для развёртывания службы сертификатов нам потребуется четыре машины с Windows Server 2016, которые будут выполнять следующие функции:

Контроллер домена — необходим для функционирования домена Active Directory;
Веб-сервер — будет обеспечивать доступ к сертификатам ЦС и спискам отзывов для клиентов;
Корневой ЦС — будет выполнять функции корневого ЦС;
Подчинённый ЦС — будет выполнять функции издающего ЦС.

Развёртывание PKI будет проходить поэтапно на каждом сервере в том порядке, в котором они указаны выше. Подготовка контроллера домена будет сводиться к обеспечению функций Active Directory, GPO и учётных записей.

В этой статье мы рассмотрим проблему нарушения доверительных отношений между рабочей станцией и доменом Active Directory, из-за которой пользователь не может авторизоваться на компьютере. Рассмотрим причину проблемы и простой способ восстановления доверительных отношений компьютера с контроллером домена по безопасному каналу без перезагрузки компьютера.

Попытался сделать следующее:
На контроллере домена, в личных сертификатах компьютера необходимо было запросить сертификаты от нового ЦС «Контроллер домена», «Почтовая репликация каталога», «Проверка подлинности контроллера домена».
Зашел в оснастку, попытался добавить запрос сертификата, но там в списке выбора пусто. Я поставил галочку отображать все сертификаты и там появились все которые есть, но которые не применимы в данный момент. Я нашел там эти три сертификата которые я должен запросить, но у них ошибка. см. ниже.

Я открыл консоль сертификации перешел в шаблон и открыл управление шаблонами. Там нашел нужные три шаблона сертификата, но непонятно что там менять чтобы они стали отображаться в выборе.
Подскажите что нужно подправить в шаблонах?

Вопрос задан

более трёх лет назад
1572 просмотра

В этой статье мы покажем, как использовать доверенные SSL/TLS сертификаты для защиты RDP подключений к компьютерам и серверам Windows в домене Active Directory. Эти сертфикаты мы будем использовать вместо самоподписанных RDP сертификатов (у пользователей появляется предупреждение о невозможности проверки подлинности при подключению к RDP хосту с таким сертификатом). В этом примере мы настроим специальный шаблон для выпуска RDP сертификатов в Certificate Authority и настроим групповую политику для автоматического выпуска и привязки SSL/TLS сертификата к службе Remote Desktop Services.

Привет. Помогите пожалуйста справиться с проблемой. Есть сервер на котором стоит Wondows Server 2012 и установлены роли DNS и AD. При попытке открыть центр администрирования Active Directory или другую оснастку AD (управления пользователями и группами и др) вылетает ошибка что это сервер не работоспособен или что не удается подключится к домену. Хотя контролером домена является этот сервер.
Через поиск понял что скорее всего проблема в DNS но не знаю как исправить.

Логи DNS-сервера:
DNS-серверу не удалось завершить перечисление зоны . в службе каталогов. Этот DNS-сервер настроен для получения и использования данных из Active Directory для указанной зоны и без них не может загрузить зону. Проверьте, нормально ли работает Active Directory, и повторите перечисление зоны. Дополнительная отладочная информация об ошибке: «» (может отсутствовать). Данные о событии содержат сведения об ошибке.

DNS-серверу не удалось завершить перечисление зоны urfac.local в службе каталогов. /-/-/

DNS-серверу не удалось завершить перечисление зоны _msdcs.urfac.local в службе каталогов. /-/-/

DNS-сервер обнаружил критическую ошибку Active Directory. Проверьте работоспособность Active Directory. Дополнительная отладочная информация об ошибке: «» (может отсутствовать). Данные о событии содержат сведения об ошибке.

На всякий случай ipconfig /all

Предупреждение о самоподписанном сертификате RDP

По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный

сертификат. В результате при первом подключении к RDP/RDS серверу через клиента mstsc.exe, у пользователя появляется предупреждение:

Не удалось проверить подлинность удаленного компьютер из-за проблем с сертификатом безопасности.
Ошибка сертификата: сертификат выдан не имеющим доверия центром сертификации.

Чтобы продолжить установление RDP подключении пользователь должен нажать кнопку Да. Чтобы RDP предупреждение не появлялось каждый раз, можно включить опцию “Больше не выводить запрос о подключениях к этому компьютеру».

Несмотря на то, что для подключения используется самоподписанный сертификат, ваше RDP подключение защищено, а трафик зашифрован.

Создаем шаблон RDP сертификата в центре сертификации (CA)

Попробуем использовать для защиты RDP подключений доверенный SSL/TLS сертификат, выданный корпоративным центром сертификации. С помощью такого сертификата пользователь может выполнить проверку подлинности RDP сервера при подключении. Предположим, что у вас в домене уже развернут корпоративной центр сертификации (Microsoft Certificate Authority), в этом случае вы можете настроить автоматическую выдачу и подключение сертификатов всем компьютерам и серверам Windows в домене.

Н на вашем CA нужно создать новый тип шаблона сертификата для RDP/RDS серверов.

Запустите консоль Certificate Authority и перейдите в секцию Certificate Templates;
Сделайте копию шаблона сертификата Computer (Certificate Templates -> Manage -> Computer -> Duplicate);
На вкладке General укажите имя нового шаблона сертификата – RDPTemplate. Убедитесь, что значение поля Template Name полностью совпадает с Template display name;
На вкладке Compatibility укажите минимальную версию клиентов в вашем домене (например, Windows Server 2008 R2 для CA и Windows 7 для клиентов). Тем самым будут использоваться более стойкие алгоритмы шифрования;
Теперь на вкладке Extensions в политике приложений (Application policy) нужно ограничить область использования такого сертификата только для Remote Desktop Authentication (укажите следующий object identifier — 1.3.6.1.4.1.311.54.1.2). Нажмите Add -> New, создайте новую политику и выберите ее;
В настройках шаблона сертификата (Application Policies Extension) удалите все политики кроме Remote Desktop Authentication;
Чтобы использовать данный шаблон RDP сертификатов на контролерах домена, откройте вкладку Security, добавьте группу Domain Controllers и включите для нее опцию Enroll и Autoenroll;
Сохраните шаблон сертификата;
Теперь в оснастке Certificate Authority, щёлкните по папке Certificate Templates, выберите New -> Certificate Template to Issue -> выберите созданный шаблон RDPTemplate.

Подготовка контроллера домена

Ряд операций на подчинённом ЦС требуют прав Enterprise Admins, поскольку производится запись в раздел configuration naming context. Если это корневой домен леса, то для этих операций достаточно прав Domain Admins.

Следующим шагом будет конфигурирование политики автоматической выдачи сертификатов (autoenrollment). Эта политика нужна будет в процессе эксплуатации служб сертификатов для автоматической выдачи и обновления истёкших сертификатов на клиентах. Политика настраивается в конфигурации компьютера и пользователя:

Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Infrastructure\Certificate Services Client – Auto-Enrollment
User Configuration\Policies\Windows Settings\Security Settings\Public Key Infrastructure\Certificate Services Client – Auto-Enrollment

Политика в обоих разделах должна быть сконфигурирована как показано на следующей картинке:

Сконфигурированный объект групповых политик (GPO) должен быть пристыкован к корню домена. Данную процедуру необходимо повторить во всех доменах текущего леса Active Directory.

Далее, необходимо создать запись типа CNAME с именем CDP на сервере ДНС, который будет указывать на веб-сервер (IIS). Эту процедуру необходимо выполнить как на внутреннем, так и на внешнем (который обслуживает зону в интернете) серверах ДНС. Запись можно создать при помощи PowerShell:

Add-DnsServerResourceRecord -CName -Name "cdp" -HostNameAlias "iis.contoso.com" -ZoneName "contoso.сom"

Подготовка веб-сервера

На веб-сервере нам потребуется выполнить следующее: установить службу IIS (если ещё не установлена), создать общую папку и сконфигурировать веб-сайт на использование этой папки.

Установка службы IIS

Для установки службы IIS можно воспользоваться следующей командой:

Install-WindowsFeature -Name Web-Server, Web-WebServer -IncludeManagementTools

Создание папки PKIdata

Согласно нашей конфигурационной таблице (см. часть 2), для хранения сертификатов ЦС и списков отзыва нам потребуется общая папка с сетевым именем PKI по следующему пути: C:\InetPub\wwwroot\PKIdata

New-Item -ItemType Directory -Path C:\InetPub\wwwroot -Name PKIdata -Force
New-SmbShare -Path C:\inetpub\wwwroot\PKIdata -Name PKI -FullAccess everyone

После этого нужно выдать права NTFS на запись в эту папку для группы Cert Publishers.

Создание веб-сайта

Теперь нам необходимо создать отдельный веб-сайт с именем “CDP” и хост-именем “cdp.contoso.com”:

New-Website -Name CDP -HostHeader cdp.contoso.com -PhysicalPath C:\inetpub\wwwroot\PKIdata
New-WebVirtualDirectory -Site cdp -Name pki -PhysicalPath C:\inetpub\wwwroot\PKIdata

Включение поддержки Delta CRL

Import-Module -Name WebAdministration
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter /system.webServer/security/requestFiltering -name allowdoubleescaping -Value 'true'

Настройка групповой политики для выдачи RDP сертификатов

Теперь нужно настроить доменную политику, которая будет автоматически назначать RDP сертификат компьютерам/серверам согласно настроенного шаблона.

Предполагается, что все компьютеры домена доверяют корпоративному центру сертификации, т.е. корневой сертификат через GPO добавлен в доверенные корневые центры сертификации.

Откройте консоль управления доменными групповыми политиками gpmc.msc, создайте новый объект GPO и назначьте его на OU с RDP/RDS серверами или компьютерами, для которых нужно автоматически выдавать TLS сертификаты для защиты RDP подключения;
Перейдите в раздел GPO: Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security. Включите политику Server Authentication Certificate Template. Укажите имя шаблона CA, который вы создали ранее (RDPTemplate);
Затем в этом же разделе GPO включите политику Require use of specific security layer for remote (RDP) connections и установите для нее значение SSL;
Для автоматического продления RDP сертификата, перейдите в раздел GPO Computer configuration -> Windows settings -> Security Settings -> Public Key Policies и включите политику Certificate Services Client – Auto-Enrollment Properties. Выберите опции “Renew expired certificates, update pending certificates and remove revoked certificates” и “Update certificates that use certificate templates”;
Если вы хотите, чтобы клиенты всегда проверяли сертификат RDP сервера, вам нужно настроить политику Configure Authentication for Client = Warn me if authentication fails (секция GPO Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Settings -> Remote Desktop Connection Client);
Если нужно, можете через политики файервола открыть входящий RDP порт TCP/UDP 3389;
Осталось обновить политики на клиенте, запустить консоль сертификатов компьютера (Certlm.msc), и проверить, что в разделе Personal -> Certificates появился сертификат для Remote Desktop Authentication, выданный вашим CA.
Если политики не применились, для диагностики GPO воспользуйтесь утилитой gpresult и этой статьей.

Для применения нового RDP сертификата, перезапустите службу Remote Desktop Services:

Теперь при RDP подключении к серверу перестанет появляться запрос на доверие сертификату (чтобы появился запрос о доверии сертификату, подключитесь к серверу по IP адресу вместо FQDN имени сервера, для которого выпущен сертификат). Нажмите кнопку “Посмотреть сертификат”, перейдите на вкладку “Состав”, скопируйте значение поля “Отпечаток сертификата”.

Также можете в консоли Certification Authority в секции Issued Certificates проверить, что по шаблону RDPTemplate был выдан сертификат определённому Windows компьютеру/серверу. Также проверьте значение Thumbprint сертификата:

Теперь, при подключении к удаленном столу любого сервера или компьютера, на который действует эта политика, вы не увидите предупреждения о недоверенном RDP сертификате.

Проверка и восстановление доверительного отношения компьютера с доменом с помощью PowerShell

Откройте консоль PowerShell и с помощью командлета Test-ComputerSecureChannel проверьте соответствует ли локальный пароль компьютера паролю, хранящемуся в AD.

Если пароли не совпадают и компьютер не может установить доверительные отношения с доменом, команда вернет значение False –
The Secure channel between the local computer and the domain winitpro.ru is broken
.

Чтобы принудительно сбросить пароль учётной записи данного компьютера в AD, нужно выполнить команду:

Test-ComputerSecureChannel –Repair –Credential (Get-Credential)

После этого нужно еще раз выполнить команду
Test-ComputerSecureChannel
и убедится, что она возвращает True (
The Secure channel between the local computer and the domain winitpro.ru is in good condition
).

Итак, пароль компьютера сброшен без перезагрузки и без ручного перевоода в домен. Теперь вы можете аутентифицировать на компьютере под доменной учетной записью.

Также для принудительной смены пароля можно использовать командлет Reset-ComputerMachinePassword.

dc01.corp.winitpro.ru
– имя ближайшего DC, на котором нужно сменить пароль компьютера.

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

Если у вас есть среда разработки или тестирования, где приходится часто восстанавливать предыдущее состояние ВМ из снапшотов, возможно стоит с помощью GPO точечно отключить смену пароля в домене для таких компьютеров. Для этого используется политика Domain member: Disable machine account password changes из секции Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options. Можно нацелить политики на OU с тестовыми компьютерам или воспользоваться WMI фильтрами GPO.

С помощью командлета Get-ADComputer (из модуля Active Directory Windows PowerShell) можно проверить время последней смены пароля компьютера в AD:

Get-ADComputer –Identity spb-pc22121 -Properties PasswordLastSet

Также можно проверить наличие безопасного канала между компьютером и DC командой:

Следующие строки подтверждают, что доверительные отношения были успешно восстановлены:

Trusted DC Connection Status Status = 0 0x0 NERR_Success
Trust Verification Status = 0 0x0 NERR_Success

Установка корневого ЦС

Фактическая установка ЦС будет включать в себя несколько этапов:

Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
Установка компонента ЦС;
Выполнение постустановочной конфигурации;
Проверка установки.

Перед установкой корневого ЦС, необходимо ещё раз вернуться к конфигурационным таблицам:

В таблице я выделил только те параметры, которые задаются до и в процессе установки. Остальные параметры будут настраиваться после установки.

Предварительная конфигурация

Предварительные конфигурационные файлы необходимы для ряда настроек, которые невозможно задать во время установки компонента (ни при помощи графического интерфейса, ни при помощи командной строки или PowerShell). К ним обычно относятся настройки расширений сертификата ЦС. Например, для настройки расширения сертификата Certificate Policies, необходимо использовать предварительный конфигурационный файл, в котором настраиваются параметры расширения. Для Microsoft ADCS таким файлом является файл CAPolicy.inf, который должен быть расположен по следующему пути: %windir%\CAPolicy.inf. С синтаксисом этого файла можно ознакомиться в следующей статье: How CA Certificates Work. Поскольку никаких специфичных или нестандартных настроек в сертификате корневого ЦС мы делать не будем, поэтому и предварительный конфигурационный файл сейчас нам не потребуется.

Установка компонента ЦС

Прежде всего необходимо добавить установочные компоненты для AD CS:

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

После этого сверьтесь с предыдущей таблицей, чтобы определить параметры установки. Исходя из данных таблицы, зададим параметры для командлета Install-AdcsCertificationAuthority:

Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Root Certification Authority" `
    -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" `
    -CAType StandaloneRootCA `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256 `
    -ValidityPeriod "years" `
    -ValidityPeriodUnits 15 `
    -DatabaseDirectory $(Join-Path $env:SystemRoot "System32\CertLog")

Итоговая настройка

После установки компонента ЦС необходимо настроить рабочие параметры ЦС. Рассмотрим ещё раз элементы, которые нам необходимо настроить:

* — копируется на сервер IIS

Скрипт настройки

Для конфигурирования настроек ЦС мы будем использовать BATCH скрипт с использованием утилиты certutil.exe:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                     Root CA post-installation script                               ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
:: в отдельные переменные
SET CrlLocal=C:\CertData\contoso-rca%%8.crl
SET CDP=http://cdp.contoso.com/pki/contoso-rca%%8.crl
SET AIA=http://cdp.contoso.com/pki/contoso-rca%%4.crt

:: Создаём папку в корне системного диска, куда будут записываться файлы ЦС. Эта папка
:: создаётся для удобства, чтобы не искать папку CertEnroll в глубине папки Windows.
md C:\CertData

:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва.
certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8.crl\n1:%CrlLocal%\n2:%CDP%"

certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%AIA%"

:: Поскольку мы не можем указывать пути публикации для файла сертификата, мы
:: вручную переименовываем его в необходимый формат и копируем в папку CertData
ren %windir%\system32\CertSrv\CertEnroll\*.crt contoso-rca.crt
copy %windir%\system32\CertSrv\CertEnroll\contoso-rca.crt C:\CertData

:: Задаём срок действия издаваемых сертификатов
certutil -setreg CA\ValidityPeriodUnits 15
certutil -setreg CA\ValidityPeriod "Years"

:: Задаём время жизни списков отзыва согласно нашей конфигурации
certutil -setreg CA\CRLPeriodUnits 180
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Months"
certutil -setreg CA\CRLOverlapUnits 1

:: Отключаем дифференциальные списки отзыва (или Delta CRL)
certutil -setreg CA\CRLDeltaPeriodUnits 0

:: Отключаем генерацию кросс-сертификатов
certutil -setreg ca\CRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS

:: Конфигурируем ЦС для включения истёкших отозванных сертификатов в списки отзыва
certutil –setreg ca\CRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS

:: Включаем полный аудит событий на ЦС**
certutil -setreg CA\AuditFilter 127

:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg ca\csp\CNGHashAlgorithm SHA256

:: Перезапускаем службу ЦС для применения изменений.
net stop certsvc && net start certsvc

:: Публикуем списки отзыва.
certutil -CRL

Ряд команд нуждается в более развёрнутом пояснении. Команды с настройкой расширений CRL Distribution Points и Authority Information Access имеют специфический синтаксис. Во-первых, пути публикации и распространения указываются в одну строку и разделяются символом новой строки «\n». Каждый путь начинается с числа и отделяется от самого пути символом двоеточия. Это число в начале пути указывает битовую маску флагов публикации для конкретного пути. Значение каждого бита для расширений CDP и AIA приведено в следующей таблице:

Если взять путь для CDP: 1:%windir%\system32\CertSrv\CertEnroll\%%3%%8.crl, то цифра 1 в начале строки говорит о том, что это путь физического размещения файла (Publich CRLs to this location). Другие опции здесь не используются. Для включения пути, который будет публиковаться в издаваемых сертификатах, мы будем использовать опцию «Include in the CDP extension of issued certificates» с числовым значением 2. Такой же принцип применяется и для остальных путей.

В каждом пути включены переменные с двойным знаком процента «%%». Это переменные, которые ЦС при формировании пути будет автоматически заполнять исходя из типа переменной.

Первый знак процента используется как эскейп-символ, чтобы процессор командной строки воспринял следующий знак процента как литерал. Дело в том, что знак процента в командном процессоре CMD является служебным символом. Сервер ЦС так же использует знак процента для указания, что это переменная. Для исключения конфликта в командном процессоре используется последовательность из двух знаков процента.

Следующая таблица содержит описание всех доступных переменных и их краткое описание:

В нашем конкретном случае будут использоваться только две переменные: <CertificateName> и <CRLNameSuffix>. Для исходного сертификата ЦС эти переменные пустые. При обновлении сертификата ЦС, переменная будет заменяться на «(index)», где index — номер сертификата ЦС. Индексирование начинается с нуля. Например, имя файла для последующего сертификата ЦС будет иметь вид: contoso-rca(1).crt. И так далее. То же самое касается и переменной , только здесь будет указываться индекс ключевой пары ЦС.

Отдельного внимания заслуживает команда, которая включает аудит операций на сервере ЦС, которые регистрируются в системном журнале Security.evtx. К ним относятся все основные операции: запуск/остановка службы, отправление запроса, выпуск или отклонение сертификата, выпуск списка отзыва. Эту строчку можно найти практически в каждом постустановочном скрипте для ЦС, которые можно найти в похожих статьях в интернете. И практически никто не утруждает себя в подробном объяснении механизма его работы, просто копируют из статьи в статью.

Особенность ведения аудита ЦС заключается в том, что настройка флагов аудита на ЦС является необходимым, но не достаточным условием. Механизм аудита основан на регистрации событий в журнале Security.evtx, который, в свою очередь зависит от настройки политики Audit Object Access в групповых политиках. Т.е. без настройки групповых политик никакого аудита не будет.

Опытные администраторы знают к чему приводит включение Audit Object Access — к лавинному созданию записей в журнале от других компонентов ОС. Например, аудит доступа файловой системы, реестра, других установленных ролей и т.д. В результате, журнал может буквально за день-два заполниться до отказа. Поэтому для эффективного использования аудита необходимы меры по фильтрации ненужных событий, например, при помощи функции подписки на интересующие события. Нет смысла в аудите, если его никто не может прочитать и эффективно проанализировать. Но эта тема уже выходит за рамки этой статьи.

Прочие настройки

После того как корневой ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена;
Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям;
Найдите в корне системного диска папку CertData и убедитесь, что там находится два файла: сертификат и список отзыва. Убедитесь, что поля списка отзыва соответствуют ожидаемым значениям.

Если всё хорошо, тогда скопируйте содержимое папки C:\CertData на сервер IIS в папку PKIData. Сертификат корневого ЦС уже можно импортировать на все устройства, которые будут использовать нашу PKI.

Для импорта сертификата на доменные клиенты, достаточно загрузить его в Active Directory и после обновления групповых политик на клиентах, сертификат будет установлен в локальные хранилища сертификатов во всём лесу. Для публикации сертификата в AD необходимо выполнить следующую команду:

Certutil -f -dspublish path\contoso-rca.crt RootCA

Для установки сертификата на клиентах в рабочих группах и мобильные устройства необходимо воспользоваться другими инструментами, которые есть в вашем распоряжении. Например, System Center Configuration Manager или Mobile Device Management. Если подходящих инструментов нет, можно копировать и устанавливать сертификат на компьютеры при помощи утилиты certutil.exe. Для установки сертификата в локальное хранилище сертификатов выполните следующую команду:

Certutil -f -addstore Root path\contoso-rca.crt

Пароль учетной записи компьютера в домене Active Directory

Когда компьютер вводится в домен Active Directory, для него создается отдельная учетная запись типа computer. У каждого компьютера в домене, как и у пользователей есть свой пароль, который необходим для аутентификации компьютера в домене и установления доверенного подключения к контроллеру домена. Однако, в отличии от паролей пользователя, пароли компьютеров задаются и меняются автоматически.

Несколько важных моментов, касающихся паролей компьютеров в AD:

Если хэш пароля, который компьютер отправляет контроллеру домена не совпадает с паролем учетной записи компьютера, компьютер не может установить защищённое подключение к DC и выдает ошибки о невозможности установить доверенное подключение.

Почему это может произойти:

Самая частая проблема. Компьютер был восстановлен из старой точки восстановления или снапшота (если это виртуальная машина), созданной раньше, чем был изменен пароль компьютера в AD. Т.е. пароль в снапшоте отличается от пароля компьютера в AD. Если вы откатите такой компьютер на предыдущее состояние, это компьютер попытается аутентифицироваться на DC со старым паролем.
В AD создан новый компьютер с тем же именем, или кто-то сбросил аккаунт компьютера в домене через консоль ADUC;
Учетная запись компьютера в домене заблокирована администраторам (например, во время регулярной процедуры отключения неактивных объектов AD);
Довольно редкий случай, когда сбилось системное время на компьютере.

Классический способ восстановить доверительных отношений компьютера с доменом в этом случае:

Сбросить аккаунт компьютера в AD;
Под локальным админом перевести компьютер из домена в рабочую группу;
Перезагрузить компьютер;
Перезагнать компьютер в домен;
Еще раз перезагрузить компьютер.

Этот метод кажется простым, но слишком топорный и требует, как минимум двух перезагрузок компьютера, и 10-30 минут времени. Кроме того, могут возникнуть проблемы с использованием старых локальных профилей пользователей.

Есть более элегантный способ восстановить доверительные отношения с помощью PowerShell без перевключения в домен и без перезагрузок компьютера.

Установка издающего ЦС

Как и в случае с корневым ЦС, установка издающего ЦС включает в себя четыре этапа:

Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
Установка компонента ЦС;
Выполнение постустановочной конфигурации;
Проверка установки и конфигурации.

Предустановочная конфигурация

Если для корневого ЦС предустановочный конфигурационный файл нам не требовался, то для издающего ЦС он понадобится. В нём мы настроим расширения Certificate Policies и Basic Constraints для сертификата ЦС. Если с политиками всё понятно, то в расширении Basic Constraints мы запретим выдачу сертификатов другим ЦС с издающего ЦС, поскольку у нас двухуровневая иерархия и добавление новых уровней только усложняет нашу структуру и увеличивает время, затрачиваемое на проверку сертификатов клиентами. Также отключим автоматическую загрузку шаблонов из Active Directory в список выдаваемых шаблонов. По умолчанию, сервер ЦС загружает на выдачу некоторый набор шаблонов сертификатов. Это вредно по двум причинам:

Контроллеры домена практически мгновенно обнаруживают появление ЦС в лесу и даже при отключённой политике автоматической выдачи сами запрашивают себе сертификаты.
Администраторы сами должны определять какие шаблоны будут использовать в организации.

Поэтому мы сконфигурируем ЦС так, что список шаблонов к выдаче будет пустым. Это возможно сделать только через CAPolicy.inf. В нашем случае он будет иметь следующее содержимое:

; заголовок INI файла
[Version]
Signature= "$Windows NT$"

; указываем список политик, которые будут включены в сертификат ЦС. В нашем
; случае будет одна политика под названием AllIssuancePolicies.
[PolicyStatementExtension]
Policies = AllIssuancePolicy
; конфигурируем детали самой политики. Ссылку на документ Certificate Practice
; Statement (CPS) и объектный идентификатор политики
[AllIssuancePolicy]
URL = http://cdp.contoso.com/pki/contoso-cps.html
OID = 2.5.29.32.0
[BasicConstraintsExtension]
IsCA = True
PathLegth = 0
IsCritical = True
; секция прочих настроек ЦС
[certsrv_server]
; отключаем автоматическую загрузку шаблонов сертификатов для выдачи
LoadDefaultTemplates = 0

Файл с именем CAPolicy.inf необходимо скопировать в системную папку Windows до установки ЦС.

Установка компонента ЦС

Прежде всего необходимо добавить установочные компоненты для AD CS:

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

После этого посмотрим на установочную таблицу, чтобы определить параметры установки:

В таблице я выделил только те параметры, которые задаются в процессе установки. Остальные параметры будут настраиваться после установки. Исходя из этих данных сформируем параметры для командлета Install-AdcsCertificationAuthority:

Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Issuing Certification authority" `
    -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" `
    -CAType EnterpriseSubordinateCa `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256

После выполнения этой команды будет выведено сообщение о том, что установка ЦС не завершена и для её завершения необходимо отправить сгенерированный запрос (находится в корне системного диска) на вышестоящий ЦС и получить подписанный сертификат. Поэтому находим файл с расширением «.req» в корне системного диска и копируем его на корневой ЦС и на корневом ЦС выполняем следующие команды:

 # отправляем запрос на ЦС.
certreq -submit 'C:\CA-01.contoso.com_Contoso Lab Issuing Certification authority.req'
# предыдущая команда выведет номер запроса. Укажите этот номер запроса в следующей команде
# в моём случае это номер 2
certutil -resubmit 2
# после выпуска сертификата сохраните его в файл. При этом укажите тот же самый номер
# запроса, который был указан после выполнения первой команды
certreq -retrieve 2 C:\subca.crt

Полученный файл (subca.crt) необходимо скопировать обратно на издающий ЦС и завершить инсталляцию:

certutil -installcert c:\subca.crt
net start certsvc

Мы устанавливаем на ЦС выписанный сертификат и запускаем службу сертификатов. После успешной установки можно запустить оснастку Certification Authorities MMC (certsrv.msc) и убедиться, что сертификат успешно установлен и ЦС в работающем состоянии. Теперь осталось дело за постустановочной конфигурацией.

Итоговая настройка

По аналогии с корневым ЦС, нам потребуется сконфигурировать ряд параметров на издающем ЦС. Для этого мы снова напишем BATCH скрипт с использованием утилиты certutil.exe. Но прежде всего посмотрим установочную таблицу и выясним параметры, которые нам необходимо настроить:

Аналогичная таблица составляется и для издающего ЦС.

За основу мы возьмём скрипт с корневого ЦС и изменим только отдельные фрагменты:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                     Issuing CA post-installation script                            ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
:: в отдельные переменные
SET CrlLocal=\\IIS\PKI\contoso-pica%%8%%9.crl
SET CDP=http://cdp.contoso.com/pki/contoso-pica%%8%%9.crl
SET AIA=http://cdp.contoso.com/pki/contoso-pica%%4.crt

:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва.
certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:%CrlLocal%\n6:%CDP%"

certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%AIA%"

:: Поскольку мы не можем указывать пути публикации для файла сертификата, мы
:: вручную переименовываем его в необходимый формат и копируем в сетевую папку
ren %windir%\system32\CertSrv\CertEnroll\*.crt contoso-pica.crt
copy %windir%\system32\CertSrv\CertEnroll\contoso-pica.crt \\IIS\PKI

:: Задаём срок действия издаваемых сертификатов
certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod "Years"

:: Задаём время жизни списков отзыва согласно нашей конфигурации
:: базовый CRL
certutil -setreg CA\CRLPeriodUnits 1
certutil -setreg CA\CRLPeriod "weeks"

:: Delta CRL
certutil -setreg CA\CRLDeltaPeriodUnits 1
certutil -setreg CA\CRLDeltaPeriod "days"

:: Включаем полный аудит событий на ЦС**
certutil -setreg CA\AuditFilter 127

:: Включаем наследование расширения Certificate Policies в издаваемых сертификатах 
certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.32"

:: Включаем поддержку расширения OcspRevNoCheck, если планируется установка
:: сетевого ответчика (Online Responder или OCSP сервера)
certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK

:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg ca\csp\CNGHashAlgorithm SHA256

:: Перезапускаем службу ЦС для применения изменений.
net stop certsvc && net start certsvc

:: Публикуем списки отзыва.
certutil -CRL

Заметим, что в путях CRLDistribution Points, изменены флаги публикации (добавлена публикация Delta CRL) и добавлена переменная %9 в имя файла для поддержки уникального имени для дельты.

Здесь мы больше не создаём папку в корне системного диска, а используем сетевую папку PKI на сервере IIS, куда напрямую копируем файл сертификата и публикуем списки отзыва.

Прочие настройки

После того как издающий ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена
Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям.
Откройте сетевую папку PKI (на сервере IIS) и убедитесь, что там есть два файла сертификата (корневого и издающего ЦС) и три списка отзыва (один для корневого, два для издающего ЦС). Убедитесь, что поля в сертификатах и списках отзыва соответствуют ожидаемым значениям.

Когда основные параметры проверены, необходимо убедиться в правильной связи иерархии ЦС и доступности всех внешних файлов для клиентов. Для этого на сервере ЦС (а лучше, на рабочей станции, где установлены средства удалённого администрирования ЦС) необходимо запустить оснастку Enterprise PKI Health (pkiview.msc). Оснастка автоматически построит текущую иерархию и проверит доступность всех путей для скачивания сертификатов ЦС и списков отзыва. Никаких ошибок быть не должно. Если есть ошибка, необходимо её точно идентифицировать и устранить. В случае успешной настройки оснастка будет выглядеть следующим образом для корневого ЦС:

И для издющего ЦС:

Если вся итоговая конфигурация соответствует ожидаемым значениям и оснастка Enterprise PKI Health не показывает ошибок, это может судить о том, что PKI установлена верно.

Восстановления доверия с помощью утилиты Netdom

В Windows 7/2008R2 и предыдущих версиях Windows, на которых отсутствует PowerShell 3.0, не получится использовать командлеты Test-ComputerSecureChannel и Reset-ComputerMachinePassword для сброса пароля компьютера и восстановления доверительных отношений с доменом. В этом случае для восстановления безопасного канала с контроллером домена нужно воспользоваться утилитой
netdom.exe
.

Server – имя любого доступного контроллера домена;
UserD – имя пользователя с правами администратора домена или делегированными правами на компьютеры в OU с учетной записью компьютера;
PasswordD – пароль пользователя.

Как вы видите, восстановить доверительные отношения междду компьютером и доменом довольно просто.

Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата

Если у вас отсутствует CA, но вы хотите, чтобы при подключении к RDP/RDS серверу у пользователей не появлялось предупреждения, вы можете добавить сертификат в доверенные на компьютерах пользователей.

Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:

Используйте этот отпечаток для подписывания .RDP файла с помощью RDPSign.exe:

Чтобы работал прозрачных RDP вход без ввода пароля (RDP Single Sign On), нужно настроить политику Allow delegation defaults credential и указать в ней имена RDP/RDS серверов (см. статью).

Об авторе

Вадим Поданс — специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его сайте.

Читать также: Сертификат соответствия. Соответствия чему?

Внутренний сертификат транспорта для локального сервера поврежден или отсутствует в active directory

Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом

Общий план развёртывания

Предупреждение о самоподписанном сертификате RDP

Создаем шаблон RDP сертификата в центре сертификации (CA)

Подготовка контроллера домена

Подготовка веб-сервера

Настройка групповой политики для выдачи RDP сертификатов

Проверка и восстановление доверительного отношения компьютера с доменом с помощью PowerShell

Установка корневого ЦС

Предварительная конфигурация

Установка компонента ЦС

Итоговая настройка

Скрипт настройки

Прочие настройки

Пароль учетной записи компьютера в домене Active Directory

Установка издающего ЦС

Предустановочная конфигурация

Установка компонента ЦС

Итоговая настройка

Прочие настройки

Восстановления доверия с помощью утилиты Netdom

Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата

Рекомендации

Шаблоны сертификатов

Обновление сертификатов ЦС

Резервное копирование

Об авторе

Добавить комментарий Отменить ответ