Произошла ошибка при проверке подлинности указанная функция не поддерживается удаленный компьютер

NexxDigital — компьютеры и операционные системы

NexxDigital — компьютеры и операционные системы » Безопасность » Rdp windows 7 указанная функция не поддерживается. Исправить когда ошибка произошла проверки подлинности RDP. Отключение NLA для протокола RDP в Windows

Владельцы ОС Виндовс знают, что разработчик определенное время обеспечивает обязательную поддержку своим операционным системам. Чаще всего это заключается в том, что Майкрософт периодически выпускает обновления, которые автоматически или в ручном режиме переносятся на компьютер и там устанавливаются.

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

Например, установка пакета KB4103718, по наблюдениям многих пользователей, приводит к тому, что попытка подсоединиться к серверу за счет удаленного рабочего стола RPR не срабатывает, а только вызывает на экране сообщение: произошла ошибка при проверке подлинности – указанная функция не поддерживается.

Естественно, это не может устраивать человека, который таким образом лишается части нужного и очень важного ему функционала. Как быть? Конечно же – исправлять.

Итак, если произошла ошибка проверки подлинности RDP Windows 7, то наиболее простым решением будет возвращение в Центр обновления операционной системы и снос недавно установленных пакетов. Как показывает практика, этого действия вполне достаточно, чтобы избавиться от сбоя.

Правда, есть несколько «но»:

При следующем автоматическом обновлении все вернется обратно.
Если запретить Винде запускать такой функционал, то операционная система может оказаться крайне уязвимой, так как не сможет получать от разработчиков важнейшие защитные наработки.

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

Выполнить установку всех важнейших, самых свежих обновляющих пакетов не только на своем оборудовании, но и на компьютере, и сервере, к которым пользователь планирует подсоединяться удаленно посредством данного протокола. Это – практически единственно и полноценное разрешение данной проблемы. Все остальные – только временные.
Можно деактивировать NLA или предоставить доступ к удаленному серверу с так называемой небезопасной версией CredSSP.

Как же отказаться от использования NLA? Необходимо выполнить следующие шаги:

Через панель управления перейти во все элементы, затем – в систему.
Открыть окошечко «Свойства» и совершить переход на вкладку «Удаленный доступ».
В самом низу можно увидеть строку, которая начинается со слов «Разрешить подключения только с компьютеров…». Убрать галочку возле нее.

После установки майских обновлений безопасности (от 8 мая 2018 г. на платформы Windows 7/8/10 и серверные платформы на ОС Windows Server 2008 R2 / 2012 R2 / 2016) пользователи не получают доступ к удаленной машине посредством RDP и RemoteApp, и происходит следующая ошибка:

Скриншот: окно ошибки CredSSP после выполнения подключения RDP к серверу с клиентской машины.

В начале весны 2018 года Microsoft выпустила обновление, предотвращающее удалённое выполнение кода с помощью уязвимости в протоколе CredSSP, и в мае было выложено обновление после установки которого по умолчанию клиентским машинам запрещено подключение к удаленным RDP-серверам с уязвимой версией протокола CredSSP. Соответственно если на клиентах весенние обновления установлены, а на серверах с ОС Windows Server — не установлены, то мы получим ошибку при подключении:

«Произошла ошибка при проверке подлинности. Указанная функция не поддерживается. Причиной ошибки может быть исправление CredSSP.»

Или английский вариант:

«This could be due to CredSSP encryption oracle remediation.»

Ошибка клиента RDP появляется после установки обновлений безопасности:

Windows 7 / Windows Server 2008 R2 — обновление KB4103718
Windows 8.1 / Windows Server 2012 R2 — обновление KB4103725
Windows 10 1803 — обновление KB4103721
Windows 10 1709 — обновление KB4103727
Windows 10 1703 — обновление KB4103731
Windows 10 1609 — обновление KB4103723
Windows Server 2016 — обновление KB4103723

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

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

