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 нужно:

• отключить проверку NLA на серверах фермы Remote Desktop Services 2012 R2/2016 или в Windows 10;
• или включить поддержку NLA на XP-клиентах;

Чтобы на сервере 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

Для корректной работы Windows XP в качестве клиента необходимо наличие, как минимум, Service Pack 3. Если нет, то обязательно скачайте и установите это обновление. Именно Service Pack 3 является минимальным требованием для обновления клиента RDP с версии 6.1 до 7.0 и поддержки необходимых компонентов, в том числе Credential Security Service Provider (CredSSP -KB969084), о котором чуть ниже.

Без поддержки CredSSP и NLA при RDP подключении с Windows XP к новым версия Windows будет появлятся ошибка

Поддержка NLA появилась в Windows XP, начиная с SP3, но по-умолчанию она не включена. Включить поддержку аутентификации NLA и CredSSP-провайдера можно только реестр. Для этого:

1. В ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders нужно отредактировать значение ключа SecurityProviders, добавив в конце credssp.dll (через запятую от его текущего значения);
2. Далее в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa в значение параметра Security Packages добавьте строку tspkg;
3. После внесения указанных изменений, компьютер нужно перезагрузить.

После выполнения всех манипуляций, компьютер с Windows XP SP3 должен без проблем подключится по rdp к терминальной ферме на Windows Server 2016 / 2012 R2 или к Windows 10. Однако вы не сможете сохранить пароль для RDP подключения на клиенте Windows XP (пароль придется вводить при каждом подключении).

Ошибка CredSSP encryption oracle remediation

В 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 из этих ОС.

Чтобы обеспечить возможность RDP подключения из Windows XP к обновлённым Windows 10/8.1/7 и Windows Server 2016/2012R2/2012/2008 R2, необходимо на стороне RDP сервера включить политику Encryption Oracle Remediation / Исправление уязвимости шифрующего оракула (Computer Configuration -> Administrative Templates -> System -> Credentials Delegation / Конфигурация компьютера -> Административные шаблоны -> Система -> Передача учетных данных) со значением Mitigated, что, как вы понимаете, небезопасно.

Подключение к удаленному рабочему столу невозможно подключиться к Windows Server 2012

Миссия на удаленный рабочий стол INTO Windows Server 2012 (автономный).

Ситуация:

• Панель управления, система, удаленные настройки, удаленный рабочий стол — разрешить
• Все брандмауэры выключены.
• Подключите попытку с использованием известного IP-адреса (ping работает нормально)
• Подключить параметр как пользователь, который уже вошел в систему.

Сообщение об ошибке:

Дополнительная информация:

• Сервер 2012 может использовать RDC OUT.
• Машины, которые я использую для подключения IN, это Windows 7 и Windows 8, они будут RDC для других машин.
• У меня есть опыт работы с удаленным рабочим столом.

Вопрос:

Является ли это ошибкой бета-версии программного обеспечения на сервере 2012 года или существует новый способ заставить RDC работать, которого я не вижу?

11 ответов

После просмотра всех ответов и комментариев, а также траления в Интернете для подобных проблем, я пришел к выводу, что это проблема с повреждением файлов на компьютере под управлением Windows 2012 Server.

Дальнейшие указания
a) Перед этим испытательным компьютером были проблемы с диском.
b) sfc /scannow обнаруживает ошибки.

Я заметил, что когда-то включение удаленного рабочего стола неправильно разрешает исключение брандмауэра для порта 3389. Проверьте, включено ли соответствующее правило. Если это так, попробуйте отключить и сразу включить брандмауэр. Это работало для меня несколько раз.

Вам, возможно, понадобится CAL ( Лицензия на клиентский доступ ), чтобы получить доступ к Ресурсы Windows Server 2012.

Я был в похожей ситуации с вами. У меня была групповая политика для включения RDP. Я проверил, что это применяется, и что я могу выполнить ping на целевом сервере. В менеджере серверов 2012 года он сказал: «Удаленный рабочий стол: включен».

Однако после выполнения шагов, отправленных sushant (cmd> systempropertiesremote) (к которым также могут быть применены другие методы, например sysdm.cpl), я перешел на вкладку «Удаленный» Свойства системы и увидел, что «Не разрешать удаленных подключений к этому компьютеру «. Очевидно, это причина моей проблемы и, как ожидалось, выбор «Разрешить удаленные подключения к этому компьютеру» позволил мне mstsc на сервер.

У меня также был еще один экземпляр, в котором, хотя включен RDC, порт брандмауэра не был открыт. Теперь у меня есть стандарт в любом домене. Я управляю двумя политиками, один для включения RDP, а другой — через брандмауэр.

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

У меня была такая же проблема, но как только я выбрал Keyboard — India , которую я настроил при установке 2012 года, система снова разрешила подключения к удаленному рабочему столу.

