Поднимаем терминальный сервер с использованием сервера шлюза терминалов в Windows 2008R2

Terminal Services Gateway StructureНе так давно, мне была поставлена задача предоставить нескольким сотрудникам одной небольшой фирмы, удаленный доступ к рабочей базе 1С и документам через интернет. Типичное решение для такой задачи это установить на сервере все необходимые программы и предоставить сотрудникам терминальный доступ. Ранее во времена Windows 2003 для подобных целей, предварительно рекомендовалось поднять VPN-тунель, т.е. пользователь сначала подключался к частной рабочей сети, а уже затем устанавливал соединение с терминальным сервером по стандартному RDP-протоколу. В настоящее момент, с выходом операционной системы Windows 2008/2008R2 появилась замечательная возможность задействовать так называемый сервер шлюза терминалов Terminal Services Gateway, который обеспечивает существенно большую безопасность в работе, нежели это было ранее, при этом отдельно поднимать VPN-подключение не требуется.

Основные преимущества сервера шлюза терминалов:

  • Трафик между клиентом и сервером теперь передается по 443 порту с использованием SSL-шифрования, а в 2012 сервере уже можно поменять этот порт.
  • Шлюз служб терминалов обеспечивает подключение типа «точка-точка» по протоколу удаленного рабочего стола, вместо предоставления удаленным пользователям доступа ко всем внутренним сетевым ресурсам.
  • Шлюз служб терминалов позволяет удаленным пользователям подключаться к внутренним сетевым ресурсам через брандмауэры, размещенные в частных сетях, и трансляторы сетевых адресов (NAT). При использовании шлюза сервера терминалов не нужно выполнять дополнительную настройку сервера шлюза или клиентов для этого сценария.
  • В предыдущих версиях Windows Server средства защиты блокировали подключение удаленных пользователей к внутренним сетевым ресурсам через брандмауэры и трансляторы сетевых адресов. Это было обусловлено тем, что порт 3389, который используется для подключения к удаленному рабочему столу, обычно блокируется для обеспечения сетевой безопасности. Вместо этого шлюз служб терминалов передает трафик удаленного рабочего стола на порт 443 с помощью HTTP-туннеля SSL/TLS. Поскольку многие организации открывают порт 443 для обеспечения подключения к Интернету, шлюз служб терминалов использует такую структуру сети для поддержки удаленных подключений через несколько брандмауэров.
  • Появились дополнительные политики авторизации удаленных пользователей для подключения к внутренним ресурсам сети.

И так у нас имеется работоспособный сервер с установленной операционной системой Windows 2008R2. Сетевое имя — TSG1. Сервер не является членом домена, по причине отсутствия в сети контроллера домена, хотя его наличие желательно, по причине о которой я расскажу ниже. В нашу задачу входит, предоставить одной группе пользователей полный доступ к рабочему столу, для редактирования документов и работы в офисных приложениях типа MS Office, 1С, а другой группе пользователей будет предоставлен только доступ в 1С посредством публикации в RemoteApp. Соответственно порядок выполнения нашей задачи будет состоять из следующих шагов:

1) Установка служб терминала (Terminal Services) и лицензий этих служб на сервере терминала.

2) Настройка лицензирования служб терминала (Terminal Services Licensing).

3) Настройка режима лицензирования служб терминала (Terminal Services Licensing Mode).

4) Установка сервиса шлюза служб терминала (Terminal Services Gateway Service) на шлюзе TS.

5) Создание и настройка шлюза на использование сертификата TS.

6) Создание политик авторизации соединений и авторизации шлюза TS. (TS СAP и TS RAP)

7) Конфигурирование узла сеанса рабочих столов.

8) Настройка клиента RDP на использование шлюза TS.

9) Настройка RemoteApp и публикация 1С. Создание ярлыка подключения.

1) Установка служб терминала (Terminal Services) и лицензий этих служб на сервере терминала.

Заходим в Server Manager нажимаем Add Roles, выбираем Remote Desktop Services (Службы удаленных рабочих столов).

TS - Select Service Role

