Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов
Обновлено: 05.07.2024
Для того чтобы повысить уровень безопасности Windows-сервера бывает недостаточно сменить TCP-порт RDP . Рассмотрим настройку шлюза удаленных рабочих столов (Remote Desktop Gateway / Terminal Services Gateway) в домене Active Directory.
Remote Desktop Gateway, что это?
Remote Desktop Gateway - это роль Windows-сервера, обеспечивающая защищенное соединение, с помощью протокола SSL, с сервером по RDP. Главное преимущество этого решения в том, что не требуется развертывание VPN-сервера, для этого и используется шлюз.
Следует отметить, что начиная с Windows Server 2008 R2, были изменены названия всех служб удаленных рабочих столов. Именуемые ранее службы Terminal Services были переименованы в Remote Desktop Services.
Преимущества Remote Desktop Gateway в следующем:
- Используя зашифрованное соединение, шлюз позволяет подключаться к внутренним сетевым ресурсам без необходимости использования VPN-соединения удаленными пользователями;
- Шлюз дает возможность контроля доступа к определенным сетевым ресурсам, тем самым реализуя комплексную защиту;
- Шлюз разрешает подключение к сетевым ресурсам, которые размещены за межсетевыми экранами в частных сетях или NAT;
- С помощью консоли диспетчера шлюза появляется возможность настраивать политики авторизации для тех или иных условий, которые должны быть выполнены при подключении к сетевым ресурсам удаленными пользователями. В качестве примера, можно указать конкретных пользователей, которые могут подключаться к внутренним сетевым ресурсам, а также должен ли клиентский компьютер при этом быть членом группы безопасности AD, допустимо ли перенаправление устройства и диска;
- Консоль диспетчера шлюза содержит инструменты, предназначенные для отслеживания состояния шлюза. Используя их, вы можете назначить отслеживаемые события для аудита, например, неудачные попытки подключения к серверу шлюза служб терминалов.
Важно! Шлюз служб терминалов должен входить в домен Active Directory. Настройка шлюза выполняется только от имени администратора домена, на любом сервере в домене.
В связи с недавними обновлениями безопасности Windows, закрывающее уязвимости в протоколе CredSSP, парочка маков (mac mini середины 2007 года) потеряли доступ к терминальному серверу на базе Windows Server 2008R2.
Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение.
Дело в том, что старая версия маковского rdp client 2.1.1 от Microsoft, ставшая последней доступной для Mac OS X 10.7 (Lion), не работает не только с Windows Server 2012, но после вышеупомянутого обновления перестала подключаться и к WinServer 2008R2. В природе существует и неофициальная версия rdp-клиента 2.1.2, однако разыскивать её, нет особого резона — результат будет аналогичным.
Установка галки «Подключаться даже если проверка подлинности завершается с ошибкой» в настройках RDP клиента (Свойства -> Безопасность) тоже никак не влияет на результат подключения.
Актуальные, на данный момент, клиенты Microsoft Remote Desktop 8.0 (совместима с OS X 10.9 и выше) и Microsoft Remote Desktop 10.0 (macOS 10.10 и выше) поставить на старую систему OS X не представляется возможным. Из вменяемых альтернатив, можно выделить, пожалуй, только Parallels Client. и вроде вот оно счастье, ведь в минимальных требованиях значится Mac OS X 10.7.3, однако не стоит верить всему что пишут. Хоть программа и благополучно устанавливается, позволяет внести данные о вашем подключении, однако вылетает на попытке соединения с сервером вываливая кучу ошибок.
От безысходности можно пойти от обратного, изменив работу службы удаленных рабочих столов на сервере (метод работает и на Windows Server 2012), однако лучшим вариантом станет замена клиентской машины.
Подключения старой версии rdp client 2.1.1 к Windows Server 2012
Нам понадобится запустить редактор групповых политик. В командной строке набираем gpedit. Переходим в раздел настроек безопасности RDP:
Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удаленных рабочих столов -> Безопасность
Здесь следует поменять значение двух параметров:
- Требовать использования специального уровня безопасности для удаленных подключений по методу RDP (ставим "Включить", а уровень безопасности выбираем "RDP")
- Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (ставим "Отключить")
Теперь даже старые версии Microsoft Remote Desktop будут подключаться к терминальному серверу, правда только по дефолтному порту 3389. Замечен и побочный эффект — Windows клиенты, которые ставили галочку «сохранить пароль» лишились такой возможности. В общем, данная статья носит скорее познавательный характер, приделывать подобные костыли рабочим серверам я бы не стал.
Яндекс.Дзен и узнавайте первыми о новых материалах, опубликованных на сайте.Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.
Комментариев: 5
Добрый день. Не ожидал что в 2018 найду свежую информацию для старых маков. Вот мне как раз актуально, так как подключаюсь по удалёнке не к серверу, а к своему рабочему компьютеру на Windows 10, обновился недавно. Теперь RDP снова работает :)
Вы так конкретно и доступно всё описали, что до меня наконец-то дошло почему не удаётся подключиться к удалённому компу. Спасибо за помощь!
8 мая 2018 г. Microsoft выпустило обновление, которое предотвращает удаленное выполнение кода с помощью уязвимости в протоколе CreedSSP.
После установки данного обновление пользователи не могут подключиться к удаленным ресурсам посредством RDP или RemoteApp. При подключении происходит такая ошибка:
Рисунок 1 - Ошибка проверки подлинности RDP
Появление ошибки обусловлено установкой данных обновлений безопасности:
- Windows Server 2016 — обновление KB4103723
- Windows 10 1609 — обновление KB4103723
- Windows 10 1703 — обновление KB4103731
- Windows 10 1709 — обновление KB4103727
- Windows 10 1803 — обновление KB4103721
- Windows 7 / Windows Server 2008 R2 — обновление KB4103718
- Windows 8.1 / Windows Server 2012 R2 — обновление KB4103725
В данной статье мы рассмотрим варианты исправления данной ошибки.
Вариант №1: Убираем проверку подлинности.
Заходим в свойства компьютера, переходим на вкладку Удаленный доступ и снимаем галку с чекбокса.
Рисунок 2 - Проверка подлинности
Вариант №2 (рекомендуемый): Обновление клиентских и серверных ОС.
Устанавливаем специально выпущенные патчи обновления, которые закрыли уязвимость в RDP-клиенте. Данные обновления можно посмотреть на сайте Microsoft. После установки данного обновления, мы обновляем CredSSP.
Вариант №3: Через групповые политики.
Локально заходим в групповые политики устройства, к которому пытаемся подключиться. Для того чтобы открыть редактор групповых политик выполним следующее действие: Нажимаете Win+R, а затем введите gpedit.msc. Переходите по данному пути: Конфигурация компьютера > Административные шаблоны > Система > Передача учетных данных > Защита от атак с использованием криптографического оракула.
В свойствах данной политики выбираем пункт Включено и ниже в параметрах выбираем уровень защиты Оставить уязвимость.
После того, как данные действия выполнены, необходимо зайти в командную строку от имени администратора и выполнить данную команду:
Вариант №4. Редактирование реестра.
Локально заходим на устройство, к которому пытаемся подключиться и нажимаем Win+R. Вводим regedit. После того, как откроется редактор реестра идем по следующему пути:
Затем находим параметр AllowEncryptionOracle, открываем его и ставим значение 2.
После выполнения данных действий с реестром выполняем перезагрузку устройства.
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
| выполните на новом сервре netstat -a | findstr 3389 покажите вывод » |
TCP 192.168.0.6:3389 192:1030 ESTABLISHED
TCP 192.168.0.6:3389 192:1025 ESTABLISHED
TCP 192.168.0.6:3389 192:1317 ESTABLISHED
TCP 192.168.0.6:3389 192:1056 ESTABLISHED
TCP 192.168.0.6:3389 192:1054 ESTABLISHED
TCP 192.168.0.6:3389 192:1068 ESTABLISHED
TCP 192.168.0.6:3389 192:1037 ESTABLISHED
TCP [::]:3389 Server:0 LISTENING
TCP [fe80::c1d8:d093:940:3a5b%15]:3389 Manager:49162 ESTABLISHED
TCP [fe80::c1d8:d093:940:3a5b%15]:3389 ЎЁ«*©*2:49156 ESTABLISHED
TCP [fe80::c1d8:d093:940:3a5b%15]:3389 admin-ЇЄ:49483 ESTABLISHED
TCP [fe80::c1d8:d093:940:3a5b%15]:3389 admin-ЇЄ:49559 ESTABLISHED
TCP [fe80::c1d8:d093:940:3a5b%15]:3389 Copicentr:50820 ESTABLISHED
UDP 0.0.0.0:3389 *:*
UDP [::]:3389 *:* может дело в настройке роутера всё таки. Чтобы в этом убедиться достаточно новому серверу поставить IP как у старого, а старый на время отключить от сети. В таком случае подключение проходить будет? В логах изменения? Сомневаюсь. Роутер абсолютно новый, настраивал его по аналогии со старым ADSL-модемом. В проброске портов я "играюсь" только с ip серверов
что выдает машина с которой пытаетесь подключиться? какую ошибку?
Вы новый сервер добавляли в группу доступа на шлюзе RDP в ресурсную политику, в раздел Network resource?
снаружи проверяли?при переключении в роутере на новый сервер, сам порт отвечает?
Да. Проверил - 443-й доступен на обоих серверах
| что выдает машина с которой пытаетесь подключиться? какую ошибку? » |
если порт отвечает снаружи, соединение должно проходить
нужно тогда больше информации с клиента
смотрите логи по службе RDP
| так сервер шлюза удаленных рабочих столов временно недоступен » |
вы к серверу подключаетесь через шлюз?
Чет я запутался. у вас старый сервер является шлюзом RDP (то есть через него вы подключались на другие станции), и вы сейчас новый сервер тоже делаете шлюзом RDP чтоб через него уже подключались.. .Подключаться вы пытаетесь извне на роутер который должен переадресовать вас к серверу шлюза RDP. Такая схема?
Читайте также: