Ошибка сертификата при подключении rdp

Содержание

Произошла ошибка проверки подлинности. Указанная функция не поддерживается
Ответ
Отключение NLA для протокола RDP в Windows
Ошибка при подключении по RDP (Исправление шифрования CredSSP)
Настройка доверенных SSL/TLS сертификатов для защиты RDP подключений
Предупреждение о самоподписанном сертификате RDP
Создаем шаблон RDP сертификата в центре сертификации (CA)
Настройка групповой политики для выдачи RDP сертификатов
Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата
Устранение неполадок с подключениями к Удаленному рабочему столу
Проверка состояния протокола RDP
Проверка состояния протокола RDP на локальном компьютере
Проверка состояния протокола RDP на удаленном компьютере
Проверка блокировки объектом групповой политики протокола RDP на локальном компьютере
Проверка блокировки объектом групповой политики протокола RDP на удаленном компьютере
Изменение блокирующего объекта групповой политики
Проверка состояния служб RDP
Проверка состояния прослушивателя протокола RDP
Проверка состояния прослушивателя RDP
Проверка состояния самозаверяющего сертификата протокола RDP
Проверка разрешений для папки MachineKeys
Проверка порта прослушивателя протокола RDP
Проверка того, что другое приложение не пытается использовать тот же порт
Проверка блокировки порта протокола RDP брандмауэром
Устранение ошибки проверки подлинности RDP

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

После установки обновления KB4103718 на моем компьютере с Windows 7 я не могу удаленно подключится к серверу c Windows Server 2012 R2 через удаленный рабочий стол RDP. После того, как я указываю адрес RDP сервера в окне клиента mstsc.exe и нажимаю «Подключить», появляется ошибка:

Произошла ошибка проверки подлинности.

Указанная функция не поддерживается.
Удаленный компьютер: computername

rdp proizoshla oshibka proverki podlinnosti ukazan

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

Ответ

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

В своей проблеме вы не одиноки. Данная ошибка может появится в любой операционной системе Windows или Windows Server (не только Windows 7). У пользователей английской версии Windows 10 при попытке подключится к RDP/RDS серверу аналогичная ошибка выглядит так:

The function requested is not supported.

Remote computer: computername

an authentication error has occurred the function

Ошибка RDP “An authentication error has occurred” может появляться и при попытке запуска RemoteApp приложений.

Почему это происходит? Дело в том, что на вашем компьютере установлены актуальные обновления безопасности (выпущенные после мая 2018 года), в которых исправляется серьёзная уязвимость в протоколе CredSSP (Credential Security Support Provider), использующегося для аутентификации на RDP серверах (CVE-2018-0886) (рекомендую познакомится со статьей Ошибка RDP подключения: CredSSP encryption oracle remediation). При этом на стороне RDP / RDS сервера, к которому вы подключаетесь со своего компьютера, эти обновления не установлены и при этом для RDP доступа включен протокол NLA (Network Level Authentication / Проверку подлинности на уровне сети). Протокол NLA использует механизмы CredSSP для пре-аутентификация пользователей через TLS/SSL или Kerberos. Ваш компьютер из-за новых настроек безопасности, которые выставило установленное у вас обновление, просто блокирует подключение к удаленному компьютеру, который использует уязвимую версию CredSSP.

Что можно сделать для исправления эту ошибки и подключиться к вашему RDP серверу?

Отключение 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).

win 10 otklyuchit nla

В 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).

trebovat proverku podlinnosti polzovatelya dlya ud

Также нужно в политике «Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP» (Require use of specific security layer for remote (RDP) connections) выбрать уровень безопасности (Security Layer) — RDP.

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

Источник

Ошибка при подключении по RDP (Исправление шифрования CredSSP)

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

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

ff2f75758bd85b36cca8f799272d0585

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

fa92da251c2065b2e2decc5701b2505f

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

9e878a08c168d1c022b463296ad51d42

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

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

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

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

eada1bf0cdb3dec467a70a53f7a63c8f

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

Источник

Настройка доверенных SSL/TLS сертификатов для защиты RDP подключений

В этой статье мы покажем, как использовать доверенные SSL/TLS сертификаты для защиты RDP подключений к компьютерам и серверам Windows в домене Active Directory. Эти сертфикаты мы будем использовать вместо самоподписанных RDP сертификатов (у пользователей появляется предупреждение о невозможности проверки подлинности при подключению к RDP хосту с таким сертификатом). В этом примере мы настроим специальный шаблон для выпуска RDP сертификатов в Certificate Authority и настроим групповую политику для автоматического выпуска и привязки SSL/TLS сертификата к службе Remote Desktop Services.

Предупреждение о самоподписанном сертификате RDP

По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный

сертификат. В результате при первом подключении к RDP/RDS серверу через клиента mstsc.exe, у пользователя появляется предупреждение:

Чтобы продолжить установление RDP подключении пользователь должен нажать кнопку Да. Чтобы RDP предупреждение не появлялось каждый раз, можно включить опцию “Больше не выводить запрос о подключениях к этому компьютеру».
rdp podklyuchenie oshibka sertifikata sertifikat vyd

При этом отпечаток RDP сертификата сохраняется на клиенте в параметре CertHash в ветке реестра с историей RDP подключений (HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientServers). Если вы скрыли уведомление о невозможности проверить подлинность RDP сервера, чтобы сбросить настройки, удалите ключ с отпечатком сертификата из реестра.

otpechatok rdp sertfikata hranitsya na kliente v ree

Создаем шаблон RDP сертификата в центре сертификации (CA)

Попробуем использовать для защиты RDP подключений доверенный SSL/TLS сертификат, выданный корпоративным центром сертификации. С помощью такого сертификата пользователь может выполнить проверку подлинности RDP сервера при подключении. Предположим, что у вас в домене уже развернут корпоративной центр сертификации (Microsoft Certificate Authority), в этом случае вы можете настроить автоматическую выдачу и подключение сертификатов всем компьютерам и серверам Windows в домене.

Н на вашем CA нужно создать новый тип шаблона сертификата для RDP/RDS серверов.

Настройка групповой политики для выдачи RDP сертификатов

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

tls sertfikat dlya remote desktop authentication

Для применения нового RDP сертификата, перезапустите службу Remote Desktop Services:

Теперь при RDP подключении к серверу перестанет появляться запрос на доверие сертификату (чтобы появился запрос о доверии сертификату, подключитесь к серверу по IP адресу вместо FQDN имени сервера, для которого выпущен сертификат). Нажмите кнопку “Посмотреть сертификат”, перейдите на вкладку “Состав”, скопируйте значение поля “Отпечаток сертификата”.
proverka rdp podklyucheniya s novym sertfikatom

Также можете в консоли Certification Authority в секции Issued Certificates проверить, что по шаблону RDPTemplate был выдан сертификат определённому Windows компьютеру/серверу. Также проверьте значение Thumbprint сертификата:

thumbprint u sertfikata

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

Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата

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

Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:

rdpsign.exe /sha256 65A27B2987702281C1FAAC26D155D78DEB2B8EE2 «C:UsersrootDesktoprdp.rdp»

politika ukazat otpechatki sha1 sertifikatov pred

Чтобы работал прозрачных RDP вход без ввода пароля (RDP Single Sign On), нужно настроить политику Allow delegation defaults credential и указать в ней имена RDP/RDS серверов (см. статью).

Источник

Устранение неполадок с подключениями к Удаленному рабочему столу

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

Проверка состояния протокола RDP

Проверка состояния протокола RDP на локальном компьютере

Сведения о том, как проверить и изменить состояние протокола RDP на локальном компьютере, см. в разделе How to enable Remote Desktop (Как включить удаленный рабочий стол).

Проверка состояния протокола RDP на удаленном компьютере

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

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

Проверка блокировки объектом групповой политики протокола RDP на локальном компьютере

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

Чтобы проверить конфигурацию групповой политики на локальном компьютере, откройте окно командной строки с правами администратора и введите следующую команду:

Когда команда будет выполнена, откройте файл gpresult.html. Выберите Конфигурация компьютераАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовПодключения и найдите политику Разрешить пользователям удаленное подключение с использованием служб удаленных рабочих столов.

Если для параметра этой политики задано значение Включено, групповая политика не блокирует подключения по протоколу RDP.

Если же для параметра этой политики задано значение Отключено, проверьте результирующий объект групповой политики. Ниже показано, какой объект групповой политики блокирует подключения по протоколу RDP. gpresult rdsh connections gp

gpresult rdsh connections lgp

Проверка блокировки объектом групповой политики протокола RDP на удаленном компьютере

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

Изменение блокирующего объекта групповой политики

Эти параметры можно изменить в редакторе объектов групповой политики (GPE) и консоли управления групповыми политиками (GPM). Дополнительные сведения об использовании групповой политики см. в статье Advanced Group Policy Management (Расширенное управление групповыми политиками).

Чтобы изменить блокирующую политику, используйте один из следующих методов.

Проверка состояния служб RDP

На локальном компьютере (клиентском) и удаленном компьютере (целевом) должны быть запущены следующие службы:

Для локального или удаленного управления службами можно использовать оснастку MMC. Вы также можете использовать PowerShell для управления службами в локальном или удаленном расположении (если удаленный компьютер настроен для приема удаленных командлетов PowerShell).

rdsservicestatus

На любом компьютере запустите одну или обе службы, если они запущены.

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

Проверка состояния прослушивателя протокола RDP

Проверка состояния прослушивателя RDP

