Как предоставить доступ RDP на основе клиентского сертификата
Репликация является полностью автоматической между контроллерами домена в том же домене, таким образом, Вы не должны должны быть волноваться вообще об этом, если что-то не идет не так, как надо; все AD содержание (пользователи, компьютеры, OUs, GPOS, и т.д.) будет копироваться в любой новый DC, который Вы добавляете к домену, и каждый DC будет всегда хранить полную копию доменной базы данных.
Существует две вещи, о которых необходимо заботиться (кроме любого другого приложения, которое может работать на сервере, конечно): роли FSMO и DNS.
Если Вы, DC является сервером DNS, необходимо заботиться, чтобы включить тот сервис на другой DCS и иметь все доменные членские компьютеры (клиент, и серверы) указывают им вместо того, который Вы ликвидируете; в стандартной AD установке, устанавливая сервис DNS на DC достаточно: Вы не должны определить и заполнить зоны DNS, поскольку основная доменная зона будет интегрироваться AD и таким образом копироваться во все серверы DNS, которые являются также DCS.
Роли FSMO являются специальными ролями, которые могут быть сохранены только единственным DC за один раз, и они обычно принадлежат первому DC, созданному в домене; они будут автоматически перемещены в другой, если Вы понизите в должности DC, который владеет ими, но Вы не будете иметь никакого контроля над их размещением, таким образом, будет всегда лучше переместить их вручную; можно сделать то использование различных инструментов AD (Пользователи и Computers, Sites & Services, Domain & Trusts, Схема), или при помощи NTDSUTIL.
Кроме того, стараться на самом деле понизить старый DC (использование dcpromo) прежде, чем ликвидировать его; это гарантирует, что вся информация относительно его предыдущей роли DC правильно удалена из Active Directory.
Вы можете настроить IPSEC с сертификатами на затронутых машинах, возможно вместе с NAP и использовать брандмауэр Windows для фильтрации RDP трафик, который поступает в незашифрованном виде .
Вот пошаговое руководство для сценария, аналогичного вашему запросу, но с использованием предварительных ключей вместо сертификатов.
Но имейте в виду, что «создание сертификата и копирование этого на все компьютеры "само по себе является плохой идеей - очевидно, вы должны создать один сертификат для каждого клиента и соответствующим образом настроить правила доступа. Это гарантирует конфиденциальность ваших подключений, а также возможность отозвать сертификаты, поскольку они будут потеряны / раскрыты, без нарушения подключений других машин.
Изменить: может показаться заманчивым настройка шлюза удаленного рабочего стола (в основном туннельный шлюз HTTPS для RDP) и требование аутентификации сертификата клиента при настройке SSL-соединения через свойства IIS (шлюз реализован как Приложение ASP.NET в IIS). Однако, похоже, это не поддерживается клиентом удаленного рабочего стола - нет способа предоставить сертификат клиента для прокси-соединения.
Один из способов - использовать смарт-карту. Вероятно, это не то, что вы ищете из-за стоимости и порога боли, но многие смарт-карты на самом деле являются именно такими (аппаратные сертификаты с надежной защитой закрытого ключа), а интеграция с удаленным рабочим столом является беспроблемной.