When configuring remote desktop services, one of the powerful capabilities that it provides is remote desktop web access, or rd web access as many know it as. Remote desktop services has become even easier to configure over the last few versions of Windows Server and this also goes for the remote desktop rd web access. In this post, we will take a look at Windows Server 2019 RD Web Access configuration and see how this is done with the latest version of Windows Server.
Remote Desktop Gateway, Certificates, and other things
To begin with, I already had a Windows Server 2019 Remote Desktop Gateway server configured and ready to go. Read my write up on how to configure Windows Server 2019 Remote Desktop Gateway server here. In my cofiguration in the lab of the rd web access, I built on the components that I already had installed on this box. This included installing the RD Web Access role.
In my configuration, I had a simple two server configuration – my remote desktop gateway server that also housed the RD Web access server and then the RDSH server that sits behind this server in the internal network.
Let’s see what steps are required to get the Windows Server 2019 rd web access configuration up and running ready to service clients via web access.
What does the RD Web Access role allow you to do? With the RD Web Access role installed, clients can easily access virtual machines via their browser without having to using a client of sorts or some other mechanism to connect.
This also opens up the opportunity for non Windows devices to connect to internal resources since all that is required is a browser. Your end users are given the various servers they can connect to via what are known as “Collections”. With the collection, users see the RDSH servers they have permissions to connect to.
Using PowerShell to RD Web Access Components
We need to install a few components for Windows Server 2019 RD Web Access. To do this, run the following cmdlets:
- Install-module -Name RDWebClientManagement
- Install-RDWebClientPackage
- Import-RDWebClientBrokerCert – Using this cmdlet, I pointed the cmdlet to the cert that was created when provisioning the RD Gateway server
- Publish-RDWebClientPackage
If you don’t already have the RD Web Access role installed, you will see the following error.
Remote Desktop Services Installation
Using Server Manager, you can finish out your Remote Desktop Services installation. To do this you just launch the Add Roles and Features Wizard and follow the wizard by selecting remote desktop services installation.
On the type of installation type, choose the Remote Desktop Services Installation. This will allow finishing out the remote desktop services installation.
Here, I am selecting the Standard Deployment that allows you to deploy Remote Desktop Services across multiple servers and have a bit more control over the configuration.
Select the deployment scenario. Here select “Session-based desktop deployment”.
Role services that will be installed if needed on the target boxes include – REmote Desktop Connection Broker, Remote Desktop Web Access, and Remote Desktop Session Host.
In the wizard, you will be able to select the servers you want to designate for each role. This includes the RD Connection Broker server.
Specify the RD Web Access server during the configuration.
RD Session Host server specified in the configuration.
Confirm the configuration of the remote desktop services components.
Designate any missing remote desktop services components. There will be a “green plus” over the component that needs further configuration. Simply click the “plus” and set the configuration.
Creating RD Web Access Collections
To allow access to specific resources via the RD Web Access role, you need to create a Collection. The Collection is a set of RDSH servers that you entitle to specific users.
Start the wizard and name the Collection.
Specify the RD Session Host servers.
Specify user groups that are allowed to have access to connect to the collection.
You can configure User profile disks to store user profile settings in a central location.
Confirm the selections made in the collection creation.
Finish out creating the collection.
You can now test out the new collection and Windows Server 2019 RD web access by logging in on a browser. You should see the collection that you created and assigned to your users.
Wrapping Up
Hopefully this look at Windows Server 2019 RD web access configuration will help anyone who might be struggling to put the pieces together. The configuration of remote desktop services has gotten easier in the later versions of Windows Server.
Much of the process is wizard driven and helps to give visibility to parts of the configuration left to finalize and setup. This includes the remote desktop gateway server, rd web access server, and RDSH.
Remote Desktop Web Access (RD Web Access) is a role service on the server that you want users to connect to over the web to access RemoteApp and Desktop Connection. When you install the RD Web Access role service, Microsoft Internet Information Services (IIS) is also installed.
The server where you install RD Web Access acts as the web server. The server does not need to be a Remote Desktop Session Host (RD Session Host) server or a Remote Desktop Connection Broker (RD Connection Broker) server.
In this tutorial, you will learn how to set up RD Web Access role service on a Windows server.
To install RD Web Access
STEP 1
On the Windows computer you want to install Rd Web Access, go to Server Manager. Server Manager can be accessed in the following ways.
A- Search for Server Manager from the Windows Search box.
B- Click Start, point to Administrative Tools, and then Click Server Manager.
STEP 2
From the Server Manager console, Select Manage, then Click Add Roles and Features.
STEP 3
On the Before You Begin page, Click Next.
STEP 4
On the Select Server Roles page, Select the Remote Desktop Services check box, and then Click Next.
STEP 5
Review the Remote Desktop Services page, Select Remote Desktop Service Installation, then Click Next.
STEP 6
On the Remote Desktop Service page, Select standard deployment or Quick Start deployment option, then Select Next.
For the purpose of this tutorial, we will be setting up Remote Desktop Service using the Quick Start.
Note: You need to make sure the server is joined to a domain before using the Quick Start deployment.
STEP 7
On the Deployment Scenario, Select Session based desktop deployment, then Click Next.
STEP 8
On the Server Selection page, Select the server from the server pool, then Click Next.
STEP 9
Select the Restart option on the confirmation page, then Click Deploy.
STEP 10
Monitor the installation progress. Do not close the page until installation is complete.
Note: The server will restart but will continue once you are signed in again.
STEP 11
Installation complete.
STEP 12
To confirm if RD Web Access is working correctly, click on the URL as shown above, and you will be redirected to the Remote Desktop web access portal.
A- Make sure to sign in using an administrator account from your domain.
That’s it! You’ve now successfully set up RD Web Access.
There’s a Better Way to Access Your Apps Remotely
Now, you know how to set up RD Web Access, but there’s a way to get the same result in 3 steps instead of 12. All you need is a V2 Cloud account.
Step 1: Create a shortcut of the application you want to give access
Login to your cloud computer with V2 Cloud as an administrator. Make sure to put the shortcut in a folder that your colleagues will have access to.
Step 2: Add a new remote application in your dashboard
Go to the V2 Cloud Dashboard and click on the Apps tab. Then, click on Add a new remote application:
The fields need to be filled in the following way:
Name / Description
Path – You need to put the path where the shortcut is located. The best way to do it is with copy/paste:
Once this is done, add .lnk at the end. It will look as on the image below:
Select Apply to all users if you would like the Remote App to be available to all users. If you want to enable the Remote App for a specific user only, leave this option unchecked.
Click Submit.
Step 3: Give access to your users
On the Dashboard, click on the Users tab:
Find the specific user and click on its Action button, then Edit user.
On the Remote apps drop-down menu, select your application: (You can select as many applications as you want and the user will be asked to choose which application to use after logging in with the V2 Cloud Desktop app.)
Click submit
Voilà! Your users now have access to the remote application on a cloud desktop connection!
В Windows Server 2022/2019/2016 с развёрнутыми службами Remote Desktop Services вы можете установить и настроить новый Remote Desktop Web Client HTML5. Этот веб клиент позволит любым устройствам (iOS, macOS, Android, Linux) получать доступ к вашим RemoteApp приложениям на RDS хостах прямо из любого браузера (не нужно устанавливать отдельный RDP клиент).
Содержание:
- Установка RD Web HTML5 клиента на Windows Server RDS
- Доступ к RDWeb серверу через браузер с HTML5
- Возможные проблемы с веб клиентом Remote Desktop
[contents h2]
Remote Desktop Web Client доступен в виде расширения роли RD Web Access на RDS серверах под управлением Windows Server 2022/2019/2016.
Перед внедрением RD Web Client нужно убедится, что ваша RDS инфраструктура соответствует следующим требованиям:
- Наличие развернутой инфраструктуры RDS (фермы Remote Desktop Services), включающей: шлюз Remote Desktop Gateway, RD Connection Broker и RD Web Access на Windows Server 2022/2019/2016;
- Используются терминальные лицензии (RDS CAL) в режиме Per User;
- На серверах RDS Gateway и Web Access должны использоваться SSL сертификаты, выданные доверенным CA. Поддерживаются бесплатные Let’s Encrypt сертификаты на RDS. Самоподписанные SSL сертификаты можно использовать в ограниченном режиме;
Установка RD Web HTML5 клиента на Windows Server RDS
HTML5 RD Web Client не входит в дистрибутив Windows Server. Вам нужно вручную установить модуль RD Web Client Management из галереи скриптов PowerShell.
Для этого установите модуль PowerShellGet на сервере с ролью RD Web Access:
Install-Module -Name PowerShellGet -Force
Перезапустите консоль PowerShell.exe и установите модуль RD Web Client Management:
Install-Module -Name RDWebClientManagement
Чтобы принять лицензионное соглашение Microsoft, введите A.
Теперь нужно установить последнюю версию пакета Web Remote Desktop:
Install-RDWebClientPackage
После установки пакета, проверьте его свойства командой:
Get-RDWebClientPackage
Как вы видите, у вас появился пакет rd-html 5.0 версия 1.0.0.
Далее вам нужно экспортировать SSL сертификат с сервера с ролью RDS Connection Broker, использующийся для SSO (Enable Single Sign On) в .cer файл (формат BASE64).
- Запустите консоль управления сертификатами компьютера
certlm.msc
: - Разверните раздел Personal -> Certificates;
- Найдите ваш сертификат, который используется в вашей RDS ферме, щелкните по нему правой кнопкой и выберите select All Tasks -> Export;
- Выберите формат экспорта Base-64 encoded X.509 (.cer) и укажите имя файла.
Импортируйте сертификат на сервере RD Web Access:
Import-RDWebClientBrokerCert C:\RDBroker.cer
Теперь можно опубликовать клиент RD Web:
Publish-RDWebClientPackage -Type Production -Latest
Для тестирования клиента RD Web, можно развернуть клиент с помощью команды:
Publish-RDWebClientPackage -Type Test -Latest
Клиент RD Web позволяет запускать RemoteApps в браузере или через локальный RDP клиент (в этом случае пользователь скачает *.rdp файл). Пользователь может сам выбрать нужные ему режим. Чтобы запуск разрешить RemoteApp только в браузере, выполните команду:
Set-RDWebClientDeploymentSetting -Name "LaunchResourceInBrowser" $true
Доступ к RDWeb серверу через браузер с HTML5
После того, как вы развернули пакет Web Client на RDS сервере, вы можете запустить браузер на клиентском компьютере. Поддерживаются все последние версии браузеров Microsoft Edge, Google Chrome, Safari, Mozilla Firefox. Для доступа к RDS серверам из браузера вам достаточно передать пользователям ссылку на сервер RDWeb.
Обязательно используйте FQDN имя сервера RD для подключения. Обратите внимание, что данное FQDN имя должно содержаться в вашем сертификате RDS развёртывания (проверьте поля Common Name/CN и Subject Alternative Names /SAN).
Откройте URL адрес:
_https://FQDN.server.name/RDWeb/webclient/index.html
Для доступа к тестовой среде используйте адрес:
_https://FQDN.server.name /RDWeb/WebClient-Test/index.html
Имя сервера должно соответствовать имени сервера RD Web Access в сертификате.
Авторизуйтесь на RDWeb сервере под своей учетной записью.
При входе у вас будет запрошено какие локальные ресурсы должны быть доступны в RD сессии. Пока доступно только перенаправление буфера обмена и принтеров (локальные диск и USB устройства через веб-клиент RDP не пробрасываются, нужно использовать полноценный клиент mstsc.exe, RDCMan или аналоги).
После успешного входа вы увидите все RemoteApp опубликованные в коллекциях. Вы можете переключаться между ними с помощью иконок в верхней части окна.
При запуске RemoteApp оно будет отображаться в браузере с возможностью развернуть окно на весь экран.
Печать из RD Web клиента осуществляется через виртуальный PDF принтер (Microsoft Print to PDF). Когда вы отправляете документ на печать в окне веб клиента, браузер предлагает скачать сформированный pdf файл. Вы можете открыть PDF файл а (PDF просмотрщик встроен в браузер Microsoft Edge) и распечатать на локальном принтере.
В HTML5 клиенте доступно динамическое изменение окна удаленного рабочего стола и возможность запуска в полноэкранном режиме. Через буфер обмена можно копировать только текст (файлы, графика через буфер веб клиента не копируются).
Возможные проблемы с веб клиентом Remote Desktop
При входе на RD Web Access вы видите список опубликованных приложений Remote App, но при попытке запуска любого из них появляется ошибка:
Oops, we could not connect to Calculator. The connection to the remote PC was lost. This might be because of a network connection problem. If this keeps happening, ask your administrator or tech support for help.
Не удалось подключиться к Calculator Потеряно подключение к удаленному компьютеру. Возможно, есть проблема с сетевым подключением. Если это будет повторяться, обратитесь за помощью к своему администратору или специалисту службы технической поддержки.
Также может быть ошибка:
The web client needs a Remote Desktop Gateway to connect to desktops and apps.
Эти ошибки возникают, если вы развернули ферму RDS без шлюза RD Web Gateway. Если у вас развернут только RD Connection Broker, нужно привязать ваш сертификат RDS на порт 3392. (см описание в разделе Connecting to RD Broker without RD Gateway in Windows Server 2019 — https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin).
Ошибка:
Your session ended because an unexpected server authentication certificate was received from the remote PC. Ask your admin or tech support for help.
Ваш сеанс завершен, так как от удаленного компьютера получен непредвиденный сертификат проверки подлинности сервера. Обратитесь за помощью к своему администратору или специалисту службы технической поддержки.
Проверьте корректность вашего RD сертификата (FQDN сервера, которые используется для запуска RD веб клиента должен содержаться в сертификате). Проверьте, что этот сертификат назначен на все роли в вашем развертывании RDS. Отдельно проверьте что этот сертификат задан в настройка сервера RDGW (вкладка SSL Certificates). Если возможно, используйте wildcard сертификат.
By Eric Geier
The first installment of this tutorial series took you through enabling the Remote Desktop feature on your Windows XP or Vista PC, which will let you remote into your computer with Microsoft’s Remote Desktop Connection client program. Before we discuss configuring your firewall and router, which will enable you to actually connect to your PC remotely, we will cover enabling Web access.
Instead of having to use the Remote Desktop Connection client, you can install and use the Remote Desktop Web Connection component, so you can bring up your PC remotely right within a Web browser. This way, the computer you’re using to remote into yours doesn’t have to have the client program installed.
This tutorial will show you how to set up this Web access.
Installing and Configuring Internet Information Services (IIS)
To activate Web access of your Remote Desktop connection, you must install the Internet Information Services (IIS) and Remote Desktop Web Connection components of Windows. The IIS component of Windows also lets you host Web sites and FTP connections. The Remote Desktop Web Connection component installs the necessary Web pages and scripts to the IIS server directory, giving you the Web page interface for your remote desktop.
Here’s how to install IIS on Windows Vista:
- Click the Start button and choose Control Panel.
- On the Control Panel window, click the Programs category.
- Under the Programs and Features section, click the Turn Windows features on or off link.If User Account Control is enabled, select an account and enter a password, if required, and click Continue on the prompt.
- On the Windows Features dialog box that appears, expand the Internet Information Services category by clicking its plus sign, and then expand the Web Management Tools and World Wide Web Services options.
- As Figure 1 shows, under the Web Management Tools section, select the IIS Management Console checkbox, and under the World Wide Web Services section, select Common Http Features.
- These are the only required components for Web access for your Remote Desktop.
- Click OK.
For Windows Vista, you must also download and install the Remote Desktop Connection Web software from Microsoft’s site. Install the software to the default root directory of IIS; for example: C:\inetpub\wwwroot\. The software should create a new folder (TSWeb) in this directory.
If you’re using Windows XP, here’s how to install IIS and the Remote Desktop Web Connection components:
- Click the Start button and choose Control Panel.
- On the Control Panel window, click Add or Remove Programs.
- On the left side of the Add or Remove Programs windows, click Add/Remove Windows Components.
- On the Windows Components Wizard, select the Internet Information Services (IIS) entry, and then click the Details button.
- On the Subcomponents list, select the World Wide Web Service, and then click the Details button.
- On the Subcomponents list, mark the Remote Desktop Web Connection check box, and then click OK.
- On the Windows Components Wizard, click Next. Then click Finish when the wizard has completed.
Before you start using IIS, make sure you’re loaded with all the appropriate security patches. Activating the World Wide Web Service (which opens up port 80) without all the updates makes your computer and network much more susceptible to hackers and infections. Immediately check for updates using Windows Update via the Control Panel. You should also enable, if you haven’t already, Automatic Updates so your system will always be up-to-date.
Another way to make your computer more secure when using IIS is to change the default TCP port 80 to some other random port of your choosing. This optional modification can make it a bit more difficult for hackers to find your port that you’re opening up to the World. However, if you are using your computer and IIS as a Web server to host Web pages (other than Remote Desktop Connections), you’ll likely want to stick with using the default port 80.
If you prefer to change the port used by IIS in Windows Vista, follow these steps:
- Click the Start button and select Control Panel.
- On the Control Panel window, click the System and Maintenance category.
- Click the Administrative Tools icon.
- Double-click the Internet Information Services (IIS) Manager icon.
- On the Internet Information Services (IIS) Manager window, click the plus signs to expand your computer name and the Web Sites folder.
- As shown in Figure 2, click the Default Web Site entry and then click the Bindings… link under the Edit Site section, on the Actions pane.
- On the Web Site Bindings dialog window, select the entry and hit the Edit button.
- Change the value for the Port field and click OK. Choose a value you can easily remember, maybe the month and day of your birthday or anniversary. You’ll need to know this number each time you go to connect to your Remote Desktop Connection via the Web browser.
Here’s how to change the port used by IIS in Windows XP:
- Click the Start button and select Control Panel.
- On the Control Panel window, click the Performance and Maintenance category.
- Click the Administrative Tools icon.
- Double-click the Internet Information Services icon.
- On the Internet Information Services window, click the plus signs to expand your computer name and the Web Sites folder.
- Right-click the Default Web Site entry and then click Properties.
- On the Web Site tab of the Default Web Site Properties window, change the value for the TCP Port field. Choose a value you can easily remember, maybe the month and day of your birthday or anniversary. Again, you’ll need to know this number each time you go to connect to your Remote Desktop Connection via the Web browser.
- When you’re done, click OK.
Stay tuned — the next installments will show you how to configure your firewall and router so the remote connections will work.
About the Author: Eric Geier is the Founder and President of Sky-Nets, Ltd., a Wi-Fi Hotspot Network. He is also the author of many networking and computing books, including Home Networking All-in-One Desk Reference For Dummies (Wiley 2008) and 100 Things You Need to Know about Microsoft® Windows Vista (Que 2007).
Eric Geier is a freelance tech writer. He’s also the founder of NoWiresSecurity, providing a cloud-based Wi-Fi security service; Wi-Fi Surveyors, providing RF site surveying; and On Spot Techs, providing general IT services.
Коллеги, добрый день. Сегодня мы поговорим о том, как можно предоставить удаленный доступ нашим дорогим пользователям к внутренним ресурсам организации из сети интернет. Обсудим плюсы и минусы подходов, узнаем нюансы конфигурации и эксплуатации сервисов.
Сначала познакомимся с ролью 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.
Следующим этапом мы займемся конфигурацией сертификатов.
В результате выполненных действий, статус изменится на Готово к применению.
Проверяем подключение со стороны клиента
Поздравляю, мы произвели необходимый минимум для работы Remote Desktop Gateway. Теперь можно проверять как технология выглядит со стороны внешнего пользователя, которому очень хочется получить удаленный доступ.
Для этого пользователю понадобиться выполнить подключение через RDP клиент. Введем внешнее имя нашего шлюза, которое мы указывали при конфигурации. Также включим настройку Использовать мои учетные данные шлюза удаленных рабочих столов для удаленного компьютера для того, чтобы не вводить одни и те же учетные данные несколько раз.
Также необходимо определить внутренний хост к которому необходимо подключиться с указанием учетных данных.
Так выглядит подключение к шлюзу через стандартный RDP клиент Windows.
В процессе подключения мы можем увидеть предупреждение о невозможности идентифицировать шлюз. Подобное ошибка обязательно возникнет если клиент не доверяет сертификату шлюза удаленных рабочих столов.
В конечном итоге клиент выполняет RDP соединение с интересующим его хостом, который находится позади шлюза.
Мониторинг удаленных подключений
Для того, чтобы узнать информацию об успешных или неудачных попытках подключения к шлюзу мы можем воспользоваться инструментом Просмотр событий. Нужную нам информацию мы найдем журналах Безопасность и Microsoft-Windows-TerminalServices-Gateway.
Для примера я произведу 2 попытки входа.
Первая — учетные данные некорректны.
Вторая — учетные данные корректны.
Нюансы эксплуатации
В ходе изучения технологии я столкнулся с несколькими нюансами которые желательно знать перед вводом в эксплуатацию.
Необходимость решения вопроса с 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.
Для этого воспользуемся способом установки через развертывание служб удаленных рабочих столов и добавим управляемый хост в Диспетчере серверов.
Теперь перейдем к установке роли 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. Так как мы разворачиваем тестовый стенд, нам проще создать новый самоподписанный.
После этого нам необходимо найти его в оснастке Сертификаты учетной записи компьютера в виде ключевой пары .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/
Запустим, единственный в нашем случае, опубликованный ресурс.
Также, для полноты картины, я решил добавить в статью подключение с устройства под управлением Linux.
Для этого точно также запускаем веб-браузер и вводим внешний fqdn-адрес:
https://ext-lab-rdgw1.party.hard/RDWeb/webclient/
Подключение к хостам вне коллекции 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 попытки входа.
Первая — учетные данные некорректны.
Вторая — учетные данные корректны.
При использовании инструментов для автоматизации процесса можно получить более удобный мониторинг и интегрировать его в другие сервисы (напр. Zabbix).
Нюансы эксплуатации
Отсутствие возможности копирования файлов
К сожалению, на момент публикации статьи в компоненте отсутствует возможность копировать файлы между системами. Возможно, в вашей рабочей деятельности это будет являться важным фактором, поэтому это стоит учитывать.
Двойное RDP подключение к хостам вне коллекции RDS
На текущий момент мне не удалось напрямую подключиться к узлам, которые не находятся в RDS коллекции. Пока что мне известен только способ через двойное подключение, где в качестве прокси будет использован RDSH узел. Для пользователя использование этого метода может стать причиной низкого быстродействия удаленного подключения.
Некорректная работа с NAT
При эксплуатации была выявлена проблема, при которой не удавалось установить соединение с RDSH узлами. В ходе диагностики выяснилось, что если доступ к узлу с компонентом Web Client осуществляется с помощью трансляции портов отличных от 443, то подключение не может быть установлено. Если транслировать внешний порт 443 в такой же внутренний, то подобной проблемы не возникает.
Итоги
Мнение
В ходе знакомства с технологиями у меня сложилось впечатление того, что они неплохо друг друга дополняют и могут практически полностью закрыть потребности как пользователей, так и администраторов.
Большой удачей является тот факт, что обе технологии могут работать вместе в гибридном варианте. Более того, они работают через один порт и через один и тот же сервис IIS, который устанавливается при развертывании, что также упрощает жизнь специалистам по эксплуатации.
Как уже упоминалось выше, при использовании некоторых хитростей можно расширить зону применения (публикация rdp клиента для дальнейшего подключения на компьютеры не входящие в коллекции) и предоставить нашим коллегам удаленный доступ вне зависимости от типа и конфигурации их ОС.
Также администраторы получают возможность централизовано (через свойства коллекций или Active Directory) управлять доступом и заниматься мониторингом подключений. Это очень удобно с точки зрения интеграции с уже существующей инфраструктурой. У специалистов по эксплуатации отпадает необходимость дружить другое ПО с учетными данными пользователей в Active Directory.
Коллеги! Если у вас есть замечания или дополнения по предмету этой статьи, прошу оставить комментарий. Возможно, они кому-то пригодятся в будущем.