+7(499)-938-42-58 Москва
+7(800)-333-37-98 Горячая линия

Установка службы сертификатов active directory. Порядок обновления ЦС

Содержание

Удаление центра сертификации из Active Directory

Установка службы сертификатов active directory. Порядок обновления ЦС

При удалении службы сертификации Active Directory Certificate Services необходимо выполнить ряд предварительных и пост шагов, необходимых для корректного удалений центра сертификации (Certification Authority или CA) из Active Directory.

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

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

Отзыв выданных сертификатов

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

Для этого откройте консоль Certification Authority, разверните узел сервера сертификации и в перейдите в раздел Issued Certificates.

В правом окне выберите выданный сертификат и в контекстном меню выберите  пункт All Tasks >Revoke Certificate.

Укажите причину отзыва сертификаты (Cease of Operation — Прекращение работы), время с которого он считается недействительным (текущее) и нажмите Yes.

Сертификат пропадет из списка. Аналогичным образом поступите со всеми выданными сертификатами.

Затем откройте свойства ветки RevokeCertificates.

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

Нажмите ПКМ по узлу Revoked Certificates и выберите All Tasks > Publish.

Выберите NewCRL и нажмите OK.

Проверьте и, в случае необходимости, откажите в выдаче всем ожидающим запросам на выдачу сертификатов. Для этого в контейнере Pending Requests выделите запрос и в контекстном меню выберите All Tasks ->Deny Request.

Удаление роли Active Directory Certificate Services

На сервере с ролью CA откройте командную строку и остановим работы служб сертификации командой:

certutil –shutdown

Чтобы вывести список локально хранящихся закрытых ключей выполним команду:

certutil –key

В нашем примере с CA ассоциирован один закрытый ключ. Удалить его можно командой certutil -delkey CertificateAuthorityName. В качестве имени ключа используется значение, полученное на предыдущем шаге. Например,

certutil –delkey le-DomainController-b44c7ee1-d420-4b96-af19-8610bf83d263

Чтобы убедится, что закрытый ключ CA удален еще раз выполним команду:

certutil –key

Затем откроем консоль Server Manager и удалим роль Active Directory Certificate Services.

После удаления роли сервер нужно перезагрузить.

Удаление объектов CA из Active Directory

При установке центра сертификации в структуре Active Directory создается ряд служебных объектов CA, которые не удаляются при удалении роли ADCS. Удаляется только объект pKIEnrollmentService, благодаря чему клиенты не пытаются запрашивать новые сертификат у выведенного из эксплуатации CA.

Выведем список доступных центров сертификации (он пуст):

certutil

Откроем консоль Active Directory Site and Services и включим отображение сервисных веток, выбрав в верхнем меню пункт View ->Show Services Node.

Затем последовательно удалим следующие объекты AD:

  1. Центр сертификации в разделе Services -> Public Key Services -> AIA.
  2. Контейнер с именем сервера CA в разделе Services -> Public Key Services -> CDP.
  3. CA  в разделе Services > Public Key Services > Certification Authorities.
  4. Проверьте, что в разделе Services -> Public Key Services -> Enrollment Services отсутствует объект pKIEnrollmentService (он должен удалиться во время процесса деинсталляции CA). Если он присутствует, удалите его вручную.
  5. Удалите шаблоны сертификатов, расположенные в разделе Services -> Public Key Services > Certificate Templates (выбелить все шаблоны CTRL+A).

Удаляем сертификаты, опубликованные в контейнере NtAuthCertificates

При установке нового центра сертификации его сертификаты добавляются и хранятся в контейнере NTAuthCertificates. Их также придется удалить вручную. Для этого с правами администратора предприятия выясним полный LDAP путь к объекту NtAuthCertificates в Active Directory.

certutil -store -? | findstr “CN=NTAuth”

Осталось удалить сертификаты с помощью утилиты certutil , указав полный LDAP путь, полученный на предыдущем шаге.

certutil –viewdelstore “ldap:///CN=NtAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=no1abnopary,DC=local?cACertificate?base?objectclass=certificationAuthority”

Подтверждаем удаление сертификата.

https://www.youtube.com/watch?v=Jb4rPIbPdoc

Далее выполним команду:

