Ошибка подключения к rdp серверу

Обновлено 08.12.2022

Добрый день! Уважаемые читатели и гости, IT блога Pyatilistnik.org. В прошлый раз мы с вами поговорили, про отложенный запуск служб в Windows, сегодня я хочу вам показать еще один не приятный момент в работе терминальных служб удаленного рабочего стола, а именно ошибка подключения «Произошла внутренняя ошибка«, после чего подключение разрывается. Такое я встречал уже в Windows Server 2012 R2 и 2016. Давайте разбираться в чем дело.

Описание проблемы

Есть сервер с операционной системой Windows Server 2012 R2, сотрудник пытается к нему подключиться, через классическую утилиту «Подключение к удаленному рабочему столу», в момент авторизации, выскакивает окно с ошибкой «Произошла внутренняя ошибка».

В английском варианте ошибка звучит вот так:

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

🆘 Что есть в логах?

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

• 1️⃣ Первым будет идти событие ID 131 «The server accepted a new TCP connection from client IP-адрес:60050.». Тут вы увидите IP-адрес с которого идет попытка входа.

• 2️⃣ Далее событие ID 65 «Connection RDP-Tcp#11 created «.

• 3️⃣ Затем событие 141 «PerfCounter session started with instance ID 11». Тут сессии будет назначен ID.

• 4️⃣ За ним будет идти ID 142 «TCP socket READ operation failed, error 1236».

• 5️⃣ Потом вы увидите ID 72 «Interface method called: OnDisconnected»

• 6️⃣ И же после этого вам покажут, что сервер разорвал подключение: «ID 102 The server has terminated main RDP connection with the client.»

• 7️⃣ В событии ID 145 так же появляются подробности «During this connection, server has not sent data or graphics update for 0 seconds (Idle1: 0, Idle2: 0).».

• 8️⃣ Могут быть события с ID 148 «Channel rdpinpt has been closed between the server and the client on transport tunnel: 0.» или «Channel rdpcmd has been closed between the server and the client on transport tunnel: 0.» или «Channel rdplic has been closed between the server and the client on transport tunnel: 0.»
• 9️⃣ Ну и вишенка на торте, ошибка  ID 227 «‘Failed to get property Disconnect Reason’ in CUMRDPConnection::Close at 2212 err=[0x80070057]»

Исправляем ошибку «Произошла внутренняя ошибка»

Так как по RDP подключиться не получается, то первым делом нужно проверить отвечает ли порт, по умолчанию это 3389. О том, как проверить порт на удаленном сервере я вам описывал, там все сводилось к выполнению команды Telnet, ознакомьтесь. Если порт отвечает, то делаем следующее.

Нужно удаленно перезапустить службу на этом сервере, чтобы сам сервер не перезагружать, так как в этот момент, он может выполнять важные задачи, можно использовать утилиту «Управление компьютером». Открыть ее можно через команду вызова оснастки, вызываем окно «Выполнить», через одновременное нажатие клавиш WIN и R, в котором пишем:

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

Выберите пункт «Другим компьютером» и укажите его DNS имя, или найдите его через кнопку обзор.

Когда вы подключитесь к нужному серверу, перейдите в пункт «Службы и приложения — Службы», в списке сервисов найдите службу удаленных рабочих столов (Remote Desktop Services), и перезапускаем ее. После этого ошибка подключения по RDP «Произошла внутренняя ошибка», у вас должна пропасть.

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

Дополнительные методы решения

Если вам не помог первый метод, перезапускающий службу удаленных рабочих столов, то можно попробовать выполнить правку реестра. Открываете редактор реестра Windows, если у вас физического доступа к серверу нет или он далеко и вам лень до него идти, то можно попробовать подключиться к реестру удаленного сервера.

Для этого в окне «Редактор реестра» пункт меню «Файл — Подключить сетевой реестр».

В открывшемся окне «Выбор компьютера» указываем его DNS-имя или ip-адрес и нажимаем ок. У вас будет установлено подключение к удаленному реестру сервера, что испытывает проблемы.

Находим ключ CheckMode по пути

Выставляем ему значение о, чтобы отключить у программы КриптоПРО CSP проверку контрольных сумм. Еще один важный момент, если у вас старая версия КриптоПРО, то это так же может быть источником, проблем, недавний пример, это ошибка «Windows installer service could not be accessed». Для этого удаляем правильно КриптоПРО CSP и ставим последнюю доступную версию.