Для выполнения этой процедуры используйте экземпляр PowerShell с разрешениями администратора. На локальном компьютере также можно использовать командную строку с разрешениями администратора. Но для этой процедуры используется PowerShell, так как одни и те же командлеты выполняются локально и удаленно.

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

Введите qwinsta. wps qwinsta

Если в списке содержится rdp-tcp с состоянием Listen, прослушиватель протокола удаленного рабочего стола работает. Перейдите к разделу Проверка порта прослушивателя протокола RDP. В противном случае перейдите к шагу 4.

Экспортируйте конфигурацию прослушивателя RDP с рабочего компьютера.

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

Чтобы создать резервную копию для существующей записи реестра, воспользуйтесь таким командлетом:

Чтобы удалить резервную копию для существующей записи реестра, воспользуйтесь таким командлетом:

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

Замените именем экспортированного REG-файла.

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

Проверка состояния самозаверяющего сертификата протокола RDP

Проверка разрешений для папки MachineKeys

Проверка порта прослушивателя протокола RDP

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

Чтобы проверить или изменить порт протокола RDP, используйте редактор реестра:

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

Проверка того, что другое приложение не пытается использовать тот же порт

Введите следующую команду:

wps netstat

Найдите запись для TCP-порта 3389 (или назначенного RDP-порта) с состоянием Ожидает вызова.

Идентификатор процесса службы или процесса, использующих этот порт, отобразится в столбце «Идентификатор процесса».

Чтобы определить, какое приложение использует порт 3389 (или назначенный порт протокола RDP), введите следующую команду:

wps tasklist

Найдите запись для номера процесса, связанного с портом (в выходных данных netstat). Службы или процессы, связанные с этим идентификатором процесса, отобразятся в столбце справа.

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

Проверка блокировки порта протокола RDP брандмауэром

С помощью средства psping проверьте, доступен ли затронутый компьютер через порт 3389.

Перейдите на другой компьютер, на котором такая проблема не возникает, и скачайте psping отсюда: https://live.sysinternals.com/psping.exe.

Откройте окно командной строки с правами администратора, перейдите в каталог, где установлено средство psping, и введите следующую команду:

Проверьте выходные данные команды psping на наличие таких результатов:

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

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

Рекомендуемые дальнейшие действия:

Источник

Устранение ошибки проверки подлинности RDP

8 мая 2018 г. Microsoft выпустило обновление, которое предотвращает удаленное выполнение кода с помощью уязвимости в протоколе CreedSSP.

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

Появление ошибки обусловлено установкой данных обновлений безопасности:

В данной статье мы рассмотрим варианты исправления данной ошибки.

Вариант №1: Убираем проверку подлинности.

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

Вариант №2 (рекомендуемый): Обновление клиентских и серверных ОС.

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

Вариант №3: Через групповые политики.

Локально заходим в групповые политики устройства, к которому пытаемся подключиться. Для того чтобы открыть редактор групповых политик выполним следующее действие: Нажимаете Win+R, а затем введите gpedit.msc. Переходите по данному пути: Конфигурация компьютера > Административные шаблоны > Система > Передача учетных данных > Защита от атак с использованием криптографического оракула.

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

После того, как данные действия выполнены, необходимо зайти в командную строку от имени администратора и выполнить данную команду:

Вариант №4. Редактирование реестра.

Локально заходим на устройство, к которому пытаемся подключиться и нажимаем Win+R. Вводим regedit. После того, как откроется редактор реестра идем по следующему пути:

Затем находим параметр AllowEncryptionOracle, открываем его и ставим значение 2.

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

Нужна помощь в настройке RDP-подключений? Обращайтесь к нам!

Источник

Содержание

Не удается проверить подлинность удаленного компьютера
Произошла ошибка проверки подлинности RDP. Указанная функция не поддерживается — Решение
В чем суть ошибки проверки подлинности RDP
Установка апдейта, если указанная функция не поддерживается
Изменение настроек групповых политик
Отключение NLA для решения ошибки проверки RPD
Заключение
Не удается проверить подлинность удаленного компьютера ошибка сертификата
Лучший отвечающий
Вопрос
Ответы
Все ответы
Настройка доверенных SSL/TLS сертификатов для защиты RDP подключений
Предупреждение о самоподписанном сертификате RDP
Создаем шаблон RDP сертификата в центре сертификации (CA)
Настройка групповой политики для выдачи RDP сертификатов
Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата
При подключении к серверу терминала, который работает Windows Server 2008 или Windows Server 2008 R2, вы получаете различные сообщения об ошибках, связанных с сертификатом.
Симптомы
Причина
Решение

Не удается проверить подлинность удаленного компьютера

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

Не удается установить соединение с удаленным помощником, не удается сопоставить DNS-имя удаленного компьютера.
Здравствуйте.Пытаюсь подключиться к другому компу через приглашение по удалённому помощнику и в.

Как проверить подлинность Windows?
Добрый день. Извиняюсь, возможно поместил не в ту тему. Работаю программистом, реального.

Как проверить подлинность Windows 7
Всем доброго времени суток!Можно ли узнать что за ОС стоит на ноутбуке.Чистая или какая-то.

Покупка оригинальной зарядки, но бу. Как проверить на подлинность?
Здравствуйте. Недавно я потерял портфель, в котором было зарядное устройство для моего телефона.

В любом случае, я считаю, что работа не стоит того.

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

Не удаётся запустить Windows из-за испорченного или удалённого файла
При включении компьютера пишет мол не удаётся запустить виндовс из за испорченного или удалённого.

Зависание удаленного компьютера
Добрый день! при работе с удаленным компьютером происходит зависание картинки рабочего стола.

7.7 Имя удаленного компьютера
Добрый день. Подскажите, как можно определить имя компьютера при работе с 1С через удаленный.

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

Отключение от удалённого компьютера
Не получается окончательно отключиться от удалённого компьютера. для начала в cmd подключусь.

Имя удаленного компьютера
Здравствуйте, подскажите пожалуйста как узнать имена доступных удаленных компьютеров? Моя.

Источник

Произошла ошибка проверки подлинности RDP. Указанная функция не поддерживается — Решение

При попытке подключения к серверу через протокол удалённого рабочего стола (RPD) пользователь может столкнуться с ошибкой подключения, сопровождающейся сообщением « Произошла ошибка проверки подлинности. Указанная функция не поддерживается ». Возникновение данной проблемы обычно связано с отсутствием необходимых обновлений на ПК клиента. А также рядом настроек на машинах сервера или клиента, блокирующих отдалённое подключение к ПК. Разберём, что является причиной проблемы, и как её исправить.

Уведомление об дисфункции при проверке подлинности

В чем суть ошибки проверки подлинности RDP

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

В апреле «Майкрософт» выпустила следующий апдейт, снабжающий пользователя более детальной информацией об ошибке во время использования клиента удалённого рабочего стола (RDP).

В мае 2018 года вышел финальный Update, изменяющий настройки сессии RDP c использованием CredSSP по умолчанию с « Vulnerable » (Уязвимый) до « Mitigated » (Смягчённый). Также это означало, что любое клиентское приложение, задействующее «CredSSP», будет невозможно откатить до небезопасной версии.

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

Разберём перечень способов, позволяющих эффективно избавиться от проблемы проверки подлинности RDP.

Установка апдейта, если указанная функция не поддерживается

Соответственно, основным способом, позволяющим исправить ошибку проверки подлинности RPD, является установка необходимого обновления ( CVE-2018-0886 ) как на клиентскую, так и на серверную ОС.

Выберите свою версию OS из списка снизу, и установите на вашу машину необходимый ей апдейт CVE-2018-0886:

Также можно перейти на сайт Майкрософта (при необходимости поставьте галочку и нажмите «Accept»), слева отыскать версию вашей системы (если не знаете, нажмите Win+Pause). Далее нажать справа на « Security Update », после чего вы получите возможность скачать нужное обновление.

Изменение настроек групповых политик

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

Установите указанные параметры

Также вы можете осуществить данную операцию с помощью специальной команды, выполненной в командной строке с правами админа:

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

Отключение NLA для решения ошибки проверки RPD

Ещё одним способом решить ошибку проверки подлинности RPD является отключение NLA (аутентификации на уровне сети).

Заключение

Появление сообщения «Произошла ошибка проверки подлинности RDP. Указанная функция не поддерживается» обычно связано с отсутствием на ПК (обычно клиентском) необходимого обновления CVE-2018-0886, позволяющего ликвидировать ряд уязвимостей в системе. Необходимо установить требуемые обновления для вашей системы, а если такое временно невозможно – просто переключите параметр шифрующего оракула на «Vulnerable» (т.е. «Оставить уязвимость»), что позволит решить ошибку.

Источник

Не удается проверить подлинность удаленного компьютера ошибка сертификата

Этот форум закрыт. Спасибо за участие!

Лучший отвечающий

Вопрос

При попытке подключения удаленным рабочим столом с ПК на Windows 7 к ПК на Windows 10 находящемся в домене, ошибка:

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

На обоих ПК выполнил:

Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Службы удаленных рабочих столов > Клиент подключения к удаленному рабочему столу > Настройка проверки подлинности клиента на сервере > Включить > Подключаться, даже если проверка подлинности не прошла

2). На ПК с 10-кой отключил брандмауэр.

Ответы

Вопрос решился после выполнения приложенной инструкции. Теперь другая проблема:

Все ответы

При попытке подключения удаленным рабочим столом с ПК на Windows 7 к ПК на Windows 10 находящемся в домене, ошибка:

На обоих ПК выполнил:

