Rd web access что это
Создание терминальной фермы RDS с использованием технологии NLB и публикация RD Web Access на ISA Server 2006
Итак, мы хотим добиться балансировки нагрузки на наши терминальные сервера, их отказоустойчивость, или же хотим добавить к уже имеющемуся терминальному серверу второй для увеличения производительности сервиса. В моем примере я буду реализовывать следующую схему: 
Как мы видим, для реализации такой схемы нам понадобится три сервера. Причем, роль Брокера можно установить на уже имеющийся у нас сервер, например, на файловый или сервер печати. Для наглядности назовем наши сервера следующим образом:
Как мы видим, имя нашего домена – domain.local. Для доступа к терминальным службам снаружи будет использоваться доменное имя domain.ru. Таким образом, в нашем DNS домена domain.local нам необходимо будет создать дополнительную зону с именем domain.ru, где мы потом создадим запись RDS.domain.ru, которая будет ссылаться на IP адрес терминальной фермы.
1. Установка терминальных служб на сервер RDS1.
1.1 Добавляем роли «Службы удаленных рабочих столов» (Remote Desktop Services) и «Службы политики сети и доступа» (Network Policy and Access Services). Выбираем для установки следующие службы ролей:
— Узел сеансов удаленных рабочих столов (Remote Desktop Session Host)
— Шлюз удаленных рабочих столов (Remote Desktop Gateway)
— Веб-доступ к удаленным рабочим столам (Remote Desktop Web Access)
— Сервер политики сети (NPS)
При установке служб ставим галочку «Require NLA», остальные настройки сконфигурим позже. Перезагружаем сервер при первом же требовании.
1.2 Создадим в ДНС нашего домена запись RDFarm.domain.local, которой присвоим IP адрес 192.168.0.80. Это будет внутренний адрес нашей фермы, а также адрес кластера NLB.
1.3 Создадим в ДНС зоне domain.ru нашего домена запись RDS.domain.ru, которой присвоим тот же IP адрес, что и адрес кластера — 192.168.0.80. Это будет внешний адрес нашей фермы, через который будут заходить удаленные пользователи.
1.4 Заходим в оснастку Remote Desktop Services – RemoteApp Manager – RD Gateway и настраиваем параметры следующим образом:
На закладке Digital Signature указываем сертификат, который надо предварительно запросить. Для выполнения этого шага в вашем домене должен быть центр сертификации (CA). На сервере RDS1 запустите mmc и добавьте оснастку Certificates (computer account):
После получения сертификата экспортируйте его в pfx-файл – он нам понадобится для настройки второго сервера.
Теперь на закладке Digital Signature мы можем указать наш сертификат:
1.5 Заходим в оснастку Remote Desktop Services – RemoteApp Manager и в разделе RemoteApp Programs и добавим одно удаленное приложение. Пусть это будет калькулятор.
Нажмем кнопку «Properties» и добавим в список пользователей, которые смогут запускать наш Калькулятор, группу rd_users.
1.6 Заходим в оснастку Remote Desktop Services – RD Gateway Manager и настраиваем свойства RDS1 (Local). Но перед этим необходимо запросить еще один сертификат (см. пункт 1.4), но на сей раз с Common Name внешнего адреса – RDS.domain.ru.
На закладке Private Key не забудьте указать, что ключ может быть экспортирован.
После получения сертификата экспортируйте его в pfx-файл – он нам понадобится для настройки второго сервера.
Теперь указываем этот сертификат в свойствах нашего шлюза удаленных рабочих столов:
Переходим на закладку Server Farm, где добавим наш сервер RDS1 в ферму шлюзов:
Обратите внимание, что на данном этапе поле статус не обязательно должно иметь состояние «ОК».
1.7 Заходим в оснастку Remote Desktop Services – RD Gateway Manager — RDS1 (Local) – Policies – Connection Authorization Policies и создаем политику авторизации подключений при помощи мастера:
Добавим в список авторизованных для подключения пользователей группу rdg_users, куда включим всех тех, кому надо получить доступ к терминальным сервисам.
1.8 Заходим в оснастку Remote Desktop Services – RD Gateway Manager — RDS1 (Local) – Policies – Resource Authorization Policies и создаем политику авторизации приложений минуя мастер (Create New Policy – Custom):
1.9 Заходим в оснастку Remote Desktop Services – RD Session Host Configuration и настраиваем свойства подключения RDP-Tcp следующим образом:
Нажимаем на кнопку «Select» и указываем сертификат с Common Name нашей фермы – RDFarm.domain.local (он уже был установлен на сервер в пункте 1.4).
Остальные параметры не настраиваем.
Здесь же, в RD Session Host Configuration, настраиваем параметры лицензирования.
1.10 Для проверки правильности настройки приложения RemoteApp заходим на адрес localhost/RDWeb
2. Установка терминальных служб на сервер RDS2.
2.1 Добавляем роли «Службы удаленных рабочих столов» (Remote Desktop Services) и «Службы политики сети и доступа» (Network Policy and Access Services). Выбираем для установки следующие службы ролей:
— Узел сеансов удаленных рабочих столов (Remote Desktop Session Host)
— Шлюз удаленных рабочих столов (Remote Desktop Gateway)
— Веб-доступ к удаленным рабочим столам (Remote Desktop Web Access)
— Сервер политики сети (NPS)
При установке служб ставим галочку «Require NLA», остальные настройки сконфигурим позже. Перезагружаем сервер при первом же требовании.
2.2 Настраиваем второй сервер RDS2 точно таким же образом, как и настроен наш первый сервер за исключением того, что сертификаты уже запрашивать не нужно – их надо импортировать с сервера RDS1. Для импортирования сертификатов запустите mmc и добавьте оснастку Certificates (computer account):
Укажите путь к pfx файлам, содержащим сертификаты, и импортируйте их в личные сертификаты компьютера RDS2.
3. Создание и конфигурирование терминальной фермы.
3.1 Устанавливаем роль RD Connection Broker на сервер BROKER.
3.2 Добавляем сервера RDS1 и RDS2 в локальную группу Session Broker Computers на сервере BROKER.
3.3 Добавляем все наши три сервера в локальную группу TS Web Access Computers на серверах RDS1 и RDS2
3.4 На сервере BROKER добавляем наши сервера RDS1 и RDS2 в группу RD Web Access (Admin Tools > Remote Desktop Services > Remote Desktop Connection Manager > Add RD Web Access Server).
3.5 Сперва на сервере RDS1, а затем и на RDS2, заходим в Remote Desktop Services > Remote Desktop Session Host Configuration и меняем настройки RD Connection Broker:
3.6 Настраиваем удаленные приложения RemoteApp на работу с нашей фермой. Для этого на серверах RDS1 и RDS2 заходим в Remote Desktop Services > RemoteApp Manager и меняем параметр Server Name:
3.7 На сервере BROKER идем в Remote Desktop Services > Remote Desktop Connection Manager > RemoteApp Sources и жмем кнопку «Add RemoteApp Source…»:
Добавляем все наши возможные ресурсы RemoteApp: RDFarm.domain.local, RDS1.domain.local, RDS2.domain.local и RDS.domain.ru.
3.8 Создаем кластер NLB.
3.8.1 Устанавливаем компонент Network Load Balancing на сервера RDS1 и RDS2. Далее открываем оснастку Network Load Balancing Manager на сервере RDS1 и создаем кластер:
Включаем в балансировку только 443 и 3389 TCP порты.
3.8.2 Добавляем второй компьютер (RDS2) в NLB кластер
3.9 Удостоверяемся, что на серверах RDS1 и RDS2, в свойствах сервера RD Gateway Manager на закладке Server Farm указаны оба наших сервера:
3.10 На серверах RDS1 и RDS2 заходим в оснастку IIS Manager, далее Sites – Default Web Site – RDWeb – Pages и справа жмем Application Settings, где присваиваем параметру DefaultTSGateway значение RDS.domain.ru:
4. Публикация фермы RemoteApp приложений на ISA Server.
Вначале необходимо установить наш сертификат с Common Name «RDS.domain.ru» на ISA сервер (сделать это можно так же, как в случае с сервером RDS2, когда мы переносили на него сертификат с RDS1).
Этот раздел я не буду рассматривать слишком подробно, а обойдусь лишь наиболее важными скриншотами с настройками правила публикации и созданием WEB-прослушивателя:
Windows в браузере без регистрации и СМС — обзор RDP-клиентов HTML5
Когда-то давно, когда деревья были высокими, а я был молодым и зеленым системным администратором, довелось мне внедрять терминальный сервер на Windows 2000. Я тогда думал, что хорошо бы, если бы для подключения к серверу не нужен был никакой отдельный клиент. Шло время, деревья выросли, олени на свитере отпустили рога, а я — бороду, на рынке начали появляться решения для работы в терминале через браузер. Но они были или нестабильные, или дорогие, и пробные внедрения ушли в долгий ящик.
Прошло еще немного времени, в бороде появилась седина, а решений на базе HTML5 стало куда больше. И мне захотелось сделать краткий обзор бесплатных вариантов — как для начинающих системных администраторов, так и для тех, кто пропустил этот момент, как я.
Итак, хотите пускать сотрудников на терминалки через браузер или админить серваки через него же? Добро пожаловать под кат.
Удобство подключения без отдельного клиента сложно переоценить — браузер есть практически на любом пользовательском устройстве. Помимо удобства пользователей есть и аспект безопасности: поскольку такой клиент является веб-сервисом, защищать его гораздо проще. Действительно, классический RDP с интересными уязвимостями высовывать наружу просто так довольно опасно, работать через VPN не всегда удобно, а сервисы fail2ban и нестандартный порт хоть и помогают, но 100% защиты не дают. В то время как веб-сервис можно защитить авторизацией по сертификату и другими методами двухфакторной аутентификации.
Есть мнение, что использование RDS-Gateway с заворачиванием RDP-трафика через HTTPS и установка сертификатов на клиентах является хорошей защитой. На самом деле это не так — установка сертификатов для RDS-Gateway нужна для проверки подлинности не клиента, а сервера. Убедиться в этом можно, попробовав подключиться сторонними RDP-клиентами. Конечно, часть ботов, ищущих открытый RDP, такой способ отсеет. Но решения fail2ban в таком случае тоже необходимы.
Оставлю настройку безопасности за рамками этой статьи и перейду к конкретным примерам реализации. Тестировать будем на терминальном сервере на базе Windows Server 2019, в качестве приложения для проверки RemoteApp будем использовать 1С 7.7. Потому что можем.
Не так давно Microsoft окончательно выпустил свое решение для подключения к RDP через браузер. Начнем, пожалуй, с него.
Microsoft Remote Desktop Web Client
Установка и настройка клиента подробно описана в документации, приведу основные шаги под спойлером.
Подготовка. Ролям шлюза удаленных рабочих столов и\или посреднику подключений должен быть назначен такой сертификат, которому бы доверяли клиенты. Да, примерно как при обычной работе RDP-клиента через https. Можно завести публичный доверенный сертификат, можно использовать внутреннюю CA, в целях тестирования можно использовать и самоподписанный.
Сначала может понадобиться обновить модуль PowerShellGet.
Это делается командой:
После этого нужно перезапустить консоль, и для установки клиента достаточно будет выполнить команды:
В процессе может быть загружен Nuget для установки модулей из репозитория, сервер должен быть подключен к интернету. Да, Windows уже взрослая и умеет в репозитории.
Теперь нужно настроить сертификат для этого клиента. Делается это командой:
Где cert.cer — путь к сертификату посредника удаленных рабочих столов в формате cer.
Теперь можно опубликовать клиента командой:
После установки клиент становится доступен по ссылке вида:
После успешного логина видны все опубликованные в коллекции приложения RemoteApp.
Опубликованные приложения в браузере.
Попробуем запустить 1С, подключившись Firefox с Kubuntu.
Kubuntu, Firefox, 1C 7.7.
Можно запускать и другие опубликованные приложения. В таком случае они будут работать в одном окне, а верхняя панель будет представлять из себя что-то вроде панели задач.
1С, Paint и WordPad.
В целом все выглядит приятно и удобно, полноценный рабочий стол тоже поддерживается. Печать работает в виде отправки на виртуальный принтер PDF с последующей загрузкой файла браузером. Буфер обмена для текста тоже работает, хотя немного раздражает необходимость подтверждать доступ браузера к буферу обмена.
Подтверждение копирования с удаленного рабочего стола.
А вот чего пока нет, так это трансфера файлов с сервера и на сервер, и это существенная ложка дегтя. Подведем итог.
Что ж, посмотрим, что нам предложит мир opensource.
Apache Guacamole
Пожалуй, одно из самых известных решений. Но версия 1.0 появилась относительно недавно. К ее минусам можно сразу отнести отсутствие официальной поддержки Windows в качестве точки установки — нужна отдельная linux-машина или образ Docker. Документация доступна, как обычно, на официальном сайте. Стоит отметить, что помимо RDP, решение поддерживает доступ через браузер к серверам ssh, telnet и vnc.
Если вам не хочется собирать свежую версию из исходников и разбираться с зависимостями, можно воспользоваться готовыми скриптами установки, вроде скрипта guac-install. Но — как обычно — за сторонние скрипты редакция ответственности не несет.
После установки согласно документации нужно так или иначе создать пользователей и настроить подключения. Я использовал работу с MySQL в качестве хранилища пользователей и их настроек и настраивал все это дело через веб-интерфейс. Через него доступно создание и настройка пользователей, подключений и групп, которые позволяют делать общие подключения для разных пользователей.
Настройка простого RDP-подключения.
Стоит отметить, что если мы хотим прозрачно подключаться, авторизовавшись только через веб-интерфейс, то понадобится или вручную создавать каждому пользователю подключение, вводя его пароль (!), или делать более сложную установку. Например, использовать для хранения настроек и авторизации БД Active Directory, что потребует модификации схемы AD. Или настраивать авторизацию через LDAP, также создавая пользователей и в классической БД вроде MySql.
Без сложных установок придется создавать отдельных пользователей веб-интерфейса или делать одного общего. При этом если не задавать имя пользователя и пароль в настройках подключения, то надо отключить безопасность NLA на сервере. Не очень удобно.
Помимо полноценного рабочего стола есть и поддержка RemoteApp. Важный нюанс — прописывать имя программы в настройках нужно точно так же, как и в файле RDP.
И если все было сделано правильно, наша «семерка» откроется в браузере.
И снова 1С 7.7 в браузере.
Печать работает так же: скачивается PDF, но — в отличие от решения от MS, — есть возможность файлового обмена с сервером.
По сути, Apache Guacamole запускает у себя freerdp и может прокидывать папки со своей линуксовой машины на виндовый сервер.
Перенаправленный диск в 1С.
В свою очередь из браузера можно скачать или загрузить файл через специальное меню. В этом меню можно еще и настроить эмуляцию мыши и экранную клавиатуру. Вызывается оно сочетанием клавиш Ctrl+Alt+Shift.
Текстовый буфер обмена также работает, но немного неудобно (бесит куда больше, чем решение от MS). Современные браузеры в паре с Apache Guacamole позволяют легко копировать текст с удаленного приложения при помощи Ctrl+C, но для вставки текста с локальной машины понадобится использовать меню по Ctrl+Alt+Shift.
Зато практически «из коробки» реализована двухфакторная аутентификация (особенно, если делать установку сторонним скриптом). Например, при помощи алгоритма TOTP.
Вкратце напомню: TOTP (Time-based One-time Password Algorithm) — это алгоритм генерации одноразовых паролей на основе времени. При первом входе пользователю будет предложено считать двухмерный штрих-код или записать набор символов, «скормить» их приложению (например, Google Authenticator). И на основе этого набора символов (security string) приложение каждые 30 секунд будет генерировать новое число-код для входа.
В целом, решение произвело впечатление более продуманного и законченного, если бы не некоторая сложность в настройке для нормальной работы. Подведу итог.
На просторах сети я нашел еще один малоизвестный проект, запускающий freerdp и отображающий получившееся через браузер. Попробуем и его.
Myrtille
Проект со всей документацией располагается на github автора. В отличие от Guacamole, Myrtille устанавливается на Windows, да ещё и практически в режиме «Далее — Далее — ОК». Устанавливаем, запускаем браузер.
Windows в браузере.
Помимо RDP поддерживается SSH и подключение к виртуальной машине Hyper-V. Меню управления подключением вызывается по кнопке с тремя точками в левом верхнем углу.
Меню управления подключением.
Работа с файлами производится через веб-интерфейс — по кнопке Files открывается доступ к папке «Мои документы» пользователя для загрузки и скачивания файлов. При этом если Myrtille установлен не на терминальном сервере, придется настраивать перенаправление папки. Печать, в отличие от двух других решений, сразу вызывает окно с диалогом печати PDF.
Чуть хуже дела с RemoteApp при работе приложения в обычном режиме. Для запуска несчастной 1С нужно сформировать ссылку вида:
В которой нужно явно указать пользователя и его пароль (или хэш пароля). Программу необходимо прописать так же, как и в файле RDP — в случае нашей 1С это будет ||1cv7l. Все параметры должны быть URL-encoded.
И в третий раз 1С в браузере.
Для получения хэша пароля можно также воспользоваться myrtille, просто перейдя по ссылке (выполнив GET-запрос):
Двухфакторная аутентификация также доступна «из коробки» и основана на сервисе oliveinnovations.com.
Для работы в доменной среде у приложения есть отдельный режим работы — Enterprise mode. Для его включения нужно при установке (или потом, в файлах конфигурации) указать имя домена и группу администраторов (пользователей, которые могут настраивать подключения). Тогда при входе будет запрашиваться только имя пользователя и пароль, и администратор может создавать предопределенные конфигурации подключения для групп пользователей. Это и позволит нам сделать удобный ярлык для запуска 1С.
Создание подключения в панели управления Enterprise-режима.
Теперь пользователь при входе будет видеть доступные ему подключения и запускать 1С по кнопке, а не по странной ссылке с паролем.
Интерфейс при входе обычного пользователя.
К сожалению, на данный момент у меня не получилось заставить работать текстовый буфер обмена в современных браузерах — работа идет только по кнопке clipboard и только в сторону с сервера на локальный ПК.
Вместо послесловия
Конечно, существуют и другие решения, в том числе и платные. Приведу несколько самых популярных, не трогая монстров вроде Xen Desktop:
В них уже есть поддержка принтеров и работы с файлами, но в принципе и бесплатные решения более-менее дошли до аналогичного уровня.
По результатам исследования я решил остановиться на решении от MS, благо перенос файлов в моем случае не был нужен (точнее, был категорически не нужен).
Скатерть-самобранка, или как развернуть службы удаленного рабочего стола на Windows Server 2012 R2
Сегодня мы объясним, чем развертывание RDS Session Host на Windows Server 2012 R2 отличается от более ранних версий Windows Server и расскажем о доступных опциях развертывания. Remote Desktop Services на Windows Server значительно усовершенствовались за последнее время, но остается, тем не менее, много непонятного по причине множества вовлеченных в процесс компонентов. RD Session выполняют всю грязную работу, обслуживая терминальные сессии пользователей. Однако даже при самом примитивном сценарии обязательно использование RD Connection Broker (посредника подключений к удаленному рабочему столу). Еще до того, как вы запланируете развертывание служб удаленного рабочего стола, стоит ознакомиться с его ролью.
RD Connection Broker
Когда сеанс удаленного рабочего стола отключается, приложения в сеансе пользователя продолжают работать. Для отслеживания сеансов пользователей RD Connection Broker (Посредник подключений удаленного рабочего стола) хранит такую информацию, как название сеансов удаленных рабочих столов, где проходит каждая сессия, состояние сессии и ее идентификатор, а также информация о подключенных пользователях в каждой сессии. Эта информация используется для подключения пользователей к существующим сеансам на серверах RD Session Host (терминальные сервера Windows). При создании новой сессии RD Connection также играют свою роль путем подключения пользователей к серверам RD Session Host по мере загрузки.
Начиная с Windows Server 2012, посредники подключений к удаленному рабочему столу не только хранят данные о пользовательских сессиях, но и информацию о конфигурации. Посредник подключений к удаленным рабочим столам использует внутреннюю базу данных Windows для сохранения сессии и информации о конфигурации, кроме случаев, когда установлен режим высокой доступности (HA), где используется сервер SQL 2008 R2 (или более поздняя версия).
Посредник подключений к удаленному рабочему столу требует домен Active Directory, но не может быть установлен на контроллере домена (DC). Можно развернуть службы удаленного рабочего стола в рабочей группе с помощью установки роли сервера, хотя при этом теряется возможность централизованного управления, пульты управления и функционал удаленных приложений Remoteapp.
Централизованная публикация приложений
В Windows Server 2012 также введен концепт коллекций (collections). В Windows Server 2008 R2 требовалось, чтобы системные администраторы публиковали приложения для каждого RD Session Host в индивидуальном порядке. Теперь посредник подключений к удаленному рабочему столу хранит информацию о конфигурации.
Опции развертывания: быстрая и стандартная
Ключ к пониманию того, как развернуть RDS на Windows Server 2012 R2 в понимании того, что недостаточно установки роли RD Session Host. Диспетчер серверов обеспечивает специальный режим развертывания для установки RDS, таким образом все необходимые компоненты установлены в нужных местах, чтобы делает развертывание простым и быстрым.
Службы удаленного рабочего стола на Windows Server 2012 R2
В мастере добавления ролей и компонентов (Add Roles and Features Wizard) в диспетчере серверов есть специальная опция установки, установка служб удаленных рабочих столов (Remote Desktop Services installation), которую необходимо выбрать при развертывании служб удаленных рабочих столов. Формулировка при этом варианте немного смущает, но опция позволяет устанавливать хосты сеансов удаленных рабочих столов без развертывания полной инфраструктуры виртуальных ПК (virtual desktop infrastructure — VDI).
Стандартное развертывание — это модель развертывания по умолчанию, и если вы действительно хотите установить все необходимые роли на одном сервере, что не является лучшей практикой, то стоит выбрать эту опцию. Быстрая установка (Quick Start) может быть полезна в сценариях тестирования или в небольших филиалах, где есть только один доступный сервер.
Консоли управления
Все необходимые консоли управления можно найти в диспетчере серверов на сервере, где установлен посредник подключений к удаленным рабочим столам, за исключением RD Gateway и RD Licensing.
Установка служб удаленного рабочего стола на Windows Server 2012 R2
Лицензирование
Развертывание служб удаленного рабочего стола
Стандартное или быстрое развертывание
Роли служб удаленных рабочих столов
Выберите сервер из пула серверов
Ход развертывания