Remoteapp программа не найдена

Удаленные приложения RemoteApp служб терминалов Windows Server 2008, часть 2

Использование шлюза 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.

44. How to Fix Do you trust the publisher of this RemoteApp program

Рассмотрим по порядку, как удалённый клиент, используя RDP-подключение, получает доступ к ресурсам сети.

• Пользователь запускает RDP-файл (в его роли может выступать сохранённый RDP-файл или ссылка с портала TS Web Access), указывающий на определённый ресурс во внутренней сети
• RDP-файл создаёт подключение к шлюзу, используя SSL-туннель
• Шлюз, в соответствии с политикой авторизации подключений (TS CAP), аутентифицирует клиента и проверяет его полномочия на возможность создания подключения
• В случае успешного завершения проверки клиента, он отправляет запрос на необходимый ресурс – удалённое приложение или подключение к удалённому рабочему столу компьютера, расположенного во внутренней сети
• Шлюз выполняет проверку запроса на соответствие политике авторизации ресурсов (TS RAP)
• Если проверка выполнена успешно, шлюз устанавливает внутреннее RDP-подключение к затребованному клиентом ресурсу. Весь дальнейший поток данных проходит через шлюз, который выполняет его преобразование, отправляя пакеты внутри сети по порту 3389, а в сторону клиента – инкапсулируя в SSL и отправляя их с 443 порта

Работу шлюза мы продемонстрируем на примере сети следующей конфигурации:

How to Publish Remote App programs in Remote Desktop Service

