В общем выпустил сертификат для шлюза удаленных рабочих столов, на нем же стоит роль 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 работает на ура и ни на что не ругается. Как все-таки в статье сделали все с помощью одного сертификата с внешним именем...