2). На ПК с 10-кой отключил брандмауэр.

Если Win7 с которых пытаетесь подключиться у Вас не в домене, Вам нужно отключить проверку на Win 10.

The opinion expressed by me is not an official position of Microsoft

На 10-ке это сделано. После отключения этой опции как раз заявленная ошибка и появляется. До отключения была другая:

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

При попытке подключения удаленным рабочим столом с ПК на Windows 7 к ПК на Windows 10 находящемся в домене, ошибка:

Подключение к удаленному рабочему столу
Удаленный компьютер требует включения проверки подлинности при подключении.
Удаленный компьютер: х.х.х.х (адрес сервера Балабит)
Подключение невозможно, поскольку не включена проверка подлинности.

На обоих ПК выполнил:

2). На ПК с 10-кой отключил брандмауэр.

Источник

Настройка доверенных SSL/TLS сертификатов для защиты RDP подключений

Предупреждение о самоподписанном сертификате RDP

По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный

otpechatok rdp sertfikata hranitsya na kliente v ree

Создаем шаблон RDP сертификата в центре сертификации (CA)

Н на вашем CA нужно создать новый тип шаблона сертификата для RDP/RDS серверов.

Настройка групповой политики для выдачи RDP сертификатов

tls sertfikat dlya remote desktop authentication

Для применения нового RDP сертификата, перезапустите службу Remote Desktop Services:

thumbprint u sertfikata

Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата

Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:

rdpsign.exe /sha256 65A27B2987702281C1FAAC26D155D78DEB2B8EE2 «C:UsersrootDesktoprdp.rdp»

politika ukazat otpechatki sha1 sertifikatov pred

Источник

При подключении к серверу терминала, который работает Windows Server 2008 или Windows Server 2008 R2, вы получаете различные сообщения об ошибках, связанных с сертификатом.

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

Применяется к: Windows Server 2012 R2
Исходный номер КБ: 2000960

Симптомы

При подключении к серверу терминала, который работает Windows Server 2008, или удаленному настольному серверу, который работает Windows Server 2008 R2, вы получаете одно из следующих сообщений об ошибке.

Подключение удаленного рабочего стола не удалось из-за невозможности проверки подлинности удаленного компьютера

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

Несоответствие имен
Запрашивается удаленный компьютер
Имя в сертификате

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

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

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

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

Несоответствие имен
Запрашивается удаленный компьютер
Имя в сертификате

Ошибки сертификата
Имя сервера в сертификате неверно
сертификат не из доверенного органа сертификации.

Вы хотите подключиться, несмотря на эти ошибки сертификата?

Причина

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

Решение

Ниже ниже 1000 действий по проверке выбранного сертификата.

Источник

Содержание:

Предупреждение о самоподписанном сертификате RDP
Создаем шаблон RDP сертификата в центре сертификации (CA)
Настройка групповой политики для выдачи RDP сертификатов
Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата

Предупреждение о самоподписанном сертификате RDP

По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный

Не удалось проверить подлинность удаленного компьютер из-за проблем с сертификатом безопасности.
Ошибка сертификата: сертификат выдан не имеющим доверия центром сертификации.

отпечаток RDP сертфиката хранится на клиенте в реестре

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

Создаем шаблон RDP сертификата в центре сертификации (CA)

Н на вашем CA нужно создать новый тип шаблона сертификата для RDP/RDS серверов.

Запустите консоль Certificate Authority и перейдите в секцию Certificate Templates;
Сделайте копию шаблона сертификата Computer (Certificate Templates -> Manage -> Computer -> Duplicate);
На вкладке General укажите имя нового шаблона сертификата – RDPTemplate. Убедитесь, что значение поля Template Name полностью совпадает с Template display name;
На вкладке Compatibility укажите минимальную версию клиентов в вашем домене (например, Windows Server 2008 R2 для CA и Windows 7 для клиентов). Тем самым будут использоваться более стойкие алгоритмы шифрования;
Теперь на вкладке Extensions в политике приложений (Application policy) нужно ограничить область использования такого сертификата только для Remote Desktop Authentication (укажите следующий object identifier — 1.3.6.1.4.1.311.54.1.2). Нажмите Add -> New, создайте новую политику и выберите ее;
В настройках шаблона сертификата (Application Policies Extension) удалите все политики кроме Remote Desktop Authentication;
Чтобы использовать данный шаблон RDP сертификатов на контролерах домена, откройте вкладку Security, добавьте группу Domain Controllers и включите для нее опцию Enroll и Autoenroll;
Сохраните шаблон сертификата;
Теперь в оснастке Certificate Authority, щёлкните по папке Certificate Templates, выберите New -> Certificate Template to Issue -> выберите созданный шаблон RDPTemplate.

Настройка групповой политики для выдачи RDP сертификатов

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

Откройте консоль управления доменными групповыми политиками gpmc.msc, создайте новый объект GPO и назначьте его на OU с RDP/RDS серверами или компьютерами, для которых нужно автоматически выдавать TLS сертификаты для защиты RDP подключения;
Перейдите в раздел GPO: Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security. Включите политику Server Authentication Certificate Template. Укажите имя шаблона CA, который вы создали ранее (RDPTemplate);
Затем в этом же разделе GPO включите политику Require use of specific security layer for remote (RDP) connections и установите для нее значение SSL;
Для автоматического продления RDP сертификата, перейдите в раздел GPO Computer configuration -> Windows settings -> Security Settings -> Public Key Policies и включите политику Certificate Services Client – Auto-Enrollment Properties. Выберите опции “Renew expired certificates, update pending certificates and remove revoked certificates” и “Update certificates that use certificate templates”;
Если вы хотите, чтобы клиенты всегда проверяли сертификат RDP сервера, вам нужно настроить политику Configure Authentication for Client = Warn me if authentication fails (секция GPO Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Settings -> Remote Desktop Connection Client);
Если нужно, можете через политики файервола открыть входящий RDP порт TCP/UDP 3389;
Осталось обновить политики на клиенте, запустить консоль сертификатов компьютера (Certlm.msc), и проверить, что в разделе Personal -> Certificates появился сертификат для Remote Desktop Authentication, выданный вашим CA.
Если политики не применились, для диагностики GPO воспользуйтесь утилитой gpresult и этой статьей.

Для применения нового RDP сертификата, перезапустите службу Remote Desktop Services:

Get-Service TermService -ComputerName msk-dc01| Restart-Service –force –verbose

Thumbprint у сертфиката

Теперь сравните полученные данные с отпечатком сертификата, который используется службой Remote Desktop Service. Вы можете посмотреть значение отпечатка сертификата службы RDS в реестре (ветка HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStations, параметр TemplateCertificate) или командой PowerShell:
Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace rootcimv2terminalservices|select SSLCertificateSHA1Hash

получить отпечаток rdp сертификата

Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата

Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:

Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace rootcimv2terminalservices|select|select SSLCertificateSHA1Hash

Используйте этот отпечаток для подписывания .RDP файла с помощью RDPSign.exe:

rdpsign.exe /sha256 65A27B2987702281C1FAAC26D155D78DEB2B8EE2 "C:UsersrootDesktoprdp.rdp"

Теперь через GPO добавим этот отпечаток сертификата в доверенные у пользователей. Укажите отпечатки (через точку с запятою) в политике Specify SHA1 thumbprints of certificates representing trusted .rdp publishers (Указать отпечатки SHA1 сертификатов, представляющих доверенных издателей RDP) в секции Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Settings -> Remote Desktop Connection Client.

политика Указать отпечатки SHA1 сертификатов, представляющих доверенных издателей RDP

Источник

Здравствуйте.
Ситуация: порядка 30 компьютеров прекрасно подключаются по RDP к серверу с гарантом и консультантом, который стоит в главной конторе. А один (как уверяет пользователь) внезапно, после его отпуска перестал, и начал выдавать запрос на проверку сертификата.
Все компы находятся в одной подсети, подключены к одному и тому же провайдеру. Все подключаются из под одного пользователя — user-trm.

Данный сертификат пробовала установить и в доверенные хранилища, и в личные — без толку.

*звонила в главную контору, там отвечают, что с их стороны всё норм и помочь они мне ничем не могут.

**из просторов интернета нашла лишь близкое только.
По ветке HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWin dowsCredentialsDelegation (последнего раздела не существовало, добавила вручную)
Вписала параметры:
REG_DWORD: AllowDefaultCredentials
Значение: 00000000
REG_DWORD: ConcatenateDefaults_AllowDefault
Значение: 00000000

Внезапно! оно начало работать! но запустилось лишь пару раз и теперь опять та же ошибка (скрин прилагаю)

