Я исследовал это, но не смог найти окончательного ответа на свой вопрос. Я никогда раньше не использовал службы сертификации в активном каталоге, поэтому не уверен в их возможном использовании / реализации.
Краткая предыстория: мы хотим настроить ферму удаленных рабочих столов с сервером шлюза, чтобы позволить удаленным пользователям подключаться к ферме без VPN. Чтобы пользователи могли подключиться, нам необходимо установить доверенный сертификат для сервера шлюза.
В своей тестовой среде я использовал самоподписанный сертификат и вручную устанавливал его в доверенные корневые центры сертификации, что отлично работает! Это означает, что любое устройство, на которое мы устанавливаем этот сертификат, может подключиться.
Очевидно, что мы не хотим делать это вручную, поэтому, как мне кажется, лучше всего покупать сертификат у кого-то вроде VeriSign. Я подумал о службах сертификатов в AD и подумал, можем ли мы просто создать наш собственный сертификат, используя внутренний центр сертификации.
По сути, мой вопрос сводится к следующему: автоматически ли компьютер, подключенный к домену, доверяет сертификатам, выданным ЦС в том же домене, или их все равно нужно будет вручную устанавливать на каждом клиентском устройстве? Можно ли каким-то образом использовать эту функцию Windows Server, чтобы сэкономить деньги на сертификатах?
По сути, мой вопрос сводится к следующему: доверяет ли компьютер, присоединенный к домену, автоматически сертификатам, выданным центром сертификации в том же домене, или их все равно нужно будет вручную устанавливать на каждом клиентском устройстве?
Обычно корневой сертификат для вашей внутренней PKI распространяется через GPO всем клиентам. Это делает его "автоматическим"
По сути, мой вопрос сводится к следующему: автоматически ли компьютер, подключенный к домену, доверяет сертификатам, выданным ЦС в том же домене, или их все равно нужно будет вручную устанавливать на каждом клиентском устройстве?
Клиенты не будут автоматически доверять сертификатам от внутреннего ЦС, нет.
Тем не менее, нет необходимости распространять сертификат вручную, потому что это может быть сделано с помощью GPO. «Руководство» Technet по этому процессу находится здесь., и с объектами групповой политики и внутренним центром сертификации вы можете сделать гораздо больше, чем просто это. Например, мы используем наш для распространения сертификатов, чтобы обеспечить автоматическое беспроводное соединение с WPA2-Enterprise, чтобы наши клиенты доверяли всем службам SSL в наших средах (принтеры, внешнее управление, даже наше программное обеспечение для резервного копирования), чтобы пользователи не получать предупреждения о сертификатах и многое другое.
В любом случае, в консоли управления групповой политикой перейдите по адресу:
Computer Configuration -> Windows Settings -> Security Setting -> Public Key Policies -> Trusted Publishers и добавьте свой сертификат в магазин «Trusted Root Certification Authorities», и все готово к тому, что вы хотите делать.
Я знаю, что это устарело, но для пояснения для будущих исследователей:
Центр сертификации предприятия, установленный в лесу AD, будет автоматически публиковать сертификат ЦС для членов домена через Active Directory, а не через GPO. Хотя вы можете распространять сертификаты через GPO, это не требуется для корпоративных ЦС (и, вероятно, не должно быть для корпоративных ЦС, поскольку это приведет к дублированию сертификатов для ЦС в вашем хранилище доверенных корневых центров сертификации)
Автономные центры сертификации не распространяют сертификаты автоматически через AD, но вы можете опубликовать их в AD вручную. Видеть: https://technet.microsoft.com/en-us/library/cc731612.aspx
Эти опубликованные сертификаты хранятся в контейнере. CN = NTAuthCertificates, CN = Public Key Services, CN = Services, CN = Configuration, DC = yourdomain, DC = com