Публикация Remote Desktop Gateway в TMG 2010
 

Всем доброго времени суток! Есть такая задача: Нужно как-то настроить публикацию внутреннего шлюза удаленных столов в tmg 2010. Можно ли сделать подобную публикацию не имея внешнего вэб сервера(не считая хостера). Появилась идея создать во внешней dns зоне провайдера запись соответствия нового под домена одному из IP адресов самого forefront tmg 2010. Но как и что придумать дальше и можно ли пользоваться такой записью с целью поубликации вэб сервера, где будет прописано, что при обращении из-вне к этому поддомену, которому соответствует один из ip адресов TMG - не знаю. Погуглив всевозможные топики на счет шлюза - понял, что нужна своя PKI. Структуру развернул. Есть оффлайновый корневой УЦ и подчиненный корпоративный УЦ. Ясно что нужно выдать сертификат для шлюза удаленных рабочих столов и экспортировать его на TMG. Пока этого не делаю - т.к. не понятно прокатит ли внешнее fqdn адресованное на TMG.

Все это делается потому что есть задача, чтобы удаленные пользователи более безопасно заходили в сеть предприятия. Т.е. планируется, если получится все-таки реализовать идею со шлюзом - установить аутентификацию на шлюзе с помощью смарт карт. Если есть конечно лучше идеи про аутентификацию со смарт-картами, скажем, без использования шлюза, очень интересно было бы почитать. Правда VPN не рассматриваю - руководство отвергло такой вариант. Спасибо и надеюсь на Вашу помощь!

Еще хотелось бы добавить пару ссылок на статьи, в которых как раз и рассказано как сделать такую публикацию. Но, прочитав их так и не понял, должен ли быть внешний вэб сервер или можно все-таки сделать как я описывал с правилом публикации. Еще в статье не понятно, почему в качестве шлюза указан, судя по имени, сам tmg... Ссылки даю на копии яндекса, т.к. оригинал уже недоступен, видимо в силу неуплаты за домен.
Часть первая:
http://yandex.ru/yandsearch?lr=213&t...ng-rd-part1%2F
Часть вторая:
http://yandex.ru/yandsearch?text=htt...art2%2F&lr=213

http://technet.microsoft.com/en-us/l...(v=ws.10).aspx - это изучили? Непонятно вообще, откуда Вы взяли информацию про веб-сервер.

Спасибо за ответ. Статью я эту читал... Во-первых в статье сначала пишут про то, что надо создать самоподписанный сертификат, и тут же пишут, что его надо экспортировать(не экспортируя закрытый ключ). Что в принципе абсурдно, т.к. закрытый ключ вообще не экспортируется, если используется самоподписанный сертификат, что сразу как-то отталкивает вообще от прочтения. Забавляет момент с фаилом hosts, в котором прописывается, что имя шлюза соответствует ip Tmg. И еще момент, судя по адресации там все машины из одной подсети(причем подсеть одинаковая как для корпоративной сети, так и для клиента. Понятно ,конечно, что внутренние адреса могут и совпадать, но все-таки бросается в глаза, т.к. даже если и у клиента дома и в корпоративной сети подсети совпали, то указание в hosts такой записи вообще тоже абсурдно). Но все-таки логика понятна, что имя шлюза должно соответствовать ip TMG для внешнего клиента. А про вэб сервер я имел ввиду, что публикуется он по правилу публикации ВЭБ, т.к. на шлюзе установлена IIS, что и делает его потенциальным вэб сервером. А сам вопрос, про который я писал наверху, остается открытым.

PS очень многого конечно не знаю и поэтому сразу прошу извинить за возможное невежество.

В статье описаны принципы того, как это должно работать.
Что в Вашем случае нужно сделать.

1. Создать во внешней DNS-зоне А-запись на один из белых IP-адресов TMG,
2. Получить у внутреннего СА сертификат, содержащий внешнее имя (см. п. 1),
3. Импортировать сертификат на TMG,
4. Создать правило публикации OWA, указав импортированный сертификат и внутреннее имя и/или RDG,
5. Проверить работу правила.

Спасибо за ответ. Все по пунктам верно и логично. Просто уже пытался проверить такую схему на работоспособность, правда с некоторыми отклонениями, в силу того, что еще один участник был - TS web access. и использовал статьи, ссылки которых указывал. Все делал как в статье, но правило не отрабатывало. Буду пробовать еще. Отпишусь после настройки.

Правило, скорее всего, не отрабатывает потому, что имя в сертификате не совпадает с "внешним" именем.

