После установки обновления KB4103718 на моем компьютере с Windows 7 я не могу удаленно подключится к серверу c Windows Server 2012 R2 через удаленный рабочий стол RDP. После того, как я указываю адрес RDP сервера в окне клиента mstsc.exe и нажимаю «Подключить», появляется ошибка:
Подключение к удаленному рабочему столу
Произошла ошибка проверки подлинности.
Указанная функция не поддерживается.
Удаленный компьютер: computername
После того, как я удалил обновление KB4103718 и перезагрузил компьютер, RDP подключение стало работать нормально. Если я правильно понимаю, это только временное обходное решение, в следующем месяце приедет новый кумулятивный пакет обновлений и ошибка вернется? Можете что-нибудь посоветовать?
Ответ
Вы абсолютно правы в том, что бессмысленно решать проблему удалением обновлений Windows, ведь вы тем самым подвергаете свой компьютер риску эксплуатации различных уязвимостей, которые закрывают патчи в данном обновлении.
В своей проблеме вы не одиноки. Данная ошибка может появится в любой операционной системе Windows или Windows Server (не только Windows 7). У пользователей английской версии Windows 10 при попытке подключится к RDP/RDS серверу аналогичная ошибка выглядит так:
An authentication error has occurred.
The function requested is not supported.
Remote computer: computername
Ошибка RDP “An authentication error has occurred” может появляться и при попытке запуска RemoteApp приложений.
Почему это происходит? Дело в том, что на вашем компьютере установлены актуальные обновления безопасности (выпущенные после мая 2018 года), в которых исправляется серьёзная уязвимость в протоколе CredSSP (Credential Security Support Provider), использующегося для аутентификации на RDP серверах (CVE-2018-0886) (рекомендую познакомится со статьей Ошибка RDP подключения: CredSSP encryption oracle remediation). При этом на стороне RDP / RDS сервера, к которому вы подключаетесь со своего компьютера, эти обновления не установлены и при этом для RDP доступа включен протокол NLA (Network Level Authentication / Проверку подлинности на уровне сети). Протокол NLA использует механизмы CredSSP для пре-аутентификация пользователей через TLS/SSL или Kerberos. Ваш компьютер из-за новых настроек безопасности, которые выставило установленное у вас обновление, просто блокирует подключение к удаленному компьютеру, который использует уязвимую версию CredSSP.
Что можно сделать для исправления эту ошибки и подключиться к вашему RDP серверу?
- Самый правильный способ решения проблемы – установка последних кумулятивных обновлений безопасности Windows на компьютере / сервере, к которому вы подключаетесь по RDP;
- Временный способ 1. Можно отключить проверку подлинности на уровне сети (NLA) на стороне RDP сервера (описано ниже);
- Временный способ 2. Вы можете на стороне клиента разрешить подключение к RDP серверам с небезопасной версией CredSSP, как описано в статье по ссылке выше. Для этого нужно изменить ключ реестра AllowEncryptionOracle (команда
REG ADD
HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
) или изменить настройки локальной политики Encryption Oracle Remediation / Исправление уязвимости шифрующего оракула), установив ее значение = Vulnerable / Оставить уязвимость).Это единственный способ доступа к удаленному серверу по RDP, если у вас отсусвует возможность локального входа на сервер (через консоль ILO, виртуальной машины, облачный интерфейс и т.д.). В этом режиме вы сможете подключиться к удаленному серверу и установить обновления безопасности, таким образом перейдете к рекомендуемому 1 способу. После обновления сервера не забудьте отключить политику или вернуть значение ключа AllowEncryptionOracle = 0 :
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 0
Отключение NLA для протокола RDP в Windows
Если на стороне RDP сервера, которому вы подключаетесь, включен NLA, это означает что для преаутентификации RDP пользователя используется CredSPP. Отключить Network Level Authentication можно в свойствах системы на вкладке Удаленный доступ (Remote), сняв галку «Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети / Allow connection only from computers running Remote Desktop with Network Level Authentication (recommended)» (Windows 10 / Windows 8).
В Windows 7 эта опция называется по-другому. На вкладке Удаленный доступ нужно выбрать опцию «Разрешить подключения от компьютеров с любой версией удаленного рабочего стола (опасный) / Allow connections from computers running any version of Remote Desktop (less secure)».
Также можно отключить проверку подлинности на уровне сети (NLA) с помощью редактора локальной групповой политики — gpedit.msc (в Windows 10 Home редактор политик gpedit.msc можно запустить так) или с помощью консоли управления доменными политиками – GPMC.msc. Для этого перейдите в разделе Конфигурация компьютера –> Административные шаблоны –> Компоненты Windows –> Службы удаленных рабочих столов – Узел сеансов удаленных рабочих столов –> Безопасность (Computer Configuration –> Administrative Templates –> Windows Components –> Remote Desktop Services – Remote Desktop Session Host –> Security), отключите политику Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (Require user authentication for remote connections by using Network Level Authentication).
Также нужно в политике «Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP» (Require use of specific security layer for remote (RDP) connections) выбрать уровень безопасности (Security Layer) — RDP.
Для применения новых настроек RDP нужно обновить политики (gpupdate /force) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.
Сентябрь 9, 2019 By Каран
При работе в системах, контролируемых доменом, при попытке удаленного доступа к компьютерам пользователи сообщали о следующей ошибке:
«Удаленный компьютер, к которому вы пытаетесь подключиться, требует проверки подлинности на уровне сети (NLA), но невозможно связаться с вашим контроллером домена Windows для выполнения NLA. Если вы являетесь администратором на удаленном компьютере, вы можете отключить NLA, используя параметры на удаленной вкладке диалогового окна «Свойства системы».
Причина
Суть ошибки предполагает, что невозможно связаться с контроллером домена, поэтому проверка подлинности на уровне сети невозможна. Об ошибке сообщается даже при включенной проверке подлинности на уровне сети.
Наша стратегия решения этой проблемы заключается в том, чтобы полностью отключить аутентификацию на уровне сети. Хотя NLA обеспечивает дополнительную безопасность, здесь у нас, возможно, нет выбора.
Решение 1]— Удалить файл Default.rdp.
1. Перейдите в Мои документы и, если найдете файл с именем Default.rdp, просто удалите его. Попробуйте еще раз.
Если не поможет, удалите машину из домена и снова добавьте. Теперь проверьте, сохраняется ли проблема.
Решение 2]Отключить NLA с помощью свойств
1]Нажмите Win + R, чтобы открыть окно «Выполнить», и введите команду sysdm.cpl. Нажмите Enter, чтобы открыть окно «Свойства системы».
2]На вкладке «Удаленный» снимите флажок «Разрешить подключения только с компьютеров, на которых запущен удаленный рабочий стол с проверкой подлинности на уровне сети (рекомендуется)».
3]Нажмите «Применить», а затем «ОК», чтобы сохранить настройки.
Решение 3]Отключить NLA с помощью реестра
Если вышеуказанный метод не работает, мы можем отключить NLA из самого реестра.
1]Нажмите Win + R, чтобы открыть окно «Выполнить», и введите команду regedit. Нажмите Enter, чтобы открыть редактор реестра.
2]Выберите «Файл», а затем нажмите «Подключить сетевой реестр».
Подключитесь к сетевому устройству, введя данные. Подождите, пока сеть не подключится.
3]Перейдите по следующему пути:
- HKLM
- СИСТЕМА
- ТекущийКонтрольСет
- Контроль
- Терминальный сервер
- ВинСтейшнс
- RDP-TCP
4]Измените значения записей SecurityLayer и UserAuthentication на 0.
5]Закройте редактор реестра.
6]Перезагрузите систему.
Решение 4]Отключить NLA с помощью Powershell
1]Нажмите Win + R, чтобы открыть окно «Выполнить», и введите команду PowerShell. Нажмите Enter, чтобы открыть окно Powershell.
2]Скопируйте и вставьте следующую команду в Powershell:
$TargetMachine = “Target-Machine-Name”
Нажмите Enter, а затем введите команду ниже.
(Get-WmiObject -class Win32_TSGeneralSetting -Namespace rootcimv2terminalservices -ComputerName $ComputerName -Filter "TerminalName="RDP-tcp"").SetUserAuthenticationRequired(0)
3]Нажмите Enter, чтобы выполнить команду и перезагрузить систему после ее завершения.
Надеюсь, поможет!
Содержание
- Исправлено: Удаленный компьютер требует проверки подлинности на уровне сети —
- Решение 1. Отключение NLA с помощью свойств
- Решение 2. Отключение NLA с использованием реестра
- Решение 3. Отключение с помощью PowerShell
- Решение 4. Использование редактора групповой политики
- Произошла ошибка проверки подлинности. Указанная функция не поддерживается
- Ответ
- Отключение NLA для протокола RDP в Windows
- Как сделать работу с Microsoft Remote Desktop лучше
- Апгрейд RPC-HTTP до HTTP
- Windows XP или Vista
- Апгрейд HTTP до HTTP+UDP
- О проблемах
- Как мониторить шлюз с RDGW
- Windows XP не подключается по RDP к Windows 10 / Server 2012 R2/ 2016 RDS
- Невозможно подключиться по RDP с Windows XP к Windows Server 2016/2012R2 и Windows 10
- Отключаем NLA на сервере RDS Windows Server 2016/2012 R2
- Включаем NLA на уровне клиента Windows XP
- Ошибка CredSSP encryption oracle remediation
Исправлено: Удаленный компьютер требует проверки подлинности на уровне сети —
Пользователи сообщают об ошибке, указанной ниже, в системах, подключенных к домену, при попытке удаленного доступа к компьютерным системам. Это происходит, даже если на компьютере включена проверка подлинности на уровне сети (или NLA). Существуют простые обходные пути для решения этой проблемы. Либо вы можете отключить эту опцию напрямую, используя свойства, либо вы можете внести некоторые изменения в реестр и попытаться перезагрузить систему.
Или это также может произойти:
Замечания: Прежде чем следовать этим решениям, важно сделать резервную копию ваших данных и заранее сделать копию реестра. Перед продолжением убедитесь, что на обоих компьютерах нет текущих задач.
Решение 1. Отключение NLA с помощью свойств
Аутентификация на уровне сети — это хорошо. Он обеспечивает дополнительную безопасность и помогает вам, как сетевому администратору, который может войти в какую систему, просто установив один флажок. Если вы выберете это, убедитесь, что ваш RDP-клиент был обновлен, а целевой объект аутентифицирован. Вы также должны увидеть контроллер домена.
Мы пройдемся по маршруту настройки удаленного рабочего стола и вначале все упростим. Если это не работает, мы также рассмотрели другие решения после этого.
Решение 2. Отключение NLA с использованием реестра
Этот метод также работает, если вы не можете выполнить первый по какой-либо причине. Однако учтите, что для этого потребуется полностью перезагрузить компьютер, что может привести к простоям, если у вас работает рабочий сервер. Убедитесь, что вы сохранили всю свою работу и зафиксировали, если что-то еще осталось в промежуточной среде.
HKLM> SYSTEM> CurrentControlSet> Control> Терминальный сервер> WinStations> RDP-Tcp
Решение 3. Отключение с помощью PowerShell
Один из моих любимых способов отключить NLA, не вдаваясь в подробности, — отключить его с помощью команды PowerShell удаленно. PowerShell позволяет подключиться к удаленному компьютеру, и после нацеливания на компьютер мы можем выполнить команды, чтобы отключить NLA.
Здесь «Target-Machine-Name» — это имя машины, на которую вы нацелены.
В приведенном выше примере имя сервера «member-server».
Решение 4. Использование редактора групповой политики
Еще один способ отключить NLA — использовать редактор групповой политики. Это полезно, если вы отключили все. Обратите внимание, что редактор групповой политики является мощным инструментом, и изменение значений, о которых вы даже не подозреваете, может сделать ваш компьютер бесполезным. Убедитесь, что вы сделали резервную копию всех значений, прежде чем продолжить.
Конфигурация компьютера> Административные шаблоны> Компоненты Windows> Службы удаленных рабочих столов> Узел сеансов удаленных рабочих столов> Безопасность
Замечания: Если даже после всех этих шагов вы не можете подключиться, вы можете попробовать удалить компьютер из вашего домена и затем прочитать его. Это приведет к повторной инициализации всех конфигураций и предоставит их вам.
Источник
Произошла ошибка проверки подлинности. Указанная функция не поддерживается
После установки обновления KB4103718 на моем компьютере с Windows 7 я не могу удаленно подключится к серверу c Windows Server 2012 R2 через удаленный рабочий стол RDP. После того, как я указываю адрес RDP сервера в окне клиента mstsc.exe и нажимаю «Подключить», появляется ошибка:
Произошла ошибка проверки подлинности.
Указанная функция не поддерживается.
Удаленный компьютер: computername
После того, как я удалил обновление KB4103718 и перезагрузил компьютер, RDP подключение стало работать нормально. Если я правильно понимаю, это только временное обходное решение, в следующем месяце приедет новый кумулятивный пакет обновлений и ошибка вернется? Можете что-нибудь посоветовать?
Ответ
Вы абсолютно правы в том, что бессмысленно решать проблему удалением обновлений Windows, ведь вы тем самым подвергаете свой компьютер риску эксплуатации различных уязвимостей, которые закрывают патчи в данном обновлении.
В своей проблеме вы не одиноки. Данная ошибка может появится в любой операционной системе Windows или Windows Server (не только Windows 7). У пользователей английской версии Windows 10 при попытке подключится к RDP/RDS серверу аналогичная ошибка выглядит так:
The function requested is not supported.
Remote computer: computername
Ошибка RDP “An authentication error has occurred” может появляться и при попытке запуска RemoteApp приложений.
Почему это происходит? Дело в том, что на вашем компьютере установлены актуальные обновления безопасности (выпущенные после мая 2018 года), в которых исправляется серьёзная уязвимость в протоколе CredSSP (Credential Security Support Provider), использующегося для аутентификации на RDP серверах (CVE-2018-0886) (рекомендую познакомится со статьей Ошибка RDP подключения: CredSSP encryption oracle remediation). При этом на стороне RDP / RDS сервера, к которому вы подключаетесь со своего компьютера, эти обновления не установлены и при этом для RDP доступа включен протокол NLA (Network Level Authentication / Проверку подлинности на уровне сети). Протокол NLA использует механизмы CredSSP для пре-аутентификация пользователей через TLS/SSL или Kerberos. Ваш компьютер из-за новых настроек безопасности, которые выставило установленное у вас обновление, просто блокирует подключение к удаленному компьютеру, который использует уязвимую версию CredSSP.
Что можно сделать для исправления эту ошибки и подключиться к вашему RDP серверу?
Отключение NLA для протокола RDP в Windows
Если на стороне RDP сервера, которому вы подключаетесь, включен NLA, это означает что для преаутентификации RDP пользователя используется CredSPP. Отключить Network Level Authentication можно в свойствах системы на вкладке Удаленный доступ (Remote), сняв галку «Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети / Allow connection only from computers running Remote Desktop with Network Level Authentication (recommended)» (Windows 10 / Windows 8).
В Windows 7 эта опция называется по-другому. На вкладке Удаленный доступ нужно выбрать опцию «Разрешить подключения от компьютеров с любой версией удаленного рабочего стола (опасный) / Allow connections from computers running any version of Remote Desktop (less secure)».
Также можно отключить проверку подлинности на уровне сети (NLA) с помощью редактора локальной групповой политики — gpedit.msc (в Windows 10 Home редактор политик gpedit.msc можно запустить так) или с помощью консоли управления доменными политиками – GPMC.msc. Для этого перейдите в разделе Конфигурация компьютера –> Административные шаблоны –> Компоненты Windows –> Службы удаленных рабочих столов – Узел сеансов удаленных рабочих столов –> Безопасность (Computer Configuration –> Administrative Templates –> Windows Components –> Remote Desktop Services – Remote Desktop Session Host –> Security), отключите политику Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (Require user authentication for remote connections by using Network Level Authentication).
Также нужно в политике «Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP» (Require use of specific security layer for remote (RDP) connections) выбрать уровень безопасности (Security Layer) — RDP.
Для применения новых настроек RDP нужно обновить политики (gpupdate /force) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.
Источник
Как сделать работу с Microsoft Remote Desktop лучше
Хочу поделиться несколькими советами по настройке удаленного подключения к рабочим местам по RDP. Расскажу как проапгрейдить древний RPC-HTTP до UDP, похвалю и поругаю Windows 10 и AVC, разберу решение нескольких типичных проблем.
Считаем, что для подключения используется Remote Desktop Gateway (RDGW), а в качестве серверов выступают рабочие станции. Использовать RDGW очень удобно, потому что шлюз становится общей точкой входа для всех клиентов. Это дает возможность лучше контролировать доступ, вести учет подключений и их продолжительность. Даже если VPN позволяет подключиться к рабочим машинам напрямую — это не лучший вариант.
RDGW настраивается быстро, просто, а Let’s Encrypt и win-acme легко решают проблему с доверенным сертификатом.
Есть три транспортных протокола по которым клиент может подключиться с серверу:
RPC-HTTP ( плохо )
HTTP ( лучше )
HTTP+UDP ( отлично )
Под сервером будем понимать рабочую машину, под клиентом — домашнюю.
Первое, с чего стоит начать, это «плохо» превратить в «отлично».
Апгрейд RPC-HTTP до HTTP
Подключение в сессию с использованием RPC-HTTP легко определить по внешнему виду полоски подключения.
Здесь нет значка качества подключения (о нем ниже), а значит мы используем старый RPC, обернутый в TLS — это очень медленно. Дело, конечно, не только в обертке — сам протокол меняется с каждым релизом ОС, меняются кодеки, алгоритмы упаковки изображения. Чем свежее протокол, тем лучше.
Windows XP или Vista
В XP можно поднять протокол с 5.1 до 7. Хотфикс windowsxp-kb969084-x86.exe
Но RDP 7 не работает по HTTP и UDP. Поможет только апгрейд клиента и сервера до Windows 7 и новее.
Сначала надо обновить протокол до RDP 8.1, а затем включить его. Поддержка добавляется обновлениями, которые сгруппированы в один загрузочный пакет:
www.microsoft.com/en-US/download/details.aspx?id=40986
Windows6.1-KB2574819-v2-x64.msu
windows6.1-kb2592687-x64.msu
Windows6.1-KB2830477-x64.msu
Windows6.1-KB2857650-x64.msu Windows6.1-KB2913751-x64.msu (заменен kb2923545)
Так вы получите и свежий клиент mstsc.exe, и поддержку RDP 8.1 серверной части ОС.
Было:
После этого протокол надо включить ключом реестра (для этого можно использовать adm шаблон в комплекте с Windows 7).
Включите поддержку транспорта UDP в групповой политике.
Перезагружаем сервер с Windows 7. Тот самый случай, когда может потребоваться перезагрузиться дважды — значение в реестре должно быть установлено до того, как включился RDP, а групповая политика применяется позже.
Если все получилось, то при подключении к серверу в полоске сессии появится иконка качества подключения (как в телефоне для мобильной сети):
Протокол работает «из коробки».
Апгрейд HTTP до HTTP+UDP
Если ваша сеть не склонна к потере пакетов, UDP существенно (для CAD — радикально) повышает отзывчивость сервера за счет использования FEC для сокращения ретрансмиссии, а также перехода подтверждения доставки пакетов с уровня системного стека TCP/IP на уровень протокола RDP-UDP.
От каждого клиента подключается одна основная управляющая сессия по HTTP (в этом канале также передается клавиатура/мышь), плюс одна или несколько сессий UDP для передачи картинки или других виртуальных каналов.
Мы коснемся только верхушки айсберга. Есть 3 различных версии протокола RDP-UDP. Кроме того, сам UDP может работать в двух режимах UDP-R (reliable) и UDP-L (lossy). С Microsoft ничего просто не бывает. Но поскольку от нас здесь ничего не зависит, просто имейте в виду — чем новее операционная система, теме более современный протокол используется.
Снаружи RDP-UDP оборачивается в Datagram Transport Layer Security (DTLS) RFC4347, в чем вы можете убедиться открыв Wireshark.
Что же нужно для включения UDP?
RDP-UDP поддерживается начиная с RDP 8.
На клиенте должен быть открыт порт udp/3389. Если вы его закрыли локальным firewall, ACL на свитче или внешнем файрволле — порт надо открыть.
Для сервера Remote Desktop Gateway к порту tcp/443 надо открыть udp/3391.
Порт можно поменять, вот как он настраивается:
Для Windows 7 обязательно должен быть включен NLA (Network Level Authentication).
Можно включить в групповой политике
В чем связь непонятно. Но без NLA на 7-ке не работает, на более свежих релизах NLA для работы UDP не обязателен.
После установления сессии по HTTP, клиент и сервер пробуют согласовать подключение по UDP. Если есть выпадение пакетов или задержки, то сессия UDP не запустится. Точный алгоритм отказа согласования UDP до конца не понятен.
Если все настроено, то после подключения нажмите на кнопку качества связи. В окошке будет указано, что согласован UDP.
На шлюзе это выглядит так:
Если у вас Windows 10 и на сервере, и на клиенте, то это самый быстрый и беспроблемный вариант. В Microsoft активно дорабатывают RDP, и в свежих релизах 10 вы можете рассчитывать на неплохую скорость работы. Коллеги не смогли обнаружить разницу между Citrix и Windows 10 RDP по скорости работы в AutoCAD.
Согласование AVC с аппаратным кодированием можно увидеть в журнале событий (подробнее в статье выше):
Замечу только, что проблема искажений все же есть даже с h.264 4:4:4. Она сразу бросается в глаза если работать в PowerShell ISE — текст ошибок выводится с неприятным искажением. Причем на скриншоте и на фотографии все отлично. Волшебство.
Также косвенным признаком работы AVC являются время от времени появляющиеся зеленые квадраты по углам.
AVC и аппаратное кодирование в свежих билдах должно работать из коробки, но групповая политика никогда не бывает лишней:
С учетом того, что AVC кодируется аппаратно видеокартой, то обновить драйверы видео — хорошая идея.
О проблемах
Если проблема возникает на Windows XP или Vista, попробуйте сначала обновить протокол до 7 версии (писал в начале статьи). Обязательно включите поддержку CredSSP. На сайте Microsoft статьи уже удалены, но Интернет помнит.
Если не помогло — «доктор говорит в морг, значит в морг». Что испытала на себе операционная система за последние 15 лет — лучше об этом даже и не думать.
Иногда помогает отключение NLA на сервере. Выяснить причину не получилось, домашние машины все разные.
Некоторые клиенты пытаются авторизоваться с использованием NTLMv1. Причины разные, но исправить на клиенте можно так:
Если вы молоды и дерзки ничего не боитесь, то есть более радикальное решение — отключение Channel Binding на Remote Desktop Gateway
Делать так не надо. Но мы делали. 🙂 Для клиента, который настаивал (нет не так, НАСТАИВАЛ) что NTLMv1 на рабочих станциях ему необходим. Не знаю, может там серверы на NT4 без SP еще в работе.
Отключение RDP 8+ в Windows 10
Если ничего не помогает, а идеи кончились, можно воспользоваться недокументированным ключом для даунгрейда протокола RDP до 7 версии.
Сам не делал, и вам не советую. Но кому-то, пишут, что помогает.
Компонент Dr.Web SpIDerGate может запретить подключение. В этом случае возвращается ошибка:
В статистике Dr.Web будет запись:
В комментариях к этой статье со мной связался сотрудник Dr.Web и наша проблема решилась в ближайшем обновлении антивирусных баз.
Если у вас такая же ошибка, лучше обратиться в поддержку.
Как временное решение, можно внести URL вашего RDGW в исключения:
И только если не помогло отключить компонент SpIDer Gate полностью.
Встретился списанный компьютер из какой-то компании, где в качестве системного прокси был прописан местный TMG, и подключение к RDGW не работало. Это можно исправить так:
Переключение раскладок клавиатуры
Иногда приезжают лишние раскладки. Можно отключить проброс раскладки с клиента
Масштабирование приходит с клиентской машины, и если на домашнем ноутбуке стоит 125%, то и на рабочей машине будет так же. На серверах это можно отключить, а на рабочих станциях не нашел как. Но в магазине приложений Windows 10 есть «современный» клиент.
В нем можно настроить DPI:
Как мониторить шлюз с RDGW
Есть счетчик производительности «Шлюз служб терминаловТекущие подключения», который немного глючит, если нет подключений или сервер долго не перезагружался. Он показывает именно число подключений, но как мы помним, для HTTP+UDP их как минимум два, а может быть и больше. Поэтому это не совсем объективный показатель числа подключений сотрудников.
Есть класс WMI Win32_TSGatewayConnection. Его содержимое соответствует тому, что вы видите в разделе «Наблюдение» шлюза удаленных рабочих столов.
С ним число подключений можно посчитать поточнее:
Just for fun есть утилита Remote Display Analyzer. Бесплатная версия мне ничего полезного не показала, но вдруг кому-то пригодится.
А как же тонкий тюнинг, настройка нескольких десятков параметров сессии?
Здесь уместен принцип Парето: 20% усилий дают 80% результата. Если вы готовы инвестировать ваше время в оставшиеся 20% результата — отлично. Только имейте в виду, что когда вы читаете статью о настройке протокола в Windows 7, то не знаете про какой протокол писал автор — 7, 8 или 8.1. Когда читаете про Windows 10 без указания релиза — проблемы те же. Например, пишут что в свежих билдах Windows 10 кодек AVC/h.264 изменился на RDPGFX_CODECID_AVC444V2, а в Windows Server 2016 остался RDPGFX_CODECID_AVC444.
Из всех таких советов мы используем только две настройки:
Вот мы и подошли к концу статьи. Хотел покороче, а получилось как всегда. Рад, если кому-то эти советы помогут сэкономить время или улучшить настройку своей инфраструктуры.
Источник
Windows XP не подключается по RDP к Windows 10 / Server 2012 R2/ 2016 RDS
Не смотря на то, что поддержка Windows XP прекращена уже 4 года назад (Windows XP End Of Support) – многие внешние и внутренние заказчики продолжают используют эту ОС, и похоже, кардинально эту проблему решить в ближайшее время не удастся 🙁 … На днях обнаружили проблему: клиенты с ОС Windows XP не могут подключиться через удаленный рабочий стол к новой терминальной Remote Desktop Services ферме на Windows Server 2012 R2. Аналогичная проблема появляется при попытке подключиться по RDP с Windows XP на Windows 10 1803.
Невозможно подключиться по RDP с Windows XP к Windows Server 2016/2012R2 и Windows 10
Пользователи XP жаловались на такие ошибки rdp клиента:
Чтобы решить данную проблему, проверьте что на компьютерах с Windows XP обновлена версия клиента RDP. На текущий момент максимальная версия RDP клиента, которую можно установить на Windows XP — rdp клиент версии 7.0 (KB969084 — https://blogs.msdn.microsoft.com/scstr/2012/03/16/download-remote-desktop-client-rdc-7-0-or-7-1-download-remote-desktop-protocol-rdp-7-0-or-7-1/). Установить данное обновление можно только на Windows XP SP3. Установка RDP клиента версии 8.0 и выше на Windows на XP не поддерживается. После установки данного обновления у половины клиентов проблема с RDP подключением решилась. Осталась вторая половина….
Отключаем NLA на сервере RDS Windows Server 2016/2012 R2
Начав более подробно изучать тему RDS сервера на базе Windows 2012 R2 мы обнаружили, что в ОС Windows Server 2012 (и выше) по умолчанию требует от своих клиентов обязательной поддержки технологии NLA (Network-Level Authentication — проверки подлинности на уровне сети, подробнее об этой технологии здесь), если же клиент не поддерживает NLA, подключиться к RDS серверу ему не удастся. Аналогично NLA включен по-умолчанию при включении RDP в Windows 10.
Из вышесказанного есть два вывода, чтобы оставшиеся XP-клиенты смогли подключаться по RDP к терминальному серверу на Windows Server 2016/2012 R2 или к Windows 10 нужно:
Чтобы на сервере RDS Windows Server 2012 R2 отключить требование обязательного использования протокола NLA клиентами, нужно в консоли Server Manager перейти в раздел Remote Desktop Services -> Collections -> QuickSessionCollection, выбрать Tasks -> Edit Properties, выбрать раздел Security и снять опцию: Allow connections only from computers running Remote Desktop with Network Level Authentication.
В Windows 10 можно отключить Network-Level Authentication в свойствах системы (Система – Настройка удаленного доступа). Снимите галку «Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети (рекомендуется)».
Естественно, нужно понимать, что отключение NLA на уровне сервера уменьшает защищенность системы и в общем случае использовать не рекомендуется. Предпочтительнее использовать вторую методику.
Включаем NLA на уровне клиента Windows XP
Без поддержки CredSSP и NLA при RDP подключении с Windows XP к новым версия Windows будет появлятся ошибка
Поддержка NLA появилась в Windows XP, начиная с SP3, но по-умолчанию она не включена. Включить поддержку аутентификации NLA и CredSSP-провайдера можно только реестр. Для этого:
После выполнения всех манипуляций, компьютер с Windows XP SP3 должен без проблем подключится по rdp к терминальной ферме на Windows Server 2016 / 2012 R2 или к Windows 10. Однако вы не сможете сохранить пароль для RDP подключения на клиенте Windows XP (пароль придется вводить при каждом подключении).
В 2018 года в протоколе CredSSP была обнаружена серьезная уязвимость (бюллетень CVE-2018-0886), которая была исправлена в обновлениях безопасности Microsoft. В мае 2018 года MSFT выпустила дополнительное обновление, которое запрещает клиентам подключаться к RDP компьютерам и сервера с уязвимой версией CredSSP (см статью: https://winitpro.ru/index.php/2018/05/11/rdp-auth-oshibka-credssp-encryption-oracle-remediation/). При подключении к удаленным компьютерам по RDP появляется ошибка Произошла ошибка проверки подлинности. Указанная функция не поддерживается.
В связи с тем, что Microsoft не выпускает обновления безопасности обновлений безопасности для Windows XP и Windows Server 2003, вы не сможете подключится к поддерживаемым версиям Windows из этих ОС.
Источник
Sometimes Windows won’t let you connect to a remote computer, citing an issue with NLA. Fortunately, it’s an easy fix.
Windows’ remote access technology is quite incredible. It allows you to easily troubleshoot issues, download files, or configure settings on your remote PC.
However, it’s frustrating when you encounter issues while trying to connect to a remote PC. Just when you’re about to get connected, you see an error message that reads, “The remote computer requires Network Level Authentication (NLA).”
Lucky for you, we’ve got all the solutions to this issue. So, let’s dive in and fix your remote connection problems.
1. Check Your Internet Connection
In most cases, «The remote computer that you are trying to connect to requires NLA» error might stem from your PC (and not the remote machine). So, resolving it will involve configuring a few settings on your device.
To get started, ensure that there aren’t any issues with your internet connection. Here are some quick fixes that could help:
- Check all your network cables and ensure there are no loose connections.
- Ensure your internet connection is active and stable. Start by testing your Wi-Fi speed with a speed test tool. If the internet speed is okay, consider resetting your router and refreshing your connection.
2. Restore the Network Settings to their Default
You’re likely to bump into «The remote computer requires NLA» error based on how you’ve configured your network settings. So, you could resolve the problem by restoring your network settings to their default.
Now, here’s how to restore the network settings via the Command Prompt:
- Press Win + R to open the Run command dialog box.
- Type CMD and press Ctrl + Shift + Enter to open an elevated Command Prompt.
- Type the following command and press Enter:
netsh int ip set DNS
From there, type the following command and press Enter:
netsh winsock reset
3. Disable and Re-Enable NLA Settings Via System Settings
Disabling and re-enabling the NLA settings on your device could help. Let’s take a look at how you can do this:
- Press Win + R to open the Run command dialog box.
- Type sysdm.cpl and press Enter to open the System Properties window.
- Navigate to the Remote tab.
- Uncheck the Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended) box.
- Press Apply and then press OK. From there, restart your PC to save these changes.
Next, re-enable the NLA settings through these steps:
- Open the System Properties window as per the previous steps.
- Check the Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended) box.
- Click Apply, click OK, and then restart your PC to apply these changes.
4. Disable and Re-Enable NLA Settings Via PowerShell
If the system settings didn’t resolve the issue, then PowerShell could help. So, we’ll explore how you can disable and re-enable the NLA settings with this tool.
To disable the NLA settings, follow these steps:
- Press Win + R to open the Run command dialog box.
- Type PowerShell and press Ctrl + Shift + Enter to open an elevated PowerShell window.
- Next, type the following command:
$TargetMachine = “Target-Machine-Name”(Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace rootcimv2terminalservices -ComputerName $TargetMachine -Filter “TerminalName=’RDP-tcp'”).SetUserAuthenticationRequired(0)
Replace the “Target-Machine-Name” command with the name of your device. From there, press Enter to run the command.
Finally, wait for the process to complete and then restart your device.
Now, re-enable the NLA settings through these steps:
- Open PowerShell as per the previous steps.
- Enter the same command but replace SetUserAuthenticationRequired(0) with SetUserAuthenticationRequired(1).
- Press Enter to run the command and then restart your PC when the process is complete.
5. Configure NLA Settings Via the Local Group Policy Editor
Are you still struggling to resolve «The remote computer requires NLA» error? Let’s now disable and re-enable the NLA settings using the Local Group Policy Editor:
To disable the NLA settings, follow these steps:
- Press Win + R to open the Run command dialog box.
- Type gpedit.msc and press Enter to open the Local Group Policy Editor.
- Navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.
- Double-click the Require user authentication for remote connections by using Network Level Authentication option on the right.
In the next window, check the Not Configured or Disabled box. Next, press Apply, press OK, and then restart your PC.
Finally, follow these steps to re-enable the NLA settings:
- Open the Local Group Policy Editor and navigate to the Security option as per the previous steps.
- Double-click the Require user authentication for remote connections by using Network Level Authentication option.
- In the next window, check the Enabled box, press Apply and then press OK. Finally, restart your PC to apply these changes.
6. Update or Reinstall the Network Drivers
This issue might be caused by corrupted or incompatible network drivers. So, you can either update or reinstall these drivers to get rid of this error.
Firstly, update your network drivers by following these steps:
- Press Win + X and select Device Manager from the options.
- Double-click the Network adapters option to expand it.
- Right-click your PC’s network adapter and click Update driver.
Next, select Search automatically for updated driver software. From there, follow the on-screen instructions to complete the process.
If the issue persists, try reinstalling the network adapters through these steps:
- Open the Device Manager and expand the Network adapters option as per the previous steps.
- Right-click your PC’s network adapter and select Uninstall device.
- Navigate to the Action tab and select Scan for hardware changes. Finally, restart your PC to apply these changes.
7. Use Windows’ Built-In Troubleshooters
Windows’ built-in troubleshooters can help resolve this issue. In this case, we’ll tackle the problem by running the Internet Connections troubleshooter, the Network Adapters troubleshooter, and the Incoming Connections troubleshooter.
Let’s start with the Internet Connections troubleshooter:
- Navigate to Win Start Menu > PC Settings > Update & Security and select Troubleshoot on the left-hand side pane.
- Click the Internet Connections troubleshooter on the right-hand side pane and press Run the troubleshooter.
From there, you can use the Network Adapters troubleshooter. This will find and fix problems with the network adapters on your device.
To run this tool, follow these steps:
- Open the Troubleshoot settings window as per the previous steps.
- Click the Network Adapters troubleshooter on the right-hand side and press the Run the troubleshooter button.
Finally, run the Incoming Connections troubleshooter. This will find and fix incoming computer connection problems.
Here’s how you can run this tool:
- Open the Troubleshoot settings window as per the previous steps.
- Click the Incoming Connections troubleshooter on the right and press the Run the troubleshooter button.
Restart your PC to apply all these changes.
Easily Connect to Your Remote Device Using Windows’ Remote Access Technology
“The Remote Computer Requires Network Level Authentication (NLA)” error is quite frustrating. The worst part is that it usually comes in many forms.
For example, the error might read, «the remote computer requires network level authentication which your computer does not support.» Sometimes it reads, «the remote computer that you are trying to connect to requires network level authentication.»
Regardless of how this error appears on your device, you can fix it using the methods we’ve covered. And if the problem persists, try applying these fixes on the remote device too.
Обновлено 28.11.2022
Добрый день! Уважаемые читатели и гости компьютерного блога pyatilistnik.org. В последнее время я очень часто пишу, об ошибках которые встречаю в работе подключения к терминальному серверу или фермам RDS. Технология отличная, но как водится у Microsoft, имеет ряд сложностей. Сегодня я хочу с вами поделиться, каким образом решается ошибка при попытке пользователем подключиться к удаленному серверу для повседневной работы и звучит она вот так «Не удается установить подключение, так как проверка подлинности не включена, а удаленный компьютер требует, чтобы проверка подлинности для подключения была включена«. Ниже будет описан метод моего решения.
Как выглядит ошибка подключения
Есть терминальная ферма, на которой мы в прошлый раз помогли пользователю решить проблему с временным профилем, сегодня у него при попытке установить удаленное подключение выскакивает ошибка, что сервер доступен, но у тебя есть проблемы с проверкой подлинности при подключении. Данное сообщение выскакивало, сразу после ввода логина и пароля при авторизации.
Клиентский компьютер работает на операционной системе Windows 10 1709, терминальная ферма собрана из Windows Server 2012 R2, выступающих в роли хостов для подключения, в качестве посредников подключения (Connection Broker) выступают два сетевых балансировщика Kemp LoadMaster. И все как обычно, вчера работало, сегодня нет.
Варианты устранения проблемы с подключением по RDP
При ошибке
Не удается установить подключение, так как проверка подлинности не включена, а удаленный компьютер требует, чтобы проверка подлинности для подключения была включена
можно сделать вывод, что порт 3389 отвечает и его не нужно проверять с помощью Telnet. Далее алгоритм такой:
- Первое, что нужно сделать, это проверить DNS записи, которые отвечают за резолвинг имени фермы, сделать это можно с помощью команды nslookup. Открываем командную строку или power shell и вводим там команду:
nslookup имя вашего терминального сервера
Как видим имя ts4.pyatilistnik.org разрезолвилось в два ip адреса, и применив команду ping мы видим, что сервер отвечает и его TTL 64, что говорит, что в роли Connection Broker выступает, что-то на операционной системе Linux. Проверьте по записям, правильно ли разрешается имя, в нужные ли ip адреса.
- Если с записями все хорошо, то нужно посмотреть логи системы на посредниках к подключению, это как раз те сервера, которые отвечают по команде nslookup, хочу отметить, что Connection Broker может и не быть, и DNS может перекидывать на членов фермы, по технологии Round robin, простым перебором, где могут быть проблемы либо с отдельной нодой, либо со всеми, об этом мы поговорим ниже. Очень часто, достаточно перезагрузить посредника, удобно если их два в HA.
Как я и писал выше в моем случае в роли посредником по подключению выступают две сетевые железки Kemp LoadMaster. Заходим в веб интерфейс, переходим в пункт «View/Modify Services». В данном пункте будут описаны правила, которые обрабатывает Kemp LoadMaster. Вижу, что у меня есть правило TS4. В столбце Real Servers я вижу на какие сервера оно применяется. Тут логика какая, создается виртуальный интерфейс отвечающий по нужному порту, в данном случае 3389, и идет форвардин на список Real Servers по разным критериям, коих у Kemp много.
Проверяем список Real Servers на соответствие актуальности. В моем случае выяснилось, что один из ip адресов был передан другому серверу, так как его предшественника вывели из эксплуатации, а так как на нем не было развернуто служб удаленных рабочих столов, то у меня и валилась ошибка «Не удается установить подключение, так как проверка подлинности не включена, а удаленный компьютер требует, чтобы проверка подлинности для подключения была включена».
Редактируем правило, через кнопку Modify. Находим в списке IP Address нужный вам сервер и выключаем/Удаляем его соответствующей кнопкой.
Посмотреть список шаблонов на Kemp LoadMaster можно на вкладке Manage Template, они подгружаются сюда отдельно с официального сайта
https://support.kemptechnologies.com/hc/en-us/articles/210136133-Templates
После этих манипуляций ошибка ушла.
- Если у вас нет Kemp LoadMaster или нет вообще Connection Broker, то попробуйте подключиться не по DNS имени фермы, а отдельно по RDP на конечный хост (Session Host). Проверьте, что у него стоят правильные настройки проверки подлинности.
Для этого зайдите в свойства системы, на вкладке «Удаленный доступ» проверьте наличие галки:
NLA: Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети
Такая галка, запрещает старым клиентам служб удаленных рабочих столов производить подключение, актуально для Windows XP или не обновленных Windows 7, если у вас есть такие клиенты, то либо их обновите, либо снимите галку.
Так же в такой ситуации, когда был конфликт в версиях RDP клиента и вам отвечает не Session Host являющийся членом фермы, а как в моем случае левый сервер, то выскакивала ошибка: Подключение было разорвано, поскольку был получен непредусмотренный сертификат проверки подлинности сервера от удаленного компьютера. Повторите попытку подключения. Если проблема сохранится, обратитесь к владельцу удаленного компьютера или сетевому администратору
PS. Советую сделать на каждом сервере, что входит в состав терминальной фермы команду RSOP в командной строке, чтобы понять какие групповые политики прилетают и посмотрите, что у вас там
Как отключить NLA (Network Level Authentication)
Если у вас еще много не обновленных клиентов со старыми версиями RDP, то можете отключить пока NLA: Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети. Либо вручную, как я показывал, выше, но правильнее это сделать централизованно.
- На Connection Brokers
- Через групповую политику (Конфигурация компьютераПолитикиАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовБезопасность. Политика «Требовать проверку подлинности на уровне сети для удаленных подключений»)
- Через реестр Windows и политику
- Понизить требование к шифрованию.
На посреднике к подключению, зайдите в свойства коллекции и на вкладке безопасности снимите соответствующую галку.
Если захотите воспользоваться реестром Windows, а потом раскидать ключик, через тужу политику. то вам нужна ветка HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp. В ней найдите ключ SecurityLayer и поставьте ему значение 0. Это отключит NLA (Network Level Authentication).
Обновление 28.11.2022
Еще данная ошибка может возникать из-за самоподписного сертификата, который нужно добавить либо в доверенные центры сертификации, или же подменить на доверенный. Это я выяснил при ошибке 0x907, там я так же мог попасть на свою RDS ферму.
Уверен, что вы смогли устранить ошибки: Подключение было разорвано, поскольку был получен непредусмотренный сертификат проверки подлинности сервера от удаленного компьютера. Повторите попытку подключения. Если проблема сохранится, обратитесь к владельцу удаленного компьютера или сетевому администратору и «Не удается установить подключение».
Если вам известны еще какие-либо методы решения, то просьба написать о них в комментариях.