Проблема с сертификатом с RemoteApp на сервере 2008
Я пытаюсь настроить демонстрацию концепции для развертывания приложений через RemoteApp, то есть потоковую передачу приложений через RDP в Windows Server 2008.
Сервер шлюза TS (назовите его srv-web) и ящик, в котором размещены приложения (назовите его srv-app), - это два разных окна.
Соединения должны проходить через сервер шлюза служб терминалов по протоколу HTTPS, поскольку srv-app находится во внутренней локальной сети за NAT.
Только srv-web доступен в Интернете, и только порт 443 (HTTPS) открыт.
Если я проигнорирую / приму различные предупреждения, соединение будет работать отлично.
Цель здесь - сделать так, чтобы у наших клиентов все работало максимально гладко.
У меня есть сертификат SSL, установленный как на srv-web, так и на srv-app. srv-web настроен на его использование для шлюза TS, и это прекрасно работает. CN сертификата совпадает с внешним публичным именем хоста.
Предупреждение, которое я получаю, выглядит следующим образом (я изменил реальное имя хоста на скриншоте)
Полагаю, у меня вопрос: как выбрать SSL-сертификат, который srv-app использует для подтверждения своей личности подключающимся клиентам?
РЕДАКТИРОВАТЬ: Я нашел, где это установить - это в Конфигурация хоста сеанса удаленного рабочего стола -> Свойства RDP-Tcp, общая вкладка внизу.
Однако у меня есть другая проблема, как и ожидалось, теперь у меня несоответствующее имя сервера:
Я подозреваю, что это потребует где-то изменения топологии. Было бы здорово получить обратную связь от того, кто уже сделал это.
РЕДАКТИРОВАТЬ 2: Я работал над этим, установив следующий параметр в пользовательских настройках RDP.
authentication level:i:0
Однако это не удовлетворительное решение, так как просто отключает проверку. Я все еще буду признателен за дополнительные отзывы по этому поводу.
Большое спасибо.
Мне кажется, что вы пытаетесь подключиться к серверу, используя его «внутреннее имя», но вы выбрали сертификат, в котором указано «внешнее имя».
Если вы хотите, чтобы «внутреннее имя» работало «за брандмауэром», а ваш брандмауэр NAT не поддерживает «фиксированный NAT» (т. Е. NAT, отправляющий запрос, поступающий из интерфейса LAN обратно в интерфейс LAN), вы можете сделать следующее: классический «обман» создания DNS-зоны на ваших внутренних DNS-серверах с именем «publicname.ourdomain.com» с одной записью «@» в ней, которая содержит внутренний IP-адрес серверного компьютера.
Это похоже на «DNS с разделенным горизонтом», но ограничено одним именем (так что это не влияет на «нормальное» разрешение имен остальной части зоны «ourdomain.com»).
Я видел это в нашей собственной среде. Из того, что я вижу, RDP-соединение с туннелем через шлюз фактически будет использовать два набора сертификатов: сначала он зашифрует туннель между клиентом и шлюзом, а затем, во-вторых, между клиентом и сервером (хотя этот трафик уже находится внутри туннель, защищенный шлюзом). Это тоже сбило меня с толку, и я не нашел другого «правильного» способа сделать это, кроме как использовать два сертификата, один из которых соответствует внешнему имени вашего шлюза, а другой - внутреннему имени вашего TS-сервера. Пожалуйста, обновите эту ветку, если найдете что-нибудь!
перейдите в свойства rdp-tcp и выберите вкладку «Общие» -> и выберите внешний сертификат в нижней части листа свойств. Это позволит всем взаимодействовать на основе внешнего сертификата вместо несоответствия, когда rdp использует внутренний по умолчанию для самого сервера.
Настройка
authentication level:i:0
в пользовательских настройках RDP работает вокруг этой проблемы (как указано в моем вопросе)
Получите сертификат SAN с несколькими именами и локальными именами хостов или IP-адресами. Это будет отлично работать.
Если вы хотите исправить это, не снижая уровень авторизации, откройте Remote App Manager и нажмите «Изменить» рядом с «Параметры сервера узла сеансов удаленных рабочих столов». Убедитесь, что имя сервера параметров подключения имеет внешний DNS-сервер corerct. В том же диалоговом окне щелкните вкладку Цифровая подпись и установите правильный сертификат SSL.
Обратите внимание, что вам также необходимо настроить внешний сертификат в свойствах RDP-Tcp конфигурации узла сеанса, как опубликовано JT.