Установить сертификат для всех пользователей терминального сервера

Установка роли RDS-Gateway в Windows Server

Служба шлюза удаленных рабочих столов не является обязательным компонентом фермы RDS, поэтому ее нужно установить отдельно. В большинстве случае рекомендуется использовать отдельный сервер для развертывания RDGW или можно совместить его с RDWeb.

Предполагается, что в вашей сети уже развернута служба каталогов Active Directory и ферма серверов RDS.

При установке службы RDGW также устанавливаются веб сервер IIS и роль NPS (Network Policy Server).

Убедитесь, что роль RDS-Gateway установлена:

Или установите роль в Windows Server с помощью команды Install-WindowsFeature:

Install-WindowsFeature RDS-Gateway -IncludeAllSubFeature –IncludeManagementTools

Создайте группы доступа в Active Directory с помощью консоли ADUC или с помощью PowerShell:

Настройка политик доступа RDS Gateway

Для управления политиками и правилами доступа на RDGW используется консоль RD Gateway Manager (tsgateway.msc). Здесь нужно настроить два типа политик:

Connection Authorization Policies (RD CAP) – определяют кому разрешено авторизоваться на шлюзе RDS;
Resource Authorization Policies (RD RAP)– определяют кому и к каким ресурсам (компьютерам) внутренней сети разрешено подключаться через RDGW.

Создайте сначала политику RD CAP:

Выберите тип аутентификации (по паролю и/или по смарт карте), укажите группу пользователей, которым разрешено аутентифицироваться на RDGW;
В окне Enable or Disable Device Redirection можно указать какие устройства разрешено прокидывать в RDP сессию (буфер обмена, принтера, локальные диски и т.д.);
Далее можно настроить таймауты для RDP сеансов;
Подтвердите создание политики.

Также вы можете создать политику клиентского доступа RDGW с помощью PowerShell:

Затем создайте политику RD RAP:

Укажите имя группу, которой разрешено подключаться к внутренним RDS ресурсам;
На вкладке Network Resources нужно указать к каким RDS серверам разрешено подключаться вашим внешним пользователям (msk-rds-farm);
Далее укажите разрешенные для подключения порты. По-умолчанию рекомендуется открыть только стандартный RDP порт 3389. Но вы можете открыть и дополнительные порты;
Политика готова.

Настройка SSL сертификата для Remote Desktop Gateway

Для защиты подключения к шлюзу RDS на нем нужно установить сертификат. Оптимально использовать коммерческий сертификат, выданный внешним центром сертификации. Возможно использовать бесплатного SSL сертификат Let’s Encrypt (установка Let’s Encrypt сертификата на IIS для Remote Desktop Gateway). Также вы можете использовать самоподписанный SSL сертификат Windows, но здесь имейте в виду что внешние клиенты должны обязательно доверять такому сертификату. Если клиент не доверяет сертификату на сервере RDGW, он не сможет подключиться к шлюзу (самоподписанные SSL сертификаты можно импортировать на клиентов вручную или через GPO) .

В поле Subject Name (CN) или Subject Alternative Name сертификата должно обязательно содержаться DNS имя сервера RDGW, которое будет использоваться для подключения внешними клиентами (доступное из интернета).

Откройте свойства сервера RDGW в консоли RD Gateway и перейдите на вкладку SSL Certificate;
Укажите имя сертификата (это DNS будет использоваться вашими клиентами для подключения к RDGW) и каталог, в который нужно сохранить сертификат (это сертификат нужно распространить на клиентов);

В Windows Server 2019 для подключения к RDGateway используются следующие порты:

HTTPPort (default) —
443/TCP
UDPPort (default) —
3391/UDP
(использование транспортного протокола UDP не обязательно, но его поддержка позволяет значительно улучшить производительность туннеля и качество картинки в RDP сессии)

Не забудьте открыть (пробросить) эти порты на ваш RDGW хост на сетевом оборудовании.

