Далее выбрать роль сервера Службы сертификатов Active Directory . В Появившемся окне оставить все по умолчанию и нажать кнопку Добавитькомпоненты .

Поставить флажок Служба регистрации в центре сертификации через Интернет .

После проверки выбранных параметров установки нажмите Установить .

За процессом установки можно наблюдать в окне Результаты .

После установки службы сертификации необходимо ее настроить. Для этого нажать Настроить службы сертификации Active Directory на конечном сервере.

В окне учетные данные нажать Далее .

В окне выбора службы роли для настройки отметить флажками Центр сертификации и Служба регистрации в центре сертификации через Интернет. Нажать кнопку Далее .

Далее следует выбрать ЦС предприятия .

Затем Подчиненный ЦС .

При создании нового ключа ЦС выбрать опцию Создать новый закрытый ключ .

Далее следует выбрать криптопровайдер RSA#Microsoft Software Key Storage Provider и установить опцию Разрешить взаимодействие с администратором, если центр сертификации обращается к закрытому ключу .

Далее ввести сведения о ЦС. Имя ЦС может быть введено как кириллицей, так и латиницей. При этом если имя вводится кириллицей, то его длина не должна превышать 50 символов. Если Имя вводится латиницей, то его длина не должна превышать 250 символов. Имя ЦС по умолчанию состоит из имени сервера и приставки CA .

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

OU = название отдела

O = название организации

L = город местонахождения

На сообщение о расширенной кодировке имен выбираем Да :

Сохранить запрос на сертификат в файл:

По окончанию появится окно с успешной установкой:

Файл запроса на сертификат будет сохранен в корне диска C:\.

Установка сертификата корневого центра сертификации и актуального списка отозванных сертификатов

Вначале следует загрузить веб-сайт корневого центра сертификации. Для этого запустить браузер, ввести в строку поиска адрес Вашего корневого центра сертификации, например, по имени сервера: http://«имя вашего корневого сервера»/certsrv . Для изготовления сертификата выберите действие Запрос сертификата :

Выбрать Расширенный запрос сертификата, затем Выдать запрос, используя base-64 шифрованный файл… :

Открыть файл с запросом на сертификат в Блокноте, выделить все содержимое в файле (комбинация клавиш Ctrl+A ) и скопировать в буфер обмена (комбинация клавиш Ctrl+C ):

Вставить содержимое буфера обмена (комбинация клавиш Ctrl+V ) в окно выдачи запроса на сертификат на веб-сайте корневого центра сертификации и нажмите кнопку Выдать> :

В результате обработки запроса корневым центром сертификации будет выдан сертификат, который нужно сохранить на подчиненном центре сертификации, нажав на строку Загрузить сертификат :

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

Нажать на строку Загрузка сертификата ЦС, цепочки сертификатов или CRL:

Скачать и сохранить на подчиненном центре сертификации сертификат ЦС и актуальный список отозванных сертификатов, нажав по ссылкам Загрузка сертификата ЦС и Загрузка последнего базового CRL :

Установить корневой сертификат на сервер. Для этого кликнуть правой кнопкой мыши на корневой сертификат, в появившемся контекстном меню выбрать Установить сертификат . В мастере импорта сертификатов выбрать хранилище – Локальный компьютер :

Выбрать хранилище вручную, установив переключатель на Поместить все сертификаты в следующее хранилище и отметить в списке Доверенные корневые центры сертификации/Реестр :

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

Запустить Центр сертификации Пуск\Приложения\Центр сертификации :

Подчиненный центр сертификации еще не работает, т.к. сертификат для него не установлен. Установка сертификата проводится при первом старте службы. Нажать кнопку старта службы:

На запрос об установке сертификата нажать кнопку Да и указать место, куда был сохранен выданный сертификат.

Если все действия были выполнены правильно, служба центра сертификации успешно запуститься.

Настройка подчиненного Центра сертификации

Чтобы просмотреть настройки Центра сертификации, нужно вызвать контекстное меню и выбрать Свойства :

Настроить центр сертификации на выпуск сертификатов в автоматическом режиме. Для этого перейти в закладку Модуль политики , нажать кнопку Свойства . В открывшемся окне выбрать режим Следовать параметрам, установленным в шаблоне…. :

Перейти в закладку Модуль выхода . Нажать кнопку Свойства :

Установить (если не установлен) флажок Разрешить публикацию сертификатов в файловой системе :

Перейти в закладку Аудит . Включить протоколирование некоторых событий безопасности, например, архивации и восстановления базы данных, изменения настроек ЦС и параметров безопасности и т.д.:

Перейти в закладку Безопасность . Разрешить Администратору запрашивать сертификаты. Установить флажок в графе Разрешить для строки Запросить сертификаты :

Перейти в закладку Расширения . Выполнить настройку публикации списка отозванных сертификатов. Для этого в меню Выберите расширение выбрать Точка распространения списка отзыва (CDP) Удалить точки распространения, кроме C:\Windows…. . Добавить путь, например, http://servername/Public/servername.crl , где servername – имя сервера, где будет настроено публичное хранилище:

Включить настройки Включать в CDP-расширение выданных сертификатов и Включать в расширения IDP выданных CRL . Перезапустить Центр сертификации:

В дополнение к CDP, необходимо сконфигурировать дополнение включающее информацию о локализации сертификата ЦС AIA. Для этого в поле Выберите расширение перейти к Authority Information Access (AIA) . Удалить доступы к сведениям о центрах сертификации, кроме C:\Windows…. . Добавить путь, например, http://servername/Public/servername.cer , где servername – имя сервера, где будет настроено публичное хранилище. Включить настройки Включать в AIA- расширение выданных сертификатов . Перезапустить Центр сертификации:

Поскольку значения дополнений CDP и AIA изменены, то для учета изменений необходимо выпустить и опубликовать CRL. Для публикации CRL необходимо в дереве консоли Центра сертификации нажать правой кнопкой мыши на узел Отозванные сертификаты . В появившемся меню выбрать Все задачи — Публикация :

По умолчанию списки отозванных сертификатов размещены в папке

ILYA Sazonov: ITPro

Windows XP

Свежие записи

Топ записей

Архивы

• Февраль 2021 (3)
• Январь 2021 (1)
• Декабрь 2020 (2)
• Октябрь 2020 (1)
• Сентябрь 2020 (1)
• Август 2020 (1)
• Май 2020 (1)
• Апрель 2020 (2)
• Март 2020 (2)
• Февраль 2020 (1)
• Январь 2020 (4)
• Декабрь 2019 (1)
• Ноябрь 2019 (4)
• Октябрь 2019 (2)
• Сентябрь 2019 (5)
• Июль 2019 (2)
• Май 2019 (1)
• Апрель 2019 (3)
• Март 2019 (5)
• Февраль 2019 (5)
• Январь 2019 (3)
• Декабрь 2018 (1)
• Ноябрь 2018 (3)
• Октябрь 2018 (1)
• Сентябрь 2018 (1)
• Август 2018 (1)
• Июль 2018 (3)
• Июнь 2018 (4)
• Май 2018 (3)
• Апрель 2018 (4)
• Март 2018 (1)
• Февраль 2018 (3)
• Январь 2018 (4)
• Декабрь 2017 (8)
• Ноябрь 2017 (3)
• Октябрь 2017 (2)
• Сентябрь 2017 (3)
• Август 2017 (1)
• Июль 2017 (5)
• Июнь 2017 (2)
• Май 2017 (1)
• Апрель 2017 (6)
• Март 2017 (3)
• Февраль 2017 (5)
• Январь 2017 (1)
• Декабрь 2016 (4)
• Ноябрь 2016 (3)
• Октябрь 2016 (5)
• Сентябрь 2016 (4)
• Август 2016 (6)
• Июль 2016 (5)
• Июнь 2016 (6)
• Май 2016 (8)
• Апрель 2016 (8)
• Март 2016 (7)
• Февраль 2016 (8)
• Январь 2016 (5)
• Декабрь 2015 (4)
• Ноябрь 2015 (6)
• Октябрь 2015 (14)
• Сентябрь 2015 (7)
• Август 2015 (6)
• Июль 2015 (3)
• Июнь 2015 (4)
• Май 2015 (8)
• Апрель 2015 (5)
• Март 2015 (10)
• Февраль 2015 (7)
• Январь 2015 (6)
• Декабрь 2014 (7)
• Ноябрь 2014 (14)
• Октябрь 2014 (8)
• Сентябрь 2014 (9)
• Август 2014 (8)
• Июль 2014 (6)
• Июнь 2014 (4)
• Май 2014 (8)
• Апрель 2014 (6)
• Март 2014 (7)
• Февраль 2014 (5)
• Январь 2014 (9)
• Декабрь 2013 (2)
• Ноябрь 2013 (11)
• Октябрь 2013 (10)
• Сентябрь 2013 (9)
• Август 2013 (4)
• Июль 2013 (4)
• Июнь 2013 (3)
• Апрель 2013 (6)
• Март 2013 (2)
• Февраль 2013 (1)
• Январь 2013 (4)
• Декабрь 2012 (3)
• Ноябрь 2012 (4)
• Октябрь 2012 (6)
• Сентябрь 2012 (7)
• Август 2012 (10)
• Июль 2012 (9)
• Июнь 2012 (6)
• Май 2012 (7)
• Апрель 2012 (7)
• Март 2012 (5)
• Февраль 2012 (7)
• Январь 2012 (6)
• Декабрь 2011 (4)
• Ноябрь 2011 (2)
• Сентябрь 2011 (11)
• Август 2011 (8)
• Июль 2011 (5)
• Июнь 2011 (3)
• Май 2011 (1)
• Апрель 2011 (3)
• Март 2011 (4)
• Февраль 2011 (1)
• Январь 2011 (2)
• Декабрь 2010 (4)
• Ноябрь 2010 (1)
• Сентябрь 2010 (2)
• Июль 2010 (3)
• Май 2010 (3)
• Апрель 2010 (1)
• Март 2010 (3)
• Декабрь 2009 (1)
• Ноябрь 2009 (2)
• Октябрь 2009 (11)
• Сентябрь 2009 (3)
• Август 2009 (5)
• Июль 2009 (5)

Подписка на email

Windows Server 2012 R2 Remote Desktop – сертификаты

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

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

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

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

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

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

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

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

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

1. RD Connection Broker – Single Sign On

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

2. RD Connection Broker – Publishing

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

3. RD Web Access

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

4. RD Gateway

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

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

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

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

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

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

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

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

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

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