Magic Cookies: Удостоверяющий центр на Windows 2008/2008R2

Введение

Протокол RDP – удобное, эффективное и практичное средство для удалённого доступа как для целей администрирования, так и для повседневной работы.
Учитывая, что его реализации есть практически везде (различные платформы и ОС), и их много, нужно хорошо представлять его возможности.
По крайней мере, это будет нужно по ряду причин:

• Зачастую вместо RDP используется другое решение (VNC, Citrix ICA) по простой причине – предполагается, что “встроенный RDP минимальный и ничего не умеет”.
• Во многих решениях, связанных с модными сейчас облачными технологиями (перевод офисов на “тонкие клиенты”, да и просто организация терминальных серверов), бытует мнение что “RDP плохой потому что встроенный”.
• Есть стандартный миф про то, что “RDP нельзя без VPN наружу выставлять, ломанут” (миф имеет под собой обоснование, но уже давно не актуален).
• Ну, раз уж про мифы заговорили – бытует мнение, что “Перейдя с RDP на Citrix трафик в пару раз падает”. Ведь цитрикс – это дорого, следовательно как минимум на 157% круче.

Все эти мифы – ерунда и смесь устаревших “дельных советов”, актуальных во времена NT 4.0, а так же откровенных вымыслов, не имеющих никаких причин к существованию. Так как IT – это точная наука, надо разобраться. Хорошо настроеный протокол RDP новых версий, с учётом всех новых функциональных возможностей, является достаточно хорошим и надёжным инструментом для организации удалённого доступа.

Поэтому мы займёмся:

• Кратким упоминанием про версии RDP
• Настройкой режима защиты RDP-сессии
• Настройкой шифрования для RDP
• Привязкой к конкретному адаптеру и порту
  • Меняем стандартный порт на нужный
  • Делаем раздельные настройки RDP для нескольких сетевых адаптеров
• Включением NLA
  • Как включается NLA со стороны RDP-сервера
  • NLA и Windows XP
  • Как включить CredSSP в XP
• Выбором правильного сертификата для RDP
• Блокированием подключений по RDP учётным записям с пустым паролем
• Настройка ACL для подключения по RDP
• Оптимизацией скорости RDP
  • Отключаем редирект неиспользуемых устройств
  • Настраиваем общую логику оптимизации визуальных данных RDP
• Оптимизацией сжатия RDP
  • Настраиваем общее сжатие RDP
  • Настраиваем сжатие аудиопотока RDP
• Оптимизацией соотношения потоков данных RDP
• Включением Require secure RPC communication для RDP

Приступим.

Вопросы и ответы по использованию сертификатов в службах удаленных рабочих столов

Вопрос: Как устанавливать на сервер сертификаты, которые я мог бы использовать в службах удаленных рабочих столов (RDS)?

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

1. Откройте консоль MMC, выполнив команду mmc.
2. Добавьте оснастку Certificates (File, Add/Remove Snap-ins).
3. Последовательно выберите Choose Computer Account и Add, после чего щелкните OK.
4. Перейдите к папке Personal, а затем к Certificates.
5. Щелкните папку правой кнопкой и выберите Import, чтобы импортировать сертификат, полученный в центре сертификации.

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

Вопрос: Как отключить все сообщения-предупреждения, отображаемые при запуске подписанного RDP-файла?

Ответ: Включите параметр политики. Задайте SHA1-отпечатки сертификатов, представляющих доверенных издателей RDP-файлов. При включении этой политики задаются сертификаты, которые клиент будет считать доверенными. Если клиент доверяет сертификату, все RDP-файлы, подписанные этим сертификатом считаются доверенными.

Вопрос:  Я установить правильные сертификаты на свои серверы узлов сеансов удаленных рабочих столов, но подключиться все равно не удается.

Ответ: Существует немного известных проблем с сертификатами в применении с реализацией служб RDS:

Защита rdp соединения при помощи ssl.

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

Какие преимущества дает нам защита 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 (за исключением отсутствующих возможностей).

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

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

Как включить credssp в xp

Ещё раз – данная операция проводится строго

после

установки Service Pack 3 на Windows XP и в контексте нашего разговора нужна для того, чтобы было возможно подключение к другим серверам по RDP 6.1 с использованием NLA.

Шаг первый – расширяем перечень Security Packages.
Для этого мы откроем ключ реестра

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa

и найдём в нём значение

Security Packages

. Нажмём правую кнопку и выберем “Modify” (не Modify Binary Data, а просто Modify). Там будет список вида “название package на каждой строке”. Нам надо добавить туда

tspkg

. Остальное надо оставить. Место добавления некритично.

Второй шаг – подцепляем библиотеку.
Ключ будет другим:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProviders

В нём надо будет найти значение

SecurityProviders

(заметьте, как и в предыдущем случае, это не subkey, а значение), и модифицировать его по аналогии, только добавив

credssp.dll

. Остальное в списке, опять же, трогать не надо.

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

Назначение корпоративного центра сертификации

Шифрование, сертификаты, цифровые подписи плотно вошли в повседневную
деятельность организаций. Ведущие игроки на рынке программного активно
продвигают идеологию «безопасного интернета», требуя поддержки цифровых
сертификатов.

Однако текущее положение в этой области не позволяет решать вопросы
безопасного интернета без существенных финансовых затрат на
приобретение SSL- сертификатов. При этом
бесплатные сертификаты сервиса
Let’s Encrypt покрывают лишь узкий спектр корпоративных потребностей в
сертификатах.

Например, не покрываются сертификаты для шифрования
документов, почты, цифровых подписей, аутентификация клиентов. Для
использования публичных сертификатов, выданных коммерческими CA вам
необходимо иметь публичный домен. Получить сертификат для веб-сервера
на имя domain.local от Let’s Encrypt технически невозможно. Именно
поэтому актуальность частных корпоративных центров сертификации
остаётся на очень высоком уровне.

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

Здесь корневой ЦС
выпускает сертификаты для подчинённых ЦС, а уже
подчинённый ЦС
выдаёт сертификаты конечным потребителям.

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

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

Типовая схема двухуровневой схемы центра сертификации (ЦС):

Обновление сертификатов цс

Периодически необходимо обновлять сертификаты ЦС. Рассмотрим несколько аспектов, связанных с обновлением сертификатов ЦС.

Периодичность обновления сертификата ЦС

Это делается в следующих случаях:

• Срок жизни сертификата ЦС истекает;
• Ключ ЦС скомпрометирован;
• Необходимо изменить длину ключа или алгоритм подписи;
• Слишком большой список отзыва (больше нескольких мегабайт).

Первый вопрос, если всё идёт штатно, за какое время до истечения срока действия сертификата ЦС его нужно обновлять?

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

В нашей двухуровневой иерархии сертификаты корневого и издающего ЦС имеют одинаковый срок действия. Поэтому, когда вы принимаете решение об обновлении сертификата любого ЦС, необходимо обновлять их вместе. Первым обновляется сертификат корневого ЦС, затем сертификат издающего ЦС.

Генерация ключей при обновлении сертификатов ЦС

При обновлении сертификатов ЦС вам предлагается две опции: использовать существующую ключевую пару или сгенерировать новую:

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

Оптимизация соотношения потоков данных в rdp

Трафик RDP-сессии не является чем-то монолитным. Наоборот, он достаточно чётко разделён на потоки данных перенаправляемых устройств (например, копирования файла с локального хоста на терминальный сервер), аудиопоток, поток команд примитивов отрисовки (RDP старается передавать команды примитивов отрисовки, и передаёт битмапы в крайнем случае), а также потоки устройств ввода (мышка и клавиатура).

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTermDD

и создать там для начала (если их там нет) четыре ключа:

• FlowControlDisable
• FlowControlDisplayBandwidth
• FlowControlChannelBandwidth
• FlowControlChargePostCompression

Тип у всех – DWORD 32. Функционал у ключей будет следующим.
Ключ

FlowControlDisable

будет определять, используется ли приоритезация вообще. Если задать единицу, то приоритезация будет выключена, если нуль – включена. Включите её.
Ключи

FlowControlDisplayBandwidthFlowControlChannelBandwidth

будут определять взаимное соотношение двух потоков данных:

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

Сами значения этих ключей не критичны; критично то, как они соотносятся. То есть, если Вы сделаете

FlowControlDisplayBandwidth

равным единице, а

FlowControlChannelBandwidth

– четырём, то соотношение будет 1:4, и на поток взаимодействия с пользователем будет выделяться 20% полосы пропускания, а на остальное – 80%. Если сделаете 15 и 60 – результат будет идентичным, так как соотношение то же самое.
Ключ

FlowControlChargePostCompression

будет определять, когда считается это соотношение – до сжатия или после. Нуль – это до сжатия, единица – после.

Я рекомендую для использования вида “наш удалённый сервак далеко и к нему все по RDP подключаются и в офисе и 1С работают” ставить соотношение 1:

1 и считать его после сжатия. По опыту это может реально помочь в ситуации “печать большого документа с терминального сервера на локальный принтер”. Но это не догма – пробуйте, главный инструмент – знание, как это считается и работает – у Вас уже есть.

Подписывание приложений remoteapps

RemoteApps подписывают с использованием сертификата, установленного на диспетчере RemoteApp на сервере узлов сеансов удаленных рабочих столов (рис. 2).

Рис. 2. Можно также подписывать приложения RemoteApps, для чего используеться сертификат в диспетчере удаленных приложений RemoteApp

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

Для этого нужно экспортировать сертификат вместе с закрытым ключом с сервера. Импортируйте сертификат, используя MMC-оснастку Certificates (Сертификаты), добавив при этом учетную запись компьютера, а не пользователя.

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

1. Сеанс, в котором устанавливается сертификат на посреднике подключений к удаленным рабочим столам называется Virtual Desktops: Resources and Configuration (Виртуальные рабочие столы: ресурсы и настройка). Устанавливаемый сертификат не только используется для подписания ВМ инфраструктуры виртуальных рабочих столов, но также применяется в процессе единого входа для интернет-решений для подписания приложений RemoteApps, когда используется посредник подключений к удаленным рабочим столам. Сертификаты подписания в посреднике и диспетчере RemoteApp серверов узлов сеансов удаленных рабочих столов должны совпадать иначе единый вход для интернет-решений работать не будет.
2. Если при запуске RemoteApp сертификат на посреднике отличается от сертификата на серверах узлов сеансов удаленных рабочих столов, единый вход для интернет-решений не работает. При этом никакой информации о различии сертификатов не предоставляется. В открывающемся окне показан только набор сертификатов в диспетчере RemoteApp, поэтому сложно узнать, что проблема в сертификатах.

Подробнее о настройке единого входа для интернет-решений см. веб-страницу «Introducing Web Single Sign-On for RemoteApp and Desktop Connections» по адресу

Получение сертификата компьютера в командной строке

Перед выполнением процедуры следует убедиться в том, что на ISA:2006:

1. Зарегистрироваться на компьютере с учетной записью администратора домена.

2. Открыть командную консоль, перейти в каталог C:Service (при необходимости создать каталог C:Service).

3. Создать файл C:ServiceRequest.inf, содержащий текст.

[Version]

Signature= “$Windows NT$” 

[NewRequest]

Subject = “CN=<полное_внешнее_имя_для_сервиса_OWA>”

KeySpec = 1

KeyLength = 1024

Exportable = TRUE

MachineKeySet = TRUE

UseExistingKeySet = FALSE

ProviderName = “Microsoft RSA SChannel Cryptographic Provider”

ProviderType = 12

RequestType = PKCS10

KeyUsage = 0xa0 

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1

Пример файла Request.inf. На данном снимке полное внешнее имя для веб-почты: owa.ext-lab.dom

Благодаря выражению Exportable=true мы получим желанную галочку Пометить ключ как экспортируемый, а MachineKeyset=true даст сертификат компьютера.

Выполнить команду для запроса сертификата

certreq -new Request.inf Request.req

Выполнить команду для получения сертификата

certreq -submit -attrib “CertificateTemplate:WebServer” Request.req Server.crt

Появляется диалог Select Certification Authority.

В диалоге щелкнуть по единственному УЦ и затем нажать OK.

Если УЦ успешно выдал сертификат, появляется сообщение об успешном получении сертификата:

Выполнить команду для установки сертификата

certreq -accept Server.crt

Выполнить тесты Проверка наличия сертификата компьютера и Проверка пригодности сертификата для веб-прослушивателя.

Пошаговая инструкция по установке и настройке центра сертификации | блог разработчиков

Проверка работоспособности

После применения групповой политики Windows клиенты должны в автоматическом порядке получить сертификат. Если этого не произошло, стоит обратить внимание на:

1. Отсутствие в правильной группе безопасности, которая указана в шаблоне;
2. Отсутствие к ЦС необходимых сетевых портов от клиента. Напомню, это tcp/135 (RPC) и динамические порты tcp/49152—65535.

Проверить что сертификат был успешно выпущен можно в консоли ADCS:

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

Скрипт настройки

Для конфигурирования настроек ЦС мы будем использовать BATCH скрипт с использованием утилиты certutil.exe:

Ряд команд нуждается в более развёрнутом пояснении. Команды с настройкой расширений CRL Distribution Points и Authority Information Access имеют специфический синтаксис. Во-первых, пути публикации и распространения указываются в одну строку и разделяются символом новой строки «n».

Если взять путь для CDP: 1:%windir%system32CertSrvCertEnroll%%3%%8.crl, то цифра 1 в начале строки говорит о том, что это путь физического размещения файла (Publich CRLs to this location). Другие опции здесь не используются. Для включения пути, который будет публиковаться в издаваемых сертификатах, мы будем использовать опцию «Include in the CDP extension of issued certificates» с числовым значением 2. Такой же принцип применяется и для остальных путей.

В каждом пути включены переменные с двойным знаком процента «%%». Это переменные, которые ЦС при формировании пути будет автоматически заполнять исходя из типа переменной.

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

Следующая таблица содержит описание всех доступных переменных и их краткое описание:

В нашем конкретном случае будут использоваться только две переменные: и . Для исходного сертификата ЦС эти переменные пустые. При обновлении сертификата ЦС, переменная будет заменяться на «(index)», где index — номер сертификата ЦС. Индексирование начинается с нуля.

Отдельного внимания заслуживает команда, которая включает аудит операций на сервере ЦС, которые регистрируются в системном журнале Security.evtx. К ним относятся все основные операции: запуск/остановка службы, отправление запроса, выпуск или отклонение сертификата, выпуск списка отзыва.

Особенность ведения аудита ЦС заключается в том, что настройка флагов аудита на ЦС является необходимым, но не достаточным условием. Механизм аудита основан на регистрации событий в журнале Security.evtx, который, в свою очередь зависит от настройки политики Audit Object Access в групповых политиках. Т.е. без настройки групповых политик никакого аудита не будет.

Опытные администраторы знают к чему приводит включение Audit Object Access — к лавинному созданию записей в журнале от других компонентов ОС. Например, аудит доступа файловой системы, реестра, других установленных ролей и т.д. В результате, журнал может буквально за день-два заполниться до отказа.

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

Создание шаблона сертификата rdp в adcs

Первый шаг состоит в создании шаблона сертификата, с помощью которого Windows клиенты будут автоматически генерировать сертификаты используемые в RDP подключениях. Для этого в оснастке ADCS переходим к управлению шаблонами сертификатов:

Дублируем сертификат Computer

Задаем имя будущего шаблона:

Указываем настройки совместимости:

В Extensions, необходимо задать правильные Application Policies для  поддержки TLS в RDP протоколе

Для этого удаляем Client Authentication и Server Authentication и добавляем Remote Desktop Authentication с OID 1.3.6.1.4.1.311.54.1.2, как показано на скриншоте:

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

Завершающим шагом будет его выпуск на выдающем корпоративном ЦС:

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

Установка службы сертификации из состава ms windows

Установка службы сертификации производится с использованием Мастера
компонентов Windows в следующей последовательности:

1. Открыть окно Панели управления, выполнив команды Пуск, Панель управления.
2. В окне Панели управления открыть пункт Администрирование и выбрать
   Диспетчер сервера.
3. Выбрать пункт Роли. В правой части окна нажать Добавить роли и выделить пункт
   Службы сертификации Active Directory.
   В следующем окне мастера выбрать пункты Центр Сертификации –и Служба регистрации
   в центре сертификации через Интернет.



4. В появившемся окне нажать кнопкуДобавить требуемые службы роли:





5. Далее следует выбрать Автономный ЦС, затем – Корневой ЦС.
6. При создании нового ключа ЦС выбрать опцию Создать новый закрытый ключ.
7. Далее следует выбрать криптопровайдер RSA#Microsoft Software Key
   Storage Provider и установить опцию Разрешить взаимодействие с администратором,
   если центр сертификации обращается к закрытому ключу.



8. Далее следует ввести сведения о ЦС. Имя ЦС (в примере это MS-Root-CA)
   может быть введено как кириллицей, так и латиницей. При этом если имя
   вводится кириллицей, то его длина не должна превышать 50 символов. Если
   Имя вводится латиницей, то его длина не должна превышать 250 символов.
   Имя ЦС может быть любым.
9. Ввести сведения о Вашей организации по следующему
   примеру:

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

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

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

C=RU

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

10. Далее нужно задать срок действия сертификата ЦС 15 лет и затем следовать указаниям Мастера
    установки службы, выбирая предлагаемые значения по умолчанию.