Здесь клиент 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) и нажимаем Далее. Указываем расположение ЦС (для рассматриваемой сети это tstestcertcenterdc1.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 по созданию решений безопасного доступа к ресурсам внутренней сети из любого места, где есть интернет. Мы не уделяли внимание вопросам администрирования, применения групповых политик, аудита и некоторым другим аспектам, поскольку основной целью являлось лишь общее описание механизмов, позволяющих создавать такие безопасные подключения. И, безусловно, необходимо признать, что практическое применение описанных технологий возможно лишь в условиях достаточно современной вычислительной инфраструктуры.

Полезные ссылки

Легкий способ снять квартиру посуточно новосибирск. Быстро, качественно и надежно.

Этот пост October 21, 2009 at 10:46 pm опубликовал molse в категории Windows Server 2008, Терминалка. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

Источник: system-administrators.info

Настраиваем RemoteApps в Windows Server 2008

08.06.2022

itpro

Windows Server 2008

комментариев 17

Технология RemoteApps является одной из функций роли служб терминалов в Windows Server 2008. До появления RemoteApps, службы терминалов подразумевали отображение на стороне клиента всего виртуального рабочего стола удаленного сервера. Такой подход достаточно удобен в ряде ситуаций, однако в том случае, если пользователю необходимо создать эффект того, что приложение, запущенное на терминальном сервере, отображалось на стороне клиента терминала, создавая иллюзию его локальной работы, такой подход не работает. Именно такую функциональность и обеспечивают функции RemoteApps, о которых мы и поговорим в этой статье.

Подготовка сервера к установке RemoteApps

Перед использованием технологии RemoteApps на сервере Windows Server 2008 необходимо выполнить ряд условий. В первую очередь на вашем сервере должна быть установлена и настроена роль служб терминалов.

Во-вторых, все приложения, которые планируется использовать с помощью RemoteApps должны быть установлены на терминал так, чтобы они поддерживали одновременную многопользовательскую работу. Как это сделать, вы можете прочитать в статье Установка приложений для Windows Server 2008 Terminal Services .

И, наконец, если планируется сделать доступ к приложениям через браузер с помощью роли TS Web Access, необходимо произвести настройки, описанные в статье Настройка TS Web Access в Windows Server 2008.

После выполнения первых двух, а, если необходимо и третьего требования, можно переходить к процессу конфигурации RemoteApp.

Что такое RemoteApps?

RemoteApps являются частью роли служб терминалов в Windows Server 2008. Цель служб терминалов – обеспечение доступа клиентских систем к рабочему столу и приложениям, работающих на терминальном сервере. Как следует из названия, удаленный доступа к рабочему столу означает отображение всего рабочего стола сервера на экране локального клиента.

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

RemoteApps могут быть запущены с помощью специальной ссылки на веб-странице TS Web Access, или путем установки специального файла на компьютере клиента.

Настройка приложения в качестве RemoteApp

Процесс настройки RemoteApps осуществляется с использованием утилиты TS RemoteApp Manager. Его можно запустить из меню Пуск -> Все программы -> Terminal Services -> TS Remote App Manager, либо с помощью оснастки remoteprograms.msc. После запуска, интерфейс менеджера будет выглядеть примерно следующим образом:

Для настройки приложения в качестве RemoteApp, необходимо нажать ссылку Add RemoteApp Programs в панели Actions, расположенной в правом верхнем углу экрана менеджера RemoteApp Manager. На экране появится мастер RemoteApp, содержащий список установленных в системе приложений. Вам необходимо отметить галочками одно или несколько приложений, и нажать Next.

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

Этот диалог позволяет настроить следующие параметры:

• RemoteApps program name – имя программы, под которым данное приложение будет видимо для пользователя.

• Location : — физический путь к исполняемому файлу приложения.

• Alias (Псевдоним) — уникальный идентификатор для программы или приложения, как правило, здесь используется имя исполняемого файла без расширения.

• RemoteApp isavailable through TS Web Access –управляет доступом к приложению RemoteApp через TS Web Access. Подробнее о TS Web Access читайте пост под названием Настройка Windows Server2008 TS Web Access .

• Command-Line Arguments(параметры командной строки) –устанавливает правила для использования приложением аргументов командной строки.

• Change Icon –Позволяет установить и изменять иконку приложения

После внесения каких-либо изменений в свойства RemoteApp, нажмите кнопку ОК, а затем Next. После завершения настройки приложений они будут перечислены в списке RemoteApp Programs, как показано на рисунке:

После настройки RemoteApps, удаленные пользователи могут приступать к их использованию. Осталось лишь установить на ПК клиента специальный пакет Windows Installer или скопировать ему заранее сформированный .rdp файл, либо же предоставить ему доступ к TS Web Access. Каждый из этих подходов будут подробно рассмотрены в последующих разделах.

Доступ пользователей к RemoteApps через TS Web Access

По умолчанию, приложение RemoteApps доступно через TS Web Access. Проверить этот факт можно, как указано выше, с помощью окна свойств RemoteApp и наличия в нем отмеченного чекбокса RemoteApp is available through TS Web Access. Естественно, этот параметр может быть изменен в любое время, для чего в списке приложений RemoteApp нужно выбрать необходимое приложение и перейти в его свойства.

Итак, если ваши RemoteApps настроены для доступа через TS Web Access, просто откройте окно браузера и введите URL-адрес веб-страницы:

В качестве значения Server1, вы можете использовать ip адрес или имя вашего терминального сервера. Когда соединение будет установлено, то перед отображением страницы, браузер запросит имя пользователя и пароль.

Для запуска приложения пользователю достаточно просто нажать на его значок, после чего появится начальное окно запуска RemoteApp. В нем нужно будет выбрать настройки терминального соединения, например какие локальные ресурсы клиента (например, диски, устройства, клавиатура, мышь, принтер, порты и т.д.) должны быть доступны в приложении, запущенном на удаленной системе. Это может быть полезно, например, если пользователю нужно печатать из удаленного приложения на локальном принтере, или сохранять файлы сразу на локальный диск или USB-флешку:

После установки соединения окно терминального приложения будет отображено в окне на локальном компьютере.

Доступ к RemoteApps с помощью пакетов Windows Installer

Альтернативным способом доступа к приложениям RemoteApp является использование пакетов установщика Windows, которые необходимо развернуть на тех системах, с которых предполагается осуществлять доступ на сервер терминалов. Чтобы создать файл Windows Installer для RemoteApp, щелкните правой кнопкой мыши по выбранному приложению в менеджере RemoteApp и выберите команду Create Windows Installer Package. В появившемся мастере необходимо выбрать каталог, в который на клиенте будет установлен RemoteApp. Также с помощью этого мастера можно переопределить порт протокола RDP, который будет использоваться клиентом для доступа к серверу RemoteApp. И, наконец, здесь же можно настроить защиту удаленного доступа с помощью сертификатов.

После создания пакета, файл .msc будет находиться по пути, который вы указали в процессе создания такого пакета (по умолчанию это Program FilesPackaged Programs). Этот файл может быть скопирован на любую клиентскую систему, где он должен быть запущен. В результате установки пакета Windows Installer RemoteApp можно найти в меню «Пуск» (Start -> All Programs -> Remote Programs).

В этом случае, так же как при использовании TS Web Access, пользователь будет предоставлена возможность указать, какие локальные ресурсы, такие как диски, порты и принтеры должны быть доступными в удаленном приложении.

Запуск RemoteApps с помощью .rdp файлов

Процесс создания RDP файла для RemoteApp полностью аналогичен процессу создания пакета Windows Installer. Чтобы создать RDP файл для RemoteApp, щелкните правой кнопкой мыши по выбранному RemoteApp в менеджере TS RemoteApp и выберите пункт меню Create .rdp File. В результате откроется мастер, который потребует от вас указать каталог, в котором будет создан .rdp файл, также можно будет определить порт протокола RDP (Remote Desktop Protocol) для создаваемого RemoteApp, а также возможно установить защиту терминальной сессии при помощи цифровой подписи.

После завершения настроек, нажмите кнопку Готово, и в результате в каталоге, который вы указали (по умолчанию это C:Program FilesPackaged Programs) появится новый .rdp файл. Этот файл нужно скопировать на любую систему, с которой предполагается воспользоваться удаленным приложением RemoteApp.

Как и в случае с TS Web Access, пользователь может определить какие локальные ресурсы могут быть доступными в опубликованном терминальном приложении.

Предыдущая статья Следующая статья

Источник: winitpro.ru

RDP-ссылка на RemoteApp в Windows Server 2012 R2

Говорят, что в Windows Server 2012 выпилили функционал по созданию rdp ярлыков на удалённые приложения. Но это не совсем так. Расскажу как сделать rdp ярлык без особых проблем.

Устанавливаете приложение на сервер. Убедитесь, что входите в группу пользователей, которым доступны удалённые приложения.

Публикуете приложение как RemoteApp.

Если вы знаете ссылку к web-интерфейсу RemoteApp вашего терминального сервера, то хорошо, если не знаете, то запускаете оснастку IIS на терминальном сервере:

В Default Web Site находите приложение RDWeb.

Справа нажимаете Browse *:443.

Откроется ссылка вида:

Теперь вы можете открыть эту ссылку в своем браузере (не IE!) Google Chrome, заменив localhost на адрес сервера.

Выполняете вход под доменной учёткой.

Кликаете на нужное приложение. и получаете требуемый rdp файлик.

Теперь этот файлик можно красиво переименовать и рассылать своим пользователям.

Источник: internet-lab.ru