Затем на следующем экране нажимаем Далее, и отмечаем чекбоксы напротив: Remote Desktop Session Host (Службы удаленных рабочих столов) и Remote Desktop Licensing (Диспетчер лицензирования удаленных рабочих столов). Мы можем так же выбрать  устанавливать сразу Remote Desktop Gateway, поскольку данная служба будет работать на этой же машине (в идеале вынести на отдельный сервер), но для понимания процесса, лучше  оставим установку шлюза на потом.

TS - Select Service Role 2

На экране Authentication выберем метод аутентификации: На уровне сети, который поддерживают только клиенты начиная с Windows Vista SP1 и выше для этого отметим первый пункт Require Network Level Authentication, либо выберем пускать клиентов с любой версией клиента RDP, для этого выберем пункт Do not require Network Level Authentication. В моем случае, на всех клиентах установлена Windows 7 SP1, поэтому выбираем первый вариант.

RDP - Select authentication level

На экране Licensing Mode выберем способом лицензирования Client Access License (CAL), на устройство, на пользователя или настроить позже. Для наглядности процесса настроим лицензирование позже через консоль. Выбираем Configure Later (Настроить позже). Подробнее о лицензировании смотрим тут.

RDP - Specify Licensing Mode

Далее в разделе User Groups можно выбрать группы пользователей, которым будет разрешено подключаться к серверу терминалов. Настроим группу пользователей позже. Группе администраторов доступ дан по умолчанию.

На экране Client Experience мы можем включить такие параметры как передача аудио и видео потока, звукозаписи, элементов Windows Aero. В корпоративной среде, такие излишества ни к чему, поэтому, оставляем по умолчанию и жмем Далее.

На следующем экране RD Licensing Configuration (Режим Лицензирования)  выбираем границы обнаружения для сервера лицензирования. Рабочая группа, домен или лес (несколько доменов). Оставляем данный шаг по умолчанию, хотя мы могли бы отметить This workgroup поскольку в нашем случае домен не используется. Но Microsoft выдает предупреждение о том, что не рекомендуется конфигурировать область для сервера лицензирования сейчас, а лучше для этого воспользоваться консолью Remote Desktop Session Host Configuration позже, поэтому оставляем по умолчанию и жмем далее.

RDP - Configure Discovery Scope for RD Licensing

Обнаружение на уровне рабочей группы доступно только в том случае, если компьютер, на котором устанавливается служба роли Лицензирование служб терминалов, не является членом домена.

Обнаружение на уровне домена и на уровне леса доступно только в том случае, если компьютер, на котором устанавливается служба роли Лицензирование служб терминалов, является членом домена.

Если выбрано обнаружение на уровне домена, серверы терминалов могут автоматически (без дополнительной настройки) обнаруживать сервер лицензирования в пределах своего домена только в том случае, если он установлен на контроллере домена. Службу роли Лицензирование служб терминалов не обязательно устанавливать на контроллере домена, однако в таком случае серверы терминалов в домене не смогут автоматически обнаруживать сервер лицензирования. Для настройки обнаружения на уровне домена необходимо войти в домен, членом которого является сервер лицензирования, с учетной записью администратора домена.

На экране Confirmation (Подтверждение) соглашаемся со всеми предупреждениями которые нам выдает мастер, в частности предупреждение о том, что возможно для корректной работы приложений в окружении сеанса служб терминала их потребуется переустановить и о том что расширенные настройки безопасности IE будут выключены, затем нажимаем Install и в конце соглашаемся с перезагрузкой.

После перезагрузки дожидаемся завершения работы мастера служб терминала, так же мы можем увидеть всплывающее сообщение в правом нижнем углу, говорящее о том что служба лицензирования у нас не настроена. Поэтому следующим нашим шагом будет как раз настройка этой службы.

RDP - Installation Result

RDP7- message

2) Настройка лицензирования служб терминала (Terminal Services Licensing).

На данном этапе нам необходимо сначала активировать сервер лицензий, а затем добавить клиентские лицензии доступа (на пользователя или устройство) и указать их количество.

Запускаем консоль Remote Desktop Licensing Manager.

RD Licensing Manager

Активируем сервер щелкнувшись правой кнопкой по имени компьютера и выбором пункта Activate Server. Запустится мастер на первом шаге которого нам предложат выбрать тип подключения, оставим выбирать автоматически и жмем далее.

Activate Server Licensing