certutil –viewdelstore “ldap:///CN=NtAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=no1abnopary,DC=local?cACertificate?base?objectclass=pKIEnrollmentService”

Подтвердите удаление сертификата.

Удаление базы центра сертификации

База CA автоматически не удаляется при удалении службы ADCS, поэтому эту операцию нужно выполнить вручную, удалив каталог %systemroot%\System32\Certlog.

Удаление сертификатов с контроллеров домена

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

certutil -dcinfo deleteBad

Certutil попытается проверить все сертификаты, выданные DC. Сертификаты, которые не удастся проверить, будут удалены.

На этом полное удаление службы Active Directory Certificate Services из структуры Active Directory завершено.

Источник: https://winitpro.ru/index.php/2014/11/28/udalenie-centra-sertifikacii-iz-active-directory/

Разворачиваем Центр сертификации в домене(PKI)

Установка службы сертификатов active directory. Порядок обновления ЦС

Оцените материал

Домен: TEST.LOCAL

Серверы: (Автономный) RootCA; (Предприятие) SRV03.TEST.LOCAL

Сетевое хранилище DFS: \\test.local\SOFT\PKI

WEB сервер: совмещён с сервером ЦС домена SRV03.TEST.LOCAL

Подготовка сетевого хранилища

Создать сетевую папку на файловом сервере и подключить к пространству имён. Назначить права на папку: Доступ – Все (чтение/запись); Безопасность – TEST\SRV03$ (чтение/запись)(учётная запись сервера ЦС в домене)

Подготовка WEB сервера

На серверах DNS (в случае домана – контроллеры домена) создать запись pki.test.local ведущую на IP адрес WEB сервера (в нашем случае SRV03.TEST.LOCAL)

Создасть сайт pki.test.local на WEB сервере, указав в качестве физического сетевой путь \\test.local\SOFT\PKI

Для возможности работы с сетевой папкой необходимо запускать сайт как сетевую службу. Для этого в разделе Пулы приложений – выбрать приложение созданого сайта PKIДополнительные параметры.

Параметр Модель процесса Удостоверение установить NetworkService.

Перейти в настройки сайта – Проверка подлинностиАнонимная проверка подлинностиИзменить и установить Удостоверение пула приложений

Чтобы IIS сервер мог распознавать DeltaCRL необходимо добавить возможность чтения знака “+”. Для этого в оснастке IIS нужно в настройках сайта открыть Фильтрация запросов – Изменить параметры и установить Разрешить двойное преобразование

Источник: https://windowsnotes.ru/iis/application-pool-identities-v-iis/

Установка корневого центра сертификации

Предполагается, что компьютер с именем RootCA установлен, обновлён и сконфигурированы параметры безопасности. Данный компьютер будет выполнять роль корневого центра сертификации (Root Certification Authority). Поскольку корневой CA — самая важная точка в иерархии PKI, этот сервер будет нормально выключен и включаться только для следующих целей:

  • Отправка новой заявки на сертификат;
  • Публикация CRL;
  • Обновление сертификата самого CA;
  • Установка обновлений безопасности.

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

https://www.youtube.com/watch?v=NhprXz6kdHw

После установки Центра сертификации (из стостава AD CS) необходимо её настроить.

  • Автономный ЦС
  • Корневой ЦС
  • Создать новый закрытый ключ
  • RSA#Microsoft Software Key Storage Provider; длину ключа в 2048 бит и алгоритм подписи в SHA1
  • Имя ЦС: ROOT-TEST-CA
  • Период действия сертификата = 15 лет
  • Период публикации отозванных сертификатов = 1 год

Последующая настройка выполняется с помощью коммандной строки

Создаём папку в корне диска C, где будут храниться CRT и CRL файлы

md C:\CertData

Задаём точки публикации CRL файлов и ссылки, публикуемые в издаваемых сертификатах. То же самое и для CRT файлов.

certutil -setreg CA\CRLPublicationURLs “65:%windir%\system32\CertSrv\CertEnroll\%3%8%9.crl65:C:\CertData\%3%8%9.crl2:http://pki.test.local/%3%8%9.crl”
certutil -setreg CA\CACertPublicationURLs “1:%windir%\system32\CertSrv\CertEnroll\%1_%3%4.crt2:http://pki.test.local/%3%4.crt”

