Особенности аутентификации контроллера домена с использованием двух разных сертификатов / Хабр

Содержание

Пошаговая инструкция по установке и настройке центра сертификации | блог разработчиков
Шаг 4. установка служб сертификации на windows server 2021 r2
Мастер добавления ролей и компонентов
Шаг 6. восстановление зарезервированного ca
Что может администратор сети через active directory?
Является ли мой компьютер частью домена?
Связанные статьи:
Шаг 3. удаление службы центра сертификации с windows server 2003
Шаг 2. резервирование параметров реестра центра сертификации
Обновление сертификатов цс
Автоматизируем
Доменные службы active directory
Dns-сервер
Решение
Начинаем
Установка компонента цс
Dhcp-сервер
Настраиваем контроллер домена active directory
Шаг 8. перевыпуск шаблона сертификата
Резервное копирование
Предустановочная конфигурация
Чем рабочие группы отличаются от доменов
Что такое active directory
Шаг 7. восстановление информации в реестре
Прочие настройки
Настройка dhcp-сервера
Подготовка веб-сервера
Почему такой стенд?

Пошаговая инструкция по установке и настройке центра сертификации | блог разработчиков

Здравствуйте, друзья!

Одним из преимуществ ЛОЦМАН:ПГС является применение цифровых подписей достоверно подтверждающих личность и роль подписавшего документ. Для создания цифровых подписей необходимы сертификаты выданные удостоверяющим центром сертификации.

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

В наших примерах мы будем использовать контроллер домена на Microsoft Windows Server 2008 и клиент Microsoft Windows 7.

Для начала нам нужно добавить роль Active Directory Certification Services (Службы сертификации Active Directory) на контроллере домена. Откройте Server Manager и выполните команду «Add Role» («Добавить роли»).
Откроется Add Roles Wizard (Мастер добавления ролей). Нажмите Next.
Выберите роль Active Directory Certification Services (Службы сертификации Active Directory). Нажмите Next.
Next.
Проверьте, что отмечена служба Certification Authority(Центр сертификации).
Вариант установки должен быть указан «Enterprise».
Тип центра сертификации Root CA(Корневой ЦС).
Создайте новый приватный ключ.
Укажите параметры шифрования, например:

Если Вы меняете параметры, рекомендуем Вам ознакомиться с советами компании Microsoft по безопасности в части выбираемой длины ключа.
Проверьте имя и суффиксы центра сертификации, например:
Задайте срок действия сертификата, например:
Next.
Install.
Процесс установки…
Установка завершена. Close.

Центр сертификации установлен. Теперь нужно создать шаблон сертификатов.
Перейдите в Certificate Templates (Шаблоны сертификатов) и выполните команду Duplicate Template (Скопировать шаблон) на существующем шаблоне, например User.
Выберите версию Windows Server минимально поддерживаемую ЦС.

Не выбирайте Windows Server 2008, иначе при подписании созданным сертификатом документов в программных продуктах использующих .NET Framework 4.0 Вы получите сообщение «Указан неправильный тип поставщика (mscorlib)». Иными словами Вы не сможете использовать сертификат.
В открывшихся свойствах шаблона укажите имя и отключите Publish certificate in Active Directory (Опубликовать сертификат в Active Directory):
Перейдите на вкладку Request Handling (Обработка запроса) и измените цель на «Signature» («Подпись»).
Проверьте параметры на вкладке Subject Name (Имя субъекта).
На вкладке Security (Безопасность) для группы Authenticated Users (Прошедшие проверку) разрешите Enroll (Заявка).
На вкладке Extensions (Расширения) скорректируйте Application Policies (Политика применения).

Выберите Document Signing (Подписывание документа).

Выберите Document Signing (Подписывание документа).

ОК.

Шаблон сертификата создан, теперь необходимо его опубликовать.
Перейдите в Certificate Templates (Шаблоны сертификатов) и выполните команду «New -> Certificate Template to Issue» («Новый -> Выдать шаблон сертификата»).
Выберите ранее созданный шаблон. ОК.

Установка и настройка шаблона сертификатов закончена. Перейдем на клиента и попробуем получить сертификат.
На клиенте запустите Certificate Manager Tool выполнив команду certmgr.msc.
Перейдите в Personal (Личное) и создайте запрос на получение сертификата, выполнив Request New Certificate (Запросить новый сертификат).
Next.
Выберите политику Active Directory. Next.
В типах сертификатов отметьте ранее созданный шаблон.