На следующем этапе вводим регистрационную информацию о своей компании. Нажимаем Next, дожидаемся завершения активации.

Activate Server Licensing 2

Сразу после активации сервера, мастер предложит установить клиентские лицензии.

Activate Server Сomplete

Но мы пока снимем галочку и нажмем закрыть. Для наших тестовых целей мы воспользуемся одним трюком, который позволит нам получить клиентские лицензии, но данный метод не стоит рассматривать как руководство к действию :)

Переходим по ссылке. Выбираем Установить клиентские лицензии доступа. Жмем Далее.

  Select User CAL

В поле 'Идентификатор сервера лицензирования' указываем свой License Server ID, который мы получили ранее во время активации сервера лицензий. Заполняем поля помеченные звездочкой и снова жмем далее.

Select User CAL 2

На следующей странице в поле тип продукта выбираем Клиентская лицензия служб удаленных столов «на пользователя» для Windows Server 2008R2, указываем количество и одно из соглашений Enterprise agreement, например 6565792, 5296992, 3325596 или любое другое найденное в сети. Нажимаем два раза Далее.

Select User CAL 3

В конце мы получим код пакета лицензионных ключей, который мы должны указать на самом последнем этапе лицензирования пользовательских лицензий. Хотя на данный момент в процессе написания данного обзора, я ничего более не вводил, а всего лишь указал мастеру все те параметры которые были указаны на сайте. Итак снова запускаем мастер Install License.

В поле, программа лицензирования выбираем Enterprise agreement, жмем Далее.

Install Licenses Wizard

В поле Agreement Number указываем тот же самый номер соглашения. На странице, версия продукта и тип лицензии, выбираем версию продукта Windows Server 2008 и тип лицензии Windows Server 2008 TS Per User CAL (для каждого пользователя) и указываем количество доступных лицензий, например 50. Идем дальше :)

Licenses Type

 После чего в консоли RD Licensing Manager, должны получить следующую картинку. Переходим к следующему этапу.

RD Lisence Manager

3) Настройка режима лицензирования служб терминала (Terminal Services Licensing Mode).

Переходим в Administrative Tools > Remote Desktop Services > Terminal Service Configuration>Remote Desktop Session Host Configuration.

Licensing mode

Заходим в свойства Licensing. Укажем серверу режим лицензирования Per User (Для каждого пользователя) и укажем сервер лицензирования ниже. Жмем ОК.

Licensing mode properties

Проверим статус лицензирования в Licensing Diagnosis (Диагностика лицензирования). Опустимся чуть ниже щелкнувшись по имени сервера. Чуть ниже можно увидеть результаты диагностики.

Licensing Diagnosis

4) Установка сервиса шлюза служб терминала (Terminal Services Gateway Service) на шлюзе TS.

Итак, переходим к установке службы шлюза Terminal Services Gateway. Установку шлюза будем производить на этом же сервере, хотя в идеале самый параноидальный и правильный с точки зрения Microsoft вариант, это установка сервера шлюза терминалов на отдельном компьютере (виртуальной машине) и вынос его за пределы локальной сети в демилитаризованную зону (DMZ). Запускаем Server Manager, переходим в Remote Desktop Services > Add Role Services > Remote Desktop Gateway после чего запустится мастер, предлагающий так же установить дополнительные службы необходимые для работы шлюза. Соглашаемся нажатием кнопки Add Required Role Services.

Add Role Services

На следующей странице Choose a Server Authentication Certificate for SSL Encryption (Выберите сертификат аутентификации сервера для шифрования SSL) выберем опцию Choose a Certificate for SSL encryption later (Выбрать сертификат для SSL шифрования позже.) Жмем Next.

Choose a certificate

На странице Create Authorization Plicies for RD Gateway (Создание политик авторизации для TS шлюза) выберем опцию Later (Позже).

Create RD policies

Нажимаем несколько раз далее, на странице Role Services убедимся, что галочка напротив Network Policy Server (Сервер сетевой политики) включена.

Network Policy Server

Жмем Далее, на последнем экране Confirm Installation Selection (Подтверждение выбранных компонентов) мастер нам напомнит, что Сервер шлюза терминалов не может быть использован без сертификата и политик авторизации. Жмем Install и дожидаемся окончания установки. В конце нажимаем закрыть и соглашаемся с перезагрузкой.

