Windows Server 2008 содержит немало нововведений, касающихся реализации служб сервера терминалов. Пожалуй, можно даже сказать, что изменился сам подход к идее использования доступа к удаленным приложениям через службы терминалов, размывающий грань между приложениями, запущенными локально, и исполняемыми на удалённом терминальном сервере.
Использование мобильных устройств и рост пропускных скоростей общедоступных соединений делает всё более востребованной необходимость доступа конечных пользователей к ресурсам корпоративной сети из любого места с помощью обычного подключения к интернету. Но эта же необходимость порождает и большую проблему — как в случае входа пользователя с компьютера, не являющегося членом корпоративной сети, обеспечить безопасность самой сети и её ресурсов. Использование традиционных VPN-подключений является достаточно безопасным с точки зрения защиты канала передачи данных, но таит в себе потенциальную угрозу прямого подключения к корпоративной сети компьютера, на котором может быть запущено злонамеренное ПО. Появляется и обратная проблема — например, когда пользователи организации смогут получить доступ к документам или данным, созданным удалёнными сотрудниками или клиентами «в дороге»?
Функционал сервера терминалов Windows Server 2008 расширен появлением новых служб — RemoteApp и TS Web Access. RemoteApp (Удаленные приложения служб терминалов) предоставляют доступ к приложениям, размещённым на сервере терминалов. Причём, для пользователя они выглядят так, как если бы они исполнялись в его системе — то есть ему показывается не рабочий стол удалённой системы с запущенными на ней приложениями, а приложения интегрируются в рабочий стол системы пользователя (с масштабированием окна и собственным значком приложения в панели задач). TS Web Access (веб-доступ к службам терминалов) позволяет использовать RemoteApp с помощью интернет-подключения. Помимо того, что с точки зрения пользователя, удалённые приложения имеют более привычный для него вид, это выглядит и более безопасным в использовании. Когда пользователю доставляется не рабочий стол системы, а отдельное приложение, администраторам уже не приходится продумывать вопросы наподобие таких — «сможет ли пользователь с помощью клавиатурных комбинаций запустить менеджер задач?» или «как запретить исполнение команды Выполнить?». Взглянем на эти новые службы поближе.
Простой пример TS Web Access
Для начала мы продемонстрируем работу служб TS Web Access в минимальном наборе и без излишней функциональности. В этом примере нам потребуется лишь Windows Server 2008 и клиент с версией RDC не ниже 6.1 (6.0.6001.x).
Для взаимодействия со службами удаленных приложений RemoteApp, развёрнутых на сервере терминалов Windows Server 2008, должен использоваться клиент RDC (Remote Desktop Connection, подключение к удаленному рабочему столу) версии 6.0 (6.0.6000.x) или более поздней. Клиент RDC с необходимой версией входит в состав ОС Windows Vista. Для Windows Server 2003 и Windows XP он доступен для скачивания и установки по адресу KB925876.
Однако для использования веб-доступа к службам терминалов TS Web Access потребуется версия клиента RDC не ниже 6.1 (6.0.6001.x), входящего в состав ОС Windows Server 2008, Windows Vista SP1 и Windows XP SP3. Причём, если для Windows Server 2008 и Vista SP1 этого вполне достаточно, то в случае использования Windows XP SP3 дополнительно потребуется разрешить использование элемента управления ActiveX при помощи правки реестра. Для этого в ключе
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings
необходимо удалить (или, например, просто переименовать) следующие два подключа:
{4eb89ff4-7f78-4a0f-8b8d-2bf02e94e4b2}
{7390f3d8-0439-4c05-91e3-cf5cb290c3d0}
Перезагрузки для вступления в силу изменений не потребуется. Использование веб-доступа к службам терминалов TS Web Access возможно лишь с использованием браузера Internet Explorer. При первом подключении в панели информации обозревателя Internet Explorer появится предупреждение, что активное содержимое веб-страницы было заблокировано. Необходимо щелкнуть панель информации, выбрать пункт Разрешить заблокированное содержимое и затем нажать кнопку Запустить элемент ActiveX.
Подготовка сервера включает в себя установку ролей сервера терминалов и веб-сервера IIS с последующей публикацией необходимых приложений. Отметим, что служба веб-доступа к серверу терминалов может быть размещена на отдельном физическом сервере, к которому будут подключаться интернет-пользователи (да и самих физических серверов терминалов может быть и несколько), но в данном примере мы объединим их «в одном флаконе».
Запускаем диспетчер сервера, щелкаем в левой панели строку Роли, затем переходим в правую панель и щёлкаем ссылку Добавить роли
На первой странице нажимаем кнопку Далее, на странице Выбор ролей сервера устанавливаем флажок Службы терминалов
и нажимаем кнопку Далее. Читаем дополнительные сведения, нажимаем кнопку Далее ещё раз. Теперь необходимо указать службы роли. Устанавливаем флажки Сервер терминалов и Веб-доступ к службам терминалов:
Для функционирования веб-доступа необходимо, чтобы на сервере были установлены компоненты веб-сервера IIS и служб активации процессов Windows. Если ранее они не были установлены, появится предложение добавить их в список устанавливаемых ролей.
Соглашаемся, нажав кнопку Добавить требуемые службы роли — нам же меньше работы — и нажимаем кнопку Далее. Знакомимся с предупреждением, что сервер терминалов рекомендуется устанавливать в систему до установки приложений, которые будут на нём развёрнуты, и опять нажимаем кнопку Далее.
На странице Метод проверки подлинности необходимо указать, каким образом будет проверяться клиент перед установлением подключения. Если все клиенты будут использовать операционные системы, поддерживающие протокол CredSSP (например, Windows 7 или Windows Vista), желательно установить требование проверки на уровне сети. Если необходимо обеспечить подключение клиентов и с Windows XP, то необходимо выбрать параметр Не требовать проверку подлинности на уровне сети.
Нажимаем Далее для перехода к странице определения типа лицензирования. Можно указать тип лицензирования сразу, или сделать это позже. В приведённых примерах мы оставим в стороне вопросы лицензирования сервера терминалов, тем более что в «тестовом» режиме (без существующего сервера лицензий) службы терминалов работоспособны в течение 120 дней. Поэтому устанавливаем переключатель в положение Настроить позже.
Снова кнопка Далее, откроется страница, позволяющая определить группы пользователей, которым будет предоставлено право подключаться к серверу терминалов.
В списке уже находится встроенная группа «Администраторы», вы можете добавить необходимые группы, воспользовавшись кнопкой Добавить. После завершения редактирования нажимаем Далее три раза, оставляя предложенные настройки ролей IIS как есть, и переходим к странице подтверждения со списком всего сформированного процесса установок. Если всё верно, нажимаем кнопку Установить, после чего начнётся сам процесс установки ролей сервера.
По завершении процесса появится предупреждение, что сервер необходимо перезагрузить. Соглашаемся, ждём, когда сервер будет перезагружен и окончательно настроен. Теперь необходимо установить и настроить приложения на сервер терминалов.
Как уже отмечалось, во избежание конфликтов, установку приложений следует производить после установки самого сервера терминалов. Если установка приложения осуществляется с помощью пакета установщика Windows msi, то никаких дополнительных действий не требуется. Для остальных случаев сервер терминалов должен быть переведён в режим установки приложений. Для этого необходимо устанавливать приложения с помощью средства Установка приложений на сервер терминалов, находящегося в панели управления, или вручную, переведя сервер в режим установки командой change user /install . В ручном режиме по окончании установки приложений на сервер выполните команду change user /execute.
Добавление приложений достаточно просто. Откройте Диспетчер удалённых приложений (Пуск — Администрирование — Службы терминалов или Диспетчер сервера — Роли — Службы терминалов), в окне Диспетчера щёлкните правой кнопкой мыши над списком Удалённые приложения RemoteApp (или выберите команду Добавление удалённых приложений в панели Действия).
Запустится мастер удалённых приложений. Нажмите кнопку Далее и установите флажки у необходимых приложений.
После того, как выбор будет закончен, нажмите кнопку Далее, затем Готово. Выбранные приложения появятся в списке окна Диспетчера RemoteApp. По умолчанию, все приложения в этом списке будут отображены в панели веб-доступа к серверу терминалов. Если вы хотите изменить такое поведение, выберите приложение и щёлкните его правой кнопкой мыши. В появившемся меню можно указать, будет ли опубликовано приложение на веб-портале,
посмотреть его свойства, выбрать команды удаления приложения или создания для него файлов RDP или установщика (для его последующего распространения).
Немного изменим параметры сервера терминалов. В окне Действия выберем команду Параметры шлюза служб терминалов и в окне диалога установим переключатель в положение Не использовать сервер шлюза служб терминалов — поскольку никакого шлюза у нас пока нет. Собственно, всё готово для начала тестирования работы TS Web Access. Запускаем на клиенте Internet Explorer, в адресной строке вводим: http://имя_сервера/ts. Чтобы выяснить, как именно происходит соединение, запустим на клиенте утилиту TCPView. При подключении к веб-порталу сервера терминалов появляется запрос на авторизацию. Отмечаем, что пока установлено обычное http-соединение (80-й порт TCP).
Указываем данные, необходимые для входа, (если заходим в первый раз, не забываем установить и запустить ActiveX, щёлкнув по появившейся панели информации в браузере) и попадаем на саму страницу веб-доступа:
Выберем щелчком мыши какое-нибудь приложение. Появится предупреждение, что удалённый веб-узел инициирует подключение. Нажимаем Подключить. Учётные данные для входа необходимо будет указать повторно. Если всё идет как следует, запустится выбранное приложение.
Заметим, что выглядит оно практически так же, как и локально запущенное, а связь с ним теперь осуществляется при помощи 3389 порта TCP (Управление удаленным рабочим столом). Причём, независимо от числа открытых приложений, все данные будут пересылаться по этому каналу.
Ну что ж, вроде всё работает. Однако, если в пределах «своей» сети, возможно, такого решения будет достаточно, то «выставление наружу» сервера терминалов в такой конфигурации для предоставления веб-доступа из интернета будет представлять собой явную угрозу безопасности всем ресурсам сети. Поэтому перейдём к рассмотрению второго примера.
Использование шлюза TS Gateway
Согласно народной примете, далеко не всякий пакет с 3389-го порта TCP может достичь системы, предназначенной для публичного использования в интернете. Устройства и программы, отвечающие за безопасность внутренних сетей, как правило, конфигурируются так, чтобы через них пропускался лишь трафик HTTP и/или HTTPS (порты 80 и 443 протокола TCP), блокируя потоки данных, пересылаемых по другим портам.
С помощью средств Windows Server 2008 можно создать шлюз служб терминалов — TS Gateway. Его роль заключается в инкапсулировании протокола RDP с последующей передачей пакетов по обычным HTTP-каналам, защищая их средствами SSL/TLS. Такая технология позволяет реализовывать безопасные подключения без использования VPN и изменения настроек файерволлов, снижающих уровень защиты сети.
Новая роль служб, появившаяся в Windows Server 2008 — TS Gateway — подобна прокси-серверу, с которым взаимодействуют серверы терминалов. TS Gateway имеет встроенные средства контроля входящих подключений и доступа к ресурсам внутренней сети. Только те пользователи, которым будет разрешён доступ к шлюзу, смогут подключиться к нему. Эти пользователи смогут использовать только разрешённые для них ресурсы. Для подключения пользователя может использоваться любой компьютер, который может выступать в роли клиента шлюза и поддерживает RDP.
Рассмотрим по порядку, как удалённый клиент, используя RDP-подключение, получает доступ к ресурсам сети.
- Пользователь запускает RDP-файл (в его роли может выступать сохранённый RDP-файл или ссылка с портала TS Web Access), указывающий на определённый ресурс во внутренней сети
- RDP-файл создаёт подключение к шлюзу, используя SSL-туннель
- Шлюз, в соответствии с политикой авторизации подключений (TS CAP), аутентифицирует клиента и проверяет его полномочия на возможность создания подключения
- В случае успешного завершения проверки клиента, он отправляет запрос на необходимый ресурс — удалённое приложение или подключение к удалённому рабочему столу компьютера, расположенного во внутренней сети
- Шлюз выполняет проверку запроса на соответствие политике авторизации ресурсов (TS RAP)
- Если проверка выполнена успешно, шлюз устанавливает внутреннее RDP-подключение к затребованному клиентом ресурсу. Весь дальнейший поток данных проходит через шлюз, который выполняет его преобразование, отправляя пакеты внутри сети по порту 3389, а в сторону клиента — инкапсулируя в SSL и отправляя их с 443 порта
Работу шлюза мы продемонстрируем на примере сети следующей конфигурации:
Здесь клиент RC1, расположенный на рисунке «за облаком», будет имитировать подключение из интернета к шлюзу TG1 (запись о адресе TG1 мы для простоты внесём в файл hosts клиента RC1). Моделировать устройства NAT или файерволлы в этом примере не будем, важно, что клиент RC1 и сервер терминалов TS1 расположены в разных сетях. TS1 и TG1 работают под управлением Windows Server 2008, клиент RC1 — Windows XP SP3 с RDP 6.1. Контроллер домена (в примере домен будет называться tstest.local) DC1 управляется Windows 2003 SP2, на нём, помимо DNS, работает центр сертификации предприятия tstestcertcenter (в принципе, ЦС для нашего тестирования необязателен, если использовать самозаверяющий сертификат), который является доверенным корневым центром сертификации для шлюза TG1.
Начнём с сервера терминалов TS1. На нём необходимо будет добавить роль сервера терминалов, установить и настроить приложения и сконфигурировать шлюз. Открываем Диспетчер сервера, переходим в левом окне в раздел Роли, в правом окне щёлкаем ссылку Добавить роли, нажимаем кнопку Далее. Отмечаем флажок Службы терминалов, два раза нажимаем кнопки Далее. Устанавливаем флажок Сервер терминалов (процесс лицензирования сервера терминалов, как и в первом примере, рассматривать не будем), нажимаем Далее два раза. Устанавливаем необходимый режим проверки подлинности на уровне сети (я поставил переключатель в положение Не требовать проверку подлинности), нажимаем Далее. Указываем тип лицензирования — Настроить позже, нажимаем Далее. Указываем, кто сможет подключаться к серверу терминалов (Пользователи домена), нажимаем Далее и Установить. Ждём, когда работа мастера будет закончена, перезагружаем сервер, и дожидаемся окончания процесса конфигурирования.
Теперь перейдём к серверу, который будет использоваться в качестве шлюза. Для него также добавим роль служб терминалов, но в качестве служб роли (и ведь ничего не поделаешь с этой тавтологией — официальная терминология Майкрософт…) укажем Шлюз служб терминалов и Веб-доступ к службам терминалов. Соглашаемся с автоматическим добавлением установки дополнительных служб для указанных ролей и нажимаем кнопку Далее. Откроется страница выбора сертификата для SSL-шифрования. Пока установим переключатель в положение Выбрать сертификат позднее — мы сделаем это при конфигурировании шлюза.
На странице создания политик проверки подлинности переведём переключатель в положение Позднее (мы также настроим их чуть позже) и нажимаем Далее два раза. На странице выбора служб ролей убедитесь, что флажок Сервер политики сети установлен. Нажимаем три раза кнопку Далее, переходим к странице подтверждения и щёлкаем кнопку Установить для завершения процесса установки.
Установим сертификат, который будет использоваться веб-службами для установления SSL-подключений. В оснастке Администрирование выберите Диспетчер служб IIS. В левой панели щёлкните строку с именем шлюза, затем в центральном окне дважды щёлкните значок Сертификаты сервера, расположенный в группе IIS. Если в сети существует внутренний центр сертификации, можно использовать выданный им сертификат, или указать сертификат, выданный одним из доверенных общедоступных центров сертификации (для тестирования сети вполне подойдёт и вариант с созданием самозаверяющего сертификата). Мы установим сертификат, выданный центром сертификации предприятия, который расположен на DC1. Для этого в панели Действия выбираем команду Создать сертификат домена.
Указываем на первой странице мастера необходимые данные (в строке Полное имя укажите DNS-имя шлюза сервера терминалов, в нашем примере это tg1.tstest.local) и нажимаем Далее. Указываем расположение ЦС (для рассматриваемой сети это tstestcertcenter\dc1.tstest.local), вводим имя для сертификата, нажимаем Готово. Сертификат должен появиться в списке веб-сервера.
Переходим к собственно конфигурации шлюза: Администрирование — Службы терминалов — Диспетчер шлюза служб терминалов. В левом окне щёлкаем имя шлюза, затем в центральном окне — ссылку Просмотр и изменение свойств сертификата.
В открывшемся окне на вкладке Сертификат SSL нажимаем кнопку Обзор сертификатов, выбираем сертификат, полученный на предыдущем шаге для веб-сервера и нажимаем кнопку Установить. Центральное окно диспетчера должно стать таким:
Настроим политики авторизации, отмеченные желтыми предупреждающими значками. Для этого нажимаем расположенные рядом ссылки (или переходим в соответствующий раздел в дереве, расположенном в левом окне диспетчера; затем в панели действий выбираем ссылку Создать новую политику и щелкаем на команде Мастер). Указываем понятное имя политики TS CAP, метод проверки пользователя (пароль/смарт-карта), выбираем группы пользователей, которые смогут подключаться к шлюзу (а если необходимо — и группы компьютеров), задаём, если необходимо, как будет функционировать перенаправление клиентских устройств.
Похожие действия выполняем и для политики TS RAP, указывая группы пользователей, к которым она будет применяться, и задав ресурсы, к которым они смогут получить доступ (для доступа ко всем сетевым ресурсам выберите Разрешить подключение к любому сетевому ресурсу). Разрешённым для удалённых подключений внутри сети оставим 3389 TCP-порт.
Если мы сейчас зайдем с помощью браузера на веб-портал шлюза терминалов, мы увидим, что он работает, но абсолютно пуст. Вернёмся к серверу терминалов TS1. Установим на него необходимые приложения и добавим их в группу удалённых приложений RemoteApp — так же, как в первом примере. В Диспетчере удалённых приложений в панели Действия щёлкнем ссылку Параметры сервера терминалов, чтобы завершить его настройку. На вкладке Сервер терминалов проверим, что флажок Требовать проверку подлинности сервера установлен, а в поле Имя сервера укажем полное DNS-имя TS1 — ts1.tstest.local.
На вкладке Шлюз служб терминалов переводим переключатель в положение Использовать следующие параметры… и указываем имя шлюза и метод входа:
и нажимаем кнопку ОК. Поскольку сервер терминалов и шлюз у нас теперь расположены на физически разных серверах, в окне диспетчера выводится предупреждение, что в группе компьютеров веб-доступа к этому серверу терминалов нет никаких записей:
Открываем оснастку Управление компьютером, переходим в раздел Локальные пользователи и группы, и выбираем Группы. Найдите и двойным щелчком откройте группу Компьютеры веб-клиента сервера терминалов (TS Web Access Computers).
Нажмите кнопку Добавить, установите тип объектов Компьютеры, и добавьте компьютер, который является шлюзом сервера терминалов (в нашем примере это TG1).
Теперь, при нажатии ссылки Обновить в списке Распределение через веб-доступ к службам терминалов диспетчера удалённых приложений RemoteApp предупреждение должно смениться на сообщение о том, что группа компьютеров веб-доступа сформирована. Нам осталось зайти на веб-портал шлюза http://tg1.tstest.local/ts с учётной записью, принадлежащей к группе администраторов, перейти на вкладку Конфигурация и указать в зоне редактора имя сервера терминалов ts1.tstest.local, откуда веб-сервер шлюза будет получать список приложений, доступных удалённым веб-пользователям:
Ну что ж, теперь попробуем подключиться браузером с клиента RC1 к шлюзу TG1, указав в строке адреса http://tg1.tstest.local/ts. На запрос указываем учётные данные для подключения
Теперь вы должны увидеть в окне браузера список приложений, опубликованных для веб-доступа на сервере TS1. Попробуем запустить какое-нибудь из них. Появляется предупреждение, что издателя этого подключения определить не удаётся, но мы всё равно нажимаем кнопку Подключить. Вводим учётные данные для входа ещё раз… и получаем отказ!
Что же случилось? Ведь в первом примере подключение устанавливалось, даже несмотря на предупреждение, что издатель неизвестен? Мы уже не раз упоминали выше, что подключение к шлюзу из внешней сети будет происходить с помощью образования SSL-туннеля. Для его создания обе стороны — и сервер-шлюз, и удалённый клиент должны установить доверительные отношения. То есть клиент так же должен быть уверен, что отправляемые им учётные данные и пароль будут переданы безопасно и по назначению. Удостоверится в этом он может, если в своём хранилище доверенных корневых центров сертификации он обнаружит сертификат, выданный тем же центром сертификации, что и сертификат, пересылаемый клиенту с сервера-шлюза.
Чтобы клиент имел в своём распоряжении такой сертификат, на шлюзе TG1 запустите консоль MMC, добавьте оснастку Сертификаты, укажите, что она будет управлять учётной записью компьютера, компьютер — локальный. В разделе Доверенные корневые центры сертификации щёлкните Сертификаты и выберите сертификат выданный tstestcertcenter, щелкните его правой кнопкой мыши, выберите команду Все задачи, затем Экспорт.
Запустится мастер экспорта сертификатов. Указываем, что закрытый ключ экспортироваться не должен, нажимаем два раза кнопку Далее и указываем имя сертификата и место, где он будет сохранён. Нажимаем Далее, затем Готово. Теперь необходимо передать любым образом этот файл сертификата клиенту RC1. На клиенте достаточно щёлкнуть этот файл правой кнопкой мыши и выбрать команду Установить сертификат.
Система автоматически поместит этот сертификат в необходимое хранилище, достаточно будет пару раз нажать кнопку Далее. При последующем подключении соединение должно быть установлено. Осталось проверить, какие порты задействованы в подключении. Вот порты, которые использует удалённый клиент после установления подключения:
А вот что происходит в это же время на шлюзе:
Как видим, шлюз соединён с клиентом с помощью 443 порта TCP, а для связи шлюза с сервером терминалов используется порт 3389. Поскольку в примере использовался доступ к приложениям через веб-портал, начальное соединение клиента со шлюзом будет происходить по HTTP (TCP, 80-й порт). Если необходимо «закрыть» на шлюзе TCP-80 порт, то обеспечить публикацию приложений на клиентах можно с помощью создания RDP-файлов или пакетов msi установщика Windows.
На этих примерах мы продемонстрировали лишь базовые возможности Windows Server 2008 по созданию решений безопасного доступа к ресурсам внутренней сети из любого места, где есть интернет. Мы не уделяли внимание вопросам администрирования, применения групповых политик, аудита и некоторым другим аспектам, поскольку основной целью являлось лишь общее описание механизмов, позволяющих создавать такие безопасные подключения. И, безусловно, необходимо признать, что практическое применение описанных технологий возможно лишь в условиях достаточно современной вычислительной инфраструктуры.
Источник: http://www.windowsfaq.ru/content/view/717