Если планируется использование нескольких сертификатов для одного пользователя, желательно присвоить имя запрашиваемому сертификату. Откройте свойства заявки.
На вкладке General (Общие) укажите Friendly name (Понятное имя).

Сохраните и закройте свойства.
Enroll.
Заявка успешно завершена, сертификат получен.
В Certificate Manager Tool можно посмотреть параметры сертификата.

Мы получили сертификат только для одного пользователя, а когда пользователей много, такой способ не очень удобен. Для облегчения процесса давайте настроим автоматическую раздачу сертификатов групповой политикой.
Для начала необходимо изменить свойства, созданного ранее шаблона, сделать его доступным для автоматической выдачи. Найдите созданный шаблон в Server Manager и откройте свойства.
Перейдите на вкладку Security (Безопасность) и для группы Authenticated Users (Прошедшие проверку) разрешите Autoenroll (Автозаявка).
Следующий шаг — настроить групповую политику автоматической регистрации сертификатов для домена. Можно изменить политику по-умолчанию, но лучше создать новую, так мы сможем ограничить круг пользователей, охватываемых политикой. На домене выполните команду Create a GPO in this domain, and Link it there… (Создать ОГП в документе и связать его…).
Введите имя групповой политики, например:
Отредактируйте созданную политику.
Перейдите в раздел «User configuration — Policies — Widows Settings — Security Settings — Public Key Policies» (Конфигурация пользователя — Политики — Конфигурация Windows — Параметры безопасности — Политики открытого ключа) и откройте свойства Certificate Services Client — Auto-Enrollment (Клиент службы сертификации — автоматическая регистрация).
Включите автоматическую регистрацию сертификатов и флажки:
- Обновлять сертификаты с истекшим сроком действия или в состоянии ожидания и удалять отозванные сертификаты;
- Обновлять сертификаты, использующие шаблоны сертификатов.
Закройте редактор групповой политики и в Server Manager при необходимости ограничьте круг пользователей или компьютеров, на которые будет применена политика. Как пример, ниже показана политика, которая будет распространена только на ПК DOMAINCOMPUTER.

Групповая политика создана, проверим как она работает.
На клиенте откройте CMD.exe с правам администратора и выполните команду «gpupdate /force /boot /logoff» или перезапустите ПК.
Сертификат должен быть автоматически запрошен и получен. Полученный сертификат можно увидеть в Certificate Manager Tool (пункт 33) или в Control Panel — Internet Options, вкладка Content — Certificates — Personal (Панель управления — Свойства обозревателя, вкладка Содержание — Сертификаты — Личные).

Это всё, что мы хотели сказать про установку и настройку центра сертификации. Спасибо, что читаете наш блог, до свидания!

Шаг 4. установка служб сертификации на windows server 2021 r2

Зайдите на Windows Server 2021 R2 под учетной записью или администратора домена, или локального администратора.

Перейдите в

Server Manager > Add roles and features

Запустится

“Add roles and features”

, нажмите

“Next”

для продолжения.

В следующем окне выберите

“Role-based or Feature-based installation”

, нажмите

“Next”

для продолжения.

Из списка доступных серверов выберите ваш, и нажмите

“Next”

для продолжения.

В следующем окне выберите роль “Active Directory Certificate Services”, установите все сопутсвующие компоненты и нажмите

“Next”

В следующих двух окнах нажимайте

“Next”

. После этого вы увидите варианты выбора служб для установки. Мы выбираем

Certificate AuthorityCertification Authority Web Enrollment

и нажимаем

“Next”

для продолжения.

Для установки

Certification Authority Web Enrollment

необходимо установить

IIS

. Поэтому в следующих двух окнах посмотрите краткое описание роли, выберите нужные компоненты и нажмите

“Next”

Далее вы увидите окно подтверждения. Если все в порядке, нажмите

“Install”

для того, чтобы начать процесс установки.

После того, как установка завершена, вы можете закрывать мастер установки и переходить к следующему шагу.

Мастер добавления ролей и компонентов

Возвращаемся на панель мониторинга (самый первый скриншот) и щелкаем на пункт “Добавить роли и компоненты”. Вас поприветствует мастер добавления ролей и компонентов. Первый экран (“Перед началом работы”) пропускаем, он совсем неинтересный, а вот дальше идёт экран “Выбор типа установки”

Нас устраивает значение по-умолчанию (Установка ролей или компонентов”), но интересен и второй пункт — он позволяет задействовать ещё одну возможность Windows Server — инфраструктуру виртуальных рабочих мест (Virtual Desktop Environment — VDI). Эта интереснейшая технология позволяет, буквально, виртуализировать рабочее место.