Для Windows 2008 строка будет с двумя знаками %% для переменных certutil -setreg CA\CRLPublicationURLs “65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl65:C:\CertData\%%3%%8%%9.crl2:http://pki.test.local/%%3%%8%%9.crl” и также для certutil -setreg CA\CACertPublicationURLs “1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt2:http://pki.test.local/%%3%%4.crt”

Поскольку мы не можем управлять публикацией CRT файлов, мы его переименовываем в нужное имя и копируем в папку CertData

ren %windir%\system32\CertSrv\CertEnroll\*.crt ROOT-TEST-CA.crt
copy %windir%\system32\CertSrv\CertEnroll\ROOT-TEST-CA.crt C:\CertData

задаём срок действия издаваемых сертификатов равным 15 лет

certutil -setreg CA\ValidityPeriodUnits 15
certutil -setreg CA\ValidityPeriod “Years”

Задаём параметры публикации CRL (повторяем, что было указано в CAPolicy.inf)

certutil -setreg CA\CRLPeriodUnits 12
certutil -setreg CA\CRLPeriod “Months”
certutil -setreg CA\CRLOverlapPeriod “Months”
certutil -setreg CA\CRLOverlapUnits 1
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod “Days”
certutil -setreg CA\CRLOverlapPeriod “Weeks”
certutil -setreg CA\CRLOverlapUnits 2

Примечание: Данные параметр может быть изменены и через реестр в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\

Включаем полный аудит для сервера CA

certutil -setreg CA\AuditFilter 127

Отключаем генерацию кросс-сертификатов

certutil -setreg ca\CRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS

Конфигурируем ЦС для включения истёкших отозванных сертификатов в списки отзыва

certutil –setreg ca\CRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS

Включаем поддержку сертификатов OCSP Response Signing на Offline CA:

certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK
net stop certsvc && net start certsvc

Публикуем новый CRL в новую локацию.

certutil -CRL

Установка издающих центра сертификации

После установки Центра сертификации (из стостава AD CS) необходимо её настроить.

  • ЦС предприятия
  • Подчиненный ЦС
  • Создать новый закрытый ключ
  • RSA#Microsoft Software Key Storage Provider; длину ключа в 2048 бит и алгоритм подписи в SHA1
  • Имя ЦС: TEST-CA
  • Создать запрос сертификата в файле на конечном компьютере
  • Период действия сертификата = 10 лет
  • Период публикации отозванных сертификатов = 3 месяца

Скопировать файл запроса на сервер RootCA и выпустить по немуц сертификат

  • открыть Панель управленияАдминистрированиеЦентр сетрификации
  • выбрать сервер-все задачиВыдать новый запрос… и выбрать файл запроса
  • перейти в подраздел запросы в ожидании
  • выбелить запрос, затем все задачи – выдать
  • перейти в подраздел выданные сертификаты и открыть сетрификат
  • на вкладке Состав нажать копировать в файл и сохратить в формате .p7b (TEST-CA.p7b)

Скопировать файл выданного сертификата (TEST-CA.p7b) и файлы из папки C:\CertData (ROOT-TEST-CA.crt и ROOT-TEST-CA.crl) в сетевое хранилище \\test.local\SOFT\PKI

После этого сервер RootCA можно выключить.

Зарегистрировать файлы с корневого ЦС на подчинённом сервере (запускать с привилегиями Администратора)

certutil –addstore Root \\test.local\SOFT\PKI\ROOT-TEST-CA.crtcertutil –addstore Root \\test.local\SOFT\PKI\ROOT-TEST-CA.crl

certutil -dspublish -f \\test.local\SOFT\PKI\ROOT-TEST-CA.crt RootCA

Если ошибок не возникло, то установить сертификат ЦС (выданный RootCA)

  • открыть Панель управленияАдминистрированиеЦентр сетрификации
  • выбрать сервер-все задачиУстановить сертификат ЦС и выбрать файл (TEST-CA.p7b)
  • после успешной установки файл .p7b можно удалить

Выполнить пакетный файл настройки для дальнейшей настройки

Задаём точки публикации CRL файлов и ссылки, публикуемые в издаваемых сертификатах. То же самое и для CRT файлов.