Еще можно попробовать изменить значение вот такого ключа реестра:

Найдите ключ SessionImageSize и задайте ему значение 0x00000020.

Дополнительные настройки RDP клиента

Например ошибка «An internal error has occurred» у меня встретилась на Windows Server 2022 и там мне помогло в настройках клиента RDP отключение некой опции. Перейдите в дополнительные настройки клиента для удаленного подключения, где н вкладке «Experiens (Взаимодействие)» вам нужно убрать галку с опции «Восстановить подключение при разрыве (Reconnect if the connection is droped)«

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

Удаление кэша подключений

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

Обновление 07.12.2022

В декабре я вновь столкнулся с внутренней ошибкой, она еще стала проявлять себя вот так:

В логах сервера очень много ошибок:

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

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

Код 2808 — Ваш сеанс служб удаленных рабочих столов завершен. Соединение с удаленным компьютером было потеряно, возможно, из-за проблем с сетевым подключением. Попробуйте снова подключиться к удаленному компьютеру. Если проблема не исчезнет, ​​обратитесь к сетевому администратору или в службу технической поддержки.

Так как у меня это была виртуальная машина, то я смог легко подключиться через консоль. В случае с ошибкой «Отключение RDP ClientActiveX (Причина= 2308)«, я отключил на сервере и клиенте autotuninglevel:

Не забываем перезагрузиться.

Это не помогло, далее я выполнил еще несколько рекомендаций. Я установил на сервер валидный SSL сертификат для RDP сессии. В ошибке 0x907, RDP соединение разрывалось, так как клиентская система не доверяла самоподписному сертификату удаленного сервера. Это нужно поправить, ссылку я указал, обязательно проверьте, кто сейчас выступает в роли активного:

Еще я создал параметр реестра MaxOutstandingConnections. В Windows по умолчанию есть ограничения на количество сетевых подключений, так например в серверной версии, это параметр равен 3000, в десктопной 100. Из-за нестабильной сети, они могут быстро забиваться. Одно из решений проблемы с внутренней ошибкой подключения, является увеличение этого значения. В командной строке в режиме администратора выполните:

После этого нужно перезагрузиться.

Временное решение

Пока вы не уберете ошибку «Код ошибки, возвращенный модулем шифрования: ошибка 0x8009030D», описанную выше, вы можете понизить уровень безопасности вот такими манипуляциями, это устранит «An internal error has occurred».

На обычном сервере все это помогло, а вот на ноде RDSH ошибка оставалась. Тут я решил проверить догадку с уровнем безопасности «Configure security settings». На моей ферме был уровень «Согласования (Negotiate)«

Я пошел на сервер, где были проблемы подключения и решил проверить один параметр локальной политики gpedit.msc.

Тут попробуйте выставить уровень RDP. В результате у меня после этих настроек все заработало. Теперь нужно понять, что изменилось. В настройках RDS фермы указано, что мы используем уровень согласование:

Если и это вам не помогло, то нужно смотреть вариант в сторону обновления или переустановки драйверов на сетевую карту, тут вы определяете модель вашей карты или материнской платы, если в нее все интегрировано и обновляете. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Дополнительные ссылки

• https://serverfault.com/questions/934026/windows-10-pro-rdp-server-an-internal-error-has-occurred
• https://social.technet.microsoft.com/Forums/en-US/e1d60cc0-0096-4859-a0e7-eb7f11905737/remote-desktop-v10-error-0x4-from-mac?forum=winRDc
• https://learn.microsoft.com/en-us/answers/questions/108219/can-not-rdp-to-2012-r2-standard-server-after-septe.html
• https://serverfault.com/questions/541364/how-to-fix-rdp-on-windows-server-2012

• Главная

• Инструкции

• Windows

• Ошибка при подключении по RDP

RDP – это протокол, предназначенный для удаленного подключения к серверу с ОС Windows. Процесс подключения по RDP довольно прост и был уже детально описан в одной из наших инструкций.