Открываем редактор локальных групповых политик: Пуск — Выполнить — gpedit.msc;
Переходим в раздел Конфигурация компьютера — Административные шаблоны — Система — Передача учетных данных (Computer Configuration — Administrative Templates — System — Credentials Delegation — англ.);
Находим политику с именем Исправление уязвимости шифрующего оракула (Encryption Oracle Remediation- англ.). Включите политику Включено (Enabled — англ.), в качестве параметра в выпадающем списке выберите Оставить уязвимость (Vulnerable — англ.);

Осталось обновить политики на компьютере (для этого открываем Cmd и используем команду gpupdate/force) и попробовать подключится по RDP. При включенной политике клиентские приложения с поддержкой CredSSP смогут подключаться даже к непропатченным Remote Desktop серверам.

Если это домашний компьютер с урезанной версией Windows, и у вас нет доступа к консоли локальных групповых политик — не беда, воспользуемся редактором реестра (Regedit). Запускаем его, и проходим по пути:

и установить значение параметра AllowEncryptionOracle в значение 2 (0х00000002).

Затем, необходимо скачать и установить обновления безопасности, подходящие для вашей системы (публикую прямые ссылки на обновления для Windows Server для вашего удобства, которые очень рекомендую установить):

Windows Server 2016 / Windows 10 1607 — KB4103723
Windows Server 2012 R2 / Windows 8 —

Данная ошибка связана с установкой обновлений CredSSP для CVE-2018–0886 . Проблема решается установкой обновления.

Отключение 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) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.

Правда, есть несколько «но»:

При следующем автоматическом обновлении все вернется обратно.
Если запретить Винде запускать такой функционал, то операционная система может оказаться крайне уязвимой, так как не сможет получать от разработчиков важнейшие защитные наработки.

Выполнить установку всех важнейших, самых свежих обновляющих пакетов не только на своем оборудовании, но и на компьютере, и сервере, к которым пользователь планирует подсоединяться удаленно посредством данного протокола. Это – практически единственно и полноценное разрешение данной проблемы. Все остальные – только временные.
Можно деактивировать NLA или предоставить доступ к удаленному серверу с так называемой небезопасной версией CredSSP.

Как же отказаться от использования NLA? Необходимо выполнить следующие шаги:

Через панель управления перейти во все элементы, затем – в систему.
Открыть окошечко «Свойства» и совершить переход на вкладку «Удаленный доступ».
В самом низу можно увидеть строку, которая начинается со слов «Разрешить подключения только с компьютеров…». Убрать галочку возле нее.

13 марта Microsoft опубликовал описание уязвимости CVE-2018-0886 в протоколе проверки подлинности CredSSP, который в частности используется при подключении по RDP к терминальным серверам. Позже Microsoft опубликовал, что будет блокировать подключения к необновлённым серверам, где присутствует данная уязвимость. В связи с чем многие заказчики столкнулись с проблемами подключения по RDP.

В частности, в Windows 7 можно увидеть ошибку: «Произошла ошибка проверки подлинности. Указанная функция не поддерживается»
В Windows 10 ошибка расписана более подробно, в частности сказано «Причиной ошибки может быть исправление шифрования CredSSP»:

Для обхода ошибки со стороны клиента многие советуют отключить групповую политику, путём установки значения Encryption Oracle Remediation в Vulnerable :
с помощью gpedit.msc в Конфигурация компьютера / Административные шаблоны / Система / Передача учётных данных, слева выбрать «Исправление уязвимости шифрующего оракула» (забавный конечно перевод), в настройках поставить «Включено» и выбрать «Оставить уязвимость».

или через реестр (т.к., например, в Windows Home нет команды gpedit.msc):

REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2

НО! Так делать не нужно! Т.к. таким образом вы оставляете уязвимость и риски перехвата вашего трафика и пр. конфиденциальные данные, включая пароли. Единственный случай, когда это может быть необходимо, это когда у вас вообще нет другой возможности подключиться к удалённому серверу, кроме как по RDP, чтобы установить обновления (хотя у любого облачного провайдера должна быть возможность подключения к консоли сервера). Сразу после установки обновлений, политики нужно вернуть в исходное состояние.