certutil -setreg CA\CRLPublicationURLs “65:%windir%\system32\CertSrv\CertEnroll\%3%8%9.crl65:\\test.local\SOFT\PKI\%3%8%9.crl6:http://pki.test.local/%3%8%9.crl”
certutil -setreg CA\CACertPublicationURLs “1:%windir%\system32\CertSrv\CertEnroll\%1_%3%4.crt2:http://pki.test.local/%3%4.crt”

Для Windows 2008 строка будет с двумя знаками %% для переменных certutil -setreg CA\CRLPublicationURLs “65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl65:\\test.local\SOFT\PKI\%%3%%8%%9.crl6:http://pki.test.local/%%3%%8%%9.crl” и также для certutil -setreg CA\CACertPublicationURLs “1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt2:http://pki.test.local/%%3%%4.crt

Поскольку мы не можем управлять публикацией CRT файлов, мы его переименовываем в нужное имя и копируем в папку CertData

ren %windir%\system32\CertSrv\CertEnroll\*.crt TEST-CA.crt
copy %windir%\system32\CertSrv\CertEnroll\TEST-CA.crt \\test.local\SOFT\PKI

задаём максимальный срок действия издаваемых сертификатов равным 5 лет

certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod “Years”

Задаём параметры публикации CRL (повторяем, что было указано в CAPolicy.inf)

certutil -setreg CA\CRLPeriodUnits 3
certutil -setreg CA\CRLPeriod “Months”
certutil -setreg CA\CRLDeltaPeriodUnits 1
certutil -setreg CA\CRLDeltaPeriod “Months”
certutil -setreg CA\CRLOverlapPeriod “Days”
certutil -setreg CA\CRLOverlapUnits 10

Включаем наследование Issuer Statement в издаваемых сертификатах

certutil -setreg Policy\EnableRequestExtensionList +”2.5.29.32″

Включаем полный аудит для сервера CA

certutil -setreg CA\AuditFilter 127 задаём контекст конфигурации для сервера CA. Контекст конфигурации должен указывать на *корневой домен* текущего леса.
certutil -setreg CA\DSConfig “CN=Configuration,DC=test,DC=local”

публикуем сертификат CA в AD

certutil -dspublish -f \\test.local\SOFT\PKI\TEST-CA.crt Subca
certutil -dspublish -f \\test.local\SOFT\PKI\TEST-CA.crt NTAuthCA
net start certsvc

Публикуем новый CRL в новую локацию.

certutil –CRL

Проверка PKI предприятия

На сервере ЦС предприятия запустить оснастку PKIView.msc и проверить весь пусть регистрауии (Корневой и подчинённый серверы) – все пути AIA и CDP должны указывать на сайт http://pki.test.local

Внимание!

Особенность такого построения серверов (когда корневой сервер находится в отключенном режиме) является то, что периодически придётся вречную его запускать и выгружать обновлённый файл отозванных сервтификатов ROOT-TEST-CA.

crt на общее хранилище. Для этого достаточно примерно за месяц до истечения действия текущего файла запустить сервер корневого ЦС и скопировать обновлённый файл из папки  C:\CertData.

Если файл автоматически не обновился при запуске сервера, то обновить его командой

certutil –CRL

P.S

Для того, чтобы теперь действующий на сервере SRV03.TEST.LOCAL WEB сервер корректно работал в домене по протоколу HTTPS нужно выпустить ему доменный сертификат.

Открываем Панель управленияДиспетчер службы IIS и выбираем WEB сервер (SRV03). Открываем Сертификаты сервера и проверяем текущие сертификаты. Сертификат сервера SRV03 на данный момент самоподписанный и поэтому не будет автоматически признаваться в домене.

Выбираем действие Создать сертификат домена… и заполняем данные. Полное имя должно соответствовать адресу требуемого сайта – в нашем случае будет SRV03.TEST.

LOCAL, остальные поля произвольно. Далее выбираем сервер сертификации – в нашем случае будет TEST-CA\SRV03.TEST.

LOCAL и назначаем Полное имя – оно будет отображаться как псевдоним в Диспетчере службы IIS.

После выпуска сертификата его нужно закрепить за основным сайтом сервера. Для этого нужно выбрать сайт Default Web SiteИзменить привязки, выбрать привязку https и в его настройках выбрать новый созданный сертификат.