5) Создание и настройка шлюза на использование сертификата TS.

Поскольку домена у нас нет и тем более доменного CA, то будем создавать самоподписанный сертификат. Заходим в Remote Desktop Gateway Manager, переходим на вкладку SSL Sertificate, жмем Greate and Import Certificate.

Create SSL Certificate

В появившемся окошке, обязательно вводим имя сервера, которое должно соответствовать полному доменному имени вашего сайта (FQDN), например tsgserver.company.com или публичному ip-адресу вашего интернет-шлюза. Жмем ОК.

SSL Create Certificate 2

 Затем Apply.

 SSL Correct Install

6) Создание политик авторизации соединения и авторизации ресурсов шлюза TS. (TS СAP и TS RAP)

Сначала создадим политику авторизации соединения Сonnection authorization policy (CAP), которая позволяет контролировать, кто сможет подключаться к серверу терминала через шлюз TS. Для этого в консоли Remote Desktop Gateway Manager нажимаем Create Connection authorization policy запустится мастер создания новой политики. Зададим имя политике, например General CAP, на вкладке Recuirements укажем метод аутентификации, зададим группу пользователей которой будет разрешен доступ к терминальному серверу через шлюз TS, так же можно указать и группы компьютеров.

Create CAP

На вкладке Device Redirection укажем для какиx клиентскиx устройств необходимо разрешить или запретить перенаправление либо оставить параметр по умолчанию — Разрешить перенаправление устройств для всех клиентских устройств. На вкладке Timeouts, укажем временные параметры бездействующего и активного сеансов. После настройки нажимаем ОК.

Теперь создадим политику авторизации ресурсов Resource Authorization Policy (RAP). RAP используется для контролирования того, к каким серверам терминала можно получить доступ через шлюз TS. Нажимаем Create resource authorization policy, задаем имя политики, например General RAP. На вкладке User Groups укажем группу пользователей к которым будет применяться данная политика, на вкладке Network Resource можно задать три из возможных варианта доступа к серверам терминала. Есть возможность выбрать определенную группу компьютеров Active Directory, или создать управляемую группу шлюза TS, либо разрешить пользователям подключаться к любому ресурсу (компьютеру) сети, что позволит пользователям подключаться ко всем серверам терминала в сети. Поскольку у нас только один сервер, то выбираем третий вариант. На вкладке Allowed Ports можно задать порт отличный от по умолчанию. Если указать нестандартный порт, то сделать это надо будет и на клиенте. Нажимаем ОК, что бы создать политику. После чего в окошке RD Gateway Server Status увидим, что политики активны и сервер шлюза терминалов готов принимать входящие подключения.

General CAP & RAP Active

7) Конфигурирование узла сеанса рабочих столов.

Запускаем оснастку «Конфигурация узла сеансов удаленных рабочих столов». Открываем свойства подключения RDP-Tcp, на вкладке Genearal (Общие), должным образом настроим безопасность подключений между клиентом и серверов RDS Session Host или проще говоря RDP-сессий. Доступно три варианта безопасности.

  • Самый низкий «RDP Security Layer» (Уровень безопасности RDP) использует собственное RDP-шифрование. Сервер RD Session Host не проходит проверку подлинности.
  • Negotiate (Согласование) — режим используемый по умолчанию  уровня TLS 1.0 (SSL). Данный вид шифрования будет использоваться, если клиент его поддерживает. Если нет, сеанс перейдет обратно на RDP безопасность.
  • TLS 1.0 (SSL). В данном варианте шифрование будет использоваться для проверки подлинности сервера и шифрования данных, передаваемых между клиентом и Session Host сервером. Это самая безопасная опция, рекомендуется выставить её.

