// DevOps

Windows Server 2019: RDP перестал подключаться, хотя порт 3389 открыт. Диагностика и лечение ошибки Event ID 1057

Опубликовано 08.07.2026

Вводная

Один из неприятных сценариев на Windows Server — когда Remote Desktop внезапно перестаёт работать, хотя снаружи всё выглядит «почти нормально»:

порт 3389 открыт;
служба Remote Desktop Services запущена;
firewall не блокирует подключение;
qwinsta показывает, что rdp-tcp слушает;
но подключиться нельзя даже администратором;
RemoteApp тоже не работает, потому что базовый RDP не поднимает сессию.

В моём случае проблема проявилась на Windows Server 2019 с RDS/RemoteApp. Сначала казалось, что сломался именно RemoteApp, но диагностика быстро показала: проблема ниже, на уровне RDP TLS / сертификата / SChannel.

Ключевой симптом в журнале событий:

Event ID: 1057
Provider: Microsoft-Windows-TerminalServices-RemoteConnectionManager

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

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

В этой статье разберём:

как правильно диагностировать такой отказ;
как понять, что порт открыт, но RDP всё равно не работает;
почему отключение TLS временно возвращает доступ;
как восстановить нормальную работу RDP через корректный сертификат;
почему нельзя оставлять SecurityLayer = 0;
что проверить после восстановления;
как вернуть RemoteApp/RDWeb после ремонта базового RDP.

1. Симптомы

Изначально проблема выглядела так:

пользователи не могут запускать RemoteApp;
обычное RDP-подключение тоже не работает;
не входит даже администратор;
порт 3389 открыт;
службы RDP запущены.

Что видит пользователь на клиенте

Со стороны клиента mstsc эта поломка выглядит по-разному в зависимости от версии клиента и настроек подключения. Чаще всего это одно из двух сообщений.

Первый вариант — лаконичное:

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

В английской версии клиента:

An internal error has occurred.

Второй вариант — с кодами:

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

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

Оба сообщения — это одна и та же проблема, видимая с разных сторон. Клиент устанавливает TCP-соединение на 3389, начинает TLS handshake — и сервер обрывает соединение, потому что не может предъявить сертификат. Клиент не знает, почему сервер оборвал сессию, поэтому показывает обобщённую «внутреннюю ошибку» или код 0x904 с расширенным кодом 0x7.

Важный вывод для диагностики: если клиент показывает «Произошла внутренняя ошибка» или 0x904 / 0x7, коды на клиенте дальше можно не расшифровывать. Настоящая причина — на сервере, и искать её нужно в журнале событий сервера, а не на клиенте.

Состояние служб на сервере

На сервере службы выглядели так:

powershell
Get-Service TermService,SessionEnv,UmRdpService,W3SVC -ErrorAction SilentlyContinue |
Select-Object Name,DisplayName,Status,StartType

Пример вывода:

Name         DisplayName                                                                     Status   StartType
----         -----------                                                                     ------   ---------
SessionEnv   Настройка сервера удаленных рабочих столов                                      Running  Manual
TermService  Службы удаленных рабочих столов                                                 Running  Manual
UmRdpService Перенаправитель портов пользовательского режима служб удаленных рабочих столов  Running  Manual
W3SVC        Служба веб-публикаций                                                           Stopped  Disabled

На этом этапе важно не сделать ошибочный вывод.

W3SVC нужен для IIS и RD Web Access. Если он остановлен, веб-портал RemoteApp может быть недоступен. Но W3SVC сам по себе не должен ломать обычный mstsc на порт 3389.

Если не работает даже прямой RDP, нужно сначала чинить базовый RDP, а уже потом возвращаться к RemoteApp/RDWeb.

2. Важное разделение: открыт порт — не значит работает RDP

Очень частая ловушка: администратор проверяет порт 3389, видит, что он открыт, и считает, что RDP должен работать.

Например:

powershell
Test-NetConnection server.example.com -Port 3389

Или с Linux/macOS:

bash

nc -vz server.example.com 3389

Если TCP-порт открыт, это доказывает только одно: до сервера можно установить TCP-соединение на 3389.

Это не доказывает, что дальше успешно работают:

RDP listener;
WinStation RDP-Tcp;
TLS handshake;
NLA;
CredSSP;
RDP certificate;
права интерактивного входа;
RDS licensing;
RemoteApp collection.

В моём случае порт был открыт, но TLS-часть RDP не работала.

3. Первый слой диагностики: слушает ли RDP listener

На сервере нужно проверить состояние RDP-сессий:

cmd

qwinsta

или:

cmd

query session

В моём случае вывод был таким:

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

Строка:

rdp-tcp  65536  Прием

означает, что RDP listener существует и находится в состоянии приёма подключений.

Также нужно проверить, не отключены ли новые входы:

cmd

change logon /query

Нормальный вывод:

Вход из сеансов сейчас ВКЛЮЧЕН

Если входы отключены, включаем:

cmd

change logon /enable

4. Проверяем, не отключён ли RDP в registry

Базовая настройка RDP хранится здесь:

powershell
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' |
Select-Object fDenyTSConnections

Нормальное значение:

fDenyTSConnections : 0

Если там 1, RDP запрещён:

powershell
Set-ItemProperty `
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
  -Name fDenyTSConnections `
  -Value 0

5. Проверяем параметры RDP-Tcp

Дальше смотрим настройки самого RDP listener:

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Get-ItemProperty $RdpTcp |
Select-Object `
  PortNumber,
  UserAuthentication,
  SecurityLayer,
  MinEncryptionLevel,
  fEnableWinStation,
  MaxInstanceCount,
  SSLCertificateSHA1Hash

В моём случае было:

PortNumber             : 3389
UserAuthentication     : 0
SecurityLayer          : 2
MinEncryptionLevel     : 2
fEnableWinStation      : 1
MaxInstanceCount       : 4294967295
SSLCertificateSHA1Hash :

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

порт 3389;
WinStation включён;
максимальное число сессий не ограничено;
NLA отключён для диагностики.

Но есть важная деталь:

SecurityLayer : 2
SSLCertificateSHA1Hash : пусто

SecurityLayer = 2 означает, что RDP должен использовать SSL/TLS. А пустой SSLCertificateSHA1Hash означает, что явной привязки сертификата нет.

Обычно Windows может сама создать self-signed сертификат для RDP. Но если создание сертификата ломается, TLS-подключение к RDP тоже ломается.

6. Что означают SecurityLayer и UserAuthentication

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

SecurityLayer

SecurityLayer = 0

Используется старый RDP Security Layer. Это аварийный и менее безопасный режим. Его можно использовать только временно для восстановления доступа.

SecurityLayer = 1

Negotiate. Клиент и сервер договариваются о доступном уровне безопасности. Обычно это практичный и безопасный вариант для восстановления.

SecurityLayer = 2

SSL/TLS only. Сервер требует TLS. Если TLS-сертификат или SChannel сломан, RDP может перестать подключаться совсем.

UserAuthentication

UserAuthentication = 0

NLA отключён.

UserAuthentication = 1

NLA включён.

NLA желательно использовать в рабочем режиме, но на время диагностики его можно отключить, чтобы отделить проблему аутентификации от проблемы транспорта/TLS.

7. Ключевая проверка: отключаем TLS временно

Чтобы понять, действительно ли проблема в TLS, можно временно перевести RDP в аварийный режим:

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Set-ItemProperty -Path $RdpTcp -Name UserAuthentication -Value 0
Set-ItemProperty -Path $RdpTcp -Name SecurityLayer -Value 0
Set-ItemProperty -Path $RdpTcp -Name MinEncryptionLevel -Value 1

Restart-Service TermService -Force

Учтите: Restart-Service TermService -Force разрывает все активные RDP-сессии. В нашем сценарии подключиться всё равно никто не может, поэтому терять нечего, но на «полуживом» сервере это стоит помнить.

После этого проверяем подключение:

cmd

mstsc /admin /v:127.0.0.1

Или с другой машины:

cmd

mstsc /admin /v:<server_ip>

В моём случае после отключения TLS RDP заработал.

Это важнейший диагностический результат.

Он означает:

порт 3389 рабочий;
TermService рабочий;
listener rdp-tcp рабочий;
права администратора на вход есть;
проблема не в firewall;
проблема не в RemoteApp;
проблема именно в RDP TLS / сертификате / SChannel.

8. Подтверждение через Event Viewer

После попыток подключения с TLS в журнале событий была ошибка:

Event ID: 1057
Provider: Microsoft-Windows-TerminalServices-RemoteConnectionManager
Level: Error

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

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

«Указан неправильный алгоритм» — это текстовое описание ошибки NTE_BAD_ALGID (0x80090008) из криптографического API Windows. Именно она и приводит к тому, что клиент видит «Произошла внутренняя ошибка» или 0x904 / 0x7.

Посмотреть такие события можно командой:

powershell
Get-WinEvent `
  -LogName System `
  -MaxEvents 200 |
Where-Object {
    $_.ProviderName -eq 'Microsoft-Windows-TerminalServices-RemoteConnectionManager' -and
    $_.Id -eq 1057
} |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Format-List

Также полезно проверить RDP-логи:

powershell
Get-WinEvent `
  -LogName 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Admin' `
  -MaxEvents 50 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