Иногда у пользователя могут возникнуть трудности при очередной попытке входа на удаленный сервер с помощью RDP. Система в момент подключения выдает ошибку и ее краткое описание. Однако для обычного пользователя информации в системном окне ошибки недостаточно, чтобы решить проблему.

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

Ошибка №1. «Произошла внутренняя ошибка»

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

Вот ее пример:

Как видно на картинке, описание ошибки нам ничего не объясняет. Причин у нее может быть множество. Например, она может возникнуть из-за неправильной настройки подключения или настройки безопасности протокола. 

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

Решение №1. Проверка работы порта

Первое, что нужно сделать – это проверить, что прослушиватель протокола RDP настроен на работу по порту 3389 как на сервере, так и на локальной машине. Для этого будем использовать системное приложение «Редактор реестра».

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

1. Нажимаем сочетание кнопок WIN+R и запускаем regedt32, используя поле ввода.
2. Создаем резервную копию. Для этого в окне реестра нажимаем вкладку «Файл», а затем «Экспорт». После выбираем место, где будут храниться файлы реестра. Если после внесенных изменений возникнут какие-либо ошибки, реестр можно будет восстановить («Файл» → «Импорт»).
3. Далее открываем папку «RDP-Tcp». Для этого воспользуемся поиском, как показано на рисунке ниже.

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

1. В найденной папке ищем параметр, который называется «PortNumber». В ситуации, когда его значение не равно 3389, его следует поменять.

1. Теперь нужно повторить предыдущий шаг, только для удаленного сервера.
2. После проверки портов следует выполнить перезапуск служб. Подробнее — в описании решения №2. 
3. Выполняем повторный вход на сервер.

Решение №2. Перезапуск служб удаленных рабочих столов

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

1. Воспользуемся сочетанием кнопок WIN+R и запускаем compmgmt.msc, используя поле ввода.
2. Далее переходим во вкладку «Службы и приложения», а затем открываем «Службы».
3. Находим «Службы удаленных рабочих столов» и кликаем «Перезапустить службу», как показано на картинке ниже.

1. Далее снова выполняем предыдущие 2 шага, но в этот раз для сервера. Чтобы это сделать, нужно для начала нажать правой кнопкой мыши по вкладке «Управление компьютером», а затем нажать «Подключиться к другому компьютеру».
2. После успешного подключения повторяем шаги 2 и 3.
3. Пробуем заново подключиться к серверу.

Решение №3. Проверка статуса протокола на сервере

Чтобы проверить статус работы протокола RDP на сервере, воспользуемся системным приложением «Редактор реестра» из Решения №1. 

1. Нажимаем сочетание кнопок WIN+R и запускаем regedt32, используя поле ввода.
2. Теперь выполняем подключение к сетевому реестру, как показано на картинке ниже.

1. Далее переходим в 2 папки, которые называются Terminal Server и Terminal Services. Для этого воспользуемся поиском (сочетание клавиш CTRL+F). 

Переключаться между найденными папками можно с помощью клавиши F3. Нажимаем ее до тех пор, пока адрес папки не совпадет с адресом на картинке ниже.

То же самое выполняем для папки Terminal Services. Ее адрес при поиске должен совпасть со следующим.

В двух найденных выше папках ищем fDenyTSConnections. Искомый параметр может принимать два значения: либо 0, либо 1. Первое указывает на успешную работу протокола RDP. Второе предполагает, что он отключен.

1. Изменяем значения параметров на 0.
2. Пробуем заново выполнить вход на сервер.

Решение №4. Изменение настроек подключения

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

1. В программе «Подключение к удаленному рабочему столу» открываем дополнительные параметры подключения.
2. Среди всех вкладок выбираем «Взаимодействие» и кликаем на нее.
3. Далее в поле, указанном на картинке ниже, следует установить или убрать галочку, в зависимости от того, в каком состоянии оно находится сейчас.

1. Теперь пробуем заново выполнить подключение.

Решение №5. Очистка кэша подключений

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

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

1. Далее переходим в папку Cache, которая расположена по адресу C:Users%Имя_пользователя%AppDataLocalMicrosoftTerminal Server Client, и удаляем все, что в ней находится.
2. Теперь заходим в системное приложение «Редактор реестра», о котором говорилось ранее, и переходим к вкладке Servers (HKEY_CURRENT_USER → Software → Microsoft → Terminal Server Client). Здесь также удаляем все записи.
3. Перезагружаем компьютер и выполняем повторное подключение к удаленному серверу.

Решение №6. Увеличение лимита на количество подключений

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

Для исправления проблемы следует увеличить размер параметра MaxOutstandingConnections. Чтобы это сделать, достаточно запустить терминал (обязательно в режиме администратора) и выполнить специальную команду:

REG ADD "HKLMSYSTEMCurrentControlSetControlTerminal Server" /v MaxOutstandingConnections /t REG_DWORD /d 65536

Результат выполнения команды продемонстрирован на картинке ниже.

Теперь перезагружаем службы удаленных рабочих столов и пробуем заново выполнить вход на сервер.

Ошибка №2 «CredSSP: ошибка при проверке подлинности»

Ошибка проверки подлинности при подключении по RDP возникает на этапе авторизации.

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

CredSSP – это протокол Windows, который служит для безопасной передачи учетных данных от локальной машину к серверу. Он защищает пользователя от DDoS-атак или несанкционированного доступа к серверу.

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

Ниже подробно опишем решение ошибки CredSSP во время подключения по RDP для Windows версий Home и Professional.

Скачать обновление безопасности после удачного входа пользователя на сервер возможно с официального сайта Microsoft либо в разделе «Центр обновления Windows» в параметрах вашей системы.

Решение №1. Windows Home

Описанное ниже решение ориентировано на пользователей с ОС Windows Home.

1. Для начала открываем на пользовательском компьютере терминал, запущенный от имени администратора.
2. Далее вводим команду в строку терминала:

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

Используемая команда вносит корректировки в реестр Windows, добавляя ключ, отвечающий за изменение политики безопасности CredSSP. Значение 2 устанавливает самый низкий уровень защиты.

1. Перезагружаем устройство.
2. Пробуем заново подключиться к серверу.
3. Далее на сервере следует обязательно установить необходимые обновления безопасности.
4. По завершении обновлений нужно вернуть начальные настройки безопасности, используя команду из шага №2. Только вместо 2 на конце, нужно ввести 0.

Решение №2. Windows Professional

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

1. Для начала открываем системное приложение «Редактор локальной групповой политики». Используем сочетание кнопок WIN+R и открываем gpedit.msc, используя поле ввода.
2. В открывшейся системе переходим в папку «Передача учетных данных» (Конфигурация компьютера → Административные шаблоны → Система → Передача учетных данных).
3. Среди всех параметров выбранной папки ищем «Защита от атак с использованием криптографического оракула». Щелкаем по нему дважды.

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

1. Перезагружаем устройство.
2. Пробуем заново подключиться к серверу.
3. Далее следует сразу перейти к установке всех обновлений безопасности.
4. По завершении обновлений рекомендуется сразу возвратить параметр «Защита от атак с использованием криптографического оракула» в первоначальное состояние.

Заключение

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

А бывает ли у вас такое, что не работает RDP? Ну, то есть, может и работает, на подключиться к виртуалке не получается. Скорее всего, для многих это не будет никакой проблемой, и у каждого прямо с сейчас с ходу найдётся пара советов, куда зайти и что проверить. Но вдруг, кто-то о чём-то всё же не знает. Здесь собрали несколько рецептов решения, начиная с самых банальных. Ну, на всякий случай…

Начнём с того, что иногда люди сами себе отрубают RDP, после чего обращаются в техподдержку, надеясь, что проблема не на стороне клиента. В таких случаях специалисты техподдержки только и могут, что предложить переустановку.

Но помимо этого, сложность может быть заключена немного глубже. Для человека, пытающегося подключиться к своему серверу, это может выглядеть как “бесконечный коннект”, не заканчивающийся ни чем. А может появиться сообщение вида “Произошла внутренняя ошибка”. Во многих подобного рода случаях могут помочь лежащие на поверхности решения.

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

Во-вторых, пользователь мог сам закрыть порт 3389 на сервере, который и используется по умолчанию службой RDP. Правила для входящих подключений по этому порту так и называются – “Удаленный рабочий стол – пользовательский режим”. Ну, вот, всякое же бывает. Допустим, неудачно настроил брандмауэр. Ну, или, скажем, скачал “супер безопасный софт для супер безопасного интернета”.

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