Чуть ниже зададим  уровень шифрования. Доступно 4-варианта:

  • Low (низкий) — использует 56-разрядное шифрование для данных, пересылаемых с клиента на сервер. Не шифрует данные, пересылаемые с сервера клиенту. Не рекомендуется к использованию.
  • Client Compatible (Совместимый с клиентом) — это опция по умолчанию. Она шифрует данные передаваемые между клиентом и сервером с самым надежным ключом, который поддерживает клиент.
  • High (Высокий) — эта опция шифрует данные в обоих направлениях между клиентом и сервером с помощью 128-битного шифрования. Следует использовать в среде содержащей только 128-разрядные клиенты, что в настоящее время уже не актуально.
  • FIPS Compliant (FIPS-совместимый) — эта опция шифрует данные передаваемые в обоих направлениях между клиентом и сервером с помощью FIPS 140-1 утвержденного алгоритма шифрования. Будет поддерживать современные симметричные алгоритмы и в явном виде не будет поддерживать RC2, RC4, одиночный DES, а также будет заставлять использовать для вычисления целостности (Message Authentication Code – MAC) алгоритм SHA-1, а не MD5. Рекомендуется к включению. В настоящий момент найти сервера, которые не умеют 3DES, AES или SHA-1 практически нереально.

Ниже отметим галочку Allow connection only from computers running Remote Desktop with Network Level Authentication (Разрешить подключаться только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровни сети). Это помогает защитить удаленные компьютеры от злоумышленных пользователей и вредоносного ПО. Чтобы использовать NLA, клиентский компьютер должен использовать операционную систему, которая поддерживает протоколы Credential Security Support Provider (CredSSP), то есть Windows XP SP3 и выше, а также иметь клиента RDC 6.0 или выше.

RDP - Security SettingsПри использовании уровня безопасности TLS 1.0 (SSL) выберем сертификат, либо нажмем кнопку «Default» (По умолчанию) что бы создать самозаверяющий сертификат.

На вкладке «Client Settings» (Параметры клиента) отключим перенаправление для устройств, которые не требуется для работы. Это делается, что бы клиенты с дефолтными настройками RDP Client не тратили время подключения на согласование неиспользуемого функционала.

RDP-Tcp Redirection Для того, чтобы сервер работал безопасно и предсказуемо (например, не начинал вдруг принимать подключения с нового,
«свежедобавленного» сетевого адаптера), необходимо в явном виде указать, на каких интерфейсах служба RDP-сервера должна принимать подключения. На вкладке Network Adapter (Сетевой адаптер) привяжем RDP к конкретному сетевому адаптеру.

8) Настройка клиента RDP на использование шлюза TS.

Перед созданием подключения необходимо предварительно установить сертификат созданный ранее, иначе получим сообщение о не допустимом центре сертификации. Добавим его в корневое хранилище центров сертификации.

Add Certificate

Так же на шлюзе/роутере/файрволе не забываем открыть 443 порт. Запускаем Подключение к удаленному рабочему столу (Remote Desktop Connection), в поле Computer задаем имя сервера терминалов, в поле User name,обязательно зададим параметры в формате имя компьютера\имя пользователя.

Remote Desktop Connection 1

Затем переходим на вкладку Advanced > Settings, отмечаем чебокс Use these RD Gateway server settings. Задаем имя сервера и метод входа в систему, я выбираю Спрашивать пароль (NTLM) нажимаем ОК. Если поставить галочку Bypass RD Gateway server for local addresses то соединение будет происходит в обход сервера шлюза терминалов.

Remote Desktop Gateway Settings

На вкладке Local Resources выберем устройства которые мы хотим перенаправлять в терминальную сессию. На вкладке Display, зададим параметры качества изображения, а на вкладке Experience параметры скорости соединения. После того, как все параметры настроены, нажимаем Save и ОК. Если все настроено правильно, то при подключении увидим следующую картинку.

Remote Desktop Connection Start

8) Настройка RemoteApp и публикация 1С. Создание ярлыка подключения.

RemoteApp — это программы, удаленный доступ к которым можно получить через службы терминалов и которые работают так, как будто они запущены на локальном компьютере пользователя.

Запускаем диспетчер удаленных приложений RemoteApp Manager, в левой части экрана на любом из пунктов нажимаем Change. Меняем параметры по своему усмотрению, в частности на вкладке Common RDP Settingsвыберем те устройства и ресурсы, которые мы будем использовать в ходе удаленного сеанса.

RemoteApp Common Settings

