Ошибка RDP: не проходит проверка подлинности на уровне сети (NLA)

Вы вводите имя пользователя и пароль в подключении к удалённому рабочему столу, нажимаете «Подключить», и ещё до появления экрана входа приходит сообщение об ошибке. Ни рабочего стола, ни индикатора загрузки, ничего. Именно так выглядит проблема с NLA: проверка подлинности на уровне сети выполняется до создания сеанса. Если она не проходит, окно входа, в котором можно было бы что-то исправить, вы так и не увидите.

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

Сообщения об ошибке дословно

Сообщение не одно, их несколько, и точная формулировка уже сильно сужает круг причин. Чаще всего встречаются такие варианты:

• «Удалённый компьютер требует проверки подлинности на уровне сети, которую данный компьютер не поддерживает.» Сервер требует NLA, клиент его не предоставляет. Типично для старых клиентов, для сторонних клиентов под Linux или macOS и для неверно заданных политик на стороне клиента.
• «Произошла ошибка проверки подлинности. Не удаётся связаться с локальным центром безопасности.» В английской версии: «The Local Security Authority cannot be contacted». Это классическое сообщение о проблеме с сертификатом или о расхождении времени.
• «Произошла ошибка проверки подлинности. Указанная функция не поддерживается.» Почти всегда это CredSSP, а не NLA в узком смысле. Подробнее об этом ниже.
• «Учётные данные, использованные для подключения, не сработали.» Учётная запись заблокирована, отключена, срок действия пароля истёк или записи нет в группе пользователей удалённого рабочего стола.
• «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом.» Учётная запись компьютера в домене больше не совпадает с записью на контроллере.

Важное разграничение: если клиент через двадцать секунд сообщает, что удалённый компьютер недоступен, это не ошибка NLA, а сеть, файрвол или незапущенная служба. Ошибки NLA приходят быстро, обычно за одну-три секунды, потому что TCP-соединение уже установлено и не проходит именно проверка подлинности.

Причина 1: расхождение времени между клиентом и сервером

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

• Kerberos по умолчанию допускает расхождение не более пяти минут. Свыше этого контроллер домена отклоняет запрос с ошибкой KRB_AP_ERR_SKEW. Касается всех членов домена.
• Проверка TLS-сертификата RDP не проходит, когда часы клиента выходят за пределы срока действия серверного сертификата. Это затрагивает и отдельные серверы без домена, а именно тогда, когда сервер после перезагрузки поднимается с часами в прошлом и свежесозданный сертификат с точки зрения клиента ещё вообще не действителен.

Проверка на сервере, в PowerShell с правами администратора:

w32tm /query /status /verbose
w32tm /query /source
w32tm /stripchart /computer:ptbtime1.ptb.de /samples:5 /dataonly

Stripchart показывает смещение в секундах. Значение меньше секунды — норма, больше 60 секунд — уже подозрительно, больше 300 секунд — прямое объяснение ошибки.

Здесь системы расходятся, а большинство инструкций валит всё в одну кучу:

• Отдельный сервер без домена: задать внешний источник NTP.
• Член домена: ни в коем случае не задавать собственный список серверов времени. Рядовой сервер обязан получать время из иерархии домена, иначе он уйдёт по времени от контроллера домена.

w32tm /config /manualpeerlist:"ptbtime1.ptb.de,0x9 time.windows.com,0x9" /syncfromflags:manual /update

w32tm /config /syncfromflags:domhier /update

После этого в обоих случаях перезапустите службу и выполните синхронизацию:

net stop w32time
net start w32time
w32tm /resync /rediscover

Особенность, которая подстерегает на виртуальных серверах: если часы врут ровно на один или два часа, это не дрейф, а разное толкование аппаратных часов. Windows ожидает RTC в местном времени, многие платформы виртуализации отдают их в UTC. Сначала проверьте часовой пояс, а затем при необходимости измените толкование:

tzutil /g
tzutil /s "W. Europe Standard Time"

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f

Причина 2: просроченный или неправильно привязанный сертификат

Без собственной инфраструктуры PKI Windows создаёт для RDP самоподписанный сертификат сроком примерно на полгода, который обычно обновляется сам. Ключевое слово здесь «обычно». Если обновление срывается из-за прав в хранилище ключей или если истекает срок вручную привязанного сертификата из внутреннего центра сертификации, войти уже не получится, и вы увидите сообщение о локальном центре безопасности.