Если доступ к удалённому серверу есть, то ещё, как временная мера, можно отключить требование NLA (Network Level Authentication), и сервер перестанет использовать CredSSP. Для этого достаточно в Свойствах системы, на вкладке удалённые подключения снять соответствующую галку «Разрешить подключения только с компьютеров, на которых работает удалённый рабочий стол с проверкой подлинности на уровне сети»:

Но, это тоже неправильный подход.

Правильный подход — это всего-лишь установить нужные обновления на операционную систему, закрывающие уязвимость CVE-2018-0886 в CredSSP, причём, как серверную, куда вы подключаетесь, так и клиентскую, с которой вы подключаетесь.

Список обновлений для всех операционных систем, начиная с Windows 7 и Windows Server 2008 доступен по ссылке: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886
Выбираете нужную версию операционной системы, скачиваете соответствующее обновление из каталога, устанавливаете и перезагружаетесь. После этого ошибка должна пропасть.
Например, на Windows Server 2016 ссылка на скачивание будет такой:

После очередного обновления операционной системы Windows, которое было примерно 8 мая 2018 года, почти все пользователи столкнулись с проблемой подключения к удаленному рабочему столу (RDP и remoteapp).

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

Удаленный компьютер:
Причиной ошибки может быть исправление шифрования CredSSP.
Дополнительные сведения см. в статье https://go.microsoft.com/fwlink/?linkid=866660

Существует два способа исправления ошибки шифрования CredSSP. Первый способ самый правильный, второй — быстрый.

произошла ошибка проверки подлинности rdp windows 7

MS RDS

Задача: Установить и настроить на одиноком (standalone) удаленном сервере (не входящим ни в какие домены и рабочие группы и не имеющем ни одного компьютера в сетевом окружении):

Microsoft Windows 2012
Microsoft Exchange 2013
Microsoft Remote Desktop Services и настроить на работу с определенным количеством пользователей.

Симптом и трудность: Установка Exchange 2013 требует наличия установленного Active Directory, в то же время RDS как полный набор служб и компонентов не ставится на контроллер домена.

Установить Windows Server 2012 в стандартном объеме

Установить Active Directory и сопутствующие службы (DNS), завести пользователей.

Установить и настроить MS Exchange 2013 в стандартном объеме, протестировать его работоспособность

Установить несколько компонентов RDS:

