Случай из практики — 5

Сегодня речь пойдет об укрощении технологий RD Gateway и RD Web Access в случае когда нет домена.

Дело №7 Непокорный WebAccess.

В один прекрасный летний день мне понадобилось настроить удаленный доступ к программам из филиалов в головной офис клиента. Сначала я склонялся к варианту с использованием 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-имя указанно как имя сертификата. Это происходит потому, что Первый сертификат использует RD Gateway, а второй «само подписанный» использует RDP сервер куда нас пробрасывает gateway.

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

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

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

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

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

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

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

1.RD Gateway и RD Web Access вполне себе работают без внешнего доменного имени и без AD. Единственный сценарий при котором они работать не будут это попытка совместить работу на одном внешнем IP-адресе нескольких приложений использующих 443 порт, например RD-WebAccess и Outlook Anywhere. (хотя вот здесь есть решение проблемы. А также на подходе клиент RDP 8.0 и возможность изменять порт подключений к RDG. Кому не терпится- можно почитать вот эту статью).

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