Откройте консоль RDGW Manager и убедитесь, что в ней нет ошибок и все пункты зелёные.

Настройка RDP клиента для подключения шлюзу RD Gateway

Теперь можно настроить клиент Remote Desktop Connection для подключения к вашим внутренним RDS хостам через шлюз удаленных рабочих столов.

Запустите клиент
mstsc.exe
;
На вкладке General укажите имя RDSH хоста, RDS фермы, или компьютера к которому вы хотите подключиться по RDP (можно также указать имя пользователя и использовать сохраненные учетные данные для RDP подключения);
Затем перейдите на вкладку Advanced и щелкните на кнопку Settings в разделе Connect from anywhere (Configure settings to connect through Remote Desktop Gateway when I am working remotely);
Чтобы не при подключении клиент не запрашивал пароль два раза, включите опцию Use my RD Gateway credentials for the remote computer;
Нажмите кнопку Connect и введите пароль для подключения к RDGW серверу в окне RD Gateway Server Credentials;
Клиент должен установить подключение с RDS/RDP хостом в вашей локальной сети;
Запустите консоль RD Gateway Manager, перейдите в раздел Monitoring и проверьте, что в списке отображается подключение вашего клиента.

Если вы используете утилиту RDCMan для RDP подключений, параметры RD Gateway можно задать на вкладке GatewaySetting. Включите опцию Use a TS Gateway server и укажите параметры подключения.

При успешном подключении пользователя через RDGW в журнале появится событие с Event ID 205 от источника TerminalServices-Gateway

Если вы хотите запускать RemoteApp через RD Gateway, нужно добавить в *.rdp файл remoteapp следующие строки:

В этой статье мы показали, как настроить роль Remote Desktop Gateway на Windows Server для реализации защищенного удаленного доступа в вашу сеть с помощью RDP over HTTPS.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Какие преимущества дает нам защита RDP при помощи SSL? Во первых надежное шифрование канала, проверку подлинности сервера на основании сертификата и проверку подлинности пользователя на уровне сети. Последняя возможность доступна начиная с Windows Server 2008. Проверка подлинности на уровне сети позволяет повысить безопасность сервера терминалов за счет того, что проверка происходит еще до начала сеанса.

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

Для полноценного использования всех возможностей RDP через SSL клиентские ПК должны работать под управлением Windows XP SP3, Windows Vista или Windows 7 и использовать RDP клиент версии 6.0 или более поздней.

При использовании Windows Server 2003 SP1 и более поздних версий, будут доступны шифрование канала при помощи SSL (TLS 1.0) и проверка подлинности сервера, клиентские ПК должны иметь версию RDP клиента 5.2 или более позднюю.

В нашей статье мы будем рассматривать настройку терминального сервера на базе Windows Server 2008 R2, однако все сказанное будет справедливо и для Windows Server 2003 (за исключением отсутствующих возможностей).

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

Читать также: Эвотор не видит сертификат на рутокен

Затем следует выполнить запрос сертификата подлинности сервера со следующими параметрами:

Имя — полное имя терминального сервера (т.е. server.domain.com если сервер входит в домен domain.com)

Тип сертификата — Сертификат проверки подлинности сервера
Установите опцию Создать новый набор ключей
CSP — Microsoft RSA SChannel Cryptographic Provider.
Установите флажок Пометить ключ как экспортируемый.
Для ЦС предприятия установите флажок Использовать локальное хранилище компьютера для сертификата. (В автономном ЦС данная опция недоступна).

Отправьте запрос центру сертификации и установите выданный сертификат. Данный сертификат должен быть установлен в локальное хранилище компьютера, иначе он не сможет быть использован службами терминалов. Чтобы проверить это запустим консоль MMC (Пуск — Выполнить — mmc) и добавим оснастку Сертификаты (Файл — Добавить или удалить оснастку) для учетной записи компьютера.

В корне консоли выберите Сертификаты (локальный компьютер) нажмите Вид — Параметры и установите режим просмотра Упорядочить сертификаты по назначению. Выданный сертификат должен находиться в группе Проверка подлинности сервера.

Если вы получали сертификат с помощью изолированного (автономного) ЦС (сеть не имеет доменной структуры) то он по умолчанию будет установлен в хранилище учетной записи пользователя и придется выполнить ряд дополнительных действий.

Откройте Internet Explorer — Свойства обозревателя — Содержимое — Сертификаты, выданный сертификат должен быть установлен в хранилище Личные.

Произведите его экспорт. При экспорте укажите следующие опции:

Да, экспортировать закрытый ключ
Удалить закрытый ключ после успешного экспорта

После чего удалите сертификат из данного хранилища. В оснастке Сертификаты (локальный компьютер) выберите раздел Проверка подлинности сервера, щелкните на него правой кнопкой мыши Все задачи — Импорт и импортируйте сертификат.

Теперь в Администрирование — Службы удаленных рабочих столов откройте Конфигурация узла сеансов удаленных рабочих столов ( в Windows Server 2003 Администрирование — Настройка служб терминалов).

Выберите необходимое подключение и откройте его свойства. В самом низу нажмите кнопку Выбрать и выберите полученный на предыдущем шаге сертификат (в Windows Server 2003 это окно выглядит несколько по другому).

Уровень безопасности SSL
Уровень шифрования Высокий или FIPS-совместимый

Сохраните введенный параметры, на этом настройка сервера закончена.

На клиентском ПК создайте подключение к удаленному рабочему столу, в качестве адреса используйте полное имя сервера, которое указано в сертификате. Откройте свойства подключения и на закладке Подключение — Проверка подлинности сервера установите опцию Предупреждать.

Чтобы данный ПК доверял сертификатам выданным нашим центром сертификации не забудьте установить на него сертификат ЦС в хранилище Доверенные корневые центры сертификации.

В Windows 7 (при использовании RDP клиента версии 7) данный сертификат требуется установить в хранилище учетной записи компьютера, для этого импортируйте его через оснастку Сертификаты (локальный компьютер) в консоли MCC, аналогично тому, как это делали выше. В противном случае подключение будет невозможно и вы получите следующую ошибку:

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

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

И напоследок капля дегтя в бочке меда. Терминальные службы Windows не умеют проверять подлинность подключающихся клиентов, поэтому если стоит такая необходимость следует использовать дополнительные методы защиты, такие как SSH туннель или IPSec VPN.

Single Sign-On (SSO — технология единого входа) это технология, позволяющая уже аутентифицированному (вошедшему в систему) пользователю получать доступ к другим сервисам без повторной аутентификации. Применительно к технологии терминальных серверов Remote Desktop Services, SSO позволяет избавить пользователя, выполнившего вход на доменном компьютере, от многократного ввода имени и пароля своей учетной записи в окне RDP клиента при подключении к RDS серверам или запуске опубликованных приложений RemoteApp.

В этой статье мы опишем особенности настройки прозрачной авторизации (Single Sign-On) пользователей на серверах RDS под управлением Windows Server 2016 и 2012 R2.

Требования к окружению:

Сервер Connection Broker и все RDS сервера должны работать под управлением Windows Server 2012 или выше;
SSO работает только в доменном окружении: должны использоваться учетные записи пользователей Active Directory, а RDS сервера и рабочие станции пользователей должны быть включены в домен;
На RDP клиентах должна использоваться версия клиента RDP 8.0 и выше (не получится установить эту версию RDP клиента в Windows XP);
На стороне клиента поддерживаются следующие версии Windows 10 / 8.1 / 7;
SSO работает с парольной аутентификацией (смарт карты не поддерживаются);
Уровень безопасности RDP (Security Layer) в настройках подключения должен быть установлен в Negotiate или SSL (TLS 1.0), а шифрование High или FIPS Compliant.

Процедура настройки Single Sign-On состоит из следующих этапов:

Необходимо выпустить и назначить SSL сертификат на серверах RD Gateway, RD Web и RD Connection Broker;
Включить Web SSO на сервере RDWeb;
Настроить групповую политику делегирования учетных данных;
Через GPO добавить отпечаток сертификата в доверенные издатели .rdp.

Итак, в первую очередь нужно выпустить и назначить SSL сертификат. В EKU (Enhanced Key Usage) сертификата должно обязательно присутствовать идентификатор Server Authentication. Мы опускаем процедуру получения сертификата, т.к. это она выходит за рамки статьи (можно сгенерировать самоподписанный SSL сертификат, но его придется добавлять в доверенные на всех клиентах через GPO).

SSL сертификат привязывается в свойствах RDS Deployment в подразделе Certificates.

Далее на всех серверах c ролью Web Access для каталога IIS RDWeb нужно включать “Windows Authentication” и отключить анонимную проверку подлинности (Anonymous Authentication).

После сохранения изменений, IIS нужно перезапустить:
iisreset /noforce

Если используется шлюз RD Gateway, убедитесь, что он не используется для подключения внутренних клиентов (должна стоять галка Bypass RD Gateway server for local address).

Следующий этап – настройка политики делегирования учетных данных. Создайте новую доменную GPO и привяжите ее к OU с пользователями (компьютерами), которым нужно разрешить SSO доступ на RDS сервера. Если вы хотите разрешить SSO для всех пользователей домена, допустимо редактировать Default Domain Policy.