На вкладке Digital Signature (Цифровая подпись) можно указать серверу подписывать RDP-файлы с помощью цифрового сертификата, что позволит клиентам распознавать удаленные ресурсы организации и доверять им. Сертификаты могут быть SSL, сертификаты подписи кода или специально определенный сертификат подписи протокола рабочего стола либо SSL-сертификат шлюза удаленных рабочих столов. Поскольку у нас уже имеется SSL-сертификат шлюза удаленных рабочих столов то выбираем его. Данная опция, в процессе создания rdp-файлов мастером, автоматически подставит выбранный сертификат, если опция не активна, то сертификат надо будет указать вручную.

RemoteApp - Digital Signature

На вкладке RD Session Host Server укажем имя сервера, порт, зададим DNS-имя, если сервер терминалов используется в ферме. Если планируется использовать веб-доступ к службам терминалов (RD Web Access) то ставим галочку напротив Remote Desktop Access.

RemoteApp - RD Session Host Server

На вкладке RD Gateway укажем свои настройки сервера шлюза рабочих столов если используется, или оставим по умолчанию. Данный параметр так же будет автоматически подставлен в процессе создания мастером RDP-файлов. Активируем галочку Bypass RD Gateway server for local addresses, если подключение будет производится из локальной сети в обход сервера шлюза терминалов.

RemoteApp RD GatewayТеперь когда все параметры настроены, опубликуем удаленное приложение доступ к которому мы хотим получить. Наш сценарий предполагает предоставление некоторым пользователям доступ к программе 1С-Предприятие. Установку любых программ на терминальном сервере желательно производить при помощи специального режима RD-Install Mode, что гарантирует правильные записи в реестре и в INI-файлах для поддержки работы приложения в многопользовательской среде. Для этого в панели управления выбираем пункт Install Program from Floppy Disk or CD-ROM и следуем указаниям мастера.  После того, как программа установлена, для ее публикации на сервере, нам необходимо всего лишь запустить мастер публикации удаленных приложений нажатием кнопки Add RemoteApp Programs в правом верхнем углу в разделе Action, выбрать необходимое приложение из списка, согласится с параметрами и нажать Finish.

Add remote app program

После чего уже можно создавать непосредственно сам rdp-файл. Нажимаем Create .rdp-файл, запустится мастер, нажимаем Далее. Указываем путь для сохранения rdp-файлов. Как видим все остальные параметры, которые мы указывали ранее уже прописаны, нажимаем снова Next и Finish.

RemoteApp Wizzard

Полученный файл копируем на компьютер клиента и используем для запуска приложения.

Remote App - 1C Предприятие

Можно также дополнительно ограничить доступ к серверу терминалов и RemoteApp в частности при помощи локальных или групповых политик. Для этого запускаем редактор политик gpedit.msc. Переходим в Computer Configuration > Administrative Tools > Windows Components > Remote Desktop Services >Remote Desktop Connection Client. Здесь нас интересуют три политики:

  • Allow rdp files from valid publishers and user's default rdp settings (Разрешить RDP-файлы допустимых издателей, а также параметры файлов .rdp по умолчанию для пользователей.) — Включить
  • Allow rdp files from unknown publishers (Разрешить RDP-файлы от неизвестных издателей.) — Выключить
  • Specify sha1 thumbprints of certificates representing trusted .rdp publishers (Указать SHA1-отпечатки сертификатов, отражающие доверенных RDP-издателей.) — Указать отпечаток указанный в сертификате.

SSL Certificate SHA1

По идее, данная политика нужна для того что бы, при подключении к серверу не получать предупреждение о том, что программа  получена  от не доверенного издателя, но лично у меня даже после указания отпечатка, сообщение все равно появлялось :) Вполне возможно, данная политика работает только в домене.

Trusted Publisher

Если нажать галочку и подключится, то в разделе реестра HKCU\Software\Microsoft\Terminal Server Client\PublisherBypassList будет создан тот самый SHA1, здесь он указан без пробелов, в верхнем регистре и имеет на конце дополнительные символы. Казалось бы вот какой SHA1 отпечаток нужно указать в политике, но нет, сообщение по прежнему выскакивает :) Так или иначе, можно сделать экспорт ключа реестра и импортировать их на нужные компьютеры. После активации двух других политик, все удаленные приложения, включая любые другие rdp-файлы, не имеющие цифровую подпись будут отклоняться.

RemoteApp Access Denied

Оставить ответ

Войти с помощью: 

Вы можете использовать эти HTML тэги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  

*