powershell
Get-WinEvent `
  -LogName 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational' `
  -MaxEvents 50 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

И SChannel:

powershell
Get-WinEvent -LogName System -MaxEvents 200 |
Where-Object {
    $_.ProviderName -eq 'Schannel' -or
    $_.Message -match 'TLS|SSL|certificate|сертификат|handshake'
} |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Format-List

9. Почему возникает Event ID 1057

В нормальной ситуации Windows Server может автоматически создать самозаверяющий сертификат для RDP. Этот сертификат используется для проверки подлинности сервера при TLS-подключении.

Ошибка 1057 говорит о том, что Windows не смогла создать такой сертификат.

Причины могут быть разные:

повреждён или недоступен crypto provider;
проблема с правами на MachineKeys;
включены жёсткие crypto/FIPS-политики;
отключены нужные TLS/SChannel алгоритмы;
повреждена старая привязка RDP-сертификата;
сертификат был удалён, но Windows не может создать новый;
использован неподходящий алгоритм/провайдер;
изменены настройки через hardening-инструменты вроде IIS Crypto или GPO;
повреждены системные компоненты криптографии.

В моём случае самый быстрый и правильный recovery-путь — не ждать автогенерации от TermService, а создать сертификат вручную и явно привязать его к RDP-tcp.

10. Перед исправлением: делаем backup

Перед изменением RDP-настроек сохраняем текущую ветку registry:

cmd
mkdir C:\Temp 2>nul

reg export "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" C:\Temp\RDP-Tcp-backup.reg /y

Также сохраняем текущие параметры:

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Get-ItemProperty $RdpTcp |
Select-Object `
  PortNumber,
  UserAuthentication,
  SecurityLayer,
  MinEncryptionLevel,
  fEnableWinStation,
  SSLCertificateSHA1Hash |
Out-File C:\Temp\RDP-Tcp-before.txt

11. Проверяем FIPS-политику

Ошибка «Указан неправильный алгоритм» может быть связана с crypto policy. Проверяем FIPS:

powershell
Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy' `
  -ErrorAction SilentlyContinue |
Select-Object Enabled

Если:

Enabled : 1

значит FIPS включён.

Также стоит проверить результат групповых политик:

cmd

gpresult /h C:\Temp\gpresult.html

В отчёте ищем:

System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

Если сервер в домене и FIPS включён через GPO, не стоит просто отключать его локально. Локальные изменения могут откатиться, а сама политика могла быть включена по требованиям безопасности.

12. Проверяем TLS 1.2 в SChannel

На Windows Server 2019 для RDP нормально использовать TLS 1.2.

Проверяем настройки TLS:

powershell
$paths = @(
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client',
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server',
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client',
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server',
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client',
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server'
)

foreach ($path in $paths) {
    Write-Host "`n$path" -ForegroundColor Cyan

    Get-ItemProperty $path -ErrorAction SilentlyContinue |
    Select-Object Enabled, DisabledByDefault
}

Если TLS 1.2\Server существует и там:

Enabled : 0

или:

DisabledByDefault : 1

TLS 1.2 на серверной стороне отключён.

Кстати, отключённый на сервере TLS 1.2 — сам по себе частая причина клиентской ошибки «Произошла внутренняя ошибка», даже когда сертификат в порядке: современный клиент просто не может согласовать протокол.