Источники: https://www.sysadmins.lv/blog-ru/ustanavlivaem-certification-authority-podvedenie-itogov.aspx
http://www.alexxhost.ru/2011/05/pki.html
https://habr.com/company/microsoft/blog/348944/

Полезные команды:

Публикуем новый CRL в новую локацию

certutil –CRL

Просмотр PKI структуры

PKIView.msc

Менеджер сертификатов

certmgr.msc

добавить сертификаты в хранилище

импортируем сертификат рутового ЦА

certmgr.exe -add -c RootCA.cer -s -r localMachine Root

импортируем сертификат выдающего ЦА

certmgr.exe -add -c CA.cer -s -r localMachine CA

импортируем сертификат в хранилище компа

certutil.exe -importpfx -p password VPN_Cert.pfx

импортируем сертификат в хранилище пользователя

importpfx.exe -f VPN_Cert.pfx -p password -t User -s My

список названий хранилищ сертификатов:
My – Личные
Root – Доверенные корневые центры сертификации
Trust – Доверительные отношения в предприятии
CA – Промежуточные центры сертификации
AuthRoot – Сторонние корневые центры центры сертификации
TrustedPublisher – Довереннные издатели
TrustedPeople – Доверенные лица
AddressBook – Другие пользователи

Прочитано 4286 раз Последнее изменение Вторник, 03 декабря 2019 11:54

Источник: https://pontin.ru/technical/windows/domain/pki-domain

Как вручную обновить корневые сертификаты в Windows

Установка службы сертификатов active directory. Порядок обновления ЦС

В операционных системах семейства Windows, начиная с Windows 7, присутствует система автоматического обновления корневых сертификатов с сайта Microsoft.

MSFT в рамках программы Microsoft Trusted Root Certificate Program, ведет и публикует в своем онлайн хранилище список сертификатов для клиентов и устройств Windows.

В том, случае если проверяемый сертификат в своей цепочке сертфикации относится к корневому CA, который участвует в этой программе, система автоматически скачает с узла Windows Update и добавит такой корневой сертификат в доверенные.

В том случае, если у Windows  отсутствует прямой доступ к каталогу Windows Update,  то система не сможет обновить корневой сертификат, соответственно у пользователя могут быть проблемы с открытием сайтов (SSL сертификаты которых подписаны CA, к которому нет доверия), либо с установкой / запуском подписанных приложений или скриптов.

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

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

Утилита rootsupd.exe

В Windows XP для обновления корневых сертификатов использовалась утилита rootsupd.exe, список корневых и отозванных сертификатов, зашитых в  которой регулярно обновлялся. Сама утилита распространялась в виде отдельного обновления KB931125 (Update for Root Certificates). Посмотрим, можно ли использовать ли ее сейчас.

  • Скачайте утилиту rootsupd.exe, перейдя по ссылке http://download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe (по состоянию на 15.09.2017 ссылка не работает, возможно в Microsoft решили убрать ее из общего доступа).

Для установки сертификатов, достаточно запустить файл. Но мы попробуем более внимательно рассмотреть его содержимое, распаковав его с помощью команды: rootsupd.exe /c /t: C:\PS\rootsupd

  • Сертификаты содержатся в SST файлах: authroots.sst, delroot.sst и т.п. Для удаления/установки сертификатов можно воспользоваться командами:updroots.exe authroots.sstupdroots.exe -d delroots.sst

Но, как вы видите, дата создания этих файлов 4 апреля 2013 (почти за год до окончания официальной поддержки Windows XP). Таким образом, с этого времени утилита не обновлялась и не может быть использована для установки актуальных сертификатов.

Получения списка корневых сертификатов с узла Windows Update с помощью Сertutil

Последняя версия утилиты для управления и работы с сертификатам Сertutil (представленная в Windows 10), позволяет скачать и сохранить в SST файл актуальный список корневых сертификатов.

Для генерации SST файла, на компьютере Windows 10 с прямым доступом в Интернет, выполните с правами администратора команду:

certutil.exe -generateSSTFromWU roots.sst

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

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

Для установки всех сертификатов, содержащихся в файле, воспользуемся утилитой updroots.exe (она содержится в архиве rootsupd.exe, который мы распаковали в предыдущем разделе).

