Назад | Перейти на главную страницу

Active Directory, групповой сертификат безопасности и удаленный доступ

Есть ли способ защитить весь домен Active Directory (AD) с помощью единого доверенного сертификата безопасности, подписанного сторонним центром сертификации (CA), чтобы удаленный доступ был беспрепятственным для:

  1. RDP с использованием удаленного веб-доступа (RWA) через шлюз удаленных рабочих столов (RDG) на ПК.
  2. RDP с использованием подключения к удаленному рабочему столу через шлюз удаленного рабочего стола (RDG) к серверу служб удаленных рабочих столов (RDS).

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

  1. Сидя в https://internal.domain.com/remote, войдя в систему и выбрав PC-01.
  2. Открытие RemoteApp и вход в систему.

Подробности:

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

Однако я знаю, что у AD есть собственная инфраструктура открытых ключей (PKI) и «внутренний» центр сертификации, который используется для обеспечения доверия между доменом и компьютерами, присоединенными к домену. Итак, есть ли способ заменить корневой сертификат безопасности ЦС AD на доверенный сторонний сертификат безопасности с подстановочными знаками, подписанный ЦС?

Обновление 2016/06/30 16:33: Я добился значительного прогресса в этом и напишу ответ, как только проблемы будут устранены.

Отказ от ответственности: это насколько я помню

 

Наш поставщик сертификатов безопасности, SSL247, сообщил мне, что сертификаты безопасности с подстановочными знаками:

  1. Охватывайте только субдомены на один уровень ниже, а не корневой домен.
  2. Может быть установлен на неограниченное количество серверов (в том числе ПК?), Если они не предоставлены Symantec (если я правильно помню).

 

Проще говоря, полное решение заключалось в следующем:

  1. На сервере RDS откройте RemoteApp Manager и измените RDG с internal.domain.com к remote.internal.domain.com.

  2. В Интернет-домене domain.comавторитетных серверов имен, создайте запись ресурса DNS (RR):

    remote.internal.domain.com 3600 IN A <public IP address>

  3. На маршрутизаторе создайте правила межсетевого экрана и NAT, чтобы разрешить и перенаправить порт TCP 443 на сервер RDG.

  4. На сервере RDG откройте диспетчер IIS и создайте запрос на подпись сертификата (CSR) для *.internal.domain.com
  5. Отправьте CSR в доверенный сторонний центр сертификации и дождитесь его выпуска.
  6. На сервере RDG откройте диспетчер IIS, заполните CSR, тем самым установив групповой сертификат безопасности, и экспортируйте групповой сертификат безопасности с его закрытым ключом в файл PFX.
  7. На сервере RDG откройте диспетчер RDG и настройте сертификат безопасности, политики авторизации подключений (CAP) и политики авторизации ресурсов (RAP).
  8. На сервере RDS откройте MMC> Certificates и импортируйте файл PXF, тем самым установив групповой сертификат безопасности.
  9. На сервере RDS откройте конфигурацию узла RDS и перенастройте соединение «RDP-Tcp», изменив сертификат безопасности.

 

На самом деле наше решение было намного сложнее.

Наша первоначальная установка была следующей:

  1. Роль RDG, установленная на сервере server-01.internal.domain.com под управлением Windows Server 2012 R2 Essentials.
  2. Роль RDS, установленная на сервере server-02.internal.domain.com под управлением Windows Server 2008 R2 Standard.

Короче говоря (при необходимости попросите разъяснений), эта установка просто не сработала. Несмотря на то, что учетная запись администратора домена и все параметры (RDG, CAP, RAP, NPS и т. Д.) Настроены как можно ниже / открыты, внешний RDP не удался последовательно со следующими ошибками:

Удаленный рабочий стол не может подключиться к удаленному компьютеру server-02.internal.domain.com по одной из следующих причин:
1) Ваша учетная запись пользователя не авторизована для доступа к шлюзу удаленных рабочих столов "remote.internal.domain.com"
2) Ваш компьютер не авторизован для доступа к шлюзу удаленных рабочих столов "remote.internal.domain.com"
3) Вы используете несовместимый метод аутентификации (например, шлюз удаленных рабочих столов может ожидать смарт-карту, но вы указали пароль)

 

Имя журнала: Microsoft-Windows-TerminalServices-Gateway / Operational
Источник: Microsoft-Windows-TerminalServices-Gateway
Дата: 30.06.2016 15:47:33
Идентификатор события: 201
Категория задачи: (2)
Уровень: Ошибка
Ключевые слова: отказ аудита, (16777216)
Пользователь: NETWORK SERVICE
Компьютер: server-01.internal.domain.com
Описание:
Пользователь «% domainAdministrativeUserAccount%» на клиентском компьютере «% ourPublicIPAddress%» не соответствовал требованиям политики авторизации подключения и поэтому не был авторизован для доступа к серверу шлюза удаленных рабочих столов. Используемый метод аутентификации: «NTLM», используемый протокол подключения: «HTTP». Произошла следующая ошибка: «23003».

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

Я поручил нашему Центру сетевых операций (NOC) провести расследование, и они пришли к выводу, что проблема была вызвана использованием Essentials.

Я переместил роль RDG с сервера №1 на сервер №2 (я понимаю, что это почти бессмысленно), обновил сеть, и это сработало практически мгновенно.

Ну что ж. По крайней мере, это работает.