Проверка наличия:

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Select-Object Subject, NotBefore, NotAfter, Thumbprint

А затем то, какой сертификат прослушиватель использует на самом деле:

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'").SSLCertificateSHA1Hash

Сравните полученный хеш с отпечатками из первой команды. Возможны две картины: хеш указывает на просроченный сертификат либо на сертификат, которого в хранилище уже нет.

Починка сводится к тому, чтобы снять привязку и удалить старый сертификат. Новый Windows создаст сам при запуске службы:

Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name SSLCertificateSHA1Hash -ErrorAction SilentlyContinue

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Where-Object { $_.NotAfter -lt (Get-Date) } | Remove-Item

Restart-Service TermService -Force

Два предупреждения к этому. Во-первых, перезапуск TermService обрывает все существующие сеансы RDP, включая ваш собственный, если вы всё же каким-то образом внутри. Выполняйте это через консоль. Во-вторых: если групповая политика задаёт шаблон сертификата для проверки подлинности сервера, сервер получает сертификат из внутреннего центра сертификации. Если центр недоступен или срок действия шаблона истёк, новый сертификат не появится и ошибка останется. Тогда проверяйте сначала центр сертификации, а не сервер.

Контроль результата: первая команда теперь возвращает сертификат с датой NotAfter в будущем, а SSLCertificateSHA1Hash указывает именно на него.

Причина 3: учётная запись заблокирована, отключена или срок действия пароля истёк

Здесь кроется ловушка, которая отличает NLA от всех прочих проблем со входом: при включённом NLA сменить просроченный пароль через RDP-клиент невозможно. Диалог «Срок действия пароля истёк, его необходимо изменить» появляется только внутри сеанса, а до сеанса без пройденной проверки подлинности вы не доберётесь. Вместо этого клиент сообщает лишь, что учётные данные не сработали. Пароль при этом совершенно верный, просто его срок истёк.

Посмотреть состояние локальной учётной записи:

net user Administrator

Обратите внимание на строки «Учётная запись активна», «Срок действия учётной записи», «Срок действия пароля истекает» и «Пароль может быть изменён». Подходящие меры:

net user Administrator "NewLongPassword!2026"

Enable-LocalUser -Name "Administrator"

Set-LocalUser -Name "Administrator" -PasswordNeverExpires $true

Локальная учётная запись, заблокированная после слишком большого числа неудачных попыток, — это отдельное состояние, которое не снимается ни командой Enable-LocalUser, ни сменой пароля. Она разблокируется сама по истечении срока блокировки, а посмотреть его можно так:

net accounts

Разблокировать сразу, без графических средств управления, можно через ADSI:

$u = [ADSI]"WinNT://./Administrator,user"; $u.IsAccountLocked = $false; $u.SetInfo()

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

Напоследок членство в группе. Название группы локализовано, и скрипты об это регулярно спотыкаются. Независимо от языка запрос делается по известному SID:

Get-LocalGroupMember -SID "S-1-5-32-555"

Причина 4: NLA на сервере отключён или отключён наполовину

Поведение определяют два отдельных переключателя, и неприятности создаёт именно их сочетание. UserAuthentication управляет NLA, SecurityLayer отвечает за защиту транспорта со значениями 0 для старого уровня безопасности RDP, 1 для согласования и 2 для принудительного TLS.

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer

Типичный тупик: кто-то отключает NLA, подозревая проблему с сертификатом, но оставляет SecurityLayer в значении 2. Согласование TLS со сломанным сертификатом при этом сохраняется, и меняется только формулировка ошибки. Если для диагностики действительно нужно понизить обе настройки, понижайте обе, а потом восстановите их.

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'") | Invoke-CimMethod -MethodName SetUserAuthenticationRequired -Arguments @{UserAuthenticationRequired=0}

Второй тупик ещё неприятнее: вы задаёте значение в реестре, перезагружаете сервер, а оно снова равно 1. Значит, оно приходит из групповой политики. Значения политик лежат в другом месте и всегда побеждают:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v UserAuthentication

gpresult /r /scope:computer

Пока там задано значение, любое локальное изменение действует лишь до следующего применения политики. Политика называется «Требовать проверку подлинности пользователя для удалённых подключений путём проверки подлинности на уровне сети», и менять её нужно на контроллере домена.

И самое важное правило в конце этого раздела: отключить NLA насовсем — не решение, а открытая дверь. Без NLA любой, кто дотянется до порта, получает доступ к экрану входа и тем самым к незащищённой части стека сеансов. Отключайте его для диагностики и сразу включайте обратно.