Где можно отключить проверку сертификатов или может куда ещё его нужно добавить?
Человек очень хочет работать уже несколько дней… ((

__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь

Источник

Обновлено 12.12.2022

rdp error 0x907

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами решили проблему «Произошла внутренняя ошибка RDP» при попытке входа на RDS ферму. Сегодня мы вновь столкнемся с трудностями авторизации на RDS ферме, ошибка звучит так «Код ошибки 0x907. Расширенный код ошибки 0x0«. Ловить я ее начал буквально вчера 27 ноября, до этого все прекрасно работало. Из пострадавших, это операционные системы Windows 10 и Windows 11, а вот на Windows 8.1, все отрабатывало на ура. Давайте разбираться в чем дело.

Диагностика ошибки 0x907

Опишу немного инфраструктуру, есть большая RDS ферма из 50 хостов RDSH. Клиенты Windows 10/11, доменные и не доменные стали получать ошибки:

Такую ошибку мы ловили, и я объяснял, что чаще всего это было из-за того, что клиент RDP (mstsc) открывается с ключом /admin. Тут я точно запускал все без ключа. Обратите внимание, что вам показывают, что вы не можете попасть именно на определенную ноду, так как брокер подключений отработал нормально и вас перекинул.

Подключению к удаленному рабочему столу не удалось подключиться к удаленному компьютеру

Так как у меня были полные права на любую ноду, то я попытался войти на данную ноду напрямую. В итоге получил ошибку:

Код ошибки: 0x907. Расширенный код ошибки: 0x0

Ранее я встречал проблему с сертификатом, но не с кодом 0x907, тем более ничего не менялось в самой конфигурации.

RDP ошибка подключения 0ч907

Диагностика и устранение ошибки для Windows клиентов

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

HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientServers

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

Terminal Server Client

Можете спокойно удалить полностью папку Servers, это почистит историю подключений

Удаление Terminal Server Client

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

сертификат выдан не имеющим доверия центром сертификации

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

Сведения о сертификате

Для установки сертификата нажмите соответствующую кнопку. В мастере импорта я всегда советую корневые сертификаты устанавливать в расположение локального компьютера.

<mark>

Выбираем пункт «Переместить все сертификаты в следующее хранилище» и указываем доверенные корневые центры сертификации.

Переместить сертификаты в следующее хранилище

Завершаем импорт корневого сертификата

Переместить сертификаты в следующее хранилище

Теперь если посмотреть состав вашего сертификата, то ваша система ему доверяет.

Корневой сертификат стал доверенным

Теперь подключение к текущему хосту будет без ошибок

Успешное подключение по RDP

Но так как у меня 50 RDSH хостов, то ставить от каждого сертификат в корневые это бред. Для этого вы можете поступать двумя методами:

1️⃣Выпустить сертификаты на все RDSH хосты из вашего внутреннего Active Directory CA, если он есть, не все его устанавливают
2️⃣Заказать внешний Wildcard сертификат на домен от внешнего CA, что проще на мой взгляд

У меня уже есть такой сертификат в формате PFX. Задача у нас такая, нам нужно на всех участниках RDS фермы поменять самоподписный сертификат на новый. Алгоритм тут такой:

1️⃣Вы устанавливаете на нужные хосты PFX сертификат в локальное хранилище компьютера
2️⃣Проверяете текущий отпечаток сертификата, что используется для RDP сессий
3️⃣Подменяете сертификат на новый
4️⃣Проверяете, что теперь используется новый сертификат

Установка PFX архива дело тривиальное

Установка pfx

В результате у вас в контейнере личное, будет ваш сертификат.

Контейнер личные сертификаты

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

# Задаем переменные
$sourceCert=»\TS102.pyatilistnik.orgTempnew.pfx» #Тут лежит pfx сертификат
$certPassword=ConvertTo-SecureString «1234436» -AsPlainText -Force #Пароль для доступа к сертификату
$servers=Get-Content «c:Tempterm.txt» #Файл со списком серверов

# Функция для копирования сертификата на удаленные серверы перед доступом к WinRM для их применения.
function copyCertsToServers{
$servers |%{Copy-Item $sourceCert -Destination «\$_`c$Temp»} # Кладу в папку C:Temp
}
copyCertsToServers;

# Установка сертификата на удаленных машинах
$servers | %{ Invoke-Command -ComputerName $_ -ScriptBlock {
param($x)
$env:computername;
Import-PfxCertificate -CertStoreLocation Cert:LocalMachineMy -FilePath «C:Tempnew.pfx» -Password $x;
} -ArgumentList $certPassword
}

Удаленная установка сертификата на сервер

Запустите теперь PowerShell ISE в режиме администратора. Введите команду, чтобы посмотреть текущие настройки сертификата для RDP.

Get-WmiObject «Win32_TSGeneralSetting» -Namespace rootcimv2terminalservices -Filter «TerminalName=’RDP-tcp'»

Нас будет интересовать поле SSLCertificateSHA1Hash, тут будет отпечаток самоподписного сертификата.

SSLCertificateSHA1Hash

Теперь выясните отпечаток вашего Wildcard сертификата. После этого выполните команду.

$path = (Get-WmiObject «Win32_TSGeneralSetting» -Namespace rootcimv2terminalservices -Filter «TerminalName=’RDP-tcp'»).__path
Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash=»3a9ba2991ca444779cdbac42126c3c4adcaf122c»}

Замена сертификата RDP

Теперь у вас будет все отлично, с подключением по RDP к данному участнику RDS фермы и ошибка 0x907 пропадет.

Смена клиента RDP в Windows

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

Remote Desktop Connection Manager
Подключение к удаленному рабочему столу Windows через магазинное приложение

Открытие приложения Удаленный рабочий стол (Майкрософт)

Диагностика и устранение ошибки для MacOS клиентов

Пользователи Windows не одиноки, ошибку 0x907 вы можете встретить и в MacOS. После обновления RD Client до 10.3.0 так же стала отображаться ошибка 0x907, когда я хочу подключиться по RDP. На предыдущей версии RD Client все работало.

0x907 в MacOS

Как я и написал все началось с версии 10.3.0. Тут вы можете либо откатиться на предыдущую версию или поставить более свежую бетта версию. Я за второй вариант. Перейдите по ссылке:

https://install.appcenter.ms/orgs/rdmacios-k2vy/apps/microsoft-remote-desktop-for-mac/distribution_groups/all-users-of-microsoft-remote-desktop-for-mac

Как видите уже есть версия Version 10.8.0 (2032). Установите ее и будет вам счастье.

Microsoft Remote Desktop Beta for macOS

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

Источник

Вопрос
И так, имеем RDS + шлюз + балансировщик нагрузки + WebClient

Скачивании RDP файла подключение происходит успешно, но вот если подключаться через WebClient выдаёт вот такое вот странное сообщение:

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

Кто то помнит это?

awefawef

Все ответы

Привет. Вы импортировали сертификат через Import-RDWebClientBrokerCert ?

Доверие в цепочке сертификатов есть ?

Коммерческий/Самоподписанный ?
Привет. Вы импортировали сертификат через Import-RDWebClientBrokerCert ?

Доверие в цепочке сертификатов есть ?

Коммерческий/Самоподписанный ?

1. Да

2. Конечно, это сертификат полученный от GlobalSign Root CA

3. Коммерческий.

При этом RDP файл скаченный успешно подключается через шлюз, проблема проявляется только в HTML5 WibClient….

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

awefawef
Балансировщик у вас настроен по L4 или L7?
Хороший вопрос.

Но вот тут я не очень понял какое отношение имеет модель ISO уровни транспорта и апликейшена к балансировщику нагрузки….

Или L4 c L7 это что то ещё, что я не знаю?

awefawef
Балансировщиком штатным в Windows Server 2019

awefawef
- Изменено
  
  5 сентября 2021 г. 10:43
Хороший вопрос.

Но вот тут я не очень понял какое отношение имеет модель ISO уровни транспорта и апликейшена к балансировщику нагрузки….

Или L4 c L7 это что то ещё, что я не знаю?

awefawef

L4 — это TCP, L7 — это https — в этом случае TLS соединение терминируется на балансировщике и сертификат нужно поменять и там.
L4 — это TCP, L7 — это https — в этом случае TLS соединение терминируется на балансировщике и сертификат нужно поменять и там.

Ну я бы согласился, если бы была такая возможность.

Но не могу, потому что сертификат выдан на *.domainname.ru а подключение происходит именно на этот домен и подключается успешно на первой фазе — это значит, что сертификат верный.

Т. е. при заходе на https://srdw.domainname.ru:4443/RDWeb/WebClient/ — сертификат именно этот он же коммерческий, он же доверенный.

А вот далее при попытке инициализировать в HTML5 опубликованное приложение выдаёт ошибку (см. скриншот в первом сообщении).

При этом же если скачать RDP файл — всё подключается без каких либо уведомлений и недоразумений.

awefawef
srdw — это сам терминальный сервер ?

Покажите вывод команд( Не прячьте настоящие имена, домен уже Ваш известен ):

Import-Module C:WindowsSystem32ServerManagerInternalRDManagementRDManagement.psd1

Get-RDServer

Get-RDCertificate

Get-RDWebClientBrokerCert

Покажите вывод команд( Не прячьте настоящие имена, домен уже Ваш известен ):

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

Get-RDServer

Server                                             Roles
------                                             -----
OL-RDS01.OPT-LOG.LOCAL                             {RDS-CONNECTION-BROKER, RDS-WEB-ACCESS, RDS-GATEWAY, RDS-LICENSING}
ol-ts03.opt-log.local                              {RDS-RD-SERVER}
ol-ts04.opt-log.local                              {RDS-RD-SERVER}
ol-ts05.opt-log.local                              {RDS-RD-SERVER}
ol-ts06.opt-log.local                              {RDS-RD-SERVER}
OL-TS01.opt-log.local                              {RDS-RD-SERVER}
OL-TS02.opt-log.local                              {RDS-RD-SERVER}

Get-RDCertificate

Role          Level          ExpiresOn                           IssuedTo
----          -----          ---------                           --------
RDRedirector  Доверенный     09/10/2022 11:02:32                 CN=*.optimalog.ru
RDPublishing  Доверенный     09/10/2022 11:02:32                 CN=*.optimalog.ru
RDWebAccess   Доверенный     09/10/2022 11:02:32                 CN=*.optimalog.ru
RDGateway     Доверенный     09/10/2022 11:02:32                 CN=*.optimalog.ru

Get-RDWebClientBrokerCert

Thumbprint                                Subject
----------                                -------
17C183443AC868F09908BE6E3336D2AFB6A0AEE5  CN=*.optimalog.ru

awefawef

А чего в браузере пишите ?
Не понял вопроса.

Я в браузере ничего не пишу.

Я в браузере пытаюсь открыть опубликованное приложение.

Или имеется в виду -«Почему я пишу в браузере используя этот форму?» ?

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

redirectclipboard:i:1
redirectprinters:i:1
redirectcomports:i:1
redirectsmartcards:i:1
devicestoredirect:s:
drivestoredirect:s:
session bpp:i:32
prompt for credentials on client:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:1
gatewayusagemethod:i:1
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:rds.optimalog.ru
gatewayhostname:s:srdw.optimalog.ru:4443
workspace id:s:ol-rds01.opt-log.local
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.OptimaLog
use multimon:i:1
alternate full address:s:rds.optimalog.ru

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

awefawef

Куда ведет запись rds.optimalog.ru ? Это случаем не Round Robin DNS типа «А» на все RDSH(ol-ts) ?

srdw.optimalog.ru — это OL-RDS01.OPT-LOG.LOCAL ?
- Изменено
  Андрей Михалевский
  6 сентября 2021 г. 12:03

Да.

OL-RDS01.OPT-LOG.LOCAL                             {RDS-CONNECTION-BROKER, RDS-WEB-ACCESS, RDS-GATEWAY, RDS-LICENSING}

На него проброшен TCP 4443

awefawef

А это не правильно. И соответственно от брокера толку мало. Ошибка дизайна. От того предупреждение в сертификате, что RDSH не знает о нем.

У Вас не должен пользователь заходить на днс записи об RDSH сервера.

А если у Вас тысячи терминальных серверов ? Будете каждый раз делать новую запись типа «А» ? А как будете следить ? Вся идеология брокера в том, что он управляет RDSH серверами и через себя прозрачно проксирует.

Пользователь заходит на брокер( Через ярлык скачанный на RDWEB ), а брокер балансирует между серверами в коллекции. Брокер перенаправляет благодаря уникальным строчкам в rdp:
```
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.OptimaLog
```
— Я поднял терминальный сервер через быстрый запуск со всеми ролями, поставил wildcard сертификат и у меня такой проблемы как у Вас нет, от того понял, что где-то у Вас не чисто.

Попробуйте применить команду на брокере:

Set-RDSessionCollectionConfiguration -CollectionName «OptimaLog» -CustomRdpProperty «full address:s:srdw.optimalog.ru» -ConnectionBroker OL-RDS01.OPT-LOG.LOCAL

— После проверьте подключение через вэб клиент.

А теперь вообще и по скачанному RDP файлу не подключается и по WEB.

Это фиаско 🙂 Вопрос, что теперь вернуть назад?! 🙂

redirectclipboard:i:1
redirectprinters:i:1
redirectcomports:i:1
redirectsmartcards:i:1
devicestoredirect:s:
drivestoredirect:s:
session bpp:i:32
prompt for credentials on client:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:1
gatewayusagemethod:i:1
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:srdw.optimalog.ru
gatewayhostname:s:srdw.optimalog.ru
workspace id:s:ol-rds01.opt-log.local
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.OptimaLog
use multimon:i:1
alternate full address:s:srdw.optimalog.ru

awefawef

А так ?

Set-RDSessionCollectionConfiguration -CollectionName «OptimaLog» -CustomRdpProperty «gatewayhostname:s:srdw.optimalog.ru:4443 `n full address:s:srdw.optimalog.ru» -ConnectionBroker OL-RDS01.OPT-LOG.LOCAL

Вы из внешки сразу тестируете ? Я забыл указать шлюз. А так, из локалки всё должно было работать.

Дайте уточнения:

srdw.optimalog.ru — ведет в IP брокера ?

В коллекции OptimaLog все RDSH сервера ?
- Изменено
  Андрей Михалевский
  6 сентября 2021 г. 13:21
srdw.optimalog.ru — резолвится в 178.57.80.106 в внешнем мире и в внутренний IP брокера, если в внутренней сети.

В коллекции OptimaLog все RDSH сервера ? — нет, не все. У нас всего три коллекции и в этом коллекции просто большинство серверов.

awefawef
Ну и HTML5 тоже ниалё вообще.

А вот rds.optimalog.ru резолвится как раз уже во все внутренние IP адреса всех rdp серверов.

И в том дизайне, что мы используем — всё работает у всех клиентов. А вот у этого проблема с сертификатов и только в HTML5…

В общем вопрос остаётся открытым 🙂

awefawef
На внутреннем DNS сервере, создайте зону прям srdw.optimalog.ru

В ней создайте пустую «А» запись в IP брокера. Или создайте запись srdw.optimalog.ru
типа «А» в IP адрес брокера, если у Вас уже есть зона optimalog.ru

В политиках шлюза поставьте пока:

Разрешить подключение пользователей к любому сетевому ресурсу

Убедитесь, что в коллекции OptimaLog добавлены Пользователи домена.
- Изменено
  Андрей Михалевский
  6 сентября 2021 г. 13:38
А так ?

Set-RDSessionCollectionConfiguration -CollectionName «OptimaLog» -CustomRdpProperty «gatewayhostname:s:srdw.optimalog.ru:4443 `n full address:s:srdw.optimalog.ru» -ConnectionBroker OL-RDS01.OPT-LOG.LOCAL

Так тот же эффект. Не работает.

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

Ну и прикрутить WebClient всего 5 минут делов например как вот тут описано: https://winitpro.ru/index.php/2018/10/30/rdp-web-client-html5-na-windows-rds/

awefawef
А так ?

Set-RDSessionCollectionConfiguration -CollectionName «OptimaLog» -CustomRdpProperty «gatewayhostname:s:srdw.optimalog.ru:4443 `n full address:s:srdw.optimalog.ru» -ConnectionBroker OL-RDS01.OPT-LOG.LOCAL

Так тот же эффект. Не работает.

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

Ну и прикрутить WebClient всего 5 минут делов например как вот тут описано: https://winitpro.ru/index.php/2018/10/30/rdp-web-client-html5-na-windows-rds/

awefawef

Почему не работает, всё понятно. Делайте как я говорю. У Вас ошибка в дизайне. Выше смотрите мое сообщение.
А это не правильно. И соответственно от брокера толку мало. Ошибка дизайна. От того предупреждение в сертификате, что RDSH не знает о нем.

У Вас не должен пользователь заходить на днс записи об RDSH сервера.

Мне всё ясно, только не ясно как керосин по проводам течёт 🙂

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

Вами предложенный дизайн мне знаком, когда используется один сервер RDP, на нём же брокер, на нём же шлюз….. Но вот если серверов больше чем один и брокер с шлюзом выделен отдельно — то надо использовать тот дизайн
как у нас. И этот же дизайн если резервировать двумя и более шлюзами/брокерами систему…

Но вот именно «тут и сейчас» что то не так и я не могу понять что именно.

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

awefawef
А это не правильно. И соответственно от брокера толку мало. Ошибка дизайна. От того предупреждение в сертификате, что RDSH не знает о нем.

У Вас не должен пользователь заходить на днс записи об RDSH сервера.

Мне всё ясно, только не ясно как керосин по проводам течёт 🙂

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

Вами предложенный дизайн мне знаком, когда используется один сервер RDP, на нём же брокер, на нём же шлюз….. Но вот если серверов больше чем один и брокер с шлюзом выделен отдельно — то надо использовать тот дизайн
как у нас. И этот же дизайн если резервировать двумя и более шлюзами/брокерами систему…

Но вот именно «тут и сейчас» что то не так и я не могу понять что именно.

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

awefawef

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

Remote Desktop Connection Broke

Remote Desktop Connection Broker (RD Connection Broker) manages incoming remote desktop connections to RD Session Host server
farms. RD Connection Broker handles connections to both collections of full desktops and collections of remote apps. RD Connection Broker can balance the load across the collection’s servers when making new connections. If
RD Connection Broker is enabled, using DNS round robin to RD Session Hosts for balacing servers is not supported. If a session disconnects, RD Connection Broker will reconnect the user to the correct RD Session Host server and their
interrupted session, which still exists in the RD Session Host farm.

Надеюсь это Вам даст понять, что сейчас у Вас сделано не правильно, хоть и работает. Я же Вам хочу помочь переделать,
так, как это должно работать правильно.

Вы можете на этом остановиться, вот будет Ваша команда для отката:

Set-RDSessionCollectionConfiguration -CollectionName «OptimaLog» -CustomRdpProperty «gatewayhostname:s:srdw.optimalog.ru:4443 `n full address:s:rds.optimalog.ru» -ConnectionBroker OL-RDS01.OPT-LOG.LOCAL

или продолжить попытки.

С учетом Вашей топологии я вижу правильную работу:

У Вас есть:

Брокер: OL-RDS01.OPT-LOG.LOCAL

Терминальные сервера:

ol-ts03.opt-log.local
ol-ts04.opt-log.local
ol-ts05.opt-log.local
ol-ts06.opt-log.local
OL-TS01.opt-log.local
OL-TS02.opt-log.local

— Они должны быть включены в коллекции на брокере. Сейчас я вижу одну коллекцию OptimaLog.

Изначально у Вас было:
```
full address:s:rds.optimalog.ru
gatewayhostname:s:srdw.optimalog.ru:4443
workspace id:s:ol-rds01.opt-log.local
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.OptimaLog
use multimon:i:1
alternate full address:s:rds.optimalog.ru
```
Как мы выяснили, srdw.optimalog.ru это тот самый брокер. Это внешняя DNS запись, разрешающая во внешний IP адрес Вашего роутера. Далее Вы делаете Port Forwarding на внутренний IP адрес брокера, где так же шлюз, с портом 4443.

Когда Вы подключаетесь по ярлыку, шлюз видит, что Вы пытаетесь зайти на rds.optimalog.ru и далее DNS RR с помощью шлюза Вас перенаправляет.

— Я же хочу донести, что Вам нужно заходить через брокер, который сам сбалансирует на терминальные сервера в коллекции. Выше я объяснил, что заходить на RDSH по DNS RR не верно. У Вас начнутся проблемы как минимум
с кэшем DNS на клиентах, если один RDSH упадет, или просто запретите доступ через режим обслуживания, клиенты все равно будут туда ломиться. Вы не можете полноценно это контролировать так, как делает это брокер.

Значит в RDP файлике должно быть:
```
full address:s:srdw.optimalog.ru
gatewayhostname:s:srdw.optimalog.ru:4443
workspace id:s:ol-rds01.opt-log.local
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.OptimaLog
use multimon:i:1
alternate full address:s:rds.optimalog.ru
```
Чего мы и добились с помощью команды:

Set-RDSessionCollectionConfiguration -CollectionName «OptimaLog» -CustomRdpProperty «gatewayhostname:s:srdw.optimalog.ru:4443
`n full address:s:srdw.optimalog.ru» -ConnectionBroker OL-RDS01.OPT-LOG.LOCAL

Теперь когда пользователь заходит, шлюз видит, что Вы пытаетесь зайти на srdw.optimalog.ru и шлюз Вас успешно туда отправляет,
а дальше брокер редеректит на терминальные сервера коллекции OptimaLog.
Но, чтоб шлюз Вас отправил на srdw.optimalog.ru, у Вас так же на внутреннем DNS сервере должна быть запись
типа «А». Например:

srdw.optimalog.ru 172.16.0.5 предположим это IP Вашего брокера.
- Изменено
  Андрей Михалевский
  6 сентября 2021 г. 14:27
Всё как бы ОК — но!!!

Я где то там выше уже писал, что srdw.optimalog.ru на внутреннем DNS реально резолвится в внутренний IP самого брокера.

Но на брокере не установлена служба удалённых рабочих столов и именно по этому шлёт он меня в пешую эротическую.

Если брокер установлен на одном из TS (и тем более когда всего один сервер) — то всё ок.
```
Set-RDSessionCollectionConfiguration -CollectionName "OptimaLog" -CustomRdpProperty "gatewayhostname:s:srdw.optimalog.ru:4443 `n full address:s:srdw.optimalog.ru" -ConnectionBroker OL-RDS01.OPT-LOG.LOCAL
```
Это я уже давно сделал, только у меня имя коллекции без кавычек проходит ибо нет пробелов и после `n я пробел не ставлю ибо так тоже не корректно формируется набор команд т. к. строка следующая начинается с пробела….

Или предлагаете установить службу удалённых рабочих столов и на брокере?

если да — то как добиться, что бы никакие сессии никогда на нём пользовательские не создавались?

Вот компоненты установленные на сервере с брокером
- Изменено
  Ivan V. Goverdovskiy
  6 сентября 2021 г. 14:55
Но на брокере не установлена служба удалённых рабочих столов и именно по этому шлёт он меня в пешую эротическую.

— Брокеру не нужна служба удаленных рабочих столов.

Если брокер установлен на одном из TS (и тем более когда всего один сервер) — то всё ок.

— Не нужно ставить брокер на TS.

— Брокер принимает подключение пользователя, а дальше перенаправляет согласно коллекции в RDP файле.
```
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.OptimaLog
```
— Пользовательские сессии на брокере ни как не создадутся, Вы разве можете пользователем домена зайти по умолчанию на
какой-либо сервер ? Нет. Конечно мы не говорим о ручном добавлении в группу «Пользователи удаленного рабочего стола».

— Брокер это посредник, он видит, что к нему идет соединение и относительно коллекции в RDP файле перенаправляет на другой RDSH сервер
коллекции. Иначе он просто отбросит соединение и Вы увидите знакомую картинку:

! Еще раз.

1) Убедитесь, что в коллекции есть RDSH сервера. В ее группе добавлены пользователи домена.

2) У Вас применен командлет:
```
Set-RDSessionCollectionConfiguration -CollectionName "OptimaLog" -CustomRdpProperty "gatewayhostname:s:srdw.optimalog.ru:4443 `n full address:s:srdw.optimalog.ru" -ConnectionBroker OL-RDS01.OPT-LOG.LOCAL
```
Чтоб изменить параметры gatewayhostname и full address, он так же поменяет alternate full address.

OptimaLog — имя коллекции на брокере.

3. На шлюзе в политиках стоит: Разрешить подключение пользователей к любому сетевому ресурсу

4. На внешнем DNS сервере запись srdw.optimalog.ru ведет на внешний адрес Вашего роутера. На внутреннем DNS сервере,
запись srdw.optimalog.ru ведет на IP адрес брокера.

— Если так не работает, покажите скрины с настройками всех пунктов и адресацией.

UPD: С компонентами брокера у Вас всё правильно.
- Изменено
  Андрей Михалевский
  6 сентября 2021 г. 15:03
1) Убедитесь, что в коллекции есть RDSH сервера. В ее группе добавлены пользователи домена.
2) У Вас применен командлет:
```
Set-RDSessionCollectionConfiguration -CollectionName "OptimaLog" -CustomRdpProperty "gatewayhostname:s:srdw.optimalog.ru:4443 `n full address:s:srdw.optimalog.ru" -ConnectionBroker OL-RDS01.OPT-LOG.LOCAL
```
Чтоб изменить параметры gatewayhostname и full address, он так же поменяет alternate full address.

OptimaLog — имя коллекции на брокере.
Команду выполнил.

Вот что в RDP файле:
```
redirectclipboard:i:1
redirectprinters:i:1
redirectcomports:i:1
redirectsmartcards:i:1
devicestoredirect:s:
drivestoredirect:s:
session bpp:i:32
prompt for credentials on client:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:1
gatewayusagemethod:i:1
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:srdw.optimalog.ru
gatewayhostname:s:srdw.optimalog.ru:4443 
workspace id:s:ol-rds01.opt-log.local
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.OptimaLog
use multimon:i:1
alternate full address:s:srdw.optimalog.ru
```
3. На шлюзе в политиках стоит: Разрешить подключение пользователей к любому сетевому
ресурсу

4. На внешнем DNS сервере запись srdw.optimalog.ru ведет на внешний адрес Вашего роутера.
На внутреннем DNS сервере, запись srdw.optimalog.ru ведет на IP адрес брокера.

— Если так не работает, покажите скрины с настройками всех пунктов и адресацией.
```
Обмен пакетами с swrdw.optimalog.ru [81.200.118.204] с 32 байтами данных:
```
```
Обмен пакетами с swrdw.optimalog.ru [192.168.*.*] с 32 байтами данных:
```
===========================================

Подключение не происходит ни в HTML5 ни в RDP клиенте по ярлыку (.rdp файлу)
- Изменено
  Ivan V. Goverdovskiy
  6 сентября 2021 г. 16:52
Так как у Вас настроены политики на шлюзе, соединение через ДНС не заработает. Для теста разрешите все, как я сказал, поставьте нижний чекбокс. Предпоследний скрин.

Все остальное выглядит нормально.

И опять же, я бы согласился, но не работает так:

redirectclipboard:i:1
redirectprinters:i:1
redirectcomports:i:1
redirectsmartcards:i:1
devicestoredirect:s:
drivestoredirect:s:
session bpp:i:32
prompt for credentials on client:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:1
gatewayusagemethod:i:1
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:srdw.optimalog.ru
gatewayhostname:s:srdw.optimalog.ru:4443 
workspace id:s:ol-rds01.opt-log.local
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.OptimaLog
use multimon:i:1
alternate full address:s:srdw.optimalog.ru

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

awefawef

Это лишь значит, что шлюз не пропускает.

У Вас нет возможности в сети или по VPN проверить, пока без шлюза ?

Если нет, Вы не показали политики авторизации подключений.

Там так же пока что нужно установить: : Разрешить подключение пользователей к любому сетевому ресурсу.

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

— Потому что изначально нужно было правильно настраивать.

Вот Вам самая правильная статья на будущее(Но сначала это добьем ): https://www.google.com/amp/s/alekssh.com/2014/09/02/rds-planning/amp/
- Изменено
  Андрей Михалевский
  6 сентября 2021 г. 20:05
Из локальной сети есть возможность подключаться.

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

А вот так выглядит файл RDP:
```
redirectclipboard:i:1
redirectprinters:i:1
redirectcomports:i:1
redirectsmartcards:i:1
devicestoredirect:s:
drivestoredirect:s:
session bpp:i:32
prompt for credentials on client:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:1
gatewayusagemethod:i:1
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:srdw.optimalog.ru
gatewayhostname:s:srdw.optimalog.ru:4443 
workspace id:s:ol-rds01.opt-log.local
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.OptimaLog
use multimon:i:1
alternate full address:s:srdw.optimalog.ru
```
Ссылка https://www.google.com/amp/s/alekssh.com/2014/09/02/rds-planning/amp/ редиректит на https://alekssh.com/2014/09/02/rds-planning/
и не открывается.

На тему утверждения -«Потому что изначально нужно было правильно настраивать.»

звучит как «Раз изначально настроено всё не корректно то теперь ничего исправить не возможно и надо всё сносить и настраивать
с нуля корректно и только тогда всё будет работать.

Я считаю такое утверждение в корне не верным.

Даже если что то и было настроено не корректно — то всегда можно исправить.

Мало того, я не видел ни разу что бы по вашей схеме работало хоть у кого то. При этом я видел множество статей где описывается
такая схема и там же сказано что так оно не работает и единственный вариант это именно использование механизма за шлюзом DNS RR. Т. е. создание одного хоста с множество A-record на все RDP сервера.

Попробуйте в своей тестовой среде реально настроить именно с доступом из внешнего мира и именно с вашими
решениями. Проверить заработает у вас или нет, я держу пари что не заработает. И единственный вариант что бы заработало, это на тот же Windows Server где установлен брокер + шлюз поставить и службу удалённых рабочих столов (сессии). Тогда всё будет
работать ибо запрос будет прилетать на эту службу, а дальше перенаправляться на один из менее загруженных серверов. И никак иначе к меня даже на курсах MS не поднялось на все утверждения тичера. В итоге сошлись на том, что сейчас некогда
с этим разбираться и он посмотрит потом почему не взлетает, но и «потом» это не случилось.
Из чего я сделал для себя однозначный вывод, что документация от вендора не верная и надо делать так, как я и делал всегда.

awefawef
Из локальной сети есть возможность подключаться.

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

— Речь изначально была, чтоб исправить проблему ошибки сертификата.

Но это и логично потому что он тоже является доверенным, а балансировщий судя по всему редиректит на внутреннее имя сервера, а не srdw…..

— Объясните подробней, какой балансировщик. И как он балансирует. На какое имя и как Вы понимаете в этой схеме srdw.

Сайт тот часто падает, можно в кэше посмотреть: Шаг 0. Исходные данные. Схема
решения.

звучит как «Раз изначально настроено всё не корректно то теперь ничего исправить не возможно и надо всё сносить и настраивать с нуля корректно и только тогда всё будет работать.

— Не знаю, как у Вас там это звучит, но второй день я бы не пытался Вам помочь, объясняя, как это должно работать и что в Вашей схеме нужно изменить. Я ни где не сказал, что Вам нужно всё удалить и переделать. Я говорю, что
нужно изменить в имеющейся схеме.

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

— Посмотрите эти темы:

Вход в терминальную коллекцию

Настройка терминальной фермы 2019. Не понимаю базовых вещей

Проблема у пользователя в системе RDS

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

Мало того, я не видел ни разу что бы по вашей схеме работало хоть у кого то. При этом я видел множество статей где описывается такая схема и там же сказано что так оно не работает и единственный вариант это именно использование
механизма за шлюзом DNS RR. Т. е. создание одного хоста с множество A-record на все RDP сервера.

— А так криво да косо у большинства и работает. Потому что все бегут в гугл и видят первую ссылку на winitpro. А чтоб детально изучить тему согласно с документацией вендора, вот люди почему-то не могут. Отлабить, посмотреть
как оно действительно должно работать и потом уже пустить в прод.

А потом бегут сюда с проблемами. Поищите здесь на форуме темы с ключевым словом RDS или Терминальный
сервер.

И вот Вы тот же случай, отрицаете и не принимаете простые, логические вещи, потому что у Вас не получается это настроить, Вас
на курсах MS не обучили и я не сомневаюсь, что курс был — прочитал слайды, а дальше сами. единственный
вариант это именно использование механизма за шлюзом DNS RR. Т. е. создание одного хоста с множество A-record на все RDP сервера.

— Поймите, шлюз ну ни как к ферме прямого отношения не имеет. Это средство безопасного подключения к любым
ресурсам сети, вот и всё. Вы можете через него подключаться к любым компьютерам в сети, конечно как Вы настроите предварительно RAP и CAP.

Про DNS я Вам объяснял. Ну не делают так. Ваш брокер не играет тогда ни какой роли.

Вы
понимаете алгоритм, который я Вам пытаюсь объяснить второй день ? Сейчас Вы его не используете, Вы прямо заходите на терминальные сервера в обиход брокера. У Вас сразу здесь пункт 7.

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

— Как бы я не пытался Вам объяснить, что в конце концов, нужно заходить
через брокер, который балансирует и шлюз не имеет прямого отношения к нему, Вы понимать отказываетесь. Пари из-за Вашего ЭГО я бесплатно заключать не буду. Но если хотите, за деньги я всё соберу. Хотя ссылку я Вам дал в кэше,
где всё сделано правильно, как я Вам и объясняю.. Или Вы и там будете отрицать, что у автора это не работает ?

Из чего я сделал для себя однозначный вывод, что документация от
вендора не верная и надо делать так, как я и делал всегда.

— Не верный вывод. Если Вам не достаточно моих утверждений, схемы
с сайта alekssh, я предлагаю задать Ваш вопрос на форуме technet QA и подождать ответ от какого-нибудь MVP и Вы удивитесь,
что Вам скажут всё то же самое, что и я.

Дальше по Вашему тексту я уже дал исчерпывающие объяснения.

Поймите, я не пытаюсь Вас принизить в чем-то, что я думаю Вам и кажется, так как Вы явно уперто стоите на своем. Чего-то не знатьне понимать это нормально,
для этого мы здесь и обмениваемся помощью, но я Вам точно говорю, что сейчас Ваша схема технически не правильная, хоть и рабочая. Но от того проблемы Вас сюда и привели.
- Изменено
  Андрей Михалевский
  7 сентября 2021 г. 9:47
Я всё прекрасно понимаю, что вы хотите донести.

Мало того, я не отрицаю что именно так написано в документации вендора.

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

По факту всё что пытались с вами делать, всё приводило только к тому, что подключиться к серверам коллекций было вообще не возможно, а как только я возвращал хост rds.optimalog.ru — подключение проходило успешно.

Из всего этого можно сделать выводы:

1. Пытаться указывать full address:s:srdw.optimalog.ru (это адрес брокера) — не верно в целом

2. В текущей конфигурации надо что то ещё изменить.

И вот тут я могу с уверенностью на 100% сказать, что если на этом же Windows Server на котором установлен брокер + шлюз поднять службу удалённых рабочих столов, то ваша схема будет рабочей на 100%. Но пока этой службы нет
на нём — подключиться будет не возможно. На тех же курсах я это продемонстрировал от чего вся аудитория была немного в шоке ибо это шло в разрез с документацией вендора.

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

В целом я то могу просто взять и доустановить её и вопрос как бы будет закрыт — но это «Не наш метод».

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

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

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

— В данной момент у меня так и реализовано и не в одной компании. Так как пришлось плотно заниматься фермами последние два года.

И в целом то уже на сейчас проблема с сертификатом отсутствует и всё по ярлыку подключается сохранённому без
ошибок.

— Поделитесь решением.

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

Сделайте на шлюзе доступ ко всем ресурсам. Переключив чекбокс о котором я говорил в обеих политиках. Попробуйте вне сети подключиться к любому ПК с помощью шлюза, если
заработает, значит правильно RAP и CAP пропускает соединение. Потом решим проблему конфигурации.
Сделайте на шлюзе доступ ко всем ресурсам. Переключив чекбокс о котором я говорил в обеих политиках. Попробуйте вне сети подключиться к любому ПК с помощью шлюза, если заработает,
значит правильно RAP и CAP пропускает соединение. Потом решим проблему конфигурации.

Уже сделано давно.

Да, подключаюсь без проблем к любому АРМ (да и ранее подключался ибо политик у нас 3 разных).

Сейчас специально проверил ещё раз.

Но как только я выполняю команду:
```
Set-RDSessionCollectionConfiguration -CollectionName OptimaLog -CustomRdpProperty "gatewayhostname:s:srdw.optimalog.ru:4443 `nfull address:s:srdw.optimalog.ru" -ConnectionBroker OL-RDS01.OPT-LOG.LOCAL
```
То:

1. Через WebClient подключение проходит успешно.

2. Через ярлык (загруженный RDP файл) подключение не происходит:
```
redirectclipboard:i:1
redirectprinters:i:1
redirectcomports:i:1
redirectsmartcards:i:1
devicestoredirect:s:
drivestoredirect:s:
session bpp:i:32
prompt for credentials on client:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:1
gatewayusagemethod:i:1
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:srdw.optimalog.ru
gatewayhostname:s:srdw.optimalog.ru:4443 
workspace id:s:ol-rds01.opt-log.local
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.OptimaLog
use multimon:i:1
alternate full address:s:srdw.optimalog.ru
```
И меня смущает, что отображается, что идёт подключение к ol-rds01.opt-log.local, а не srdw.optimalog.ru.
- Изменено
  Ivan V. Goverdovskiy
  7 сентября 2021 г. 12:24
___________________________________________________________________

И так, я создал лабу и нашел проблему в DNS, из-за чего у Вас думаю не подключалось. Но об этом чуть позже.

_________________________________________________________________________________________

1. Схема.

ADDS.oilservice.local — 192.168.1.50

RDCB01.oilservice.local — 192.168.1.51

RDS01.oilservice.local — 192.168.1.52

RDS02.oilservice.local — 192.168.1.53

RDCB01.oilservice.group — 95.31.39.130 — Запись на внешнем DNS хостинге nic.ru.

https://rdcb01.oilservice.group/RDWeb/Pages/en-US/default.aspx

https://rdcb01.oilservice.group/RDWeb/webclient/

2. Роли:

3. Я захожу на WebClient и вижу проблему как у Вас.

— После применения:
```
Set-RDSessionCollectionConfiguration -CollectionName "RD" -CustomRdpProperty "full address:s:RDS.oilservice.group" -ConnectionBroker RDCB01.oilservice.local
```
Нет ни каких проблем. Так как имя сервера и сертификата теперь совпадают. Так же потребовалось создать зону oilservice.group и создать там запись типа «А» в IP брокера. RDS.oilservice.group.

4. Пробросы порта 443. 3391 — для работы RDP по UDP протоколу.

— Клиент заходит на брокер. Брокер смотрит какая коллекция:
```
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.RD
```
И перенаправляет на RDSH. Ни каких балансировок RR, посредством добавления множеств RDSH в одну запись нет.

— Как видите, всё работает.

Это лаба, сделаны с этого момента снапшоты. Логин administrator@oilservice.local, пароль: Sam@1245

Можете изучить.

! До этого у меня всегда совпадало имя внутреннего домена и внешнего, а тут для лабы я сделал разные, чтоб смоделировать ситуацию как у Вас. Внутренний oilservice.local и внешний oilservice.group. !

Когда я создал внешнюю и внутреннею запись RDS.oilservice.group и установив ее командлетом в качестве имени подключения, у меня RDGW перестал пускать. Такая же проблема как у Вас. По логам вижу отлупы, почему так,
я пока не знаю. Когда я удалил запись RDS.oilservice.group на внешнем хостинге, стало пускать. Такой проблемы нет, если внутренний и внешний домен одинаковые. С чем связано, пока затрудняюсь ответить. Как вариант, внутри сделать rds.optimalog.ru
в IP брокера(Его не должно быть во внешнем DNS) и прописать его в командлете выше.

— Вопросы ?
- Изменено
  Андрей Михалевский
  8 сентября 2021 г. 13:53
В целом то вопросов нет, я думаю вы как раз наткнулись на ту же проблему, что и мы.

У нас проброшен только 4443 порт (HTTPS) и порт 3991 в целом и не нужен (работает через шлюз всё прекрасно).

Что касается DNS RR — я так понимаю, вы думаете, что у нас на роутере есть множество net-map на разные a-record c белыми IP, но это не так.

У нас только один net-map и только TCP/4443 на тот самый брокер на котором же шлюз.

Исходя из этих вводных вы подтверждаете что у нас именно DNS RR используется для подключения из внешнего мира?

awefawef
Я говорю про то, что клиент должен заходить на брокер, а не на rdsh. Не важно, внешнее или внутренне.

Порт 3391 нужен для подключения по протоколу UDP.

https://habr.com/ru/post/501132/

Так что советую пробросить этот порт.
- Изменено
  Андрей Михалевский
  8 сентября 2021 г. 18:28
Ну для начала устанавливается соединение с шлюзом на на TCP/4443.

Вторым сервером указан у меня rds.optimalog.ru (на внутреннем DNS это множество a-record всех RDP серверов), а вы предполагаете, что если указать IP/DNS имя брокера, то подключение произойдёт успешно?

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

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

Я на курсе так же спорил с тичером и в итоге я смог доказать, что именно при такой схеме надо делать именно как я сделал ибо брокер сам по себе не принимает подключения и как следствие не перенаправляет никуда. Т.е.
по сути брокер и не должен принимать подключения вообще от слова совсем. Это не его функционал. Брокер только поддерживает связь с всеми rdp серверами. И подключение надо что бы клиент установил с любым одним живым
rdp сервером. Далее rdp сервер сообщает например что он слишком занят и есть более свободный тут рядом с таким то IP/DNS. И вот тогда клиент устанавливает новое соединение уже с новым rdp сервером. Но в случае работы
через шлюз, это всё делает шлюз. Если шлюза нет, то тогда сам клиент.

Я то это всё тестировал и на синтетической площадке и потом уже на курсах с тичером спорил и доказал. Попробуйте разверните синтетическую среду (точную копию где нет службы rdp на брокере с шлюзом) и получите я уверен в точности такой же
результат.

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

awefawef
Вы видимо так в это верите, что не хотите слышать что я говорю.

Выше это я реализовал и дал даже доступ.

Что с Вами не так ?) Почему Вы не хотите понять простых вещей.

Я же всё описал… На каком шаге Вам не понятно ? Давайте по порядку, по пунктам.

___________________

Вторым сервером указан у меня rds.optimalog.ru (на внутреннем DNS это множество a-record всех RDP серверов),
а вы предполагаете, что если указать IP/DNS имя брокера, то подключение произойдёт успешно?

— Да, это я Вам и объясняю второй день, что нужно заходить через брокер, а не DNS на множество RDSH.

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

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

— Вы читали пост, где я поднял лабу и даже дал доступ, чтоб продемонстрировать, что всё работает правильно через брокер, А Вы и Ваш тренер microsoft заблуждаетесь ?
- Изменено
  Андрей Михалевский
  9 сентября 2021 г. 6:55
Но я не оставляю надежду что я всё же не прав и тогда да, ибо та схема о которой вы говорите реально более разумная и надёжная. Тут спору нет.

awefawef

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

Вы просите помощи, но отказываетесь слушать.
— Вы читали пост, где я поднял лабу и даже дал доступ, чтоб продемонстрировать, что всё работает правильно через брокер, А Вы и Ваш
тренер microsoft заблуждаетесь ?

Из контекста я понял, что у вас в этой лабе так же не получилось подключиться при условии что Microsoft Domain не совпадает с Internet Domain.

Я верно понял?

awefawef
— Вы читали пост, где я поднял лабу и даже дал доступ, чтоб продемонстрировать, что всё работает правильно через брокер, А Вы и Ваш
тренер microsoft заблуждаетесь ?

Из контекста я понял, что у вас в этой лабе так же не получилось подключиться при условии что Microsoft Domain не совпадает с Internet Domain.

Я верно понял?

awefawef

— Да, rdwg почему-то отбрасывает соединение, если DNS запись одинаковая снаружи и внутри. Нужно наверно wireshark’ом посмотреть, что там прилетает и почему шлюз делает отлуп. И изучить логи. Хотя с одинаковыми доменами
такой проблемы. Это конкретно случай, почему у Вас вс1 же не завелось, так, как я говорил. Но алгоритм работы фермы и то, что я Вам пытаюсь объяснить, не меняет.
- Изменено
  Андрей Михалевский
  9 сентября 2021 г. 8:22
Скажем так, у меня ни разу за всю мою практику за примерно 20 лет, не было ни одного реального предприятия, где бы Microsoft Domain совпадал с Internet Domain…

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

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

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

awefawef

Источник

Ошибка сертификата при подключении rdp

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

Ответ

Отключение NLA для протокола RDP в Windows

Ошибка при подключении по RDP (Исправление шифрования CredSSP)

Настройка доверенных SSL/TLS сертификатов для защиты RDP подключений

Предупреждение о самоподписанном сертификате RDP

Создаем шаблон RDP сертификата в центре сертификации (CA)

Настройка групповой политики для выдачи RDP сертификатов

Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата

Устранение неполадок с подключениями к Удаленному рабочему столу

Проверка состояния протокола RDP

Проверка состояния протокола RDP на локальном компьютере

Проверка состояния протокола RDP на удаленном компьютере

Проверка блокировки объектом групповой политики протокола RDP на локальном компьютере

Проверка блокировки объектом групповой политики протокола RDP на удаленном компьютере

Изменение блокирующего объекта групповой политики

Проверка состояния служб RDP

Проверка состояния прослушивателя протокола RDP

Проверка состояния прослушивателя RDP

Проверка состояния самозаверяющего сертификата протокола RDP

Проверка разрешений для папки MachineKeys

Проверка порта прослушивателя протокола RDP

Проверка того, что другое приложение не пытается использовать тот же порт

Проверка блокировки порта протокола RDP брандмауэром

Устранение ошибки проверки подлинности RDP

Не удается проверить подлинность удаленного компьютера

Произошла ошибка проверки подлинности RDP. Указанная функция не поддерживается — Решение

В чем суть ошибки проверки подлинности RDP

Установка апдейта, если указанная функция не поддерживается

Изменение настроек групповых политик

Отключение NLA для решения ошибки проверки RPD

Заключение

Не удается проверить подлинность удаленного компьютера ошибка сертификата

Лучший отвечающий

Вопрос

Ответы

Все ответы

Настройка доверенных SSL/TLS сертификатов для защиты RDP подключений

Предупреждение о самоподписанном сертификате RDP

Создаем шаблон RDP сертификата в центре сертификации (CA)

Настройка групповой политики для выдачи RDP сертификатов

Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата

При подключении к серверу терминала, который работает Windows Server 2008 или Windows Server 2008 R2, вы получаете различные сообщения об ошибках, связанных с сертификатом.

Симптомы

Причина

Решение

Предупреждение о самоподписанном сертификате RDP

Создаем шаблон RDP сертификата в центре сертификации (CA)

Настройка групповой политики для выдачи RDP сертификатов

Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата

Диагностика ошибки 0x907

Диагностика и устранение ошибки для Windows клиентов

Смена клиента RDP в Windows

Диагностика и устранение ошибки для MacOS клиентов

Вопрос

Все ответы

А вот еще интересные материалы: