Это не совсем случай из практики, а небольшая шпаргалка, которую я сделал для себя и решил поделиться. Если, конечно, есть еще такие же фрики, как я.
Сразу замечу, я не пропагандирую использование RDP и Сертификатов без доменов, просто часто попадаются маленькие клиенты с разнесенной географически инфраструктурой. Например офис на 3 компьютера и 10 точек- магазинов, 4 склада, где просто нужен доступ к складской 1С, и пока нет домена (или он не нужен). Картинки можно увеличивать щелчком мыши.
Контрольный список
установки и настройки RemoteApp через RD Gateway
без домена AD и внешнего доменного имени
*Предполагается, что в сети имеется больше одного сервера, хотя все возможно реализовать и на одном сервере.
1. Установка и настройка роли RDS со службами RD Licensing, RDSH, RD Gateway.
2. Если подключение к интернету осуществляется через роутер — настроить проброс порта 443 на внутренний адрес RD Gateway.
3. Предварительная настройка RDSH. Предварительная настройка RemoteApp. Добавление приложения в список RemoteApp.
4. Настройка RD Gateway. Создание правил RD CAP и RD RAP.
5. Установка роли AD CS для создания сертификата на подключения к RD Gateway. При создании сертификата указываем внешний IP-адрес и внутренний IP-адрес сервера RD Gateway, чтобы сертификат проходил проверку подлинности, и мы могли бы подключиться к серверу шлюза терминалов по внешнему статическому адресу снаружи, и по внутреннему NetBIOS имени изнутри.
5.1 Установки роли AD CS в режиме Standalone на другом сервере (который будет центром сертификации, имя сервера после этого изменить будет нельзя).
5.2 Создание на сервере RD Gateway пользовательского запроса на сертификат:
то самое окошко, ради которого и устанавливалась роль AD CS
выбираем, как мы будем использовать ключ:
не забываем эту галочку, чтобы вместе с сертификатом экспортировался и личный ключ:
По окончании настройки запроса сохраняем запрос с расширением *.req.
5.3 Переходим на сервер с Центром сертификации. Для начала можно настроить время действия сертификата выданного Центром сертификации по умолчанию. В целях безопасности лучше оставить этот параметр равным 1 году. Я делаю это только потому, что я не буду находиться у клиента постоянно и возможны простои в работе. А через 5 лет ”или падишах помрет или осел… ”.
Открываем запрос в центре сертификации, и выпускаем новый сертификат (Issue).
Публикуем список отзыва (CRL).
5.4 Экспортируем сертификат в файл с расширением *.cer. Переходим в папку где хранятся сертификат Центра сертификации и список отзывов. Копируем личный сертификат и эти два файла на сервер RD Gateway (или на файловый сервер как удобнее).
5.5 Открываем личный сертификат на сервере RD Gateway и убеждаемся, что доверия к нему нет.
5.6 Устанавливаем: Сертификат центра сертификации в доверенные корневые центры сертификации, устанавливаем список отзывов. Устанавливаем личный сертификат. Открываем его и убеждаемся что цепочка доверия работает.
5.7 Изменяем само подписанный сертификат на вновь выпущенный в настройках RD Gateway, RD Web Access, ну и если надо в настройках RDSH, у него отдельный сертификат, который будет использоваться для внутренних подключений, имейте в виду, когда срок действия само подписанного сертификата закончится сервер в этом случае сам пере выпустит сертификат, если же для RDSH создать сертификат самодельный, то по истечении его срока действия зайти через удаленный рабочий стол не получится, надо отслеживать этот момент. Опять же здесь видны недостатки использования службы сертификации вне домена.
5.8 Создаем rdp-файл для пользователей.
6. Проверяем работу RemoteApp и RDC через RDGateway.
7. Нам нужно также будет создать must-have пакет для клиентов, который представляет архив с набором файлов:
— Инструкция по установке сертификатов, списка отзывов, установке обновлений (если клиент не Win7 и выше);
— Личный сертификат сервера RD Gateway;
— Сертификат Центра сертификации;
— Список отзывов (CRL);
— rdp-файл;
Инструкцию конечно можно и не писать, но тогда придется либо долго объяснять клиенту все по телефону, либо ехать собственной персоной.
Будет дополняться по мере возможности.
ЗЫ. В процессе тестирования, заметил интересную штуку- несмотря на то, что подключение рабочего стола к тестируемой системе осуществлялось успешно, порт 3389 был закрыт на роутере (т.е. подключение явно происходило через порт 443) и RD Gateway manager показывал мне что соединение осуществляется через него – заветный значок подключения через шлюз, у меня не появился на полоске RDC. Я попробовал подключить через RD Gateway к другому клиенту, где значок точно появлялся- в прошлом Случае из практики есть снимок экрана в подтверждение. Но у другого клиента также не было этого значка… Возможно это просто какой то глюк.
Статья опубликована в продолжение рубрики «Записки системного администратора» или «Случай из практики», материалами для которой любезно делится мой коллега из Белоруссии. Оригинал статьи он опубликовал в своём блоге RDP dog.