Включите политику (Enabled);
В список серверов нужно добавить имена RDS серверов, на которые клиент может автоматически отправлять учетные данные пользователя для выполнения SSO авторизации. Формат добавления сервера: TERMSRV/rd.contoso.com. (обратите внимание, что все символы TERMSRV должны быть в верхнем регистре). Если нужно предоставить такое право всем терминальным системам домена (менее безопасно), можно воспользоваться такой конструкцией: TERMSRV/*.contoso.com .

Далее, чтобы избежать появления окна с предупреждением о надежности издателя удаленного приложения, нужно с помощью GPO на клиентских компьютерах добавить адрес сервера с ролью Connection Broker в доверенную зону с помощью политики «Список назначений зоны безопасности для веб-сайтов» (по аналогии со статьей Как убрать предупреждение системы безопасности при открытии файла в Windows):

После обновления политик на клиенте, при попытке запустить RemoteApp приложение, запрос пароля не появится, но появится окно с предупреждением о доверии к издателю данной программы RemoteApp:

Читать также: Пачка пароизоляционной пленки Ютафол 3-х слойная с армированным слоем

Do you trust the publisher of this RemoteApp program?

Чтобы это сообщение не выводилось каждый раз при подключении пользователя, вам нужно получить отпечаток SSL сертификата (certificate thumbprint) RD Connection Broker и добавить его в список доверенных издателей rdp. Для этого на сервере RDS Connection Broker выполните команду PowerShell:

На этом настройка SSO закончена, и после применения политик, пользователь должен подключатся к ферме RDS по протоколу RDP без повторного ввода пароля.

Your Windows logon credentials will be used to connect.

Для использования Web SSO на RD Web Access, обратите внимание, что рекомендуется использовать Internet Explorer с включенным Active X компонентом MsRdpClientShell (Microsoft Remote Desktop Services Web Access Control).

Имеется терминальный сервер для пользователей, которые работают на порталах по закупкам. Задача — автоматизировать установку сертификатов личных и доверенных корневых центров.
Пробросить флешку/смарт-карту с сертификатом и ключами в терминал можно легко, поставив галку в свойствах rdp-подключения:

Далее создаем групповую политику, цепляем её к OU, в которой находится учетная запись компьютера-терминала и добавляем нужные доверенные корневые сертификаты сюда:
Computer Configuration – Policies – Windows Settings – Security Settings – Public Key Policies — Trusted Root Certification Authoritiesshow

В групповой политике обязательно включите опцию Loopback Processing Mode (Замыкание на себя) — «Конфигурация компьютераАдминистративные шаблоныСистемаГрупповая политика», чтобы настройки юзера применялись ко всем, кто заходит на терминальный сервер.

Примеры команд для работы с certutil:

Добавить личный сертификат пользователя в личное хранилище:

Добавить сертификат в личное хранилище компьютера (для всех пользователей):

certutil -addstore «My» «filename.cer»

Добавить сертификат в доверенные корневые центры сертификации (для всех пользователей):

certutil -addstore «Root» «filename.cer»

Добавить сертификат в промежуточные центры сертификации (для всех пользователей):

certutil -addstore «CA» «filename.cer»

В этой статье мы покажем, как использовать доверенные SSL/TLS сертификаты для защиты RDP подключений к компьютерам и серверам Windows в домене Active Directory. Эти сертфикаты мы будем использовать вместо самоподписанных RDP сертификатов (у пользователей появляется предупреждение о невозможности проверки подлинности при подключению к RDP хосту с таким сертификатом). В этом примере мы настроим специальный шаблон для выпуска RDP сертификатов в Certificate Authority и настроим групповую политику для автоматического выпуска и привязки SSL/TLS сертификата к службе Remote Desktop Services.

Предупреждение о самоподписанном сертификате RDP

По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный

сертификат. В результате при первом подключении к RDP/RDS серверу через клиента mstsc.exe, у пользователя появляется предупреждение:

Не удалось проверить подлинность удаленного компьютер из-за проблем с сертификатом безопасности.
Ошибка сертификата: сертификат выдан не имеющим доверия центром сертификации.

Чтобы продолжить установление RDP подключении пользователь должен нажать кнопку Да. Чтобы RDP предупреждение не появлялось каждый раз, можно включить опцию “Больше не выводить запрос о подключениях к этому компьютеру».

Несмотря на то, что для подключения используется самоподписанный сертификат, ваше RDP подключение защищено, а трафик зашифрован.

Создаем шаблон RDP сертификата в центре сертификации (CA)

Попробуем использовать для защиты RDP подключений доверенный SSL/TLS сертификат, выданный корпоративным центром сертификации. С помощью такого сертификата пользователь может выполнить проверку подлинности RDP сервера при подключении. Предположим, что у вас в домене уже развернут корпоративной центр сертификации (Microsoft Certificate Authority), в этом случае вы можете настроить автоматическую выдачу и подключение сертификатов всем компьютерам и серверам Windows в домене.

Н на вашем CA нужно создать новый тип шаблона сертификата для RDP/RDS серверов.

Запустите консоль Certificate Authority и перейдите в секцию Certificate Templates;
На вкладке General укажите имя нового шаблона сертификата – RDPTemplate. Убедитесь, что значение поля Template Name полностью совпадает с Template display name;
На вкладке Compatibility укажите минимальную версию клиентов в вашем домене (например, Windows Server 2008 R2 для CA и Windows 7 для клиентов). Тем самым будут использоваться более стойкие алгоритмы шифрования;
В настройках шаблона сертификата (Application Policies Extension) удалите все политики кроме Remote Desktop Authentication;
Чтобы использовать данный шаблон RDP сертификатов на контролерах домена, откройте вкладку Security, добавьте группу Domain Controllers и включите для нее опцию Enroll и Autoenroll;
Сохраните шаблон сертификата;

Настройка групповой политики для выдачи RDP сертификатов

Теперь нужно настроить доменную политику, которая будет автоматически назначать RDP сертификат компьютерам/серверам согласно настроенного шаблона.

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

Откройте консоль управления доменными групповыми политиками gpmc.msc, создайте новый объект GPO и назначьте его на OU с RDP/RDS серверами или компьютерами, для которых нужно автоматически выдавать TLS сертификаты для защиты RDP подключения;
Затем в этом же разделе GPO включите политику Require use of specific security layer for remote (RDP) connections и установите для нее значение SSL;

Для применения нового RDP сертификата, перезапустите службу Remote Desktop Services:

Теперь при RDP подключении к серверу перестанет появляться запрос на доверие сертификату (чтобы появился запрос о доверии сертификату, подключитесь к серверу по IP адресу вместо FQDN имени сервера, для которого выпущен сертификат). Нажмите кнопку “Посмотреть сертификат”, перейдите на вкладку “Состав”, скопируйте значение поля “Отпечаток сертификата”.

Также можете в консоли Certification Authority в секции Issued Certificates проверить, что по шаблону RDPTemplate был выдан сертификат определённому Windows компьютеру/серверу. Также проверьте значение Thumbprint сертификата:

Теперь, при подключении к удаленном столу любого сервера или компьютера, на который действует эта политика, вы не увидите предупреждения о недоверенном RDP сертификате.

Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата

Если у вас отсутствует CA, но вы хотите, чтобы при подключении к RDP/RDS серверу у пользователей не появлялось предупреждения, вы можете добавить сертификат в доверенные на компьютерах пользователей.

Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:

Используйте этот отпечаток для подписывания .RDP файла с помощью RDPSign.exe:

Чтобы работал прозрачных RDP вход без ввода пароля (RDP Single Sign On), нужно настроить политику Allow delegation defaults credential и указать в ней имена RDP/RDS серверов (см. статью).

Как я уже писал 2012 2 – теперь две модели есть два способа настройки . Это также касается сертификатов.

Как мы настраиваем сертификаты в классической модели. Когда стартует сервис , он проверяет наличие сертификата, если его нет, то либо получает сертификат из леса, либо создает самоподписанный сертификат. И наконец, мы можем получить сертификат из внутреннего вручную, либо взять коммерческий сертификат и назначить такой сертификат сервису вручную. Автоматический и ручной методы описаны в статье Configuring Remote Desktop certificates. В 2012 2 отсутствует для настройки в классической модели. Это касается и сертификатов: нужно использовать командную строку для назначения сертификатов сервису .

Теперь рассмотрим практические сценарии. Если у вас один-два терминальных сервера, то совсем не трудоёмко назначить им сертификат вручную. Даже можно использовать самоподписанный сертификат: только его необходимо будет распространить на клиентские компьютеры с помощью . Если терминальных серверов больше, чем один-два, то хорошо помогает автоматическое назначение сертификатов внутреннего : клиенты им доверяют по умолчанию. А вот если у вас не просто терминальные серверы, а несколько ферм из нескольких серверов, то сертификаты не могут быть автоматически установлены: либо их надо копировать на все серверы и вручную назначать сервису , либо делать тоже самое, но скриптом; ни о каком автоматическом продлении сертификата речи быть не может.

Читать также: Марок PU-Bond 2K, Soudabond Easy, Soudabond Easy GUN, Soudatherm, Colotuile, PUROCOL, Soudabond Easy WINTER

Таким образом, в классической модели есть некоторые проблемы назначения и контроля за сертификатами и эти проблемы разрастаются в случае множества терминальных ферм.

Что нам предлагает новая модель. Сертификаты больше не нужно ставить на терминальные серверы! В любом развертывании () есть брокер – сертификат (сертификаты) устанавливаются только на нем (или на двух брокерах, если они сконфигурированы в режиме В новой модели сертификаты могут быть назначены брокеру через или с помощью .

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

Можете оценить насколько это удобно. Вы настраиваете сертификат(-ы) один раз на брокере, после чего можете создавать любое количество коллекций с любым количеством серверов, на лету включать в коллекции дополнительные серверы – и все это без заботы о сертификатах.

Теперь собственно о сертификатах.

Новая модель требует 4 сертификата.

RD Connection Broker – Single Sign On

– используется для аутентификации серверов. Точнее сказать в нем указывается имя развертывания (при одном брокере по умолчанию это его ).

RD Connection Broker – Publishing

– используется для подписи файлов, чтобы пользователи не получали дополнительный вопрос о доверии. Соответствующее свойство сертификата должно быть включено при его создании. (В локальной сети для исключения окна уведомления о доверии нужно к тому же настроить «Specify SHA1 thumbprints of certificates representing trusted .rdp publishers».)

– используется для аутентификации сервера и для включения – доставка на клиентские компьютеры ярлыков. Это типичный сертификат для . В качестве указывается имя сервера или фермы RD Web Access.

– используется для аутентификации сервера .

Варианты использования сертификатов.

На практике все эти сертификаты это обычно один и тот же сертификат.

Использовать самоподписанные сертификаты неудобно: клиенты получают много дополнительных предупреждений и вопросов при подключении.

. Если все клиенты внутри домена, то все работает прозрачно и удобно. Если клиент подключается извне, то корневой сертификат должен быть установлен на компьютере и должен быть опубликован во внешнюю сеть. Иначе клиенты вообще не смогут подключаться (последние версии клиента очень жестко и бескомпромиссно выполняют все проверки сертификатов).

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

Можно ли внутри использовать сертификаты внутреннего , а наружу опубликовать RD Web Access и RD Gateway с публичным сертификатом? Можно, но это усложнение решения и к тому же прозрачной работы пользователей все равно не будет: можно опубликовать RD Web Access как вэб-сервер с публичным сертификатом, например, на , и он будет прозрачно работать, теоретически тоже самое можно сделать с RD Gateway, но клиент в результате подключения все равно неявно получит файл, который подписан внутренним сертификатом и ссылается на внутренние ресурсы с внутренним сертификатом, которому нужно доверять и который нужно проверять на отзыв – доверие к пограничным серверам не распространяется на ресурсы. Иначе говоря, число предупреждений и вопросов к клиенту будет меньше, чем при использовании только внутренних сертификатов, но они все равно будут.

Рекомендуемый (мной) сценарий – если нужен доступ извне, то использовать внутри и снаружи публичные сертификаты. Как частный случай, когда много клиентов работают извне – использовать один сертификат и для RD Web Access и RD Gateway. Во-первых, клиенты работают прозрачно без лишних запросов. Во-вторых, используют для подключения одно и тоже имя.

В место заключения.

Новая модель управления в 2012 2 сильно упрощает настройку сертификатов особенно для решений с большим числом терминальных серверов. При этом она работает удобным образом и для небольших развертываний. Классическая модель сохранена, но настройка поддерживается только через командную строку.

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Защита RDP соединения при помощи SSL.

Имя — полное имя терминального сервера (т.е. server.domain.com если сервер входит в домен domain.com)

Тип сертификата — Сертификат проверки подлинности сервера
Установите опцию Создать новый набор ключей
CSP — Microsoft RSA SChannel Cryptographic Provider.
Установите флажок Пометить ключ как экспортируемый.
Для ЦС предприятия установите флажок Использовать локальное хранилище компьютера для сертификата. (В автономном ЦС данная опция недоступна).

Уровень безопасности SSL
Уровень шифрования Высокий или FIPS—совместимый
Установите флажок Разрешить подключаться только с компьютеров. (недоступно в Windows Server 2003)

Установка своего сертификата для RDP

Можно ли каким-то образом, в клиентской винде не входящей в AD, для сервера удалённых рабочих столов установить свой сертификат?

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

Цитата: Добавляем NETWORK SERVICE (права Чтение). Про это я не знал!

Цитата: Идем в реестр . добавляем Binary Value (Value name: SSLCertificateSHA1Hash ; Value data: ). Для этого дела есть скрипт — запускать с такими параметрами:

(если лень пробелы их хеша убирать, то можно в кавычки его)