, поэтому я столкнулся с проблемой при установке статического IP-адреса в VMware Windows 2012. Когда статический IP был установлен, моя виртуальная машина стала невосприимчивой к RDP или RDC. как я его исправил?

перейти к панели управления> Сеть и Интернет> Сеть и совместное использование

Настройки адаптера изменения верхнего левого угла

щелкните правой кнопкой мыши по сети, для которой требуется статический IP-адрес, и выберите свойства

Выберите интернет-протокол Версия 4 (TCP /IPv4)

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

Введите указанный и предпочтительный DNS

нажмите «ОК» и откройте командную строку и введите: ipconfig /flushDNS

в приведенной выше командной строке не используется Collin, и там есть пробел после ipconfig

после этого сделайте сброс vm и попробуйте rdp вам vm

vm теперь работает на статическом IP

У меня была такая же проблема с клиентом WINDOWS XP, который не смог подключиться к удаленному серверу Windows 2012 R2.

Я решил проблему, сняв флажок на этом флажке на сервере: «Разрешить подключения только для компьютеров, работающих на удаленном компьютере с аутентификацией на уровне сети (рекомендуется)».

Чтобы найти эти параметры в Windows 2012 R2: щелкните правой кнопкой мыши на «Мой компьютер», выберите «Свойства», затем «Удаленные настройки». На экране, который будет всплывать, вы найдете этот флажок.

Вероятно, XP не поддерживает «Аутентификацию уровня сети», и когда серверу требуется это, клиент XP не может подключиться.

1. Переместите указатель мыши в нижнем правом углу экрана, и вы увидите панель, панель «Шарм».
2. Нажмите кнопку «Поиск», с увеличительным стеклом. Смотрите скриншот ниже:
3. Введите CMD в текстовое поле поиска приложений:
4. Нажмите на CMD слева, он запустит командную строку:
5. В окне командной строки введите SystemPropertiesRemote и нажмите Enter
6. Вышеупомянутая команда запустит окна свойств системы.
7. Выберите соответствующий параметр в разделе «Удаленный рабочий стол» и нажмите «ОК».

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

На одном сервере я удалил американскую клавиатуру (которая по умолчанию была настроена во время установки), а затем попыталась включить RDP, и она не сработала.

Как только я снова установил американскую клавиатуру, RDP начал работать!

У меня была такая же проблема с клиентами XP и Windows 8 . казалось, что сервер не был правильно подключен к домену, я перезагрузил сервер, зарегистрировался как администратор домена, а затем, когда я попытался подключиться с помощью RDP, Машина Win 8 работала нормально, XP не вызвана NLA, как указано выше.

Как исправить 8 распространенных проблем подключения к удаленному рабочему столу?

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

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

Ошибка сети удаленного рабочего стола

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

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

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

Проблемы с брандмауэром

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

Инструменты на основе протокола удаленного рабочего стола (RDP) по умолчанию используют порт 3389. Некоторые публичные сети блокируют трафик RDP. Это особенно верно в отношении сетей Wi-Fi.

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

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

Проблемы с сертификатом SSL

Сертификаты безопасности также могут вызвать проблемы с подключением к удаленному рабочему столу. Многие продукты VDI используют шифрование Secure Sockets Layer (SSL) для пользователей, которые получают доступ к сеансам VDI за пределами периметра сети. Но SSL-шифрование требует использования сертификатов, что создает две проблемы, которые могут привести к неработоспособности удаленного рабочего стола.

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

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

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

Проблемы с DNS

Многие проблемы с подключением к удаленному рабочему столу могут быть связаны с проблемами DNS. Если администратор изменил IP-адрес хоста, клиенты не смогут подключиться к хосту, пока не истечет срок действия кэша распознавателя DNS клиента.

Введите следующую команду на клиентском компьютере, чтобы очистить кэш и принудительно разрешить имена DNS: IPConfig / FlushDNS

У клиентов также могут возникнуть проблемы с подключением к хосту, если они используют внешний DNS-сервер, который не может разрешить хосты в частной сети организации. Решением этой проблемы является изменение настроек IP-адреса клиента, чтобы он использовал один из DNS-серверов организации, а не внешний DNS-сервер. В качестве альтернативы вы можете подключиться к удаленной системе, указав ее IP-адрес, а не имя хоста.

Ошибки аутентификации

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

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

Превышение емкости инфраструктуры

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

Отключенные соединения

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

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

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

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

Проблемы CredSSP

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

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

Лучший способ исправить это – убедиться, что на клиенте и на хосте установлены поддерживаемые версии Windows и обе системы полностью обновлены.

Вы можете предотвратить большинство этих проблем с подключением с помощью предварительного планирования, а хорошие навыки устранения неполадок удаленного рабочего стола помогут, когда возникнут другие проблемы. Убедитесь, что ваши SSL-сертификаты обновлены, правильно настроите брандмауэры и следите за возможностями VDI .