Впрочем, технология VDI это отдельная большая тема, а в этом туториале надо сосредоточиться на контроллере AD, так что кликаем “Далее” и видим экран выбора целевого сервера.

Мастер добавления ролей позволяет устанавливать роль не только на текущую машину, но вообще на любой добавленный сервер, и даже на виртуальный жёсткий диск. Да, если ваша Windows Server развернута на виртуальной машине (а это довольно частое явление), то вы можете администрировать эту виртуальную машину даже не запуская её! Понаблюдать за этим процессом можно, например, здесь

Нам же такая экзотика ни к чему, так что просто выбираем единственный возможный сервер (обратите внимание, что он теперь называется ADController место непонятной абракадабры), жмём “Далее” и, наконец, попадаем на экран выбора ролей, которые нужно добавить.

Выбираем три роли, о которых уже говорили ранее, и продолжаем.

Теперь необходимо выбрать дополнительные компоненты. В чём разница между ролью и компонентом, можете спросить вы? О, это не такой уж и лёгкий вопрос, честно говоря!

Согласно идеологии Microsoft, роль — это набор программ, которые позволяют компьютеру предоставлять некоторые функции для пользователей в сети. Например, DNS, DHCP, контроллер домена AD — это всё роли. А вот компоненты — это набор программ, которые улучшают либо возможности ролей сервера, либо самого сервера.

Про сертификаты: Продлены сроки действия сертификатов ФСБ России на продукты ViPNet Client 3.2, ViPNet Coordinator 3.2 и ViPNet Administrator 3.2. | ИнфоТеКС

При этом глядя на список “Компонентов” так сходу и не скажешь, что какие-то вещи в списке лишь “вспомогательные”. Вот например, DHCP-сервер расценивается как роль, а WINS-сервер — уже как компонент. А чем SMTP-сервер хуже DNS?

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

В любом случае, дополнительные компоненты нам не нужны, так что кликаем “Далее”.

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

На экране подтверждения ещё раз видим все устанавливаемые роли и компоненты, после чего жмём “Установить”.

Остаётся лишь дождаться, когда заполнится progress-bar, и перейти к следующему пункту туториала — настройке контроллера домена AD.

Шаг 6. восстановление зарезервированного ca

Теперь мы переходим к наиболее важной части всего процесса миграции, в которой мы восстановим зарезервированный в Windows Server 2003 CA.

Открываем

Server Manager > Tools > Certification Authority

Щелкаете правой кнопкой мыши по имени сервера и выбираете

AllTasks > RestoreCA

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

ОК

Запустится

Certification Authority Restore Wizard

, нажмите

“Next”

для продолжения.

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

“Next”

для продолжения.

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

“Next”

для продолжения.

В следующем окне нажмите

“Finish”

для завершения процесса импорта.

После успешного завершения процесса, система спросит, можно ли запустить центр сертификации. Запустите службу.

Что может администратор сети через active directory?

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

Кроме того, вы можете указать ещё более точные разрешения. Чтобы проиллюстрировать это, давайте рассмотрим пример: предположим, у вашей компании есть каталог в сети для всех документов, относящихся к кадрам. Сюда могут входить любые формы, которые нужны сотрудникам для подачи в отдел кадров (официальные запросы, официальные жалобы и так далее).

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

Ещё одним огромным плюсом для сетевых администраторов, использующих Active Directory, является то, что они могут выполнять обновления в масштабе всей сети одновременно. Когда все ваши машины автономны и действуют независимо друг от друга, вашим сетевым администраторам придётся переходить от машины к машине каждый раз, когда необходимо выполнить обновления. Без Active Directory им пришлось бы надеяться, что все сотрудники обновят свои машины самостоятельно.

AD позволяет централизовать управление пользователями и компьютерами, а также централизовать доступ к ресурсам и их использование.

Вы также получаете возможность использовать групповую политику, когда у вас настроена AD. Групповая политика — это набор объектов, связанных с подразделениями, которые определяют параметры для пользователей и/или компьютеров в этих подразделениях. Например, если вы хотите сделать так, чтобы в меню «Пуск» не было опции «Завершение работы» для 500 лабораторных ПК, вы можете сделать это с помощью одного параметра в групповой политике.

Вместо того, чтобы тратить часы или дни на настройку правильных записей реестра вручную, вы создаёте объект групповой политики один раз, связываете его с правильным OU (organizational units, организационные единицы) или несколькими OU, и вам больше никогда не придётся об этом думать.