• откройте редактор реестра regedit.exe и перейдите в ветку HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server Client;
• разверните ветку реестра HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientDefault, и чтобы очистить историю последних RDP-соединений, выделите все ключи с именами MRU0-MRU9, щелкните правой клавишей и выберите пункт Delete или Удалить.

Чтобы очистить историю всех RDP-подключений и сохранённых имён пользователей, нужно очистить содержимое ветки реестра Servers. Так как выделять все вложенные ветки не очень удобно, проще всего удалить ветку Servers целиком, а затем пересоздать ее вручную.

Те же операции можно сделать и через Powershell. Для получения информации о правилах брандмауэра приложение должен быть запущен с правами администратора.

Далее, необходимо проверить, запущена ли служба:

Get-Service TermService

Из полученного результата следует убедиться, что поле Status установлено в значение Running:

Также, это можно посмотреть в диспетчере задач на вкладке Services (Службы) или в оснастке services.msc:

Ещё необходимо проверить, слушается ли порт 3389 на стороне сервера. Сделать это можно так же через Powershell:

Get-NetTCPConnection -State Listen | Where-Object LocalPort -EQ 3389

Порт должен быть в выведенном списке. Поле State должно иметь значение Listen.

На виртуальном сервере проверить порт 3389 можно и через монитор ресурсов (resmon.exe). Активность порта видна на вкладке Network (Сеть) в разделе TCP Connections (TCP-подключения):

Туда же можно попасть через Диспетчер задач, перейдя на вкладку Performance (Производительность) и далее на Open Resource Monitor (Открыть монитор ресурсов):

Также, данный функционал доступен через Панель управления → Администрирование → Монитор ресурсов:

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

Итак, для брандмауэра Windows проверьте, существует ли правило, разрешающее входящие подключения RDP:

Get-NetFirewallPortFilter | Where-Object LocalPort -EQ 3389 | Get-NetFirewallRule

Поле Enabled должно иметь значение True, поле Action – значение Allow.

Также, эти данные доступны в оснастке wf.msc:

Перейти к настройкам брандмауэра можно также через Windows Administrative Tools в меню Пуск.

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

Ну, и наконец в крайнем случае, если на сервере нет важных данных, можно переустановить систему или написать в техническую поддержку.

После установки обновлений безопасности Windows, которые вышли после мая 2018 года, вы можете столкнуться с ошибкой CredSSP encryption oracle remediation при RDP подключении к удаленному серверу и компьютеру Windows в следующих случаях:

• Вы подключаетесь к удаленному рабочему столу компьютера с недавно установленной старой (например, RTM) версией Windows (например, Windows 10 ниже билда 1803, Windows Server 2012 R2, Windows Server 2016), на котором не установлены последние обновления безопасности Windows;
• Вы пытаетесь подключиться к RDP компьютеру, на который давно не устанавливали обновления Microsoft;
• RDP подключение блокирует удаленный компьютер, т.к. нет нужных обновлений безопасности на вашем клиентском компьютере.

Попробуем разобраться с тем, что означает RDP ошибка CredSSP encryption oracle remediation и как ее можно исправить.

Итак, при попытке подключения к приложению RemoteApp на RDS серверах под Windows Server 2016 / 2012 R2 / 2008 R2, или к удаленным рабочим столам других пользователей по протоколу RDP (на Windows 10, 8.1 или 7), появляется ошибка:

Remote Desktop connection
An authentication error has occurred.
The function is not supported.
Remote Computer: hostname
This could be due to CredSSP encryption oracle remediation.

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

Дело в том, что еще в марте 2018 Microsoft выпустила обновление, закрывающее возможность удаленного выполнения кода с помощью уязвимости в протоколе CredSSP (Credential Security Support Provider). Подробно проблема описана в бюллетене CVE-2018-0886. В мае 2018 было опубликовано дополнительное обновление, в котором по-умолчанию клиентам Windows запрещается подключаться к удаленным RDP серверам с уязвимой (непропатченной) версией протокола CredSSP.

Таким образом, если вы на RDS/RDP серверах (компьютерах) Windows с марта 2018 года не устанавливались накопительные обновления безопасности, а на RDP клиентах установлены майские обновления (или более новые), то на них при попытке подключится к RDS серверам с непропатченной версией 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 Server 2016 — KB4103723
• Windows 10 1803 — KB4103721
• Windows 10 1709 — KB4103727
• Windows 10 1703 — KB4103731
• Windows 10 1609 — KB4103723

