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

Сначала познакомимся с ролью Remore Gateway, затем перейдем к Web Client. Увидим как будет выглядеть подключение со стороны клиента с разных ОС. Также подведем некоторые итоги по проведенной работе.

Содержание

Remote Desktop Gateway

Описание функционала

Компонент RD Gateway представляет из себя стандартную (доступную из коробки) роль Windows Server. Суть заключается в том, что на периметре локальной сети разворачивается хост на котором инсталлируется компонент RD Gateway. Как нам подсказывает название, он является шлюзом для удаленных подключений. Само подключение производится через RDP клиент (в ОС отличных от Windows может потребоваться поддержка функционала шлюза подключений).

Принципиальным отличием работы компонента от обычного подключения RDP является тот факт, что соединение RDP устанавливается поверх HTTPS (веб-сервер IIS будет инсталлирован автоматически при установке).

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

  • По части публикации — нам достаточно опубликовать один порт в сеть интернет, нет необходимости плодить большое количество портов при публикации дополнительных узлов подключения.
  • По части управления — мы получаем инструменты политик авторизаций, где мы можем явно указывать: кто, куда и как может подключаться.
  • По части мониторинга — мы получаем возможность ведения лога подключений, удачных и неудачных попыток при помощи журналов Windows.

Предварительные требования

  • Windows Server 2008+ в качестве ОС узла установки роли.
  • Наличие развернутого домена Active Directory.

Наш тестовый стенд

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

Стенд состоит из 4х узлов:

  • lab-dc1.party.hard — контроллер домена.
  • lab-rds1.party.hard — сервер, на котором уже создано тестовое развертывание служб удаленных рабочих столов.
  • lab-rdgw1.party.hard — сервер шлюза удаленных рабочих столов и компонента web client.
  • lab-client1 — узел вне домена, моделирует клиентское подключение.

Установка, конфигурация и проверка роли Remote Desktop Gateway

Установить роль возможно произвести разными способами. Мы рассмотрим способ через развертывание служб удаленных рабочих столов.

Установка через развертывание служб удаленных рабочих столов

Начнем с сервера lab-rds1.party.hard. Для инсталляции роли нам необходимо в Диспетчере серверов, где уже существует развертывание инфраструктуры RDS, добавить сервер lab-rdgw1.party.hard для управления.

Производим поиск и добавление сервера для управления.

Затем, через иконку RD Gateway, добавить роль узлу lab-rdgw1.party.hard.

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

Следующим этапом мы займемся конфигурацией сертификатов.

Выберем пункт Создать новый сертификат.
Заполним необходимые поля и чекбоксы.

В результате выполненных действий, статус изменится на Готово к применению.

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

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

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

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

Так выглядит подключение к шлюзу через стандартный RDP клиент Windows.

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

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

Мониторинг удаленных подключений

Для того, чтобы узнать информацию об успешных или неудачных попытках подключения к шлюзу мы можем воспользоваться инструментом Просмотр событий. Нужную нам информацию мы найдем журналах Безопасность и Microsoft-Windows-TerminalServices-Gateway.

Для примера я произведу 2 попытки входа.

Первая — учетные данные некорректны.

В журнале Безопасность, в поле Account Name и Account Domain мы можем увидеть введенные пользователем данные. Также мы видим причину неудачи авторизации.
В журнале Microsoft-Windows-TerminalServices-Gateway мы можем увидеть запрос на удаленное подключение.

Вторая — учетные данные корректны.

Процедура авторизации завершилась успехом.
Журнал Microsoft-Windows-TerminalServices-Gateway также зафиксировал успешное соединение пользователя.

Нюансы эксплуатации

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

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

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

  • Использование самоподписанного сертификата и ручной импорт клиентам в случае если ПК не в домене и автоматизация этого процесса через GPO если ПК в домене.
  • Использование бесплатного сертификата Let’s Encrypt (90 дней). О выпуске и установке сертификата вы можете почитать — здесь.
  • Покупка сертификата безопасности на год.
Невозможность указать нестандартный порт подключения на старых RDP клиентах Microsoft

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

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

Решение только одно — установка обновления RDP клиента. Начиная с Windows 8 клиент уже обновлен и такой проблемы замечено небыло.

Возможные проблемы при подключении с ОС отличных от Windows

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

HTML5 Web client

Описание функционала

Компания Microsoft пошла дальше в вопросах предоставления удаленного доступа пользователям и выпустила специальный Web client компонент, позволяющий подключаться к рабочему столу или RemoteApp приложению через обычный веб-браузер.

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

Схема работы примерно та же. Мы организуем хост с установленным компонентом Web Client на периметре сети и публикуем один порт в сеть интернет.

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

Также прошу обратить внимание, что компонент Web client и роль Remote Desktop Web Access не одно и тоже. RD Web Access позволяет нам публиковать сеансы и RemoteApp приложения, которые, по факту, будут подключаться через RDP. Web client позволяет нам устанавливать сессию непосредственно в веб-браузере.

Предварительные требования

  • В сети должно быть сконфигурировано развертывание удаленных рабочих столов.
  • Версия ОС на узлах с ролями Connection Broker, Web Access, Session Host, Gateway должна быть Windows Server 2016+.
  • Лицензии CAL должны выдаваться на пользователя, не на устройство.
  • На узле Web client должно быть установлено обновление KB4025334.
  • Наличие развернутого домена Active Directory.

Установка, конфигурация и проверка Web client