Установка сертификатов из STT фалйла выполняется командой:

updroots.exe roots.sst

Запустите оснастку certmgr.msc и убедитесь, что все сертификаты были добавлены в хранилище Trusted Root Certification Authority.

Список корневых сертификатов в формате STL

Есть еще один способ получения списка сертификатов с сайта Microsoft. Для этого нужно скачать файл http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab (обновляется дважды в месяц).С помощью любого архиватора (или проводника Windows) распакуйте содержимое архива authrootstl.cab. Он содержит один файл authroot.stl.

Файл authroot.stl представляет собой контейнер со списком доверенных сертификатов в формате Certification Trust List.

Данный файл можно установить в системе с помощью контекстного меню файла STL (Install CTL).

Или с помощью утилиты certutil:

certutil -addstore -f root authroot.stl

После выполнения команды, в консоли управления сертификатами (certmgr.msc) в контейнере  Trusted Root Certification Authorities появится новый раздел с именем Certificate Trust List.

Аналогичным образом можно скачать и установить список с отозванными сертификатами, которые были исключены из программы  Root Certificate Program. для этого, скачайте файл disallowedcertstl.cab (http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab), распакуйте его и добавьте в раздел Untrusted Certificates командой:

certutil -addstore -f  disallowed disallowedcert.stl

В это статье мы рассмотрели несколько простейших способов обновления списка корневых сертификатов на изолированной от Интернета системе Windows.

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

Источник

Источник: https://zen.yandex.ru/media/id/5a3211a177d0e6afcba2adfd/5b3c8aacf03ecf00a86cec85

Установка служб федерации Active Directory (ADFS)

Установка службы сертификатов active directory. Порядок обновления ЦС

В обзоре служб федерации Active Directory (ADFS) было дано развернутое объяснение назначения  и принципов работы данного сервиса.

Сейчас же, пришло время познакомится с практической стороной вопроса, а именно с установкой служб ADFS.

Ранее, мной уже рассматривался этот процесс, но тогда фокус статьи был смещен в сторону Exchange Server и, по прошествии времени,  у меня появились замечания к качеству проработки материала.

Архитектура развертывания служб федерации Active Directory (ADFS)

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

  • Высокая доступность
  • Планирование пространства имен DNS
  • Использование сертификатов безопасности
  • Размещение хранилище конфигурации

Высокая доступность

Службы федерации, как и службы каталога Active Directory, выполняют роль аутентификации пользователей в приложениях.  В случае отсутствия сервиса веб аутентификации, аутентификации в приложениях не будет. Этот факт сразу же диктует требование к резервированию компонентов решения.  Базовый дизайн служб федерации выглядит следующим образом:

Архитектура высокой доступности служб федерации Active Directory (ADFS)

Он обусловлен дублированием компонентов, как серверов федерации, так и пограничных северов (Web Application Proxy). Внешние и внутренние запросы от клиентов будут терминироваться на балансировщиках сетевой нагрузки NLB.

Это важный момент, так как игнорирование подобного дизайна может привести к серьезным последствиям. Например, если аутентификация в Office 365 или G Suite связана с ADFS и архитектура не предполагает высокую доступность, во время отказа все новые аутентификации будут провальными.

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

Планирование пространства имен DNS

Еще одним важным вопросом будет планирование DNS имен. Лучшим решение будет использование DNS Split зоны. Будет происходить дублирование внешней доменной зоны на DNS серверах контроллеров домена.

Это позволит разрешать один и тот же FQDN фермы серверов федерации в разные IP (публичный и приватный). Публичный для внешних клиентов, приватный для внутренних.

Схематически, это будет выглядеть следующим образом:

Архитектура пространства имен в службах федерации Active Directory (ADFS)

FQDN фермы служб федерации задается на этапе создания новой фермы ADFS, после чего потребуется настройка NLB и DNS.

Использование сертификатов безопасности

Для функционирования сервиса необходимы сертификаты безопасности. Они будут служить для поддержки SSL/TLS сессий между клиентами и сервисом, а также для внутренней коммуникации компонентов ADFS. Рекомендуется использовать сертификаты, подписанные внутренними и внешними центрами сертификатов.

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