Включить TLS 1.2 можно так:

powershell
$Tls12Server = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server'
$Tls12Client = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client'

New-Item -Path $Tls12Server -Force | Out-Null
New-Item -Path $Tls12Client -Force | Out-Null

New-ItemProperty -Path $Tls12Server -Name Enabled -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $Tls12Server -Name DisabledByDefault -Value 0 -PropertyType DWord -Force | Out-Null

New-ItemProperty -Path $Tls12Client -Name Enabled -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $Tls12Client -Name DisabledByDefault -Value 0 -PropertyType DWord -Force | Out-Null

После изменения SChannel-настроек часто нужна перезагрузка. Но сначала можно восстановить RDP-сертификат и проверить работу.

13. Проверяем права на MachineKeys

Windows хранит машинные приватные ключи здесь:

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

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

Сохраняем текущие ACL:

cmd
mkdir C:\Temp 2>nul
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c > C:\Temp\MachineKeys-before.txt

Базовое восстановление прав:

cmd
takeown /f "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /a /r

icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /t /c /grant "NT AUTHORITY\SYSTEM:(F)"
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /t /c /grant "BUILTIN\Administrators:(F)"
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /t /c /grant "NT AUTHORITY\NETWORK SERVICE:(R)"
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /t /c > C:\Temp\MachineKeys-after.txt

Это recovery-шаг. В продакшене лучше сохранять исходные ACL и понимать, какие политики управляют правами.

14. Удаляем старую RDP TLS-привязку

Удаляем старый hash сертификата из RDP-Tcp:

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Remove-ItemProperty `
  -Path $RdpTcp `
  -Name SSLCertificateSHA1Hash `
  -ErrorAction SilentlyContinue

Удаляем старые RDP self-signed сертификаты из хранилища Remote Desktop:

powershell
Get-ChildItem 'Cert:\LocalMachine\Remote Desktop' -ErrorAction SilentlyContinue |
Remove-Item -Force

Проверяем, что осталось:

powershell
Get-ChildItem 'Cert:\LocalMachine\Remote Desktop' -ErrorAction SilentlyContinue |
Select-Object Subject, Thumbprint, NotAfter

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

Ключевой момент: сертификат лучше создать явно с RSA/SHA256 и совместимым crypto provider.

В моём случае я использовал:

Microsoft RSA SChannel Cryptographic Provider

Команда:

powershell
$ComputerSystem = Get-CimInstance Win32_ComputerSystem

$DnsNames = @($env:COMPUTERNAME)

if ($ComputerSystem.PartOfDomain) {
    $DnsNames += "$env:COMPUTERNAME.$($ComputerSystem.Domain)"
}

$Cert = New-SelfSignedCertificate `
  -DnsName $DnsNames `
  -CertStoreLocation 'Cert:\LocalMachine\My' `
  -Provider 'Microsoft RSA SChannel Cryptographic Provider' `
  -KeyAlgorithm RSA `
  -KeyLength 2048 `
  -HashAlgorithm SHA256 `
  -KeySpec KeyExchange `
  -KeyUsage DigitalSignature, KeyEncipherment `
  -NotAfter (Get-Date).AddYears(3) `
  -TextExtension @('2.5.29.37={text}1.3.6.1.5.5.7.3.1')

$Cert |
Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey

Нужно убедиться, что:

HasPrivateKey : True

Без приватного ключа такой сертификат для RDP бесполезен.

Даём TermService доступ к приватному ключу

TermService работает от имени NETWORK SERVICE. Если у этой учётной записи нет права читать приватный ключ, RDP не сможет использовать сертификат — и мы получим ту же клиентскую «внутреннюю ошибку», только с новым сертификатом.

Выдаём права на файл ключа:

powershell
$RsaKey = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($Cert)
$KeyFile = $RsaKey.Key.UniqueName
$KeyPath = Join-Path 'C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys' $KeyFile

icacls $KeyPath /grant 'NT AUTHORITY\NETWORK SERVICE:(R)'

Проверяем:

powershell
icacls $KeyPath

В выводе должна быть строка с NT AUTHORITY\NETWORK SERVICE:(R).

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

Теперь назначаем сертификат на RDP-tcp.

powershell
$RdpSetting = Get-WmiObject `
  -Namespace 'root\cimv2\TerminalServices' `
  -Class 'Win32_TSGeneralSetting' `
  -Filter "TerminalName='RDP-tcp'"

Set-WmiInstance `
  -Path $RdpSetting.__PATH `
  -Arguments @{ SSLCertificateSHA1Hash = $Cert.Thumbprint }

Проверяем:

powershell
Get-WmiObject `
  -Namespace 'root\cimv2\TerminalServices' `
  -Class 'Win32_TSGeneralSetting' `
  -Filter "TerminalName='RDP-tcp'" |
Select-Object TerminalName, SSLCertificateSHA1Hash

Также проверяем registry:

powershell
Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' |
Select-Object SSLCertificateSHA1Hash

Значение должно быть не пустым.

17. Возвращаем RDP из аварийного режима

Не стоит сразу возвращать принудительный TLS SecurityLayer = 2.

Сначала ставим безопасный промежуточный вариант:

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Set-ItemProperty -Path $RdpTcp -Name SecurityLayer -Value 1
Set-ItemProperty -Path $RdpTcp -Name MinEncryptionLevel -Value 2
Set-ItemProperty -Path $RdpTcp -Name UserAuthentication -Value 0

Restart-Service TermService -Force

Проверяем локально:

cmd

mstsc /admin /v:127.0.0.1

Проверяем снаружи:

cmd

mstsc /admin /v:<server_ip_or_fqdn>

Если работает — возвращаем NLA:

powershell
Set-ItemProperty `
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name UserAuthentication `
  -Value 1

Restart-Service TermService -Force

Проверяем ещё раз:

cmd

mstsc /admin /v:<server_ip_or_fqdn>

18. Можно ли вернуть SecurityLayer = 2

Если хочется принудительно использовать TLS, после успешной проверки с SecurityLayer = 1 можно попробовать:

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Set-ItemProperty -Path $RdpTcp -Name SecurityLayer -Value 2
Set-ItemProperty -Path $RdpTcp -Name MinEncryptionLevel -Value 3
Set-ItemProperty -Path $RdpTcp -Name UserAuthentication -Value 1

Restart-Service TermService -Force

Проверяем:

cmd

mstsc /admin /v:<server_ip_or_fqdn>

Если при SecurityLayer = 1 всё работает, а при SecurityLayer = 2 снова ломается, значит проблема с TLS/SChannel/certificate policy полностью не устранена.

В таком случае лучше временно оставить:

SecurityLayer = 1
UserAuthentication = 1
MinEncryptionLevel = 2 или 3

Это значительно лучше, чем аварийный режим:

SecurityLayer = 0

19. Проверяем, исчезла ли ошибка 1057

После восстановления сертификата и перезапуска TermService проверяем журнал:

powershell
Get-WinEvent `
  -LogName System `
  -MaxEvents 100 |
Where-Object {
    $_.ProviderName -eq 'Microsoft-Windows-TerminalServices-RemoteConnectionManager' -and
    $_.Id -eq 1057
} |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

Если новых событий 1057 после перезапуска нет, это хороший признак.

Также можно посмотреть события рядом:

powershell
Get-WinEvent `
  -LogName System `
  -MaxEvents 100 |
Where-Object {
    $_.ProviderName -eq 'Microsoft-Windows-TerminalServices-RemoteConnectionManager' -and
    $_.Id -in 1056,1057,1058
} |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

20. Проверяем политики RDP через GPO

Если сервер в домене, настройки могут приходить политиками.

Создаём отчёт:

cmd

gpresult /h C:\Temp\gpresult.html

В отчёте ищем:

Computer Configuration
  Administrative Templates
    Windows Components
      Remote Desktop Services
        Remote Desktop Session Host
          Security

Особенно важны политики:

Require use of specific security layer for remote (RDP) connections
Require user authentication for remote connections by using Network Level Authentication
Set client connection encryption level
Server authentication certificate template

Также проверяем registry-политику:

powershell
Get-ItemProperty `
  'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' `
  -ErrorAction SilentlyContinue |
Select-Object SecurityLayer, UserAuthentication, MinEncryptionLevel, SSLCertificateSHA1Hash

Если там задано что-то вроде:

SecurityLayer : 2

локальные изменения могут откатываться после gpupdate.

21. Что делать с RemoteApp и RDWeb после восстановления RDP

После того как обычный RDP заработал, можно возвращаться к RemoteApp.

В моём случае W3SVC был остановлен и отключён:

W3SVC  Stopped  Disabled

Для RD Web Access это проблема.

Включаем IIS:

powershell
Set-Service W3SVC -StartupType Automatic
Start-Service W3SVC

Проверяем:

powershell
Get-Service W3SVC

Проверяем доступность RDWeb:

https://<server_fqdn>/RDWeb

Если используется RD Gateway, проверяем:

powershell
Get-Service TSGateway -ErrorAction SilentlyContinue

И логи:

powershell
Get-WinEvent `
  -LogName 'Microsoft-Windows-TerminalServices-Gateway/Operational' `
  -MaxEvents 50 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

Проверяем RDS deployment:

powershell
Import-Module RemoteDesktop

Get-RDServer
Get-RDSessionCollection
Get-RDRemoteApp

Проверяем права на коллекцию:

powershell
Get-RDSessionCollection | ForEach-Object {
    Write-Host "`nCollection: $($_.CollectionName)" -ForegroundColor Cyan

    Get-RDSessionCollectionConfiguration `
      -CollectionName $_.CollectionName `
      -UserGroup
}

22. Минимальный recovery-чеклист

Если нужно быстро восстановить доступ, порядок такой.

1. Проверить listener

cmd

qwinsta
change logon /query

Должно быть:

rdp-tcp  Прием
Вход из сеансов сейчас ВКЛЮЧЕН

2. Проверить параметры RDP

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Get-ItemProperty $RdpTcp |
Select-Object PortNumber, UserAuthentication, SecurityLayer, MinEncryptionLevel, fEnableWinStation, SSLCertificateSHA1Hash

3. Если нужно срочно войти — временно отключить TLS

powershell
Set-ItemProperty -Path $RdpTcp -Name UserAuthentication -Value 0
Set-ItemProperty -Path $RdpTcp -Name SecurityLayer -Value 0
Set-ItemProperty -Path $RdpTcp -Name MinEncryptionLevel -Value 1

Restart-Service TermService -Force

Проверить:

cmd

mstsc /admin /v:<server_ip>

4. Проверить Event ID 1057

powershell
Get-WinEvent `
  -LogName System `
  -MaxEvents 200 |
Where-Object {
    $_.ProviderName -eq 'Microsoft-Windows-TerminalServices-RemoteConnectionManager' -and
    $_.Id -eq 1057
} |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Format-List

5. Создать и привязать новый RSA/SHA256 сертификат

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Remove-ItemProperty `
  -Path $RdpTcp `
  -Name SSLCertificateSHA1Hash `
  -ErrorAction SilentlyContinue

Get-ChildItem 'Cert:\LocalMachine\Remote Desktop' -ErrorAction SilentlyContinue |
Remove-Item -Force

$ComputerSystem = Get-CimInstance Win32_ComputerSystem
$DnsNames = @($env:COMPUTERNAME)

if ($ComputerSystem.PartOfDomain) {
    $DnsNames += "$env:COMPUTERNAME.$($ComputerSystem.Domain)"
}

$Cert = New-SelfSignedCertificate `
  -DnsName $DnsNames `
  -CertStoreLocation 'Cert:\LocalMachine\My' `
  -Provider 'Microsoft RSA SChannel Cryptographic Provider' `
  -KeyAlgorithm RSA `
  -KeyLength 2048 `
  -HashAlgorithm SHA256 `
  -KeySpec KeyExchange `
  -KeyUsage DigitalSignature, KeyEncipherment `
  -NotAfter (Get-Date).AddYears(3) `
  -TextExtension @('2.5.29.37={text}1.3.6.1.5.5.7.3.1')

$RsaKey = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($Cert)
$KeyPath = Join-Path 'C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys' $RsaKey.Key.UniqueName
icacls $KeyPath /grant 'NT AUTHORITY\NETWORK SERVICE:(R)'

$RdpSetting = Get-WmiObject `
  -Namespace 'root\cimv2\TerminalServices' `
  -Class 'Win32_TSGeneralSetting' `
  -Filter "TerminalName='RDP-tcp'"