Да в том то и дело, что имя сертификата специально создавал в соответствии с именем поддомена, который прописал в днс зоне хостера. А самое интересное что если создавать правило публикации не вэб сервера(просто прослушка на 443 порту и проброс далее на сам шлюз) и использовать на всех участниках самоподписанный сертификат, то правило отрабатывается и проброс проходит )). Вроде бы все понятно, что и для чего делать, но есть сомнения в силу того, что в результате хотелось бы увидеть не просто подключение на рабочий стол или сервер терминалов, а чтобы через браузер(rd web access) сотрудник сам выбирал среди удаленных приложений приложение rdp, которое уже и пробрасывало на его рабочее место. Но почитав все статьи несовсем понимаю возможен ли такой вариант, т.к. если использовать rdp подключение, что в любом случае куда-то подключишься в итоге, будь то рабочая машина или сервер терминалов... В такой ситуации, наверно, глупо просто будет уже заходить на rd web access. Может все-таки возможен такой вариант, что будет создано просто соединение со шлюзом, без захода на Rdp и уже после того как прошел аутентификацию на шлюзе спокойно через браузер выбрать что нужно из удаленных приложений)) Или просто при заходе на rd web access проходить там аутентификацию... Т.е. в идеале, пока не удаленный пользователь не прошел аутентификацию, чтобы нельзя было зайти на rd web access через браузер. Конечно, в силу отсутствия опыта и нужных знаний конкретно в этих ролях могу и задавать глупые вопросы, просто надеюсь на понимание)) И если есть возможность, подскажите возможен ли такой вариант.

В общем выпустил сертификат для шлюза удаленных рабочих столов, на нем же стоит роль rd web access. Создал запись в публичном днс имя там соответствует Ip TMG. в поле кому выдан в сертификате - указано имя поддомена, которое записано в зону публичного днс(само имя шлюза естественно другое). Создал правило в котором указал в качестве внутреннего имени сайта внутреннее имя шлюза. В качестве публикуемого имени указала имя, которое прописывал на публичном днс. Правило не работает. При этом если использовать простое правило в котором опубликован 443 порт, все работает за исключение того, что при подключении к удаленному компьютеру, ругается на то что имя сертификата не соответствует имени компьютера(т.к в качестве шлюза и в качестве терминального сервера используется одна машина и получается, что сертификат записан на внешнее доменное имя, что естественно не соответствует имени самой машины). Вообще все пытался сделать исходя из этих статей:
1:http://www.isaserver.org/articles-tu...way-Part1.html
2:http://www.isaserver.org/articles-tu...way-Part2.html
Но в результате ничего не получается, т.к. ssl мост не проходит видимо из-за того, что TMG, если все сделать исходя из статьи, просто не реализует мост на основе https to https, т.к., сертификат и имя внутреннего сервера различаются. Сам TMG на это ругается, при тестировании правила. Хорошая статья, но если все делать в логике этой статьи, то попытка соединения всегда неудачна...И на данный момент вижу только такое решение, в котором удаленный пользователь может пользоваться ts web access, не подключаясь к удаленному рабочему на прямую через mstsc: сертификат все-таки выдать на внешнее публикуемое имя, а в настройках remote app указать использовать шлюз как имя, запись которого есть на публичном днс сервере. При таком раскладе, заходя на RD web access и последующей попытке запуска удаленного приложения, пойдет запрос к шлюзу. Проверено и работает. Остается только настроить политики на использование аутентификации на шлюзе на основе смарт-карт. Думаю, что достаточно безопасно, если использовать правильные etokenы(без возможности перехвата данных). Хотя все-таки очень хотелось бы, чтобы было все как в статье.... Еще интересный момент, поставил эксперимент и выдал шлюзу два сертификата один на вшенее публикуемое имя, а второй в соответствии с локальным именем компьютера. В Tmg указала в прослушивателе использовать сертификат внешнего имени, а на шлюзе установил сертификат с внутренним именем. В такой ситуации ssl мост https to https работает на ура и ни на что не ругается. Как все-таки в статье сделали все с помощью одного сертификата с внешним именем...

Вобщем вопрос решил. Добавил в сертификат шлюза удаленных рабочих столов альтернативное имя, где указал внутреннее имя шлюза. Правило в TMG и ssl мост теперь работает на ура. Единственный момент, что даже подключившись к серверу терминалов зайти на ts web access получается только после ввода логина и пароля, а не как в статье, где вроде бы после подключения к серверу терминалов через шлюз - можно просто заходить на ts web access и выбирать соответствующее приложение.