Например, не доменные рабочие станции или мобильные телефоны.

Размещение хранилище конфигурации

Вся конфигурация фермы ADFS хранится в MSSQL базе данных. Во время развертывания сервиса, мастер предлагает один из способов ее хранения — внутренняя база Windows Internal Database (WID) или на выделенная MSSQL инфраструктура.

Для подавляющего большинства установок ADFS, первый вариант является предпочтительным. Это обусловлено легкостью развертывания, отсутствием дополнительных задач по обеспечению работы SQL и маленьким количеством запросов.

Именно последние является ключевым фактом при выборе размещения хранилища конфигурации. При работе с WID, будет определена master и slave ноды. Изменения в конфигурацию могут быть внесены только на master ноде.

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

Согластно дизайну, для минимальной установки сервиса потребуется минимум 4-е сервера:

В качестве серверной ОС, я буду использовать Windows Server 2019 на борту которого службы федерации версии 5.0. Сразу же стоит сделать ремарку — более удобное администрирование сервиса предоставит редакция с GUI.

Это обусловлено тем, что в пакете RSAT отсутствует GUI консоль управления сервисом. Службы ADFS можно поставить в Core редакции, но тогда все последующее управление необходимо выполнять сугубо через PowerShell.

Установка первого сервера и создание фермы ADFS

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

Add-WindowsFeature ADFS-Federation

Add-WindowsFeature ADFS-Federation

После установки, из Server Manager запускаем мастер установки служб федерации Active Directory (ADFS)

Запуск мастера установки служб федерации Active Directory

На следующем шаге необходимо задать учетные данные администратора домена Active Directory:

Указание учетных данных администратора домена Active Directory

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

  • Сертификат должен обладать EKU «Server Authentication» и возможностью экспорта закрытого ключа. Это важно, так как на всех серверах фермы должен использоваться единый сертификат. Другими словами, после установки первого сервера фермы, сертификат подлежит экспорту и импорту на последующий сервер. Использовать разные сертификаты с не совпадающими thumbprint не представляется возможным.
  • Для создания сертификата может служить шаблон веб сервера или другой на его основе. Главное, чтобы EKU был верным. Я предпочитаю использовать его более стойкую модифицированную версию с новой криптографией. Еще одним важным моментом будет правильные subject name и subject alternative name:
  1. В subject name и subject alternative name должно присутствовать полное доменное имя фермы ADFS, например, sts.ait.in.ua;
  2. В subject alternative name должны присутствовать записи enterpriseregistration и certauth в таком виде: enterpriseregistration. и certauth..  Например, enterpriseregistration.ait.in.ua и certauth.sts.ait.in.ua:

Правильные subject name и subject alternative name в SSL сертификате ADFSВозможность экспорта сертификата служб федерации Active Directory

enterpriseregistration используется для возможности клиентов регистрации посредству Workplace Join. Это даст необходимые механизмы для реализации задач условного доступа (Condition Access) в веб приложениях, аутентификация оных настроена через ADFS.

certauth предоставит возможность использовать аутентификацию посредству смарт-карт, в том числе виртуальных. Более подробно о виртуальных смарт-картах можно прочитать в заметке — Виртуальная смарт-карта. Используем?

Установка ADFS может быть продолжена и на следующем шаге производим выбор сертификата SSL

Выбор сертификата SSL в мастере установки служб федерации Active Directory

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

В качестве типа аккаунта, я рекомендую использовать Group Managed Service Accounts, далее gMSA. Подробно об этом типе можно прочитать тут.

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

В случае, если в лесу Active Directory еще не разу не использовались gMSA, необходимо создать KDS Root Key для генерирования паролей gMSA. Если этого не сделать, в процессе создания будет получена следующая ошибка:
Group Managed Service Accounts are not available because the KDS Root Key has not been set

Сам же KDS Root Key создается с помощью следующего PowerShell командлета:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

Права должны быть администратора предприятия. Успешным результатом его создания будет вывод его GUID:

PS C:\Users\administrator.CORP> Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) Guid—-0edbe8ee-f883-a6ec-2121-e98889a4a0d2 PS C:\Users\administrator.CORP>

PS C:\Users\administrator.CORP> Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))0edbe8ee-f883-a6ec-2121-e98889a4a0d2PS C:\Users\administrator.CORP>

