В продолжение публикаций материалов из цикла «Записки системного администратора» или «Случай из практики» мой коллега из Белоруссии volk123 поделился опытом настройки RD Gateway и RD Web Access в сети без домена.

В один прекрасный летний день мне понадобилось настроить удаленный доступ к программам из филиалов в головной офис клиента. Сначала я склонялся к варианту с использованием VPN-подключения, однако мне показалось интересным поработать с технологиями RD Gateway и RD Web Access. Аргументы для использования такого способа доступа — не надо устанавливать ПО для VPN, кроме того подключение через VPN требует открытого порта, что в условиях турецких и белорусских гостевых WiFi становится проблемой, а доступ к программам хотелось бы иметь везде.

Так как RemoteApp у меня уже был настроен и работал, осталось только настроить RD Gateway и RD Web Access.Я не буду утомлять вас подробностями установки- в интернете есть множество инструкций с картинками.

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

Сразу хочу предупредить, что в организации, о которой идет речь, нет домена, используется простая рабочая группа, правда все узлы имеют DNS суффикс вида company.net. Мне пришлось пробросить 443 порт с роутера на сервер терминалов, где у меня установлены все роли RD. Можно было конечно установить RD Gateway и RD Web Access прямо на роутер, но я решил не усложнять(кроме того роутера на самом деле два, они подключены последовательно, и установка ролей RD на второй роутер ничего бы не решила).

После проброса порта я создал правила RD CAP и RD RAP. Остальные настройки делаются в оснастке RemoteApp Manager. Сразу после настройки я решил подключиться к удаленному рабочему столу. Здесь все оказалось довольно просто, в качестве имени сервера к которому подключаешься надо указать внутреннее имя [1] сервера RDSH, а вот в качестве сервера RD Gateway придется указать внешний IP-адрес [3], поскольку внутренняя сеть без домена и к внешним DNS- именам никакого отношения не имеет.

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

Проблема возникла при попытке использовать RD Web Access. Я сразу опишу ее причину:

Так как Internet Explorer более тщательно относиться к проверке сертификатов, то при моей схеме подключения к RD WebAccess возникает конфликт: в качестве адреса я указываю

https://195.222.xx.xx/rdweb  (т.е. адрес роутера)

а в сертификате подписанном сервером RDSH заданно имя server.company.net. Если бы я мог написать адрес в виде

https://server.company.net /rdweb

то браузер без проблем принял бы сертификат. Но у комапнии нет такого доменного имени, а WebAccess использовать хотелось бы.

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

Способ 1. Используя самоподписанный сертификат

Это, так сказать, способ с «подменой». Я просто прописал в файле hosts, который находиться по адресу

C:\WINDOWS\system32\drivers\etc

имя своего сервера и внешний IP-адрес к которому я подключаюсь. Получилась строка вида:

195.222.xx.xx  server.company.net

После перезагрузки службы DNS я смог зайти на сайт RD WebAccess и в принципе можно было бы остановиться, но я пошел дальше.

Способ 2. Используя службу сертификации

Я установил компонент Active Directory Certificate Services, который несмотря на название не требует наличия AD.

На сервере RDSH я создал запрос на сертификат. Особенность сертификата в том, что он имеет атрибут SAN (Subject Alternative Name) [3], в котором выбран тип атрибута DNS и указан внешний IP-адрес к которому осуществляется подключение. Именно ради этого поля и устанавливалась роль ADCS, поскольку в самоподписанном сертификате дополнительных атрибутов добавить нельзя. Именно этот атрибут позволяет добавить множество имен и адресов [1] [3] к которым будет установлено доверие на основании всего лишь 1 сертификата.

Второй важный атрибут Enhanced Key Usage [2], я задал лишь свойство Server Authentication – сертификат нам нужен только для аутентификации.

На сервере с ADCS я выпустил сертификат, затем скопировал 2 сертификата (CA, сертификат для сервера RDSH). На сервере RDSH в оснастке RemoteApp Managemer я изменил самоподписанный сертификат на вновь выпущенный. На клиенте я также добавил сертификаты в локальное хранилище.

Первая попытка подключиться не удалась, поскольку я не учел одной важной вещи- если речь идет о самоподписанном сертификате, то он не требует списков отзыва (CRL), а вот сертификат подписанный CA уже требует. В моем новом сертификате даже указан путь к месту где храниться crl. Однако этот путь локальный:

*Еще раз повторюсь домена нет — имя компьютера DC01 на картинке — это задел на будущее.

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

certutil -addstore My c:\mycrlfile.crl

Замечу, что это можно сделать и через контекстное меню Проводника.

После установки сертификатов все стало хорошо и почти красиво:

Почти красиво- и заметьте в первом предупреждении в качестве издателя указан внешний IP-адрес, а во втором DNS-имя указанно как имя сертификата.

Однако на этом приключения не закончились- зайти на портал можно, но при попытке запустить приложения я получал следующую ошибку:

—————————
 Удаленное приложение RemoteApp отключено
 —————————
 Не удается подключиться к удаленному компьютеру, так как на нем произошла ошибка. Обратитесь к администратору сети.
 —————————
 ОК   Справка

Хотя ошибка явно указывала на сервер в журналах не было никаких ошибок, и самое загадочное, если с компьютера-клиента запускать файл RemoteApp напрямую, без WebAccess, то приложение запускалось. Более того, после запуска файла RemoteApp приложения начинали запускаться и через WebAccess- но ненадолго, через минуты 2-3 я снова получал ошибку. Поиски ничего не дали и я задал вопрос на форуме Technet. Среди прочих советов Юрий Винокуров, спросил в каком формате я ввожу имя пользователя. Я ввел учетные данные в формате

сервер\имя пользователя

и все заработало! Ура!

По всей видимости здесь мы имеем дело с несогласованной работой аутентификации Windows и IIS.

Подведем итоги:

1. RD Gateway и RD Web Access вполне себе работают без внешнего доменного имени и без AD. Единственный сценарий при котором они работать не будут это попытка совместить работу на одном внешнем IP-адресе нескольких приложений использующих 443 порт, например RD-WebAccess и Exchange.

2. Последовательность действий:

Настроить сервер (RDSH, RD RemoteApp, RD Gateway, RD WebAccess), Выпустить сертификат с двумя адресами, настроить клиента- и можно работать.

3. Джентельмменский набор для настройки клиента:

.Net Framework 3.5

обновление RDC с поддержкой 7.1 для WinXP и Vista клиентов

— 2 сетификата (Вашего центра сертификации и сертификат сервера RDSH)

— 1 файл списка отзывов CRL, если CRL не опубликован на веб-сервере

Проще ли это чем установить на клиенте приложение для VPN-cоединения решать вам. Однако на мой взгляд RD Web Access намного удобнее, как единая точка доступа к приложениям. Даже без разделения прав на приложения (эта функция доступна только при наличии AD).

PS. Решение проблемы с модальными окнами в RemoteApp описывается здесь http://blogs.technet.com/b/ai/archive/2012/01/16/remoteapp.aspx

Оригинал статьи