В списке перечислены номера KB от мая 2018 года, на данный момент вам нужно скачивать и устанавливать более новый пакет накопительных обновлений для вашей редакции Windows. Вы можете получить последние обновления безопасности через Windows Update с серверов Microsoft, с локального WSUS сервера, или скачать вручную из каталога обновлений Windows — Microsoft Update Catalog — https://www.catalog.update.microsoft.com/Home.aspx. Например, для поиска обновлений за август 2019 года для Windows 10 1803 нужно использовать поисковый запрос: windows 10 1803 8/*/2019. Скачайте и установите кумулятивное обновление (в моем примере это будет “2019-08 Cumulative Update for Windows 10 Version 1803 for x64-based Systems (KB4512509)”.

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

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

1. Запустите редактор локальных GPO — gpedit.msc;
2. Перейдите в раздел политик Computer Configuration -> Administrative Templates -> System -> Credentials Delegation (Конфигурация компьютера -> Административные шаблоны -> Система -> Передача учетных данных);
   
3. Найдите политику с именем Encryption Oracle Remediation (Исправление уязвимости шифрующего оракула). Включите политику (Enabled/ Включено), а в качестве параметра в выпадающем списке выберите Vulnerable / Оставить уязвимость;
4. Осталось обновить политики на вашем компьютере (команда
   gpupdate /force
   ) и попробовать подключится по RDP к удаленному компьютеру. При включенной политике Encryption Oracle Remediation со значением Vulnerable ваши терминальные приложения с поддержкой CredSSP смогут подключаться даже к RDS/RDP серверам и компьютерам Windows, на которых отсутствуют актуальные обновления безопасности.

Если у вас отсутствует редактор локальных GPO (например, в Home редакциях Windows), вы можете внести изменение, разрешающее RDP подключение к серверам с непропатченной версия CredSSP, напрямую в реестр с помощью команды:
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2

Вы можете изменить этот параметр в реестре сразу на множестве компьютеров в AD с помощью доменной GPO (консоль gpmc.msc) или таким PowerShell скриптом (список компьютеров в домене можно получить с помощью командлета Get-ADComputer из модуля RSAT-AD-PowerShell):

Import-Module ActiveDirectory
$PSs = (Get-ADComputer -Filter *).DNSHostName


Foreach ($computer in $PCs) {
Invoke-Command -ComputerName $computer -ScriptBlock {
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
}
}

После успешного подключения к удаленному RDP серверу (компьютеру) нужно установить на нем актуальные обновления безопасности через службу Windows Update (проверьте, что служба включена) или вручную. Скачайте и установите последние кумулятивные обновления Windows как показано выше. Если при установке MSU обновления появляется ошибка “Это обновление неприменимо к вашему компьютеру”, познакомьтесь со статей по ссылке.

Для Windows XP/ Windows Server 2003, которые сняты с поддержки нужно установить обновления для Windows Embedded POSReady 2009. Например, https://support.microsoft.com/en-us/help/4056564

После установки обновлений и перезагрузки сервера, не забудьте отключить политику на клиентах (либо выставить ее на Force Updated Clients), или вернуть значение 0 для ключа реестра AllowEncryptionOracle. В этом случае, ваш компьютер не будет подвержен риску подключения к незащищенным хостам с CredSSP и эксплуатации уязвимости.

REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 0 /f

Есть еще один сценарий, когда обновления отсутствуют на вашем компьютере. Например, RDP сервер обновлен, но на нем выставлена политика, блокирующая RDP подключения с компьютеров с уязвимой версией CredSSP (Force Updated Clients). В этом случае при RDP подключении вы также увидите ошибку “This could be due to CredSSP encryption oracle remediation”.

Проверьте последнюю дату установки обновлений Windows на вашем компьютере с помощью модуля PSWindowsUpdate или через WMI команду в консоли PowerShell:

gwmi win32_quickfixengineering |sort installedon -desc

В этом примере видно, что последние обновления безопасности Windows устанавливалось 17 июня 2018 года. Скачайте и установите более новый MSU файл с кумулятивным обновлением для вашей редакции Windows (смотрите выше).