Перейдем к следующем шагу и зададим сервисную учетную запись. В случае отсутствия gMSA в домене Active Directory, мастер установки выполнит его автоматическое создание при условии его запуска с правами администратора предприятия:

Задание сервисного аккаунта в мастере установки служб федерации Active Directory

Указываем место размещение хранилище конфигурации новой фермы:

Указание расположения SQL базы данных в мастере установки служб федерации Active Directory

На завершающем этапе, мастер проверит введенную ранее конфигурацию перед установкой:

Установка служб федерации Active Directory

После чего, установка первого сервера фермы федерации ADFS завершена:

Завершение работы мастера установки служб федерации Active Directory

Добавление второго сервера в ферму ADFS

Добавление второго и более сервера в ферму ADFS осуществляется проще. Для успешного добавления потребуется предварительный импорт SSL сертификата, который использовался при создании новой фермы, и сетевая связность по tcp/443 с первым сервером ADFS.

Выполняем установку бинарых файлов и доходим до мастера установки ADFS. На первом шаге выбираем добавление сервера в существующею ферму ADFS:

Добавление второго сервера в ферму ADFS

Указываем FQDN первого сервера в фермы ADFS:

Указание FQDN первого сервера в ферме ADFS

Сертификат и сервисный аккаунт указываем такие же, как и при создании первого сервера фермы:

Задание сервисного аккаунта на втором сервере фермы ADFS

После проверки конфигурации мастером выполняем установку:

Успешное добавление второго сервера в ферму ADFS

После завершения процесса установки и конфигурирования обеих нод фермы, необходимо настроить балансировщик сетевой нагрузки. DNS записи фермы федерации, enterpriseregistration и certauth должны указывать на VIP адрес NLB балансировщика.

Установка и настройка Web Application Proxy

Установка первой и второй нод Web Application Proxy является однотипной операцией, для которой необходимо выполнить ряд условий:

  • Добавление в доверенные ЦС внутреннего корневого центра сертификатов, которым подписан SSL сертификат фермы ADFS. PKI инфраструктура должна быть настроена соответствующим образом для возможности проверки CRL листов отзыва. Публикации в LDAP недостаточно, так как сервера WAP не будут являться членом домена Active Directory;
  • Наличие SSL сертификата, подписанного внешним коммерческим ЦС. Рекомендую использовать SAN тип сертификатов, так как wildcard не будет покрывать домен certauth.sts.ait.in.ua. Напомню, он будет использоваться для аутентификации по средству смарт-карт. Минимальный набор доменов в сертификате то же что использовалось при создании сертификата для фермы ADFS + те домены, веб приложения которых планируется к публикации. Например, если речь идет об Exchnage, это может быть mail и autodiscover.

Задание имени и доменного суффикса на WAP сервере

Используя PowerShell, устанавливаем бинарники служб Web Application Proxy:

Add-WindowsFeature Web-Application-Proxy

Add-WindowsFeature Web-Application-Proxy

После чего, открываем мастер конфигурирования Web Application Proxy из Server Manager:

Мастер настройки Web Application Proxy

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

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

Выбор коммерческого сертификата на сервере Web Application Proxy

Работа мастера завершена успешно:

Успешное завершение работы мастера настройки Web Application Proxy

Аналогичным образом необходимо настроить второй сервер Web Application Proxy. Как и в случае с фермой ADFS, далее следует конфигурирование балансировщика сетевой нагрузки. DNAT c публичного IP адреса необходимо будет выполнить именно на VIP балансировщика, за которым находятся сервера WAP.

Касаемо портов, это tcp/80 и tcp/443. Интересной особенностью будет необходимость ручного создания правила для 80-го порта в локальной брандмауэре. В время работы мастера, нужно исключение не создается.

Выводы

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

В статье » Установка служб федерации Active Directory (ADFS)» детально был рассмотрен процесс установки и конфигурации ADFS в отказоустойчивом режиме.  Работа над материалом заняла две недели и как результат он получился довольно объемным и детализированным. Надеюсь, он поможет в развертывании и последующему освоению данного сервиса.

Источник: https://ait.in.ua/on-premise/windows-server/ustanovka-sluzhb-federacii-active-directory-adfs.html

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.