Подключение не удается установить поскольку удаленный компьютер с которым установлена связь
При этой ошибке можно подключиться по IP и из внутренней сети это получается, даже перенаправление работает, т.е. по IP попадаю на другой сервер.
Но идея была в том, чтобы не изменяя настройки клиентов "подсунуть" им настроенную ферму терминальных серверов. Т.е. с тем же внешним и внутренним именами (совпадают).
Подключение не удается установить, поскольку удаленный компьютер, с которым установлена связь, отличается от указанного пользователем. Это может быть связано с тем, что запись в кэше DNS устарела. Попробуйте использовать IP-адрес вместо имени компьютера.
Как отключить NLA (Network Level Authentication)
Если у вас еще много не обновленных клиентов со старыми версиями RDP, то можете отключить пока NLA: Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети. Либо вручную, как я показывал, выше, но правильнее это сделать централизованно.
- На Connection Brokers
- Через групповую политику (Конфигурация компьютера\Политики\Административные шаблоны\Компоненты Windows\Службы удаленных рабочих столов\Узел сеансов удаленных рабочих столов\Безопасность. Политика "Требовать проверку подлинности на уровне сети для удаленных подключений")
- Через реестр Windows и политику .
На посреднике к подключению, зайдите в свойства коллекции и на вкладке безопасности снимите соответствующую галку.
Если захотите воспользоваться реестром Windows, а потом раскидать ключик, через тужу политику. то вам нужна ветка HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. В ней найдите ключ SecurityLayer и поставьте ему значение 0. Это отключит NLA (Network Level Authentication).
Уверен, что вы смогли устранить ошибки: Подключение было разорвано, поскольку был получен непредусмотренный сертификат проверки подлинности сервера от удаленного компьютера. Повторите попытку подключения. Если проблема сохранится, обратитесь к владельцу удаленного компьютера или сетевому администратору и "Не удается установить подключение".
Если вам известны еще какие-либо методы решения, то просьба написать о них в комментариях.
Здравствуйте. Пытаюсь поднять RDS, столкнулся с проблемой.
Все необходимые роли службы удаленных рабочих столов заведены на одном сервере. Доменное имя сервера внутри сети server.mydomen.com совпадает с "внешним" доменным именем. Настроил веб-доступ к удаленным рабочим столам, личные рабочие столы для пользователей и тд.
Если подключаться из локальной сети с помощью веб доступа к "мой рабочий стол" - заходит без проблем. В опубликованные приложения и "удаленный рабочий стол" говорит ошибку:
«Подключение не удается установить, поскольку удаленный компьютер, с которым установлена связь, отличается от указанного пользователем. Это может быть связано с тем, что запись в кэше DNS устарела. Попробуйте использовать IP-адрес вместо имени компьютера.»
Если так же заходить снаружи, не из домена, ошибка следующая:
Удаленному рабочему столу не удалось подключиться к удаленному компьютеру "server.mydomen.com" по одной из этих причин:
1) Данной учетной записи пользователя не предоставлены права на доступ к шлюзу удаленных рабочих столов "server.mydomen.com"
2) Данный компьютер не авторизован для доступа к шлюзу удаленых рабочих столов "server.mydomen.com"
3) Используется несовместимый метод проверки подлинности (например, шлюз удаленных рабочих столов ожидает смарт-карту, а предоставлен пароль)
Как выглядит ошибка подключения
Клиентский компьютер работает на операционной системе Windows 10 1709, терминальная ферма собрана из Windows Server 2012 R2, выступающих в роли хостов для подключения, в качестве посредников подключения (Connection Broker) выступают два сетевых балансировщика Kemp LoadMaster. И все как обычно, вчера работало, сегодня нет.
Понижение требования к уровню шифрования
Не самое правильное решение, так как уменьшает уровень защиты и шифрования трафика, но может быть палочкой-выручалочкой в некоторых ситуациях. В настройках сервера терминалов снизить уровень "безопасности/уровень шифрования". Для этого заходите в "Пуск > Администрирование > Удаленный рабочий стол > Конфигурация узла сеансов удаленного рабочего стола", выбираете "Настройка для сервер", далее вкладка "Общие" и два пункта:
- Уровень безопасности > Уровень безопасности RDP
- Уровень шифрования > Низкий
Все теперь повторите подключение и повторите попытку зайти по RDP, ошибка должна исчезнуть, но поищите возможность все же обновиться.
Удаления обновления KB2992611
Следующим методом я вам посоветую установка новых обновлений, которые это решают, могу посоветовать KB3018238 (оно идет теперь вместе с KB2992611) и KB3011780, с ходом времени, данные обновления могут перекрываться уже более новыми, так, что следите за ними на официальном сайте Microsoft. Если KB2992611 установлено, то попробуйте его удалить, проверить возможность подключения и снова поставить.
Скачиваете и производите обновление, это похоже на шаги описанные в проблеме, где windows 7 не находит обновления, мы так же устанавливали автономные версии.
Решаем ошибку с устаревшей записью в кэше DNS
Сама ошибка выглядит вот таким образом. Доступ к серверу не удается получить.
В английском варианте это звучит вот так: The connection cannot be completed because the remote computer that was reached is not the one you specified. This could be caused by an outdated entry in the DNS cache. Try using the IP address of the computer instead of the name.
- Первое, что необходимо выполнить это команды ping и nslookup. Вы должны удостовериться, что ip адрес отвечает и dns имя правильно в него разрешается, я встречал ситуации, когда в DNS была создана Cname запись ведущая совершенно на другую запись, в результате чего получал данную ошибку.
- В моем случае проблема была в том, что часовой пояс на сервере, куда я пытался зайти по RDP отличался на 1 час от времени от Domain Controller. Как только поменял на нужный то все стало ок. Убедитесь, что у вас корректно настроен NTP сервер.
- Если был изменен Ip адрес, то у вас возможно старый локальный кэш, который необходимо почистить.
Причины ошибки "Повторите попытку подключения"
В прошлый раз мы с вами победили ошибку с синим экраном dpc watchdog violation, победим и эту, но для начала нужно понять причину всего этого действия. Вот как выглядит данная проблема:
Как я и писал выше, появляется она после ввода корректного логина и пароля.
- Вся эта канитель началась еще с 2014 года, после обновлений KB2992611 и последующих. В момент установки данных обновлений ужесточился уровень безопасности и шифрования.
- Вторая возможная причина, это наличие программ КриптоПро или VipNet, у меня был именно второй вариант
- Другие сторонние программные обеспечения по шифрованию.
Если вы посмотрите логи Windows, то сможете обнаружить вот такие системные предупреждения:
- возникло следующее неустранимое предупреждение: 36888. Внутренне состояние ошибки: 1250
- Компонент X.224 RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента.
Все ответы
Перерегистрация записи в DNS не помогает? Если пинговать сервер по имени, отклик приходит с нужного IP?
Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
При этой ошибке можно подключиться по IP и из внутренней сети это получается, даже перенаправление работает, т.е. по IP попадаю на другой сервер.
Но идея была в том, чтобы не изменяя настройки клиентов "подсунуть" им настроенную ферму терминальных серверов. Т.е. с тем же внешним и внутренним именами (совпадают).
Подключение не удается установить, поскольку удаленный компьютер, с которым установлена связь, отличается от указанного пользователем. Это может быть связано с тем, что запись в кэше DNS устарела. Попробуйте использовать IP-адрес вместо имени компьютера.
В итоге была создана ферма терминальных серверов на кластерной службе и также был настроен шлюз терминальных серверов для доступа извне.
за NAT-ом и не получится. Перенаправление работает по IP, а не по имени, на сколько я помню, и естесственно внешний клиент получает внутренний IP.
Тут поможет только RDGateway, но при этом практически теряется смысл терминальной фермы. Сам бился над этой проблемой, но пока отложил в сторону.
за NAT-ом и не получится. Перенаправление работает по IP, а не по имени, на сколько я помню, и естесственно внешний клиент получает внутренний IP.
Тут поможет только RDGateway, но при этом практически теряется смысл терминальной фермы. Сам бился над этой проблемой, но пока отложил в сторону.
Вы ошибаетесь, можно сделать и по имени, только с нашим сетевым оборудованием не завелось, видимо нужен какой-то unicast режим, на esxi вечно какая-то хрень с этим.
И могли бы Вы пояснить почему вы считаете, что с RD Gateway теряется смысл?
Потому, как я уже сказал выше, был настроен шлюз терминальных серверов=RD Gateway и эта связка вполне успешно и производительно работает!
Если без RD Gateway, то можно в связку с кластером терминальных серверов добавить VPN канал так, чтобы VPN сервер был в той же подсети, так хоть multicast, а всё равно нормально подключается, проверено.
Ответы
При этой ошибке можно подключиться по IP и из внутренней сети это получается, даже перенаправление работает, т.е. по IP попадаю на другой сервер.
Но идея была в том, чтобы не изменяя настройки клиентов "подсунуть" им настроенную ферму терминальных серверов. Т.е. с тем же внешним и внутренним именами (совпадают).
Подключение не удается установить, поскольку удаленный компьютер, с которым установлена связь, отличается от указанного пользователем. Это может быть связано с тем, что запись в кэше DNS устарела. Попробуйте использовать IP-адрес вместо имени компьютера.
В итоге была создана ферма терминальных серверов на кластерной службе и также был настроен шлюз терминальных серверов для доступа извне.
Ответы
При этой ошибке можно подключиться по IP и из внутренней сети это получается, даже перенаправление работает, т.е. по IP попадаю на другой сервер.
Но идея была в том, чтобы не изменяя настройки клиентов "подсунуть" им настроенную ферму терминальных серверов. Т.е. с тем же внешним и внутренним именами (совпадают).
Подключение не удается установить, поскольку удаленный компьютер, с которым установлена связь, отличается от указанного пользователем. Это может быть связано с тем, что запись в кэше DNS устарела. Попробуйте использовать IP-адрес вместо имени компьютера.
В итоге была создана ферма терминальных серверов на кластерной службе и также был настроен шлюз терминальных серверов для доступа извне.
Ответы
Переустановил роль rdg, перенастроил точно так же. В итоге получил ещё одну ошибку (в дополнение к трём существующим):
4. В группе "Пользователи удаленного рабочего стола" на сервере узла сеансов удаленных рабочих столов должны присутствовать пользователи или группы домена.
Сервер узла сеансов - это мой единственный физический сервер. Пользователи и группы в этой группе присутствуют. =)
После этого на клиенте через rdweb появилась уже другая ошибка:
"При отправке данных на сервер шлюза удаленных рабочих столов произошла ошибка. Сервер временно недоступен или не работает сетевое подключение."
ПС: давно не работал с виндовс, совсем забыл про актуальность шутки:
Едут в машине таксист, бизнесмен и программист. Вдруг машина ломается.
Таксист говорит:
- Давайте мотор смотреть.
Бизнесмен:
- Да ладно, давай тачку поймаем.
Программист:
- А давайте все выйдем и снова войдем, может, она заработает?
Как решить ошибку с RDP подключением
Существует несколько методов решения ошибки "Не удается подключиться к удаленному компьютеру. Повторите попытку подключения. Если проблема повторится, обратитесь к владельцу удаленного компьютера." что вы должны сделать:
- Удалить необходимые обновления Windows
- Удаление или обновление "Крипто ПРО" и VipNet
- Понижение требования к уровню шифрования
- Установка дополнительных обновлений
Варианты устранения проблемы с подключением по RDP
Не удается установить подключение, так как проверка подлинности не включена, а удаленный компьютер требует, чтобы проверка подлинности для подключения была включена
можно сделать вывод, что порт 3389 отвечает и его не нужно проверять с помощью Telnet. Далее алгоритм такой:
- Первое, что нужно сделать, это проверить DNS записи, которые отвечают за резолвинг имени фермы, сделать это можно с помощью команды nslookup. Открываем командную строку или power shell и вводим там команду:
- Если с записями все хорошо, то нужно посмотреть логи системы на посредниках к подключению, это как раз те сервера, которые отвечают по команде 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, они подгружаются сюда отдельно с официального сайта
После этих манипуляций ошибка ушла.
- Если у вас нет Kemp LoadMaster или нет вообще Connection Broker, то попробуйте подключиться не по DNS имени фермы, а отдельно по RDP на конечный хост (Session Host). Проверьте, что у него стоят правильные настройки проверки подлинности.
Для этого зайдите в свойства системы, на вкладке "Удаленный доступ" проверьте наличие галки:
NLA: Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети
Такая галка, запрещает старым клиентам служб удаленных рабочих столов производить подключение, актуально для Windows XP или не обновленных Windows 7, если у вас есть такие клиенты, то либо их обновите, либо снимите галку.
Так же в такой ситуации, когда был конфликт в версиях RDP клиента и вам отвечает не Session Host являющийся членом фермы, а как в моем случае левый сервер, то выскакивала ошибка: Подключение было разорвано, поскольку был получен непредусмотренный сертификат проверки подлинности сервера от удаленного компьютера. Повторите попытку подключения. Если проблема сохранится, обратитесь к владельцу удаленного компьютера или сетевому администратору
PS. Советую сделать на каждом сервере, что входит в состав терминальной фермы команду RSOP в командной строке, чтобы понять какие групповые политики прилетают и посмотрите, что у вас там
Удаление или обновление ПО
Начинаю я с этого метода, так как он самый правильный и с точки удобства и с точки безопасности. Если вам данное ПО не нужно, то советую его удалить его и провести очистку системы от мусора, если же программы нужны, то рассмотрите вариант их обновления на свежие версии в которых уже таких проблем нет. В моем случае это не получилось сделать, так как мне была необходима старая версия VipNet.
Если ошибка появляется на виртуальном сервере
Сейчас подавляющее количество серверов либо в облаках, либо в виде виртуальных машин. У меня это второй вариант, так как моя RDS ферма построена на базе гипервизора Vmware ESXI 6.5. Тут есть подводный камень со временем, так как сама виртуальная машина может его брать с физического сервера на котором она работает. Я всегда советую отключать данную синхронизацию. Найти ее можно в свойствах виртуальной машины, на вкладке "VM Options" в разделе "VMware Tools", тут снимите галку "Synchronize quest time with host"
После этого вам нужно в гостевой операционной системе этой VM, открыть командную строку и перезапустить службу времени:
Так же бывают глюки из-за времени на vCenter сервере, в следствии чего вы опять видите ошибку "Подключение не удается установить, поскольку удаленный компьютер, с которым установлена связь, отличается от указанного пользователем. Это может быть связано с тем, что запись в кэше DNS устарела. Попробуйте использовать IP-адрес вместо имени компьютера". Тут необходимо войти на ваш vCenter сервер по адресу:
По идее все эти не хитрые действия, должны вам помочь в решении ошибки: "Подключение не удается установить, поскольку удаленный компьютер, с которым установлена связь, отличается от указанного пользователем. Это может быть связано с тем, что запись в кэше DNS устарела. Попробуйте использовать IP-адрес вместо имени компьютера".
Все ответы
При этом политики диспетчера шлюза удаленных рабочих столов:
Политики авторизации подключений
Если пользователь является членом любой из перечисленных ниже групп пользователей:
Политики авторизации ресурсов
Сетевой ресурс: разрешить подключение пользователей к любому сетевому ресурсу
Разрешенные порты: 3389
1. Проверьте наличие учетной записи RDG в группе безопасности RAS and IAS Servers в Active Directory.
1. Что вы имеете в в виду под "учетной записью RDG"? Группу RAS and IAS Servers нашел. Вот список моих групп:
2. Настройку осуществил, выбрал уровень безопасности RDP. Только в статье тип подключения 6.1, а у меня 7.1. Немного изменился ход подключения, но ошибка в итоге та же самая.
Под "учетной записью RDG" подразумевалась учетная запись сервера, на которой развернут шлюз удаленных рабочих столов. Добавьте этот сервер в группу RAS and IAS Servers.
«Подключение не удается установить, поскольку удаленный компьютер, с которым установлена связь, отличается от указанного пользователем. Это может быть связано с тем, что запись в кэше DNS устарела. Попробуйте использовать IP-адрес вместо имени компьютера.»
бывает если подключаться к члену фермы через имя компьютера, а не фермы. У вас случайно не включена эта фича?
Вот она по-моему где включается. Видимо нет.
Таким образом настроено.
Если все настроенно на одной машине с какой целью предпологается использовать Connection Broker?
Отношения к делу наверное не имеет, так скорее интересно.
Про виртуальные машины ранее информации не было, то есть это физическая машина одна. Может быть еще информация какая-нибудь будет? Где стоит Web-Access и что происходит на виртуальных машинах?
1. RDG стоит на контроллере домена. Каким образом он не может достучаться до AD?
2. Политики есть и они включены.
Точно такие же проблемы на форуме видел, но решения там не было.
Переустановил роль rdg, перенастроил точно так же. В итоге получил ещё одну ошибку (в дополнение к трём существующим):
4. В группе "Пользователи удаленного рабочего стола" на сервере узла сеансов удаленных рабочих столов должны присутствовать пользователи или группы домена.
Сервер узла сеансов - это мой единственный физический сервер. Пользователи и группы в этой группе присутствуют. =)
После этого на клиенте через rdweb появилась уже другая ошибка:
"При отправке данных на сервер шлюза удаленных рабочих столов произошла ошибка. Сервер временно недоступен или не работает сетевое подключение."
ПС: давно не работал с виндовс, совсем забыл про актуальность шутки:
Едут в машине таксист, бизнесмен и программист. Вдруг машина ломается.
Таксист говорит:
- Давайте мотор смотреть.
Бизнесмен:
- Да ладно, давай тачку поймаем.
Программист:
- А давайте все выйдем и снова войдем, может, она заработает?
Читайте также: