RDP ошибка 0x4 при рабочем порте 3389. Диагностика Schannel 36870 и Event ID 1057

Windows Server • RDP • Terminal Services • TLS • Schannel

О проблеме

На одном из компьютеров под управлением Windows 10 перестали приниматься подключения по RDP.

При попытке подключения клиент получал сообщение:

Произошла внутренняя ошибка.

Код ошибки: 0x4
Расширенный код ошибки: 0x0

При этом:

порт TCP/3389 оставался доступен;
служба удалённых рабочих столов была запущена;
слушатель RDP-Tcp находился в состоянии «Прием».

На первый взгляд проблема выглядела как неисправность службы удалённых рабочих столов или сетевого подключения. Однако в ходе диагностики выяснилось, что причиной являлся TLS-сертификат, используемый службой RDP.

В статье показан полный порядок диагностики и решение, позволившее восстановить работу удалённого рабочего стола.

Что было известно перед началом диагностики

Проверка через qwinsta показала, что слушатель RDP работает.

qwinsta

Результат:

 СЕАНС             ПОЛЬЗОВАТЕЛЬ             ID  СТАТУС
 services                                    0  Диск
 console           USER                      1  Активно
 rdp-tcp                                 65536  Прием

Дополнительно было подтверждено:

служба TermService запущена;
порт TCP/3389 доступен;
TCP-соединение устанавливается;
подключение к порту 3389 через Telnet выполняется успешно;
слушатель RDP находится в состоянии «Прием».

При этом подключение по RDP не устанавливалось.

Note

На этом этапе проблема уже не выглядела как неисправность сети, брандмауэра или самой службы удалённых рабочих столов.

01. Проверяем журналы служб удалённых рабочих столов

Первым шагом проверяем журналы служб удалённых рабочих столов.

Get-WinEvent `
    -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" `
    -MaxEvents 50 |
Select TimeCreated, Id, Message

Дополнительно проверяем журнал локального диспетчера сеансов.

Get-WinEvent `
    -LogName "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational" `
    -MaxEvents 50 |
Select TimeCreated, Id, Message

Проверка показала, что служба продолжает принимать подключения.

Кроме того, в журнале присутствовали события успешного входа пользователей.

Это означало, что проблема находится не на уровне TCP и не связана с самим слушателем RDP.

02. Проверяем системный журнал

Следующий этап — анализ системного журнала Windows.

Get-WinEvent `
    -FilterHashtable @{
        LogName='System'
        StartTime=(Get-Date).AddMinutes(-10)
    } |
Select TimeCreated, ProviderName, Id, LevelDisplayName, Message |
Format-List

Практически сразу были обнаружены повторяющиеся ошибки Schannel.

Event ID: 36870

Произошла неустранимая ошибка при попытке обращения
к закрытому ключу учетных данных TLS server.

Код ошибки:
0x8009030D

Одновременно фиксировались ошибки службы удалённых рабочих столов.

Event ID: 1057

Серверу узла сеансов удаленных рабочих столов
не удалось создать новый самозаверяющий сертификат
для использования при проверке подлинности сервера.

Код состояния:
Указан неправильный алгоритм.

Warning

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

03. Проверяем состояние служб

Проверяем службы, участвующие в работе TLS и криптографической подсистемы.

Get-Service `
    TermService,
    KeyIso,
    CryptSvc |
Format-Table Name, Status, StartType -Auto

Результат:

TermService Running
KeyIso      Running
CryptSvc    Running

Все необходимые службы были запущены и работали без ошибок.

04. Проверяем сертификаты

Проверяем сертификаты локального компьютера.

certutil -store My

После этого проверяем специализированное хранилище сертификатов Remote Desktop.

certutil -store RemoteDesktop

В результате была получена ошибка:

CertUtil: -store команда НЕ ВЫПОЛНЕНА

0x80070002

Не удается найти указанный файл.

Хранилище сертификатов Remote Desktop отсутствовало.

К этому моменту стало понятно, что проблема связана не только со службой удалённых рабочих столов, но и с инфраструктурой сертификатов Windows.

05. Проверяем криптографических провайдеров

Следующим шагом проверяем работу криптографической подсистемы Windows.

Для просмотра установленных криптографических провайдеров выполняем команду:

certutil -v -csptest

