После того, как развёртывание служб RDS успешно выполнено (RDS на основе сеансов в Windows Server 2012 R2. Часть 1 — Развёртывание в домене), коллекции сеансов созданы и настроены необходимым образом (RDS на основе сеансов в Windows Server 2012 R2. Часть 2 — Создание и настройка коллекций сеансов) и во всех коллекциях опубликованы и сконфигурированы удалённые рабочие столы или приложения RemoteApp (RDS на основе сеансов в Windows Server 2012 R2. Часть 3 — Публикация и настройка удалённых приложений RemoteApp) перед системным администратором возникает задача распространения или, если угодно, доставки программ RemoteApp или удалённых рабочих столов конечным пользователям.
Простая, на первый взгляд, задача не так уж бесхитростна, как кажется на первый взгляд. Ведь пользователи могут получать доступ к опубликованным приложениям RemoteApp совершенно различными способами. Об этих способах и пойдет речь в этой статье.
Если вкратце, то рассмотрены следующие ключевые моменты:
- Использование веб-доступа
- Использование средств Панели инструментов в Windows 7/8/8.1
- Использование приложения Удалённый рабочий стол на Windows RT
- Использование средств групповой политики для доставки приложений RemoteApp клиентам с Windows 8/8.1 и Windows 7
- Доступ к приложениям RemoteApp из Windows XP
Использование веб-доступа
Наиболее простым и очевидном способом доступа к приложениям RemoteApp является использование веб-доступа. Для того чтобы получить доступ к приложениям RemoteApp необходимо в строке браузера набрать адрес вида https://servername/rdweb и пройти процедуру аутентификации. В общем случае страница веб-доступа будет выглядеть примерно так как изображено на рисунке ниже.
Конечно, большинство системных администраторов вполне устроит такой вид страницы, а подавляющее количество пользователей даже не обратят внимания на вид этой страницы. Однако же существуют ситуации когда кастомизация страницы веб-доступа становится необходимостью.
Настройка внешнего вида страницы веб-доступа
Изменение имени рабочей области. Первым делом хотелось бы поменять надпись Work Resouces на что-то другое, например, на Удалённые приложения RemoteApp. Эта надпись обозначает имя рабочей области (Workspace) и управлять ею можно средствами PowerShell.
На любом сервере фермы RDS запустим PowerShell от имени администратора. Я эту операцию выполняю на сервере посредника подключений — rdcb.domain.local. итак, для того, чтобы посмотреть идентификатор рабочей области и её имя используем командлет Get-RDWorkspace (синтаксис). Как видно на скриншоте ниже, имя текущей рабочей области Work Resources. Изменим его на Удалённые приложения RemoteApp с помощью командлета Set-RDWorkspace (синтаксис) и проверим результат, выполнив командлет Get-RDWorkspace.
Настройка элементов страницы веб-доступа. Значок, который расположен рядом с именем рабочей области, так же можно поменять на, скажем, логотип компании. Сделать это можно подредактировав файл Site.xsl, который находится на сервере веб-доступа в папке %WINDIR%WebRDWebPages. Открыв этот файл с помощью любого текстового редактора в разделе Replaceable Company Logo Image указываем путь к файлу, содержащему логотип.
В этом же файле можно изменить и баннер, который является фоном для названия рабочей области и логотипа. Путь к фалу баннера можно изменить в разделе Customizable banner and Text row. Фон страницы веб-доступа можно изменить в файле, содержащем таблицы стилей — tswa.css. Он расположен на сервере веб-доступа в папке %WINDIR%WebRDWebPagesru-RU. Если будет установлена локализация отличная от русской, то папка ru-RU будет называться согласно языку системы. Я строку с указанием файла изображения закомментирую. Это приведет к тому, что фон страницы установится в цвет определенный свойством background-color.
Выполнив приведенные выше изменения, получим следующий вид страницы для организации веб-доступа.
Следует обратить внимание на то, что если серверов веб-доступа несколько, то все операции по изменению внешнего вида страницы веб-доступа следует выполнять на всех серверах. Однако операцию смены названия рабочей области нужно выполнить единожды на любом сервере фермы RDS.
Добавление сертификата подлинности сервера
При попытке установления безопасного подключения по протоколу HTTPS к узлу веб-доступа пользователь будет проинформирован о том, что сертификат, который использует данный сервер не является доверенным.
Для того, чтобы устранить эту проблему нужно создать для развёртывания RDS доверенный сертификат и установить его для службы веб-доступа к удалённым рабочим столам. Сделать это можно двумя способами. Первый — это получить сертификат от доверенного локального или доменного центра сертификации (более предпочтительный вариант) либо использовать самоподписанный сертификат. Поскольку создание и использование центра сертификации выходит за рамки этой статьи, рассмотрим создание наименее безопасного варианта сертификата — самоподписанного сертификата подлинности.
Сначала заходим в Диспетчер серверов, и последовательно переходим по вкладкам Службы удалённых рабочих столов и Коллекции. На панели Коллекции из меню Задачи выбираем пункт Изменить свойства развёртывания и в открывшемся диалоговом окне Настройка развёртывания переходим на вкладку Сертификаты.
Из перечня служб ролей RDS выбираем Веб-доступ к удалённым рабочим столам. Если будет использоваться сертификат от доверенного центра сертификации, путь к нему можно указать нажав на кнопку Выбрать существующий сертификат.
Т.к. мы будет создавать собственный самоподписанный сертификат, то нажимаем на кнопку Создать новый сертификат. Для того, чтобы создать новый сертификат, достаточно указать его имя (на чьё имя будет сформирован сертификат) и пароль.
В связи с тем, что мы планируем распространять сертификат вручную, то отметим пункты Хранить этот сертификат, указав путь для хранения, и Разрешить добавление сертификата в хранилище «Доверенные корневые центры сертификации» на конечных компьютерах.
Аналогично можно создать сертификаты и для посредника подключений и для шлюза удалённых рабочих столов. Уровень сертификата Без доверия указывает на то, что мы используем самоподписанный сертификат.
Теперь, когда сертификат создан, нужно установить его на рабочих станциях домена. Для этого скопируем сертификат на локальную машину и в его контекстном меню выберем пункт Установить PFX.
После этого откроется окно мастера импорта сертификатов. На первом его шаге нужно выбрать хранилище сертификатов для размещения импортируемого сертификата подлинности. Т.к. планируется использование сертификата для всех пользователей локальной рабочей станции. то выбираем пункт Локальный компьютер.
Затем проверяем путь расположения файла сертификата и жмём Далее.
Следующее окно позволяет ввести пароль для закрытого ключа сертификата и настроить некоторые параметры импорта. Пароль для закрытого ключа сертификата — это тот же пароль, который был введен нами при создании сертификата.
Далее указываем хранилище для импортируемого сертификата. Выбираем пункт Поместить все сертификаты в соответствующее хранилище и указываем Доверенные корневые центры сертификации.
После этого будет отображено окно для сверки с правильностью указания основных параметров импорта. После нажатия на кнопку Готово, сертификат будет импортирован и при успешном выполнении операции будет выдано соответствующее сообщение.
Проверим правильность установки сертификата зайдя на страницу веб-доступа. Как мы видим на экране ниже, сообщение об ошибке сертификата исчезло.
Использование средств панели инструментов Windows 7 и Windows 8/8.1 для доставки приложений RemoteApp
Альтернативой использованию веб-страницы для доступа к приложениям RemoteApp и удалённым рабочим столам является использование средства доступа к удалённым приложениям RemoteApp и удалённым рабочим столам. Возможность его использования появилась еще в Windows 7 и получила логическое развитие в Windows 8/8.1. В пользу использования такого метода доступа к приложениям RemoteApp говорит тот факт, что пользователю нет необходимости заходить на специальную веб-страницу, а достаточно выбрать приложение на стартовом экране или в меню Пуск. Ещё одним достоинством такого способа доставки приложений является возможность ассоциировать определённые типы файлов с приложениями RemoteApp.
Перед тем, как использовать данное средство необходимо убедиться, что сертификат сервера находится в хранилище доверенных корневых сертификатов. Если он туда не был импортирован, то необходимо выполнить процедуру импорта сертификата, как было описано выше.
Для того, чтобы получить доступ к средству подключения приложений RemoteApp необходимо на локальной рабочей станции зайти в Панель управления и там выбрать пункт Подключения к удалённым рабочим столам и приложениям RemoteApp. Так же можно, воспользовавшись каноническим именем этого элемента, выполнить команду control /name Microsoft.RemoteAppAndDesktopConnections
В левой части окна кликнем по ссылке Доступ к удалённым приложениям RemoteApp и рабочим столам, которая запустит соответствующий мастер. На первом шаге предлагается выбрать способ подключения: с помощью прямой ссылки либо с помощью электронного адреса. Рассмотрим оба случая.
Вариант первый, указание прямой ссылки для подключения. В этом случае указываем ссылку вида https://servername/rdweb/feed/webfeed.aspx и жмём Далее.
Далее откроется окно подтверждения правильности введённой ссылки. Если всё верно приступаем к созданию подключения нажав кнопку Далее.
Вариант второй, использование электронного адреса. Этот вариант доступен на ОС Windows 8/8.1. Тут следует дать небольшое разъяснение. На самом деле вводить настоящий электронный адрес вовсе необязательно, т.к. по факту используется только лишь имя домена. Когда имя домена определено, на сервере DNS производится поиск текстовой записи _msradc, которая содержит ссылку для подключения приложений RemoteApp. Поэтому, прежде чем вводить в строку адреса какой-либо e-mail, следует создать в DNS новую текстовую запись с именем _msradc. Сделать это можно в диспетчере DNS, выбрав в меню Действие пункт Другие новые записи.
В окне выбора типа записи отмечаем Текст (TXT) и нажимаем Создать запись
В окне свойств создаваемой текстовой записи в поле Имя записи запишем _msradc, в поле Текст ссылку на страницу веб-доступа https://rdwh.domain.local/rdweb/feed Поле Полное доменное имя (FQDN) должно заполниться автоматически.
Как видим, запись успешно создана и она присутствует в перечне всех записей. Кроме графического представления, эту запись можно проверить с помощью контекста SET TYPE=TXT утилиты NSLOOKUP.
После того, как подготовительный этап закончен, можно в поле адреса подключения ввести электронный адрес пользователя. Так как вводить настоящий адрес вовсе не обязательно, то перед @domain.local укажем абсолютно произвольные символы.
В окне подтверждения правильности ввода данных, в этом случае, будет отображаться электронный адрес, который был введён на предыдущем шаге, а в качестве URL-адреса подключения — адрес, который был использован при создании текстовой записи в DNS.
В случае успешной установки будет отображено окно с информацией о созданном подключении. Здесь можно ознакомиться с именем подключения (именем рабочей области), URL-адресом подключения и числом доступных приложений RemoteApp либо удалённых рабочих столов.
Если подключение осуществлялось на клиентской ОС Windows 8/8.1 приложения можно найти на стартовом экране.
Если подключение осуществлялось на рабочей станции с ОС Windows 7, то приложения можно найти в меню Пуск.
После успешной операции добавления удалённых приложений RemoteApp в панели Подключения к удалённым рабочим столам и приложениям RemoteApp можно посмотреть список установленных приложений, а так же даты установки и последнего обновления.
Окно свойств вызывается одноимённой кнопкой и содержит в себе список свойств подключения (таких как имя, URL-адрес и дату создания) и информацию об обновлении приложений и кнопку для немедленного обновления.
Если нажать на ссылку Просмотр ресурсов, то мы увидим ярлыки, которые ссылаются на непосредственно RDP файлы, которые используются для подключения к программам RemoteApp. В общем случае найти эти файлы можно в папке %APPDATA%RoamingMicrosoftWorkspaces{GUID}Resource. А в соседней папке %APPDATA%RoamingMicrosoftWorkspaces{GUID}Icons можно найти иконки приложений RemoteApp.
Использование приложения Удалённый рабочий стол на Windows RT
На Windows RT так же можно использовать удалённые приложения RemoteApp способом отличным от веб-доступа. Для этого из магазина Windows Store необходимо установить приложение Удалённый рабочий стол (Remote Desktop).
После установки приложения, на первом его экране предлагаются различные варианты подключения. Нас интересует подключение приложений RemoteApp, потому переходим по ссылке Получить доступ к подключениям к удалённым приложениям RemoteApp и рабочим столам.
В качестве адреса подключения введём вымышленный электронный адрес, принадлежащий нашему домену, хотя, как мы видим, можно использовать и полный адрес.
Затем, вводим учётные данные пользователя приложений RemoteApp. Можно поставить галочку Запомнить учётные данные, что повысит удобство использования, но снизит безопасность.
После успешного выполнения установки, отобразится экран содержащий информацию о количестве установленных приложений RemoteApp и удалённых рабочих столов.
После процедуры добавления, программы RemoteApp доступны как со стартового экрана так непосредственно из приложения Удалённый рабочий стол.
Использование средств групповой политики
Удобнейшим способом доставки приложений RemoteApp и удалённых рабочих столов является использование групповых политик. Однако, штатная распространяется политика только на клиентские системы с Windows 8/8.1.
Найти нужную политику можно в узле Конфигурация пользователя Политики Административные шаблоны Компоненты Windows Службы удалённых рабочих столов Подключения к удалённым рабочим столам и приложениям RemoteApp. Параметр называется Указать URL-адрес подключения по умолчанию. Включаем его и в качестве параметра URL-адрес подключения по умолчанию задаем адрес доступа к приложениям. В общем случае он выглядит так https://servername/rdweb/feed/webfeed.aspx.
В случае с клиентскими ОС Windows 7, дело обстоит несколько сложнее, но распространять приложения средствами GPO все же можно. Для этого понадобится скачать PowerShell скрипт Install-RADCConnection.ps1 с TechNet. Кроме самого скрипта понадобится создать файл для передачи скрипту параметров подключения и сохранить его в той же директории, что и сам скрипт. Имя файла с параметрами может быть произвольным, но расширение должно быть WCX.
Содержание файла параметров должно быть примерно таким:
<?xml version=”1.0″ encoding=”utf-8″ standalone=”yes”?> <workspace name=”Удалённые приложения RemoteApp” xmlns=”http://schemas.microsoft.com/ts/2008/09/tswcx” xmlns:xs=”http://www.w3.org/2001/XMLSchema”> <defaultFeed url=”https://rdwh.domain.local/RDWeb/Feed/webfeed.aspx”/> </workspace>
Оранжевым цветом подсвечены параметры имени рабочей области и ссылки для веб-доступа к приложениям.
После того, как файл скрипта сохранён и файл параметров настроен, перейдём к созданию групповой политики. Для этого перейдём в узел Конфигурация пользователя Политики Конфигурация Windows Сценарии Вход в систему и в окне добавления скрипта перейдём на вкладку Сценарии PowerShell.
В этом окне укажем месторасположение сценария нажав на кнопку Добавить. В открывшемся окне указываем наш скрипт не забывая в поле Параметры сценария указать созданный ранее файл с параметрами.
После того, как все данные указаны, закрываем окно добавления сценария входа и привязываем групповую политику к необходимому контейнеру.
Доступ к приложениям RemoteApp из Windows XP
Тем клиентам, у которых до сих пор установлена Windows XP, штатно доставлять приложения предлагается только средствами веб-доступа. Однако же, никто не запрещает самому создавать RDP-файлы и распространять их. Сразу же возникает вполне резонный вопрос — где же их взять?
Ну во-первых, можно забрать с любого компьютера с Windows 7/8/8.1 из папки %APPDATA%RoamingMicrosoftWorkspaces{GUID}Resource. Во-вторых, в том случае, если позаимствовать файлы неоткуда, то можно скачать их со страницы веб-доступа используя для этого браузер отличный от IE или же в самом IE отключив использование всех элементов ActiveX.
Для того, чтобы Windows XP могла взаимодействовать с фермой RDS необходимо обновить клиент RDC до седьмой версии, включить поддержку NLA и установить .NET Framework 3.5 SP1, если необходимо использовать технологию EasyPrint. Если у вас развёрнут только один сервер RDS, то обновлять клиент RDC не обязательно.
Напомню, что для того чтобы включить поддержку NLA на клиентской машине с Windows XP SP3 можно использовать Microsoft Fix it 50588 либо внести необходимые изменения в реестр вручную, как описано тут.
***
Как мы видим, использовать удалённые приложения RemoteApp можно на всех современных клиентских платформах Windows. Конечно, на более современных Windows 7, Windows 8/8.1 и Windows RT развёртывание таких приложений значительно менее трудоёмкий процесс, но и на устаревшей Windows XP всё ещё возможно запускать приложения RemoteApp. Не без глюков, конечно, но об этом как-нибудь в другой раз.
- Remove From My Forums
-
Question
-
We currently have an 2012R2 RDS environment running 8 farms across 12 session hosts from one connection broker. Recently I went to provision 2 new Session Hosts (one to a new farm and one to an existing) however they both fail with the following error in
the Server Manager Wizard:Access is denied
The term ‘Get-LocalMachineFqdn’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.I’ve also tried installing from PowerShell without success.
Has anyone come across this before? I haven’t been able to find anything in my searches on the web let alone find anything of use in the event viewer.
Cheers,
Ryan.
Answers
-
So we finally got to the bottom of this and it’s definitely worth posting the answer!
We’d deployed a GPO to add a PSModulePath environment variable which had been in place and working for a long time, however with the aid of ProcMon we identified that something strange was happening when anything tried to access the RDS PS Modules — it was
constantly referencing the path we’d added as opposed to the local path and hence the failures.Removing the policy, resetting the $env:PSModulePath back to default and rebooting still didn’t fix it though — it still kept trying to reference the path we’d added… Deleting the profile we were trying to manage the deployment with proved successful!
We’re now able to manage the certificates for the deployment and add new servers to the deployment (but only after removing the profile from the servers before trying to add them to the deployment).
Hopefully this helps someone else at some point
-
Marked as answer by
Sunday, June 7, 2015 10:37 PM
-
Marked as answer by
Как упоминалось в сообщении об ошибке («Не удается войти в Lync: при проверке сертификата с сервера произошла ошибка»), это явная ошибка сертификации. Если вы работаете в большой компании (где у них есть собственный внутренний CA — (Центр сертификации)), в большинстве случаев они использовали бы свой внутренний сертификат для установления доверительных отношений. Если вы просто устанавливаете / экспортируете корневой сертификат ЦС в разделе «Доверенные корневые центры сертификации» учетной записи «Локальный компьютер», эта ошибка должна быть устранена.
Если в вашей компании нет собственного ЦС, найдите нашего, выдавшего сертификат для Lynch, и установите / экспортируйте корневой сертификат этого ЦС в то же место, что и выше, эту проблему следует решить.
Разгребая свои очередные заметки по тому, каким образом была решена та или иная проблема я наткнулся на, казалось бы, простую, на первый взгляд, проблему – ошибку “Ошибка при получении свойства сертификата (0x00000000)”, которая генерировалась при попытке установки нового сертификата в 1С. Но я потратил почти день на поиски решения… Наверное, в силу небольшого опыта работы с 1С. Мне редко приходится заниматься 1С, но иногда какие-то задачи на меня прилетаю.
По итогу решение оказалось простое, но не совсем очевидное (да, это был кэш). Возможно, это позволит сэкономить вам какое-то время при решении подобное проблемы.
Описание проблемы
При проверки настроек сертификата электронной подписи в 1С геренируется ошибка “Ошибка при получении свойства сертификата (0x00000000)”:
Окружение
Версия платформы: 1С:Предприятие 8.3 (8.3.17.1851)/
Конфигурация 1С: Управление торговлей, редакция 11 (11.4.13.282) – серверная версия.
Версия Крипто Про: 5.0.12000 KC1
Операционная системы: Windows Server 2008 R2 Standard x64.
ЭЦП расположена на токене Rutoken Lite.
Какие шаги не помогли решить проблемы
Итак, какие шаги я выполнял для устранения проблемы, но они не помогли решить проблему:
1. В Крипто Про я протестировал контейнер закрытого ключа. Проблем не обнаружено. Закрытый ключ присутствует на токене.
2. В какой-то момент генерировалась ошибка “Сертификат не имеет связи с закрытым ключом”, но я выполнил шаги из этого руководства для устранения этой ошибки.
3. Также я установил сертификат в личный контейнер пользователя.
4. Еще пробовал установить сертификат в личный контейнер пользователя вот таким способом.
5. Проверил наличие закрытого ключа в личном контейнере пользователя.
6. Пометил сертификат на удаление, удилил его и попробовал добавить сертификат заново.
7. Перезагружал сервер после выполнения шагов выше (несчетное количество раз).
8. Обновил версию Крипто Про до 5.0.12000 KC1.
Иногда менялась последовательность и комбинация действий. Это из того, что вспомнилось. Возможно делал что-то еще, но не столь важное.
Решение
Как видно из предыдущего раздела я выполнил довольно много действий, но тут я приведу то последнее действие, которое в итоге помогло мне решить проблему. Да, скорее всего, какие-то из действий предыдущего раздела были необходимо и без них решение ниже не помогло бы. Но я не могу сказать какие именно.
Как в итоге я смог устранить эту ошибку:
1. Пометил сертификат на удаление и удалил через удаление помеченных на удаление объектов (ток его удалил, другое ничего не удалял).
2. Очистил кэш 1С для пользователя.
3. Повторно импортировал сертификат.
Да, все таки думаю, что это было из-за кэша 1С. Где-то осела какая-то не актуальная информация о сертификате.
В этой статье мы покажем, как использовать доверенные SSL/TLS сертификаты для защиты RDP подключений к компьютерам и серверам Windows в домене Active Directory. Эти сертфикаты мы будем использовать вместо самоподписанных RDP сертификатов (у пользователей появляется предупреждение о невозможности проверки подлинности при подключению к RDP хосту с таким сертификатом). В этом примере мы настроим специальный шаблон для выпуска RDP сертификатов в Certificate Authority и настроим групповую политику для автоматического выпуска и привязки SSL/TLS сертификата к службе Remote Desktop Services.
Содержание:
- Предупреждение о самоподписанном сертификате RDP
- Создаем шаблон RDP сертификата в центре сертификации (CA)
- Настройка групповой политики для выдачи RDP сертификатов
- Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата
Предупреждение о самоподписанном сертификате RDP
По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный
сертификат. В результате при первом подключении к RDP/RDS серверу через клиента mstsc.exe, у пользователя появляется предупреждение:
Не удалось проверить подлинность удаленного компьютер из-за проблем с сертификатом безопасности. Ошибка сертификата: сертификат выдан не имеющим доверия центром сертификации.
Чтобы продолжить установление RDP подключении пользователь должен нажать кнопку Да. Чтобы RDP предупреждение не появлялось каждый раз, можно включить опцию “Больше не выводить запрос о подключениях к этому компьютеру».
При этом отпечаток RDP сертификата сохраняется на клиенте в параметре CertHash в ветке реестра с историей RDP подключений (HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientServers). Если вы скрыли уведомление о невозможности проверить подлинность RDP сервера, чтобы сбросить настройки, удалите ключ с отпечатком сертификата из реестра.
Несмотря на то, что для подключения используется самоподписанный сертификат, ваше RDP подключение защищено, а трафик зашифрован.
Создаем шаблон RDP сертификата в центре сертификации (CA)
Попробуем использовать для защиты RDP подключений доверенный SSL/TLS сертификат, выданный корпоративным центром сертификации. С помощью такого сертификата пользователь может выполнить проверку подлинности RDP сервера при подключении. Предположим, что у вас в домене уже развернут корпоративной центр сертификации (Microsoft Certificate Authority), в этом случае вы можете настроить автоматическую выдачу и подключение сертификатов всем компьютерам и серверам Windows в домене.
Н на вашем CA нужно создать новый тип шаблона сертификата для RDP/RDS серверов.
- Запустите консоль Certificate Authority и перейдите в секцию Certificate Templates;
- Сделайте копию шаблона сертификата Computer (Certificate Templates -> Manage -> Computer -> Duplicate);
- На вкладке General укажите имя нового шаблона сертификата – RDPTemplate. Убедитесь, что значение поля Template Name полностью совпадает с Template display name;
- На вкладке Compatibility укажите минимальную версию клиентов в вашем домене (например, Windows Server 2008 R2 для CA и Windows 7 для клиентов). Тем самым будут использоваться более стойкие алгоритмы шифрования;
- Теперь на вкладке Extensions в политике приложений (Application policy) нужно ограничить область использования такого сертификата только для Remote Desktop Authentication (укажите следующий object identifier — 1.3.6.1.4.1.311.54.1.2). Нажмите Add -> New, создайте новую политику и выберите ее;
- В настройках шаблона сертификата (Application Policies Extension) удалите все политики кроме Remote Desktop Authentication;
- Чтобы использовать данный шаблон RDP сертификатов на контролерах домена, откройте вкладку Security, добавьте группу Domain Controllers и включите для нее опцию Enroll и Autoenroll;
- Сохраните шаблон сертификата;
- Теперь в оснастке Certificate Authority, щёлкните по папке Certificate Templates, выберите New -> Certificate Template to Issue -> выберите созданный шаблон RDPTemplate.
Настройка групповой политики для выдачи RDP сертификатов
Теперь нужно настроить доменную политику, которая будет автоматически назначать RDP сертификат компьютерам/серверам согласно настроенного шаблона.
Предполагается, что все компьютеры домена доверяют корпоративному центру сертификации, т.е. корневой сертификат через GPO добавлен в доверенные корневые центры сертификации.
- Откройте консоль управления доменными групповыми политиками gpmc.msc, создайте новый объект GPO и назначьте его на OU с RDP/RDS серверами или компьютерами, для которых нужно автоматически выдавать TLS сертификаты для защиты RDP подключения;
- Перейдите в раздел GPO: Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security. Включите политику Server Authentication Certificate Template. Укажите имя шаблона CA, который вы создали ранее (RDPTemplate);
- Затем в этом же разделе GPO включите политику Require use of specific security layer for remote (RDP) connections и установите для нее значение SSL;
- Для автоматического продления RDP сертификата, перейдите в раздел GPO Computer configuration -> Windows settings -> Security Settings -> Public Key Policies и включите политику Certificate Services Client – Auto-Enrollment Properties. Выберите опции “Renew expired certificates, update pending certificates and remove revoked certificates” и “Update certificates that use certificate templates”;
- Если вы хотите, чтобы клиенты всегда проверяли сертификат RDP сервера, вам нужно настроить политику Configure Authentication for Client = Warn me if authentication fails (секция GPO Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Settings -> Remote Desktop Connection Client);
- Если нужно, можете через политики файервола открыть входящий RDP порт TCP/UDP 3389;
- Осталось обновить политики на клиенте, запустить консоль сертификатов компьютера (Certlm.msc), и проверить, что в разделе Personal -> Certificates появился сертификат для Remote Desktop Authentication, выданный вашим CA.
Если политики не применились, для диагностики GPO воспользуйтесь утилитой gpresult и этой статьей.
Для применения нового RDP сертификата, перезапустите службу Remote Desktop Services:
Get-Service TermService -ComputerName msk-dc01| Restart-Service –force –verbose
Теперь при RDP подключении к серверу перестанет появляться запрос на доверие сертификату (чтобы появился запрос о доверии сертификату, подключитесь к серверу по IP адресу вместо FQDN имени сервера, для которого выпущен сертификат). Нажмите кнопку “Посмотреть сертификат”, перейдите на вкладку “Состав”, скопируйте значение поля “Отпечаток сертификата”.
Также можете в консоли Certification Authority в секции Issued Certificates проверить, что по шаблону RDPTemplate был выдан сертификат определённому Windows компьютеру/серверу. Также проверьте значение Thumbprint сертификата:
Теперь сравните полученные данные с отпечатком сертификата, который используется службой Remote Desktop Service. Вы можете посмотреть значение отпечатка сертификата службы RDS в реестре (ветка HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStations, параметр TemplateCertificate) или командой PowerShell:
Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace rootcimv2terminalservices|select SSLCertificateSHA1Hash
Теперь, при подключении к удаленном столу любого сервера или компьютера, на который действует эта политика, вы не увидите предупреждения о недоверенном RDP сертификате.
Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата
Если у вас отсутствует CA, но вы хотите, чтобы при подключении к RDP/RDS серверу у пользователей не появлялось предупреждения, вы можете добавить сертификат в доверенные на компьютерах пользователей.
Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:
Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace rootcimv2terminalservices|select|select SSLCertificateSHA1Hash
Используйте этот отпечаток для подписывания .RDP файла с помощью RDPSign.exe:
rdpsign.exe /sha256 65A27B2987702281C1FAAC26D155D78DEB2B8EE2 "C:UsersrootDesktoprdp.rdp"
Теперь через GPO добавим этот отпечаток сертификата в доверенные у пользователей. Укажите отпечатки (через точку с запятою) в политике Specify SHA1 thumbprints of certificates representing trusted .rdp publishers (Указать отпечатки SHA1 сертификатов, представляющих доверенных издателей RDP) в секции Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Settings -> Remote Desktop Connection Client.
Чтобы работал прозрачных RDP вход без ввода пароля (RDP Single Sign On), нужно настроить политику Allow delegation defaults credential и указать в ней имена RDP/RDS серверов (см. статью).