Иногда при попытки подключиться к удаленному рабочему столу, пользователи могут столкнуться с ошибкой. Описание ошибки, ясности не дает. “Произошла внутренняя ошибка” что это и как от нее избавиться – постараемся ответить в этой статье.

Причины появления окна “Произошла внутренняя ошибка” могут быть совершенно различным, и могу быть как с сервером Remote Desktop, так и с клиентом.

UPD (01.05.2020): В первую очередь попробуйте перезапустить службу удаленных рабочих столов на сервере. Если это не поможет :

Одним из способов решить данную проблему это очистка историю RDP подключений на клиенте в ветке HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientServers
Так же может помочь сброс кеша RDP в каталоге C:Users%Username%AppDataLocalMicrosoftTerminal Server ClientCache (перед очисткой завершите все запущенные сеансы mstsc.exe).
Для очистки кеша используйте команду:

del "C:Users%Username%AppDataLocalMicrosoftTerminal Server Clientcache"
(не забудьте указать корректный путь)

Одной из возможных причин возникновения данной ошибки, могут быть множественные попытки несанкционированного доступа. Иными словами, если ваш RDP сервер доступен для всего интернета по стандартному порту 3389 – велика вероятность, что вас пытаются взломать. Косвенным признаком, что “Внутренняя ошибка”  происходит именно по причине ломящихся снаружи – в журнале (о том как открыть журнал – в конце статьи) RDP подключений будут ошибки с кодом 1006 “Сервер узлов сеансов удаленных рабочих столов получил большое количество незавершенных подключений. Возможно, система атакована.”

Решений тут несколько:

1. Закрыть доступ к серверу по порту 3389 для неизвестных IP-адресов через firewall
2. Сменить порты 3389 на любой другой

Как изменить RDP Порт

1. Открываем редактор реестра regedit
2. Открываем ветку HKEY_LOCAL_MACHINESystemCurrentControlSetControlTerminalServerWinStationsRDP-Tcp
3. Правим параметр PortNumber в десятичном фрмате
4. Порт RDP по умолчанию 3389
5. Перезагружаем сервер

В интернете можно встретить и другие варианты решений, какие подойдут именно вам – надо проверять.

1. 1. Если у вас на удаленном сервере установлен КриптоПРО, он может быть источником проблем с rdp подключением. Попробуйте отключить проверку контрольных целостности файлов (проверки контрольных сумм) в КриптоПро через реестр. Перейдите в ветку реестра HKLMSYSTEMCurrentControlSetControlSession ManagerCProIntegrity и измените значение параметра CheckMode на 0. Перезагрузите сервер.
   2. Если в журнале событий TerminalServices-RemoteConnectionManager вы встретите событие с EventID 1057 (The RD Session Host Server has failed to create a new self signed certificate to be used for RD Session Host Server authentication on SSL connections), перейдите в каталог C:ProgramDataMicrosoftCryptoRSA, переименуйте папку Machinekeys в Machinekeys_bak и перезапустите службу TermService.
   3. Также нашел информацию, что RDP проблема “Произошла внутренняя ошибка” встречалась в Windows 10 1809, если на удаленном компьютере включена политика Configure H.264/AVC hardware encoding for Remote Desktop connections (находится в секции GPO: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment). Для решения этой проблемы достаточно отключить UDP протокол для RDP, создав в ветке реестра HKLMSOFTWAREPoliciesMicrosoftWindows NTTerminal ServicesClient параметр fClientDisableUDP со значением 1.

Пользователи windows 10 иногда сталкиваются с “Внутренней ошибкой” при подключении к RDP еще и из-за обновлений безопасности. В редких случаях, вместо ошибки “Ошибка RDP подключения CredSSP encryption oracle remediation” – пользователи могут получать “внутренняя ошибка подключения”. Если ни один из приведенных выше способов не помог – попробуйте решения описанные в статье RPD: ошибка подключения CredSSP encryption oracle remediation

Открыть журнала событий RDP

Откройте меню пуск и в строке поиска введите “Просмотр событий” (англ. Event Viewer).
В нем Журналы приложений и служб > Microsoft > Windows > TerminalServices-RemoteConnectionManager