Set-WmiInstance `
  -Path $RdpSetting.__PATH `
  -Arguments @{ SSLCertificateSHA1Hash = $Cert.Thumbprint }

6. Вернуть нормальный режим

powershell
Set-ItemProperty -Path $RdpTcp -Name SecurityLayer -Value 1
Set-ItemProperty -Path $RdpTcp -Name MinEncryptionLevel -Value 2
Set-ItemProperty -Path $RdpTcp -Name UserAuthentication -Value 0

Restart-Service TermService -Force

Проверить:

cmd

mstsc /admin /v:<server_ip>

Если работает — вернуть NLA:

powershell
Set-ItemProperty -Path $RdpTcp -Name UserAuthentication -Value 1

Restart-Service TermService -Force

23. Что нельзя делать

Нельзя оставлять SecurityLayer = 0

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

Нельзя начинать с переустановки RDS

Если rdp-tcp слушает и RDP оживает без TLS, переустановка RDS почти наверняка избыточна.

Нельзя чинить RemoteApp, пока не работает обычный mstsc

RemoteApp зависит от RDP. Если базовый RDP не работает, диагностика RemoteApp будет шумной и малоэффективной.

Нельзя игнорировать GPO

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

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

Удаление RDP self-signed сертификата обычно допустимо, но если был назначен корпоративный сертификат, его нужно будет назначить заново.

24. Почему это решение сработало

Диагностика показала:

Порт 3389 открыт
TermService запущен
rdp-tcp слушает
Входы разрешены
RDP без TLS работает
RDP с TLS не работает
Event ID 1057: TermService не может создать self-signed certificate

Значит проблема была не в сети, не в firewall и не в правах администратора.

Корневая проблема находилась в цепочке:

TermService → RDP TLS certificate → SChannel / crypto provider → TLS handshake

Ручное создание RSA/SHA256 сертификата и явная привязка к RDP-tcp убирают зависимость от сломанной автогенерации сертификата.

После этого можно вернуть нормальные параметры безопасности:

SecurityLayer = 1
UserAuthentication = 1

И уже после этого заниматься RemoteApp, RDWeb, RD Gateway и коллекциями RDS.

25. Итог

Если на Windows Server 2019 перестал работать RDP, но порт 3389 открыт, нельзя ограничиваться проверкой firewall. Открытый TCP-порт не означает, что RDP успешно проходит TLS/NLA/CredSSP.

Со стороны клиента такая поломка выглядит как «Произошла внутренняя ошибка» (An internal error has occurred) или как код ошибки 0x904 с расширенным кодом 0x7. Расшифровывать эти клиентские коды бесполезно — причина на сервере.

В моём случае ключом к диагностике стало сравнение:

SecurityLayer = 2  → RDP не работает
SecurityLayer = 0  → RDP работает

И подтверждение в Event Viewer:

Event ID 1057
Не удалось создать новый самозаверяющий сертификат
Код состояния: Указан неправильный алгоритм

Правильное лечение:

временно восстановить доступ через SecurityLayer = 0;
не оставлять этот режим постоянно;
удалить старую RDP TLS-привязку;
создать новый RSA/SHA256 сертификат;
дать NETWORK SERVICE доступ к его приватному ключу;
явно назначить сертификат на RDP-tcp;
вернуть SecurityLayer = 1;
вернуть NLA;
проверить GPO и SChannel;
после восстановления базового RDP чинить RDWeb/RemoteApp.

Главная мысль: RemoteApp нельзя диагностировать, пока не работает обычный RDP. Сначала нужно поднять базовый RDP listener с нормальным TLS, и только потом разбирать верхние роли RDS.

Теги:

#windows-server #rdp #remoteapp #tls #schannel #certificates #troubleshooting #security #devops

Помогла статья? Поддержать Поддержать на Boosty

// Reviews

Отзывы по теме

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

Пришел с дорогим запросом по настройке VPS-сервера, но в процессе консультации Михаил предложил гораздо более простое и экономичное решение. В итоге сэкономил бюджет и время. Михаил — настоящий эксперт, который работает …

kfhzasorin