Во время выполнения команды неожиданно запускался CryptoPro и запрашивал подключение носителя закрытых ключей.

Такое поведение выглядело нетипичным и потребовало дополнительной проверки.

Просматриваем список зарегистрированных криптографических провайдеров.

certutil -csplist

В системе присутствовали CryptoPro CSP.

Note

На этом этапе не удалось установить, связан ли отказ службы удалённых рабочих столов непосредственно с CryptoPro.

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

06. Проверяем ключи

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

CertUtil: -delkey команда НЕ ВЫПОЛНЕНА

0x80090016

NTE_BAD_KEYSET

Набор ключей не существует

Одновременно продолжали появляться события:

Schannel 36870

0x8009030D

и

RemoteConnectionManager 1057

Указан неправильный алгоритм

К этому моменту удалось установить следующее:

сеть работает исправно;
порт TCP/3389 доступен;
служба удалённых рабочих столов запущена;
проблема связана с TLS-сертификатом или его закрытым ключом.

При этом установить не удалось:

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

07. Создаём новый сертификат

Восстанавливать существующий сертификат не стали.

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

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

Останавливаем службу RDP.

Stop-Service TermService -Force

Создаём новый сертификат.

$Cert = New-SelfSignedCertificate `
    -DnsName $env:COMPUTERNAME `
    -CertStoreLocation "Cert:\LocalMachine\My" `
    -KeyAlgorithm RSA `
    -KeyLength 2048 `
    -HashAlgorithm SHA256 `
    -Provider "Microsoft Software Key Storage Provider" `
    -NotAfter (Get-Date).AddYears(5) `
    -TextExtension @(
        "2.5.29.37={text}1.3.6.1.5.5.7.3.1"
    )

$Hash = $Cert.Thumbprint

08. Привязываем сертификат к RDP

Получаем объект RDP-Tcp.

$ts = Get-CimInstance `
    -Namespace root/cimv2/TerminalServices `
    -ClassName Win32_TSGeneralSetting `
    -Filter "TerminalName='RDP-tcp'"

Привязываем новый сертификат.

Set-CimInstance `
    -InputObject $ts `
    -Property @{
        SSLCertificateSHA1Hash = $Hash
    }

09. Запускаем службу RDP

Запускаем службу удалённых рабочих столов.

Start-Service TermService

Проверяем, что новый сертификат успешно привязан.

Get-CimInstance `
    -Namespace root/cimv2/TerminalServices `
    -ClassName Win32_TSGeneralSetting `
    -Filter "TerminalName='RDP-tcp'" |
Select TerminalName, SSLCertificateSHA1Hash

10. Проверяем результат

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

В рассматриваемом случае были получены следующие результаты:

RDP снова начал принимать подключения;
ошибка 0x4 больше не появлялась;
события Schannel 36870 перестали регистрироваться;
новые события RemoteConnectionManager 1057 больше не возникали.

Дополнительных изменений не потребовалось.

Настройки сети, брандмауэра, NLA и службы удалённых рабочих столов остались без изменений.

Вывод

Если одновременно выполняются следующие условия:

порт TCP/3389 доступен;
служба TermService работает;
слушатель RDP-Tcp находится в состоянии «Прием»;
клиент получает ошибку 0x4;
в системном журнале появляются события Schannel 36870 и RemoteConnectionManager 1057,

то в первую очередь следует проверить сертификат службы удалённых рабочих столов и связанный с ним закрытый ключ.

В рассматриваемом случае причиной отказа являлась невозможность использования TLS-сертификата или его закрытого ключа.

После выпуска нового сертификата через Microsoft Software Key Storage Provider и его привязки к службе RDP работа удалённого рабочего стола была полностью восстановлена.

Не удалось установить:

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

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

Перед заменой сертификата рекомендуется сохранить текущую конфигурацию службы удалённых рабочих столов.

Минимальный набор:

текущий сертификат компьютера (если его можно экспортировать);
резервную копию системы или точку восстановления;
текущее значение SSLCertificateSHA1Hash;
журналы событий, если планируется дальнейший анализ причины неисправности.

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

После восстановления работоспособности рекомендуется повторно проверить:

подключение по RDP;
отсутствие новых событий Schannel 36870;
отсутствие новых событий RemoteConnectionManager 1057;
успешную привязку сертификата к объекту RDP-Tcp.