В этой статье мы развернем компонент Web client, как и Remote Desktop Gateway, на отдельном узле — lab-rdgw1.party.hard. Воспользуемся уже сконфигурированной инфраструктурой, описанной выше.

Т.к мы планируем развернуть компонент на узле lab-rdgw1.party.hard, нам необходимо установить на него роль Web Access, иначе, мы столкнемся с невозможностью установки Web client.

Подобная ошибка возникнет при отсутствии роли RD Web Access на узле, в момент публикации Web client.

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

Теперь перейдем к установке роли Web Access. Для этого выберем пункт Добавить сервера Web Access в Обзоре развертывания.

Укажем узел для развертывания роли.

Подтверждаем установку и ждем ее завершения.

Теперь переходим непосредственно к установке Web client. На текущий момент установка компонента возможна только через PowerShell. Может быть, со временем, разработчики добавят возможность установки через GUI.

Сперва нам необходимо обновить модуль PowershellGet. Открываем Powershell от имени администратора и вводим:

Install-Module -Name PowerShellGet -Force

Для корректной работы нам нужно закрыть и еще раз открыть Powershell от имени администратора, иначе установленный модуль не будет работать.

После установки PowershellGet устанавливаем модуль RDWebClientManagement. Для этого вводим в Powershell:

Install-Module -Name RDWebClientManagement

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

Теперь установим модуль Web client выполнив в Powershell командлет:

Install-RDWebClientPackage

Теперь ненадолго переместимся на узел с ролью RD Connection Broker. Отсюда нам нужен сертификат который уже или будет назначен для роли RD Connection Broker. Так как мы разворачиваем тестовый стенд, нам проще создать новый самоподписанный.

В разделе коллекций, меню задачи, выбираем редактирование свойств развертывания.
В появившемся окне переходим в раздел сертификаты. Выбираем Создать новый сертификат для роли RD Connection Broker — Enable Single Sign On.
Указываем имя сертификата, пароль. Также определяем место сохранения.
Теперь мы готовы к назначению нового сертификата. Для этого нажмем Применить.
Если мы видим подобную картину, значит сертификат был назначен успешно.

После этого нам необходимо найти его в оснастке Сертификаты учетной записи компьютера в виде ключевой пары .pfx и экспортировать публичную часть.

Сформированные нами сертификаты можно найти в папке Личное.
Нам необходимо экспортировать только публичную часть, указываем это при экспорте.

Только что полученный сертификат переносим на сервер lab-rdgw1.party.hard любым доступным способом и сами возвращаемся на него же. 🙂

Импортируем открытую часть сертификата для развертывания Web client.

Import-RDWebClientBrokerCert "C:\users\Administrator\Desktop\lab-rds1.party.hard.cer"

И наконец публикуем компонент.

Publish-RDWebClientPackage -Type Production -Latest
Дополнительная литература

Для более подробных инструкций предлагаю посмотреть документацию Microsoft.

https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin

Проверяем подключение со стороны клиента

Итак, проверим как наши пользователи будут удаленно подключаться. Для этого запускаем веб-браузер и вводим внешний fqdn-адрес:
https://ext-lab-rdgw1.party.hard/RDWeb/webclient/

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

Запустим, единственный в нашем случае, опубликованный ресурс.

Браузер вежливо предлагает нам пробросить в удаленный сеанс буфер обмена и принтеры.
Производим подключение.
Мы попадаем в удаленную сессию на узле lab-rds1.party.hard.

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

Для этого точно также запускаем веб-браузер и вводим внешний fqdn-адрес:
https://ext-lab-rdgw1.party.hard/RDWeb/webclient/

Нас встречает уже знакомая процедура авторизации.
Подключение установлено с устройства под управлением Linux и книжной ориентацией экрана.

Подключение к хостам вне коллекции RDS

У некоторых может возникнуть вопрос:

Возможно ли подключение через веб-браузер к серверам, которые не находятся в коллекции RDS? А к клиентским компьютерам?

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

Ниже я покажу пример публикации удаленного подключения к серверу lab-dc1.party.hard.

Подход имеет свои недостатки. Таким образом мы, фактически, устанавливаем 2 RDP соединения. Сначала с узлом RDSH и отсюда устанавливаем новое соединение с нужным нам хостом.

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

  • Сессии
  • Приложения RemoteApp

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

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<collection>\RemoteDesktops\<collection>\ShowInPortal

Значение этого ключа должно быть равно 1.

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

Мониторинг удаленных подключений

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

Для примера я произведу 2 попытки входа.

Первая — учетные данные некорректны.

В поле Account Name и Account Domain мы можем увидеть введенные пользователем данные. Также мы видим причину неудачи авторизации.

Вторая — учетные данные корректны.

При использовании инструментов для автоматизации процесса можно получить более удобный мониторинг и интегрировать его в другие сервисы (напр. Zabbix).

Нюансы эксплуатации

Отсутствие возможности копирования файлов

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

Двойное RDP подключение к хостам вне коллекции RDS

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

Некорректная работа с NAT

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

Итоги

Мнение

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

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

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

Также администраторы получают возможность централизовано (через свойства коллекций или Active Directory) управлять доступом и заниматься мониторингом подключений. Это очень удобно с точки зрения интеграции с уже существующей инфраструктурой. У специалистов по эксплуатации отпадает необходимость дружить другое ПО с учетными данными пользователей в Active Directory.

Коллеги! Если у вас есть замечания или дополнения по предмету этой статьи, прошу оставить комментарий. Возможно, они кому-то пригодятся в будущем.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *