В продолжение публикаций материалов из цикла «Записки системного администратора» или «Случай из практики» мой коллега из Белоруссии 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 возникает конфликт: в качестве адреса я указываю
1 |
https://195.222.xx.xx/rdweb (т.е. адрес роутера) |
а в сертификате подписанном сервером RDSH заданно имя server.company.net. Если бы я мог написать адрес в виде
1 |
https://server.company.net /rdweb |
то браузер без проблем принял бы сертификат. Но у комапнии нет такого доменного имени, а WebAccess использовать хотелось бы.
После продолжительных консультаций с умными людьми у меня вырисовалось два пути решения этой проблемы.
Способ 1. Используя самоподписанный сертификат
Это, так сказать, способ с «подменой». Я просто прописал в файле hosts, который находиться по адресу
1 |
C:\WINDOWS\system32\drivers\etc |
имя своего сервера и внешний IP-адрес к которому я подключаюсь. Получилась строка вида:
1 |
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
1 |
certutil -addstore My c:\mycrlfile.crl |
Замечу, что это можно сделать и через контекстное меню Проводника.
После установки сертификатов все стало хорошо и почти красиво:
Почти красиво- и заметьте в первом предупреждении в качестве издателя указан внешний IP-адрес, а во втором DNS-имя указанно как имя сертификата.
Однако на этом приключения не закончились- зайти на портал можно, но при попытке запустить приложения я получал следующую ошибку:
1 2 3 4 5 6 |
————————— Удаленное приложение RemoteApp отключено ————————— Не удается подключиться к удаленному компьютеру, так как на нем произошла ошибка. Обратитесь к администратору сети. ————————— ОК Справка |
Хотя ошибка явно указывала на сервер в журналах не было никаких ошибок, и самое загадочное, если с компьютера-клиента запускать файл RemoteApp напрямую, без WebAccess, то приложение запускалось. Более того, после запуска файла RemoteApp приложения начинали запускаться и через WebAccess- но ненадолго, через минуты 2-3 я снова получал ошибку. Поиски ничего не дали и я задал вопрос на форуме Technet. Среди прочих советов Юрий Винокуров, спросил в каком формате я ввожу имя пользователя. Я ввел учетные данные в формате
1 |
сервер\имя пользователя |
и все заработало! Ура!
По всей видимости здесь мы имеем дело с несогласованной работой аутентификации Windows и IIS.
Подведем итоги:
1. RD Gateway и RD Web Access вполне себе работают без внешнего доменного имени и без AD. Единственный сценарий при котором они работать не будут это попытка совместить работу на одном внешнем IP-адресе нескольких приложений использующих 443 порт, например RD-WebAccess и Exchange.
2. Последовательность действий:
Настроить сервер (RDSH, RD RemoteApp, RD Gateway, RD WebAccess), Выпустить сертификат с двумя адресами, настроить клиента- и можно работать.
3. Джентельмменский набор для настройки клиента:
— обновление 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