Причина 5: нарушенные доверительные отношения с доменом

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

Классический повод в эксплуатации серверов — откат к более раннему состоянию, например из резервной копии или снимка, который старше последней смены пароля. Проверка:

Test-ComputerSecureChannel -Verbose

nltest /sc_verify:mydomain.local

Восстановление, под локальным администратором через консоль:

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

Reset-ComputerMachinePassword -Credential (Get-Credential)

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

Restart-Service Netlogon

Когда RDP не работает совсем: путь через консоль

Все команды выше предполагают, что на сервер вы как-то попадаете. В серьёзной ситуации это как раз не так. Поэтому на KVM root-серверах KernelHost в личном кабинете доступна VNC-консоль, которая работает независимо от RDP, от файрвола Windows и даже от сетевого стека гостевой системы. Это аварийный доступ, с помощью которого вы самостоятельно выбираетесь из любой описанной выше ситуации. На выделенных серверах аварийный доступ организуется через поддержку.

Три вещи на VNC-консоли устроены иначе, чем в сеансе RDP, и регулярно отнимают время:

• Раскладка клавиатуры. Консоль часто отдаёт раскладку US, тогда как в Windows выбрана другая, или наоборот. Спецсимволы в паролях тогда вводятся неверно, и правильный пароль кажется вам ошибочным. В сомнительном случае используйте экранную клавиатуру osk.exe прямо с экрана входа.
• Буфер обмена. Копирование со своего компьютера в консоль чаще всего не работает. Рассчитывайте на ручной ввод и подбирайте временные пароли соответственно.
• Вход под локальной учётной записью. При проблемах с доменом входите как .\Administrator: точка и обратная косая черта заставляют использовать локальную запись вместо доменной.

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

sc query TermService

netstat -ano | findstr :3389

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections

Если fDenyTSConnections равен 1, удалённые подключения выключены полностью, независимо от NLA:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

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

Enable-NetFirewallRule -Group "@FirewallAPI.dll,-28752"

Особый случай CredSSP, который часто путают

Если в сообщении дословно сказано «Указанная функция не поддерживается» и упоминается исправление шифрующего оракула CredSSP, то ни одна из пяти причин выше ни при чём. Здесь не совпадают уровни обновлений клиента и сервера: одна сторона требует усиленный вариант CredSSP, другая его ещё не знает.

Единственное чистое решение — обновить обе стороны. Гуляющее по сети изменение реестра с AllowEncryptionOracle на клиенте отключает ровно ту защиту, из-за которой возникает ошибка, и тем самым снова открывает известный путь атаки. Если оно ненадолго нужно, чтобы установить обновления, верните значение обратно, как только сервер станет актуальным.

Как понять, что проблема действительно устранена

Успешное подключение — самое слабое доказательство, потому что оно проходит и в том случае, когда NLA отключён для диагностики. Проверьте вместо этого по порядку:

1. NLA снова включён. UserAuthentication равен 1, а SecurityLayer равен 2.
2. Часы точны. Смещение из stripchart меньше секунды, а w32tm /query /source называет реальный источник, а не «Local CMOS Clock» и не «Free-running System Clock».
3. Сертификат действителен. NotAfter лежит в будущем, а привязанный хеш указывает именно на этот сертификат.
4. Журнал событий подтверждает пройденную проверку подлинности на уровне сети. Событие 1149 появляется только после прохождения NLA, и потому именно оно служит настоящим доказательством.

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" -MaxEvents 20 | Where-Object Id -eq 1149

Для обратной проверки при неудачных попытках коды состояния в событии 4625 говорят больше, чем любое сообщение клиента: 0xC0000071 означает истёкший срок действия пароля, 0xC0000072 отключённую учётную запись, 0xC0000234 заблокированную учётную запись, а 0xC000006A действительно неверный пароль.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

И напоследок сами сеансы, лучше прямо из консоли:

qwinsta

Краткая сверка для поиска причины

Если вы разворачиваете новый сервер Windows, имеет смысл сразу правильно задать источник времени, политики учётных записей и способ доступа, а не чинить их потом в спешке. В качестве ориентира подойдёт чек-лист для нового root-сервера, а тем, кто хочет дополнительно защитить доступ по RDP, статья смена порта RDP без перезагрузки описывает самый простой первый шаг против автоматических попыток входа.