Является ли мой компьютер частью домена?

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

Вы можете быстро проверить, является ли ваш компьютер частью домена. Откройте приложение «Параметры» (Win x).

Нажмите «Система».

Перейдите на вкладку «О программе» и найдите пункт «Переименовать этот ПК (для опытных пользователей)»:

Если вы видите «Домен»: за которым следует имя домена, ваш компьютер присоединён к домену.

Если вы видите «Рабочая группа»: за которым следует имя рабочей группы, ваш компьютер присоединён к рабочей группе, а не к домену.

В англоязычной версии это соответственно «Settings» → «System» → «About» → «Rename this PC (advanced)».

Используя командную строку (PowerShell) вы также можете узнать, прикреплён ли компьютер к домену или входит в рабочую группу.

Для этого выполните команду (можно за один раз всё скопировать-вставить в окно терминала):

$ComputerSystem = Get-CimInstance -Class Win32_ComputerSystem;
$ComputerName = $ComputerSystem.DNSHostName
if ($ComputerName -eq $null) {
    $ComputerName = $ComputerSystem.Name
}

$fqdn = ([System.Net.Dns]::GetHostByName($ComputerName)).HostName

$ComputerSystem | Microsoft.PowerShell.UtilitySelect-Object `
@{ Name = "ComputerName"; Expression = { $ComputerName }},
@{ Name = "Domain"; Expression = { if ($_.PartOfDomain) { $_.Domain } else { $null } }},
@{ Name = "DomainJoined"; Expression = { $_.PartOfDomain }},
@{ Name = "FullComputerName"; Expression = { $fqdn }},
@{ Name = "Workgroup"; Expression = { if ($_.PartOfDomain) { $null } else { $_.Workgroup } }}

Подробности смотрите в статье: Как в PowerShell узнать, прикреплён ли компьютер к домену или к рабочей группе

Связанные статьи:

Шаг 3. удаление службы центра сертификации с windows server 2003

Теперь, когда готовы резервные файлы и прежде, чем настроить службы сертификации на новом Windows Server 2021 R2, мы можем удалить службы центра сертификации с Windows Server 2003. Для этого нужно проделать следующие шаги.

Щёлкаем

Start > Control Panel > Add or Remove Programs

Затем выбираем

“Add/Remove Windows Components”

В следующем окне

уберите

галочку с пункта

“CertificateServices”

и нажмите

“Next”

для продолжения

После завершения процесса, вы увидите подтверждение и можете нажать

“Finish”

На этом этапе мы закончили работу со службами центра сертификации на Windows Server 2003 и следующим шагом будем настраивать и конфигурировать центра сертификации на Windows Server 2021 R2.

Шаг 2. резервирование параметров реестра центра сертификации

Нажмите

Start

, затем

Run

. Напечатайте

regedit

и нажмите

ОК

Затем откройте

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvc

Щелкните правой кнопкой мыши по ключу

“Configuration”

и выберите

“Export”

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

“Save”

, чтобы закончить резервирование.

Теперь у нас есть резервные файлы центра сертификации и мы можем переместить эти файлы на новый сервер Windows Server 2021 R2.

Обновление сертификатов цс

Периодически необходимо обновлять сертификаты ЦС. Рассмотрим несколько аспектов, связанных с обновлением сертификатов ЦС.

Периодичность обновления сертификата ЦС

Это делается в следующих случаях:

Первый вопрос, если всё идёт штатно, за какое время до истечения срока действия сертификата ЦС его нужно обновлять?

Сертификат издающего ЦС должен обновляться за максимальный срок действия издаваемых сертификатов. В нашем случае срок действия сертификата издающего ЦС 15 лет, а максимальный срок действия издаваемых сертификатов 5 лет (см. конфигурационную таблицу).

Порядок обновления ЦС

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

Генерация ключей при обновлении сертификатов ЦС

При обновлении сертификатов ЦС вам предлагается две опции: использовать существующую ключевую пару или сгенерировать новую:

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

При генерации новой ключевой пары для каждого сертификата будет гарантирован только один путь к корневому сертификату и модуль построения цепочек сертификатов уже не ошибётся.

Автоматизируем

Как вы могли заметить, весь туториал можно выполнить, пользуясь исключительно мышкой и клавиатурой. Больше того, нам даже не пригодились знания PowerShell, который позволяет выполнять бОльшую часть настройки контроллера домена AD с помощью скриптов.

Так почему бы не автоматизировать все действия с клавиатурой и мышкой, которые мы предпринимали? И нет, я говорю не об AutoIT, я говорю о платформе Testo, создателем которой я являюсь. Эта платформа позволяет фиксировать все действия, проводимые с виртуальными машинами, в виде скриптов на специальном языке Testo-lang. Ну а Testo затем превратит эти скрипты обратно в действия.

Про сертификаты: Курсы веб-программирования: JavaScript, PHP, MySQL и др. в Специалисте

Я приведу лишь один скриншот с кусочком скрипта, чтобы у вас сложилось представление о том, о чём я говорю (да, именно скриншот, ведь хабр не умеет подсвечивать скриповый язык Testo-lang). Я даже не буду комментировать этот скрипт, т.к. верю, что код говорит сам за себя.

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

Всё, что Вам потребуется для создания собственного стенда с настроенной Active Directory — это:

Установочный iso-образ Windows Server 2021 русской версии;
Установочный iso-образ Windows 7 (придётся поискать самим);
Скрипты на языке Testo-lang;
Установленная платформа Testo (бесплатно);
Выполнить команду.

sudo testo run ./tests.testo --param ISO_DIR /path/to/your/iso/dir

И всё. Как и я обещал — всего одна команда. Через пол часа — час (зависит от шустрости вашего компьютера) вы сможете наслаждаться своим готовым стендом.

Доменные службы active directory

Эта роль фактически “включает” технологию Active Directory на сервере и делает его контроллером домена (под доменом в технологии AD понимается группа логически связанных объектов в сети). Благодаря этой роли администратор получает возможность управлять объектами в сети, а также хранить информацию о них в специальной распределенной базе данных.

Эта база данных содержит всю информацию об объектах в сети (например, именно в неё заносится информация об учётных записях пользователей). Когда человек подходит к рабочей станции и пытается выполнить вход в свою доменную учётную запись, эта рабочая станция связывается с контроллером домена с запросом на аутентификацию, и в случае успеха загружает пользовательский рабочий стол.

Однако, что же делать, если контроллер домена выйдет из строя (или просто будет недоступен для рабочих станций)? Если вы настроили только один контроллер домена, то дела ваши довольно плохи — без связи с рабочим контроллером домена пользователи не смогут выполнить вход на свои рабочие места.

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

Однако этот туториал рассчитан на простое ознакомление с технологией AD “на виртуалках”, поэтому здесь не будет рассматриваться вопрос создания нескольких контроллеров AD в одном домене.

С этим пунктом все более менее понятно, а зачем же нам включать дополнительно ещё DNS-сервер?

Dns-сервер

Обычно протокол DNS (Domain Name System) используется для обращения к узлам в сети не по их IP-адресу, а по доменному имени (строковый идентификатор), что, конечно, гораздо удобнее. Другими словами, DNS чаще всего используется для разрешения доменных имен.

Но область применения протокола DNS не ограничивается только сопоставлением хостового имени и IP-адреса, что как раз подтверждает технология Active Directory. Дело в том, что Microsoft решила построить технологию Active Directory не с нуля, а на основе протокола DNS.

В частности, протокол DNS используется при определении местонахождения всех ключевых сервисов Active Directory в сети. Другими словами, рабочая станция при подключении к контроллеру домена понимает, “куда” ей надо обращаться, именно с помощью протокола DNS.

Все DNS-записи (в том числе с информацией о сервисах Active Directory) хранятся на DNS-сервере, а это значит, что нам нужно заиметь свой собственный DNS-сервер! Вот только вопрос, откуда его взять? Есть два варианта:

Использовать отдельную машину в роли DNS-сервера;
Использовать саму машину windows_server в роли DNS-сервера.

Первый вариант, безусловно, самый правильный — именно так и надо поступать при реальном администрировании сетей (чем больше вы разносите логику по разным узлам в сети — тем лучше). Но в учебных целях я решил выбрать второй вариант (хотя бы потому, что не придётся создавать ещё одну виртуальную машину).

Именно поэтому эту роль (DNS-сервера) тоже нужно добавить к ролям машины windows_server.

Кстати, если не добавить роль “DNS-сервер” сейчас, то в будущем у вас ещё будет такая возможность при конфигурировании контроллера домена AD.

Решение

Подготовка ROOT-CA. (CentOS7)

Корневой сертификат ROOT-CA, будем выпускать на CentOS, там-же будем подписывать сертификат для PKI AD-CA.

Для решения данной задачи на машине с Linux необходимо установить пакет easy-rsa, который содержится в репетиторе epel-release

yum install epel-releas

yum install easy-rsa

Более подробно с документацией к easy-rsa можно ознакомится на GitHub/OpenVPN

После того как мы установили easy-rsa мы можем создать главный удостоверяющий центр сертификации.

(Все операции буду выполнять из под пользователя root)

Создадим в директории пользователя, каталог – в котором будем хранить наш PKI

mkdir -p ~/ROOTca

Далее нужно скопировать последнюю версию easy-rsa в наш каталог ROOTca,

dir /usr/share/easy-rsa/

В моём случаи последняя версия 3.0.8. Её и будем копировать.

Копируем easy-rsa в каталог ROOTca

cp -R /usr/share/easy-rsa/3.0.8/* ~/ROOTca

теперь нам необходимо создать файл ответов vars, и отредактировать его

создаем и сразу редактируем

cat > ~/ROOTca/vars

пример файла vars с описанием

собираем файл vars, у меня получилось так:

Начинаем

Вы установили Windows Server 2021 и (надеюсь) видите следующий экран:

Эта панель — основное (графическое) средство администрирования Windows Server 2021. Здесь вы можете управлять компонентами и сервисами на вашем сервере (проще говоря, настраивать то, что умеет делать сервер). Эту же панель можно использовать и для базовых сетевых настроек Windows Server, для чего есть вкладка “Локальный сервер”.

Первое, что нужно сделать — это поменять сетевое имя сервера.

Сетевое имя (hostname) — это удобный способ идентификации узла в сети. Сетевое имя используется как альтернатива IP-адресу и позволяет не запоминать IP-адрес компьютера (при том, что этот адрес может меняться время от времени), а связываться с этим компьютером по его логическому названию.

Проблема в том, что по-умолчанию для Windows Server генерируется совершенно нечитаемое и неинформативное сетевое имя (я выделил его красным цветом на скриншоте).

Рабочие станции ещё могут позволить себе иметь нечитаемый Hostname, но никак не сервер. Поэтому я предлагаю поменять эту абракадабру его на что-то более разумное (например, на ADController), благо делается это быстро.

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

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

Установка компонента цс

Прежде всего необходимо добавить установочные компоненты для AD CS:

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

После этого посмотрим на установочную таблицу, чтобы определить параметры установки:

В таблице я выделил только те параметры, которые задаются в процессе установки. Остальные параметры будут настраиваться после установки. Исходя из этих данных сформируем параметры для командлета

Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Issuing Certification authority" `
    -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" `
    -CAType EnterpriseSubordinateCa `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256

После выполнения этой команды будет выведено сообщение о том, что установка ЦС не завершена и для её завершения необходимо отправить сгенерированный запрос (находится в корне системного диска) на вышестоящий ЦС и получить подписанный сертификат. Поэтому находим файл с расширением «.req» в корне системного диска и копируем его на корневой ЦС и на корневом ЦС выполняем следующие команды:

Dhcp-сервер

Протокол DHCP (Dynamic Host Configuration Protocol) нужен для автоматической выдачи сетевых настроек узлам в сети. Под сетевыми настройками понимается IP-адрес, адрес шлюза по-умолчанию, адрес DNS-сервера, и ещё ряд других настроек. Этот протокол чрезвычайно удобен при администрировании сетей, особенно больших.

В этом туториале я использую протокол DHCP чтобы рабочая станция workstation могла получить сетевые настройки (в частности, адрес DNS-сервера) без каких-либо действий с моей стороны.

Протокол DHCP не имеет никакого отношения к технологии Active Directory, и можно было бы обойтись вовсе без него (достаточно прописать все сетевые настройки на рабочей станции самостоятельно), но я решил включить этот протокол в данный туториал просто для общего ознакомления.

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

Что ж, довольно теории, давайте лучше перейдём к включению этих самых ролей.

Настраиваем контроллер домена active directory

Все роли и компоненты успешно добавлены, о чём свидетельствует следующий экран:

Вот только AD на сервере всё еще не работает — для этого его необходимо донастроить. Для этого нам настойчиво предлагают “Повысить роль этого сервера до уровня контроллера домена”.

Погодите-ка, ЧТО?!

А чем же я занимался последние 15 минут? Я же добавлял роли, и судя по сообщению, они успешно добавились! И тут меня снова хотят заставить добавлять какие-то новые роли? В чем-то тут подвох.

Про сертификаты: Подарочный сертификат в Молодечно

Подвох тут действительно имеется, но вообще в не самом очевидном месте. Вот так выглядит предыдущий скриншот в английской версии Windows Server (картинка из интернета).

Видите разницу? В английской версии ни слова ни про какие роли! Про повышение есть, про роли — нет. Один из тех случаев, когда перевод вносит сумятицу на пустом месте. Согласно английской версии, никакими ролями мы дальше не занимаемся, что и логично, ведь мы их как раз только что добавили.

Что ж, тыкаем на предложение “Повысить роль этого сервера до уровня контроллера домена”, и теперь нас привествует мастер настройки доменных служб Active Directory с предложением выбрать конфигурацию развёртывания.

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

Шаг 8. перевыпуск шаблона сертификата

Мы завершили процесс миграции, и сейчас нужно перевыпустить сертификаты. У меня были настройки шаблона в окружении Windows Server 2003, который назывался

“PCCertificate”

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

Открывает консоль

Certification Authority

Щелкаем правой кнопкой мышки по

Certificate Templates Folder > New > Certificate Template to Reissue

Из списка шаблонов сертификатов выберите подходящий шаблон сертификата и нажмите

ОК

Резервное копирование

Вопросы резервного копирования и восстановления после отказа являются отдельной темой. Здесь я лишь отмечу основные моменты, которые следует учесть при планировании стратегии резервного копирования.

Microsoft Active Directory Certificate Services предоставляет инструменты для резервного копирования компонентов ЦС:

С ними можно сделать резервную копию для ключевой пары ЦС и базы данных. Однако эти инструменты не позволяют делать резервную копию настроек ЦС. Эти операции необходимо выполнять вручную. Все настройки ЦС находятся в реестре по следующему пути:

HKLMSystemCurrentControlSetServicesCertSvc

При резервном копировании всегда экспортируйте данную ветку реестра. При восстановлении ЦС сохранённый REG файл импортируется обратно в реестр после установки роли ЦС.

Полный список элементов ЦС, который подлежит обязательному резервному копированию выглядит так:

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

Предустановочная конфигурация

Если для корневого ЦС предустановочный конфигурационный файл нам не требовался, то для издающего ЦС он понадобится. В нём мы настроим расширения Certificate Policies и Basic Constraints для сертификата ЦС. Если с политиками всё понятно, то в расширении Basic Constraints мы запретим выдачу сертификатов другим ЦС с издающего ЦС, поскольку у нас двухуровневая иерархия и добавление новых уровней только усложняет нашу структуру и увеличивает время, затрачиваемое на проверку сертификатов клиентами.

Контроллеры домена практически мгновенно обнаруживают появление ЦС в лесу и даже при отключённой политике автоматической выдачи сами запрашивают себе сертификаты.
Администраторы сами должны определять какие шаблоны будут использовать в организации.

Поэтому мы сконфигурируем ЦС так, что список шаблонов к выдаче будет пустым. Это возможно сделать только через CAPolicy.inf. В нашем случае он будет иметь следующее содержимое:

Чем рабочие группы отличаются от доменов

Рабочая группа — это термин Microsoft для компьютеров Windows, подключённых через одноранговую сеть. Рабочие группы — это ещё одна организационная единица для компьютеров Windows в сети. Рабочие группы позволяют этим машинам обмениваться файлами, доступом в Интернет, принтерами и другими ресурсами по сети. Одноранговая сеть устраняет необходимость в сервере для аутентификации.

Каждый компьютер Windows, не присоединённый к домену, является частью рабочей группы. Рабочая группа — это группа компьютеров в одной локальной сети. В отличие от домена, ни один компьютер в рабочей группе не контролирует другие компьютеры — все они объединены на равных. Для рабочей группы пароль также не требуется.

Рабочие группы использовались для общего доступа к домашним файлам и принтерам в предыдущих версиях Windows. Теперь вы можете использовать домашнюю группу чтобы легко обмениваться файлами и принтерами между домашними ПК. Рабочие группы теперь переведены в фоновый режим, поэтому вам не нужно о них беспокоиться — просто оставьте имя рабочей группы по умолчанию WORKGROUP и настройте общий доступ к файлам домашней группы.

Есть несколько различий между доменами и рабочими группами:

Что такое active directory

Active Directory — это службы каталогов от компании Microsoft, как подсказывает нам Википедия. За этим сухим и невзрачным определением скрывается одна из важнейших технологий в администрировании сетей. Благодаря Active Directory администратор сети получает очень удобное централизованное средство управления учетными записями пользователей, групповыми политиками (в т.ч. политиками безопасности) и объектами в сети (причём Active Directory без особых проблем справляется даже с гигантскими сетями).

А благодаря встроенному механизму репликации, “положить” правильно настроенные сервисы AD не так-то просто. Ну и напоследок, благодаря Windows настроить Active Directory можно буквально мышкой, так что даже совсем начинающие IT-шники смогут с этим справиться.

Несмотря на то, что технологией заведует Microsoft, она вовсе не ограничивается управлением Windows-машин — все известные Linux-дистрибутивы уже давным давно научились работать с этой технологией. Повстречаться с Active Directory не просто, а очень просто — практически каждый офис предполагает наличие этой технологии, поэтому даже самым заядлым линуксоидам было бы неплохо разбираться в азах работы Active Directory.

Шаг 7. восстановление информации в реестре

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

Появится предупреждающее окно. Нажмите

“Yes”

для восстановления ключа реестра.

По окончании вы получите подтверждение об успешном восстановлении.

Прочие настройки

После того как издающий ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

Когда основные параметры проверены, необходимо убедиться в правильной связи иерархии ЦС и доступности всех внешних файлов для клиентов. Для этого на сервере ЦС (а лучше, на рабочей станции, где установлены средства удалённого администрирования ЦС) необходимо запустить оснастку

Enterprise PKI Health

(pkiview.msc). Оснастка автоматически построит текущую иерархию и проверит доступность всех путей для скачивания сертификатов ЦС и списков отзыва. Никаких ошибок быть не должно. Если есть ошибка, необходимо её точно идентифицировать и устранить. В случае успешной настройки оснастка будет выглядеть следующим образом для корневого ЦС:

И для издющего ЦС:

Если вся итоговая конфигурация соответствует ожидаемым значениям и оснастка Enterprise PKI Health не показывает ошибок, это может судить о том, что PKI установлена верно.

Настройка dhcp-сервера

Пришло время заняться настройкой DHCP-сервера. Настройка глобально состоит из двух частей:

Авторизация DHCP-сервера в домене AD. Не каждый DHCP-сервер может раздавать сетевые настройки в домене AD — только авторизованные. Это сделано с целях безопасности, чтобы другие DHCP-серверы не могли “подсунуть” неправильные настройки компьютерам в домене;
Настройка новой DHCP-области. Это уже непосредственно настройка самого DHCP-сервера, в ходе которой определяются какие сетевые настройки будут выдаваться компьютерам в сегменте сети.

Для того, чтобы авторизировать DHCP-сервер, нужно вернуться на панель мониторинга (она и так должна быть перед вами после перезагрузки), перейти на вкладку DHCP (слева) и кликнуть на предложение донастроить DHCP-сервер:

В открывшемся мастере настройки DHCP после установки пропускаем первый приветственный экран и переходим к экрану авторизации

На выбор предлагаются три варианта:

Использовать учётные данные администратора (по-умолчанию)
Использовать учётные данные другого пользователя;
Пропустить авторизацию AD.

Подготовка веб-сервера

На веб-сервере нам потребуется выполнить следующее: установить службу IIS (если ещё не установлена), создать общую папку и сконфигурировать веб-сайт на использование этой папки.

Для установки службы IIS можно воспользоваться следующей командой:

Install-WindowsFeature -Name Web-Server, Web-WebServer -IncludeManagementTools

Согласно нашей конфигурационной таблице (см. часть 2), для хранения сертификатов ЦС и списков отзыва нам потребуется общая папка с сетевым именем PKI по следующему пути: C:InetPubwwwrootPKIdata

New-Item -ItemType Directory -Path C:InetPubwwwroot -Name PKIdata -Force
New-SmbShare -Path C:inetpubwwwrootPKIdata -Name PKI -FullAccess everyone

После этого нужно выдать права NTFS на запись в эту папку для группы Cert Publishers.

Почему такой стенд?

Такой стенд, с моей точки зрения, отлично подходит для первого самостоятельного “прощупывания” технологии Active Directory. Он минималистичен (всего 2 виртуальные машины), занимает минимум ресурсов, но при этом изолирован и самодостаточен. Его можно развернуть даже на довольно средненьком компьютере и ноутбуке.

Туториал предполагает подробный разбор всех шагов по настройке, с пояснениями “что, зачем и почему”. Туториал ориентирован на людей, не слишком знакомых с технологиями Active Directory, DNS и DHCP, которые хотели бы немного узнать о внутренней кухне администрирования сетей с Active Directory.

Если же базовая настройка AD вызывает у вас лишь зевоту, переходите прямо сюда и посмотрите, как можно автоматизировать весь процесс по развёртыванию собственного стенда с AD и рабочей станцией.