Произошла ошибка проверки подлинности. Указанная функция не поддерживается / Запрошенная функция не поддерживается
#Что такое NLA и почему ломается
Network Level Authentication (NLA) проверяет учётные данные до открытия сеанса. Если проверка не проходит, клиент выдаёт «Произошла ошибка проверки подлинности». Причины: расхождение времени между клиентом и сервером, нарушенное доверие сервера к домену (secure channel), пользователь не входит в группу «Пользователи удалённого рабочего стола», политика CredSSP на клиенте и сервере различается, истёк пароль, сертификат RDP недействителен, либо учётная запись заблокирована.
#Причины
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Расхождение времениЧасы отличаются. | Ошибка Kerberos 4. | Синхронизируйте с контроллером домена. |
| Нет права RDPПользователь не в группе. | «Подключение отклонено». | Добавьте в группу. |
| Разрыв доверия доменаПароль компьютера устарел. | Test-ComputerSecureChannel возвращает False. | Восстановите канал. |
| Несовпадение CredSSPОбновление безопасности только на одной стороне. | «Функция не поддерживается». | Обновите обе стороны. |
| Недействительный сертификатПросрочен. | Предупреждение о сертификате. | Выпустите новый. |
| Блокировка учётной записиНеверные пароли. | «Учётная запись заблокирована». | Разблокируйте. |
#Порядок
- Проверьте время на клиенте и сервереНа клиентском компьютере запустите «Подключение к удалённому рабочему столу»: Win+R →
mstsc→ Enter. Введите имя сервера, затем в «Показать параметры» проверьте сохранённое имя пользователя и домен. Если сообщение упоминает NLA или CredSSP, сохраните полный текст и время. На сервере (через консоль гипервизора или другое разрешённое подключение) проверьте требования NLA; не отключайте их ради первого теста. - Проверьте членство пользователя в группе удалённого доступаС компьютера пользователя откройте PowerShell и выполните
Test-NetConnection server.example.local -Port 3389, заменив имя на реальный сервер.TcpTestSucceeded : Trueпоказывает доступность порта, но не подтверждает верность учётных данных; приFalseпроверьте VPN, DNS и правила брандмауэра с сетевым администратором. Если сервер использует нестандартный порт, укажите его. Не открывайте RDP в Интернет без VPN или шлюза RDP. - Проверьте доверие доменаНа клиенте и сервере откройте настройки даты и времени; на сервере в PowerShell администратора запустите
w32tm /query /statusи проверьте источник и смещение часов. При доменной аутентификации большое расхождение времени может мешать входу. Командуw32tm /resyncвыполняйте на сервере только после выяснения правильного источника времени и политики домена; если синхронизация невозможна, передайте вывод администратору домена. - Проверьте политики CredSSPАдминистратор сервера: откройте «Управление компьютером» → «Локальные пользователи и группы» → «Группы» → «Пользователи удалённого рабочего стола», если система не является контроллером домена. Проверьте членство конкретного пользователя и наличие права «Разрешить вход через службы удалённых рабочих столов» в применяемой групповой политике. Членство в группе само по себе не отменяет явного запрета. Для контроллера домена используйте доменные группы и политику.
- Проверьте сертификат RDPЕсли пользователя действительно нет в разрешённой группе, согласуйте изменение с администратором безопасности. В PowerShell на нужном рядовом сервере выполните
Get-LocalGroupMember -Group "Remote Desktop Users", затем добавляйте только конкретную проверенную учётную запись через свойства группы в оснастке управления. Не добавляйтеEveryone, неизвестные доменные группы или локального администратора без необходимости. Проверьте вход тестовой учётной записью. - Проверьте, что учётная запись не заблокирована и пароль не истёкЕсли сервер в домене и ошибка говорит об аутентификации, проверьте доступность контроллера домена и доверительный канал: в повышенном PowerShell на сервере
Test-ComputerSecureChannel -Verbose(не для контроллеров домена). При результатеFalseне сбрасывайте пароль компьютера самостоятельно — согласуйте восстановление канала с администратором AD. Также проверьте журнал «Просмотр событий → Журналы Windows → Безопасность» для конкретной неудачной попытки. - Только для диагностики временно отключите NLAВременно отключать требование NLA допустимо только администратору в изолированной доверенной сети и при наличии доступа к консоли для возврата настройки. Сначала запишите исходное значение
UserAuthenticationдляRDP-Tcpи действующие групповые политики; предпочтительнее исправить CredSSP, доменную аутентификацию и обновления клиента. Если проводился временный тест, после него восстановите прежнее требование NLA и убедитесь, что защищённый вход работает. - Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
После исправления проверьте подключение с клиента командой mstsc /v:192.0.2.10 и убедитесь, что NLA включён обратно. Учётные данные в запросе указывайте в формате ДОМЕН\пользователь.
#Политики CredSSP и шифрования
После обновлений безопасности на клиенте и сервере политика «Исправление Oracle для шифрования» может различаться, тогда клиент выдаёт «функция не поддерживается». Решение — обновить обе стороны, а не снижать защиту. Временная диагностика: в групповой политике «Конфигурация компьютера → Административные шаблоны → Система → Передача учётных данных → Исправление Oracle для шифрования» значение «Оставить уязвимость» допустимо только для краткой проверки.
Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" -MaxEvents 10 | Select TimeCreated, Id, MessageGet-WinEvent -LogName Security -MaxEvents 5 -FilterXPath "*[System[EventID=4625]]" | Select TimeCreated, MessageСобытие 4625 показывает причину отказа входа: неверный пароль, блокировка, время суток, ограничение рабочих станций. Эти данные точнее подскажут, что исправлять.