Remote Desktop Licensing (Лицензирование удаленных рабочих столов)
Remote Desktop Session Host (Узел сеансов удаленных рабочих столов)
Remote Desktop Web Access (Веб-доступ к удаленным рабочим столам) (https:///rdweb)

консоль RD Licensing Manager (Диспетчер лицензирования Удаленных рабочих столов) – Активация сервера (следуем указаниям мастера).
Расскажем серверу, где ему найти сервер лицензий с помощью групповой политики

Start->Run->gpedit.msc (ЛИБО Default Domain Policy)Computer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostLicensing — Use the specified Remote Desktop license servers (добавляем имя нашего сервера)Computer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostLicensing — Set the Remote licensing mode (выбираем тип лицензий)

Пуск->Выполнить->gpedit.mscКонфигурация компьютераАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовЛицензирование — Использовать указанные серверы лицензирования удаленных рабочих столов (добавляем имя нашего сервера)Конфигурация компьютераАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовЛицензирование — Задать режим лицензирования удаленных рабочих столов(выбираем тип лицензий)

Можно также воспользоваться методом: http://social.technet.microsoft.com/wiki/ru-ru/contents/articles/16879.windows-server-2012.aspx

Создаем группу в AD (используем стандартную группу “Пользователи удаленного рабочего стола”), куда поместим всех пользователей, которые будут иметь доступ к удаленному рабочему столу.

В локальной политике:Пуск->Выполнить->gpedit.mscКонфигурация компьютераПараметры БезопасностиЛокальные политикиНазначение прав пользователяРазрешить вход в систему через службу удаленных рабочих столов — добавить ту самую созданную на предыдущем шаге группу. (по умолчанию группа «Пользователи удаленного рабочего стола» уже присутствует в списке, но когда сервер провозглашается контроллером домена, она удаляется из этого списка)

И последний нюанс, настройка профиля пользователя: “Требовать смены пароля при следующем входе в систему” по умолчанию при попытке входа пользователя на сервер удаленных рабочих столов порождает ошибку “Произошла ошибка проверки подлинности. Не удается установить связь с локальным администратором безопасности.”Решаем через отключение NLA в групповой политике:

Пуск->Выполнить->gpedit.mscКонфигурация компьютераАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовБезопасностьТребовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети — Отключить.

Для сервера, который не входит в состав домена, данный способ развертывания RDS тоже подойдет. Причем, в этом случае у нас остается возможность в случае надобности установить на нем AD и сделать его контроллером домена.

Обновление на стороне сервера

Этот путь рекомендован Майкрософт. Стоит перейти на сайт разработчиков по ссылке , пролистать страницу до раздела «Affected Products», в самой первой колонке таблицы находим свою редакцию Windows, а в столбике «Download» кликаем по URL для скачивания пакета апдейтов CredSSP cve-2018-0886.

Полезный контент:

Ошибка CredSSP, исправляем за минуту

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз мы с вами чинили HDD с поврежденной файловой системой и состоянием RAW уверен, что вам удалось это сделать. Сегодня я в очередной раз переведу наш вектор траблшутера в сторону терминальных столов, а именно мы рассмотрим ситуацию, что когда вы пытаетесь подключиться к удаленному серверу по RDP протоколу, а у вас после ввода логина и пароля, выскакивает ошибка, что вы не прошли проверку подлинности и причиной ошибки может быть исправление шифрования CredSSP. Давайте разбираться, что за зверь, этот CredSSP и как вам получить доступ к вашему серверу.

Перед тем, как я покажу вам известные мне методы ее устранения, я бы как обычно хотел подробно описать ситуацию. Вчера при попытке подключиться к своему рабочему компьютеру, работающему на Windows 10 1709, с терминального стола, входящего в RDS ферму на Windows Server 2012 R2, я получил ошибку после ввода логина и пароля:

Ну и конечно в русском исполнении:

Получается двоякая ситуация, что RDP как бы работает, но вот по какой-то причине ваши учетные данные на принимающей стороне не соответствуют, каким-то критериям, давайте разбираться, что это за зверь CredSSP.

Хостинг уровня /b или даже ниже⁠ ⁠

Этот пост касается облачных серверов и их поставщиков, а точнее поставщика. Даже если вы не программист или разработчик, уверяю, вы сможете знатно пригореть от манеры работы тех. поддержки сервиса https://cp.vpsdedic.ru (:

Итак, после ухода Oracle из России, я решил поискать сервера в Европе по доступным ценам и мне попался сервис vpsdedic, который предлагал сервера по доступным ценам, а именно 289р в месяц за скромный конфиг, которого-бы мне в принципе для учёбы и экспериментов вполне бы хватило.

Хостинг уровня /b или даже ниже Программирование, Учеба, Программист, IT, Урок, IT юмор, Облачный сервис, Хамство, Сервер, VPS, Длиннопост

Как видно на скрине, они обещают сервер в Нидерландах или Франции за 289 рублей, что как раз уложилось в мой бюджет 🙂

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

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

Пишу, что знатно посмеялся с ситуации, получаю ещё более не понятный ответ от ТП.

Думаю, круто! За 300р сервер в 4 раза мощнее, это просто праздник какой-то!

Но тут оказывается, что сервер то в России, хотя я, напомню, заказывал Нидерланды или Францию!
Ответ как вы понимаете опять убил 🙂

Итого, данный хостинг обладает низкими ценами, а ещё низкой социальной ответственностью, вы заказываете, что хотите по прайсу, а получаете то что получится! Крайне не советую!