В этой части рассмотрим установку отказоустойчивого Issuing CA.
Для этого установим и введем в домен сервера ica1 и ica2.
На сторедже (в моем примере стореджем выступает сервер str с установленным iSCSI Target) создадим Target “pki” и в нем два диска – quorum и data :
Подключим эти диски к ica1 и ica2, переведен в онлайн, инициализируем, отформатируем и проверим доступность на обех нодах будущего кластера:
Выключим вторую ноду (ica2), подключимся к первой ноде (ica1) и начнем установку:
На кластерном диске с данными создадим папки CertDB и CertLog.
Перед установкой роли AD CS, создадим в C:Windows файл CAPolicy.inf следующего содержания:
[Version]
Signature=”$Windows NT$”
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
Notice=”Legal Policy Statement”
URL=http://pki.lab.kagarlickij.com/cps.txt
OID=2.5.29.32.0
[certsrv_server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
CRLPeriodUnits=5
CRLPeriod=days
CRLOverlapUnits=1
CRLOverlapPeriod=days
CRLDeltaPeriodUnits=12
CRLDeltaPeriod=hours
Пояснения аналогичны тем, которые я давал при развертывании Root CA.
Отдельно стоит отметить что OID – это идентификатор, который определяет область применения. Для организаций желательно получение собственного OID, если сервис PKI будет работать не только в локальной сети.
Бесплатно получить OID можно тут – http://pen.iana.org/pen/PenApplication.page
Для демо мне достаточно будет wildcard OID (определен в RFC 3280).
Установим роль AD CS:
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
Пройдем по шагам мастера и определим базовые настройки, самое важное из них – указать имя ICA-кластера.
После этого, в C: появиться файл запроса *.req , который мы перенесем на rca и обработаем запрос:
certreq -submit *.req , (запомним номер запроса).
Откроем консоль центра сертификации, перейдем в Pending Requests , нажмем правой кнопкой на запросе и выберем пункт Issue.
Вернемся в PowerShell и экспортируем выданный сертификат:
certreq –retrieve %Идентификатор_запроса% *.crt
Этот этап выглядит вживую следующим образом:
Полученный сертификат перенесен на ica1 , откроем Certification Authority – All Tasks – Install CA Certificate , выберем сертификат (формат Х.509) и запустим службу (если будут проблемы с недоверием к руту – они решаються с помощью обновления групповой политики).
Ознакомимся с дефолтными настройками путей к AIA и CDP для нашего издающего CA:
Get-CAAuthorityInformationAccess | fl
Get-CACRLDistributionPoint | fl
Руководствуясь пояснениями которые я давал при настройке Root CA укажем пути к настроимпути к CDP и AIA:
certutil -setreg CACRLPublicationURLs “65:C:Windowssystem32CertSrvCertEnroll%3%8%9.crln6:http://pki.lab.kagarlickij.com/%3%8%9.crln65:file://labpki%3%8%9.crl”
certutil –setreg CACACertPublicationURLs “1:C:Windowssystem32CertSrvCertEnroll%1_%3%4.crtn2:http://pki.lab.kagarlickij.com/%1_%3%4.crtn1:file://labpki%1_%3%4.crt”
Проверим результат:
Укажем параметры списка отзывов:
certutil -setreg CAValidityPeriodUnits 10
certutil -setreg CAValidityPeriod “Years”
certutil -setreg CACRLPeriodUnits 5
certutil -setreg CACRLPeriod “Days”
certutil -setreg CACRLDeltaPeriodUnits 12
certutil -setreg CACRLDeltaPeriod “Hours”
certutil -setreg CACRLOverlapPeriod “Days”
certutil -setreg CACRLOverlapUnits 1
В локальной политике включим Audit Object Access, для того чтобы потенциально можно было выполнить аудит ЦС:
Включим наследование Issuer Statement в издаваемых сетификатах:
certutil -setreg PolicyEnableRequestExtensionList +”2.5.29.32″
Укажем раздел конфигурации в Active Directory (в нашем случае настройки уже были сделаны):
certutil -setreg CADSConfigDN “CN=Configuration,DC=lab,DC=kagarlickij,DC=com”
Включим возможность выдачи сертификатов со списками альтернативных имен (SAN):
certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
restart-service certsvc
certutil -crl
Опубликуем CRL в Active Directory:
certutil -dspublish -f LAB-ICA.crl
certutil -dspublish -f LAB-ICA+.crl
Убедимся что в labpki успешно опубликованы списки отзывов и скопируем сертификат издающего кластера (%1_%3%4.crt):
Используем pkiview.msc и еще раз убедимся что сертификаты и списки отзывов опубликованы правильно:
Экспортируем сертификат ica1 с помощью мастера резервного копирования:
Далее нужно указать путь для сохранения и пароль.
После этого останавливает службу AD CS и переводим кластерный диск с данными в оффлайн на сервере ica1.
На сервере ica2 переводим кластерный диск с данными в онлайн, и импортируем сертификат от ica1 в Local ComputerPersonal :
Установим на сервер ica2 роль AD CS:
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
В мастере настройки роли укажем импортированный сертификат:
И пути к базе и логам на кластерном диске:
Сразу после окончания установки убедимся что слкжба AD CS работает и остановим ее.
На обеих нодах переведем общие диски в online и установим фичу failover clustering:
Add-WindowsFeature Failover-Clustering,RSAT-Clustering-Mgmt
После успешной установки откроем Failover Cluster Manager и выполним Validate Configuration (возникшее у меня предупреждение касается единственного сетевого интерфейса на каждой ноде):
Перейдем в открывшийся мастер создания кластера, и укажем в нем имя кластера icacl и IP:
После успешной установки перейдем к конфигурированию ролей, выберем Generic Service, затем Active Directory Certificate Services, введем имя LAB-ICA (важно оно, а не имя кластера) и IP, общий диск и общую ветку реестра (SYSTEMCurrentControlSetServicesCertSvc):
Теперь откроем Active Directory Sites and Services, включим View – Show Services Node и в контейнерах AIA, Enrollment Services, KRA дадим полные права для ICA1$ и ICA2$
Теперь откроем ADSI, подключимся к конфигурации и перейдем в Services => Public Key Services => Enrollment Services и в свойствах LAB-ICA укажем атрибуту dNSHostName имя издающего кластера:
Затем можно перезагрузить лабораторные сервера и запустить службу AD CS на ica1.
Убедимся что настройки успешно среплицированы на ica2:
Откроем ADSI и убедимся что добавление кластерного издающего ЦС прошло штатно:
Продолжим проверку кластера, для этого запустим оснастку Failover Cluster Manager и убедимся что сервис работает на второй ноде:
Проверим доступность сервиса:
certutil –config “ServiceNameCAName” –ping
certutil –config “ServiceNameCAName” –pingadmin
Переместим сервис на другую ноду вручную и выполним проверку повторно:
Теперь сэмулируем аварию – селаем turn off на ica1 или просто отключим его от сети, а затем убедимся что сервис успешно подымется на ica2:
На этом настройку отказоустойчивого Issuing CA можно считать оконченной.