Меню

Настройка cep ces на windows server 2012



Настройка SCEP-сервера для автоматического получения AMT сертификатов

Если у вас возникнет серьёзная потребность в написании собственного ПО для АМТ, вы обязательно столкнётесь с обслуживанием сертификатов — в первую очередь это автоматизация их получения. Потому что, как бы это ни было удобно, использовать Manageability Director для такой цели (именно автоматическое получение) — не получится. Intel SCS во многом решает эту задачу, но, повторюсь, если зайдёт речь именно о своём ПО — код SCS, начиная с версии 8.0, закрыт, кроме того, SCS страшно громоздок и негибок, не говоря уже про нелюбовь к линуксу.

Собственно, такая же задача — «автополучение сертификатов» — стоит среди главных для того же MDM и любой другой сферы, связанной с шифрованием посредством «привычных» сертификатов. Если по-простому, то для какого-то устройства, которое нуждается в сертификате, должна быть возможность отправить запрос по http/https и получить в ответ сертификат, выписанный от имени нашего CA.

Такую задачу решает SCEP (Simple Certificate Enrollment Protocol) сервер. В версии от микрософт (MSCEP) она реализуется с помощью NDES (Network Device Enrollment Service) сервиса. Далее опишу настройку SCEP для выдачи AMT-сертификатов. (При чём не только для TLS-шифрования, но и для инициализации/управления, что пригодится нам после, при рассмотрении работы AMT7+, поддерживающих HostBasedSetup, где как раз такие и требуются).

Как обычно, при настройке MS-сервисов, я не акцентирую внимание на подробностях их работы — это другая тема. Считаю правильным сделать «пошаговую инструкцию», чтобы по картинкам любой мог это же повторить, и останавливаюсь подробней лишь на важных и проблемных моментах.

В «полной» версии MSCEP предполагает наличие отдельного сервера с домен-контроллером, отдельного для СА и отдельного для SCEP (NDES) — итого 3 шт.

Однако я исхожу из предположения, что ПО предполагает условно «малый бизнес» (Small Business), где количество/стоимость обслуживания виртуалок для этого играет значение, потому опишу настройку всего этого на одной виртуалке.

То есть с DC+СА+SCEP в одном флаконе.

В моём случае она поднимается на Amazon EC2, достаточно варианта с 1.7Гб памяти (по опыту нужно от 1Гб, использовать самые «бюджетные» виртуалки с 640Мб крайне не рекомендуется — глюки с получением сертификатов крайне многовероятны).

Поставив домен и СА (см. руководство из прошлой части) приступаем к установке NDES (т.е. собственно, SCEP-сервера).

Сначала создадим юзеров (в домене):

  • админа SCEP
  • юзера из-под которого будет запускаться сервис SCEP (NDES)
  • Device-админа, который будет иметь права на получение сертификата «со стороны устройства» (по простому — через веб-интерфейс)

Я обзываю их SCEPadmin, SCEPservice и DeviceAdmin.

SCEPadmin добавляем в группу «Administrators», SCEPservice в группу «IIS_IUSRS».

Далее добавляем ещё одну роль для CA:

Ставим галку напротив NDES:

На следующем шаге прописываем нашего пользователя с правами «IIS_IUSRS», из-под которого будет трудиться NDES.

Наличие группы «IIS_IUSRS» у данного юзера (SCEPservice ) принципиально, иначе получите ошибку 0x80070529:

Тут заполняем, что хотим (не принципиально):

На следующей можно ничего не трогать.

Проверяем и запускаем установку:

После окончания установки, если у вас до этого уже была открыта консоль с шаблонами — её нужно обновить, чтобы отобразились свежедобавленные в результате шаблоны. Для нас важен будет, появившийся после установки NDES — шаблон «CEP Encryption«.

Добавляем SCEP-админа (SCEPadmin) для «CEP Encryption«:

И даём ему права на «Enroll«:

Далее аналогично для шаблона «Exchange Enrollment Agent (Offline request)» — добавляем «Enroll» для SCEPadmin:

Далее настраиваем админу SCEP права на добавление шаблонов в СА:

Ставлю все галки в закладке «Security«:

И, наконец, добавляем SCEP-админа в «Administrators» и «Enterprise Admins»:

Настраиваем пользователя, из-под которого запускается NDES, в моём случае это SCEPservice. Ранее мы его уже добавили в группу «IIS_IUSRS». Однако подразумевается именно локальная группа, потому, из-за того, что мы делаем это «прямо на домене» (где «всё в одном» — DC+CA+SCEP), придётся добавить SCEPservice в группу «Administrators».

Иначе (если не добавить SCEPservice в администраторы) после SCEP-ApplicationPool просто не стартанёт (будем получать ошибку 503 — «Service Unavailable«), т.к. у данного пользователя не будет прав на вход в систему.

The identity of application pool SCEP is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights.

Далее, ещё SCEPservice нужны права на запрос сертификатов из СА:

Кроме этого ему требуются «Read» и «Enroll» для шаблона, с помощью которого мы будем отдавать сертификаты. По умолчанию, после установки NDES, это шаблон «IPSec (Offline request)«. Поэтому мы настроим всё нужное для него, а после сделаем на базе оного шаблон для Intel AMT.

Читайте также:  Бесконечный поиск обновлений подготовка к настройке windows 7

Итак, для шаблона «IPSec (Offline request)» ставим SCEPservice права на «Read» и «Enroll«:

Наконец, добавляем SPN для SCEPservice. Для этого выполняем в командной строке:

setspn -a SCEPservice/scs.vpro.by scs
(в вашем случае имя сервиса и домен прописываем своё)

Для DeviceAdmin-а, аналогично SCEPservice, добавляем права на «Enroll» для «IPSec (Offline request)«:

Настройка аккаунтов закончена, теперь на базе «IPSec (Offline request)» сделаем шаблон для Intel AMT.

Шаблон SCEP для Intel AMT

Делаем дубликат «IPSec (Offline request)«:

Выбираем 2003:

Я обзываю его «AMTinitTLS» — он будет и для инициализации (пригодится для AMT7+) и для TLS.

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

Я минимальный размер ключа с дефолтных 2048 понижаю до 1024 (AMT поддерживает 10242048):

Добавляем галку «Microsoft Strong Cryptographic Provider«:

Проверяем/ставим «Supply in the request» в «Subject Name«:

Проверяем/ставим «Read» и «Enroll» для SCEPservice в закладке «Security«:

Добавляем в «Extensions» политики «Client Authentication» и «Server Authentication«:

Вышеописанные шаги для шаблона AMT мы уже делали при настройке TLS-сертификатов для Intel SCS. «Client Authentication» и «Server Authentication» — это «обычные» политики для SSL-сертификатов. Сейчас же добавим ещё и «необычных», специфичных именно для Intel AMT.

Настройка OID, специфичных для Intel AMT

На «Add Application Policy» жмём «New» и в поле OID вводим 2.16.840.1.113741.1.2.3 (предварительно очистив это поле от того, что там по умолчанию). Это политика, необходимая для инициализации AMT, потому обзываю её, например, «AMT init»:

Аналогично повторяем и вводим 2.16.840.1.113741.1.2.1 — требуемая политика для удалённого доступа, называю «AMT remote access»:

И для локального доступа 2.16.840.1.113741.1.2.2 — «AMT local access»:

В результате получим следующий набор политик:

Для «красоты» можно удалить политику IPSec — останутся все те, что требуются для работы Intel AMT.

Применяем все изменения и получаем новый шаблон.

Добавляем «AMTinitTLS» в шаблоны СА:

Рестартим СА для публикации новодобавленного шаблона:

Шаблоны на месте, приступаем к следующей стадии.

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

Однако и тут сложности — по дефолту пароль (который проверяется при запросе сертификата) одноразовый, т.е. он меняется после выписывания каждого сертификата. Такие сложности ни к чему, переделаем на постоянный пароль. Для этого придётся лезть в реестр.

Ищем ветку «HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\MSCEP«:

Меняем на единичку:

Видим, что в реестре стоит дефолтный шаблон — «IPSECIntermediateOffline«:

Однако мы добавили в СА и хотим выдавать свой, а не дефолтный, потому меняю его (все три поля) на «AMTinitTLS» (имя шаблона, выше нами сделанного):

Далее нужно добавить возможность изменять данную ветку реестра пользователю, из-под которого стартует NDES (у меня это SCEPservice).

Для этого даём ему Full Control:

Ну и последний штрих — настраиваем IIS. Для этого в свойствах «Application Pool» — «SCEP» жмём «Advanced Settings«:

Меняем «Load User Profile» с дефолтного «False» на «True«:

Перезагружаем IIS командой iisreset и заходим по адресу http://192.168.0.197/CertSrv/mscep_admin/ (тут, конечно, у каждого свой адрес/IP) и вводим логин-пароль DeviceAdmin-а:

Наконец, получаем долгожданный результат:

Мы получили сгенерированный постоянный пароль (Enrollment Challenge Password), которым можно пользоваться для автоматического получения сертификатов с помощью HTTP и HTTPS (настроим в следующей части) запросов.

В общем, SCEP-сервер настроен и готов к работе.

Источник

Group Policy configuration

После установки службы CEP у вас появляется адрес HTTP, который указывает на сервер CEP и этот адрес имеет вид:

где auth_protocol указывает на протокол аутентификации клиента на сервере CEP. Это может быть Kerberos (только для доменных клиентов), Password или Certificate. Вот этот адрес нужно добавить в настройки групповой политики. Для этого откройте редактор групповой политики (gpmc.msc или gpedit.msc для недоменных машин) и в секции: Computer Configurtion\Windows Settings\Security Settings\Public Key Policies настроить параметр Certificate Services Client — Certificate Enrollment Policy. В свойствах следует включить эту политику и вы увидите окно Certificate Enrollment Policy list и в котором уже одна политика будет определена. Предопределённую политику следует удалить совсем и кнопкой Add добавить новую. В открывшемся окне вставить эту ссылку, указать нужный тип аутентификации и нажать Validate. В результате вы должны получить нечто вроде такого:

Читайте также:  Что такое настройки dns в виндовс 7

fig.1

Если вам это удалось сделать, значит клиент смог успешно пообщаться с сервером XCEP и CES. Причём, вы увидите, что клиент по этой ссылке смог найти название данной политики и вставить её в окошко:

И таким образом вы можете добавлять несколько различных адресов политик, которые могут относиться к различным организациям. Причём, организация может развернуть несколько серверов XCEP для обеспечения высокой доступности, тогда вы можете добавлять несколько адресов серверов CEP и они будут линковаться к одной политике.

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

Уникальность политики определяется по её GUID’у. В этом окне может формироваться список всех серверов CEP, которые обслуживают одну и ту же политику (с одинаковым GUID’ом). По умолчанию для всех политик включается разрешение автоэнроллмента.

Примечание: галочка Enable for automatic enrollment and renewal не является самодостаточной и зависит от классической политики автоэнроллмента. Если автоэнроллмент отключен, то соответственно, автоматическая подача заявок на сертификаты производиться не будет.

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

  • создать новый объект групповой политики или отредактировать существующую политику по адресу:
    Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> Certificate Services Client — Autoenrollment
    данный элемент политики следует установить в состояние Enabled, поставить галочку Update certificates that use certificate templates и при необходимости выбрать автоматическое обновление просроченных сертификатов и удалении отозванных сертификатов из хранилища.
  • Те же параметры настраиваются и в секции User Configuration, чтобы обеспечить автоматическое распространение пользовательских сертификатов. Это могут быть сертификаты EFS, подписи электронной почты или сертификаты для аутентификации пользователей:
    User Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> Certificate Services Client — Autoenrollment
  • прилинкуйте созданную или отредактированную политику к нужному OU (чаще всего её применяют для всего домена).

Примечание: для успешного энроллмента сертификатов на основе новых шаблонов (для которых у клиента ещё нет ни одного сертификата) галочка Update certificates that use certificate templates обязательна!

В общем смысле, новый автоэнроллмент работает примерно так:

fig.4

Client behavior

Примечание: по причине громоздкости текста, я не буду приводить содержание ответа сервера XCEP. Но его cтруктуру можно увидеть в §4.1.1.2 (GetPoliciesResponse Response) документа [MS-XCEP]. Поэтому я буду подразумевать, что вы ознакомились с его примерным содержанием.

Когда срабатывает триггер автоэнроллмента, клиент считывает параметры из реестра:

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

Данные ключи будут содержать подключи политик. Каждому подключу политики присваивается уникальный GUID и внутри него будет содержаться необходимая информация о каждой политике, как URI, метод аутентификации, «стоимость» политики и флаги автоэнроллмента. После этого происходит сортировка политик по следующим правилам:

  • сортируются по «стоимости» политики. Политика с меньшей стоимостью будет более приоритетной и политика с большей стоимостью будет менее приоритетной, соответственно. Если 2 и более политик имеют одинаковую стоимость, то идёт второй уровень сортировок по методу аутентификации (в порядке приоритета):
    • используется аутентификация Kerberos;
    • используется анонимная аутентификация;
    • остальные политики используются в том порядке, в каком они записаны в реестре.

Когда политики отсортированы, клиент подключается к серверу XCEP из каждой политики по HTTPS. Если по какой-то ссылке не удаётся подключиться или сервер возвращает ошибку (SOAP), клиент переходит к следующей ссылке. Если в ответ получены политики, клиент извлекает следующие параметры:

  • адрес или адреса серверов CES;
  • список серверов CA, на работу с которыми настроен сервер CES. Один сервер CES должен быть настроен на работу с неболее, чем одним сервером CA;
  • список шаблонов и их параметры.
Читайте также:  Настройка умолчаний для цветовой системы windows wcs

Pended request processing

Как и в случае с ACR, клиент после всех подготовительных процедур пытается получить сертификаты в ответ на запросы. Как мы уже знаем, запросы хранятся в контейнере Certificate Enrollment Requests. Сперва клиент удаляет все запросы, которые старше 60 дней, а затем посылает запрос на CES для выяснения статуса каждого запроса. Если в ответ на запрос был получен сертификат, то он помещается в список ToBeAdded. Если статус запроса Denied, то запрос удаляется. Если статус неизвестен, клиент переходит к следующему запросу.

Certificate update and enrollment

После обработки всех ожидающих запросов, клиент проверяет статус каждого существующего сертификата. Если сертификат отозван или его срок истёк, он помещается в список ToBeDeleted.

Примечание: просроченные сертификаты будут помещены в этот список только если в групповой политике выставлен флаг Renew expired certificates, update pending certificates, and remove revoked certificates и сертификат не используется для шифрования.

Если срок действия сертификата преодолел отметку 80% и шаблон этого сертификата находится в списке доступных шаблонов (который был получен после нескольких уровней фильтрации в предыдущих шагах), клиент отправляет запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом. Если в реестре для текущего сертификата указан PolicyID, клиент будет пытаться найти тот же ID в списке политик CEP и запрос на обновление сертификата отправлять на сервер CES, который указан в политике. Если PolicyID для текущего сертификата не указан, то запрос будет отправляться на тот сервер CES, политика которого является по умолчанию (см fig.2). Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded и записывает PolicyID, который использовался при энроллменте. Этот ID будет использоваться при обновлении сертификата.

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

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

Если версия шаблона (Major Version), который использовался при предыдущем энроллменте отличается от текущего Major Version шаблона, клиент посылает запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом. Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded.

Примечание: при каждом редактировании шаблона (кроме вкладки Security) изменяется только Minor Version. И держатели сертификатов этого шаблона не увидят, что шаблон изменён, поскольку они проверяют только Major Version. В случае, если после внесения изменений в шаблон необходимо переиздать все сертификаты этого шаблона, администратор должен изменить Major Version. Для этого администратор в оснастке certtmpl.msc должен выбарть нужный шаблон, нажать правой кнопкой и выбарть Reenroll All Certificate Holders. Этот шаг изменит Major Version шаблона и все клиенты, которые уже имеют сертификат данного шаблона его обновят, получив новый сертификат с новыми изменениями.

Если шаблон, который использовался при предыдущем энроллменте был заменён более новым (вкладка Superseded Templates нового шаблона содержит устаревший шаблон), клиент отправляет запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом. Если в реестре для текущего сертификата указан PolicyID, клиент будет пытаться найти тот же ID в списке политик CEP и запрос на обновление сертификата отправлять на сервер CES, который указан в политике. Если PolicyID для текущего сертификата не указан, запрос будет отправляться на тот сервер CES, политика которого является по умолчанию (см fig.2). Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded и записывает PolicyID, который использовался при энроллменте. Этот ID будет использоваться при обновлении сертификата.

Для необработанных шаблонов клиент отправляет запросы на получение сертификатов на основе этих шаблонов.Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded и записывает PolicyID, который использовался при энроллменте. Этот ID будет использоваться при обновлении сертификата.

Когда все запросы, сертификаты и шаблоны были обработаны, триггер автоэнроллмента очищает список ToBeDeleted и все сертификаты из списка ToBeAdded копирует в контейнер Personal.

Epilogue

Вот, вроде и всё. На этом я завершаю цикл статей, посвящённых Certificate Autoenrollment во всех его вариациях и с рассказом о новых возможностях Windows 7 и Windows Server 2008 R2. Рассказал как умел и, мне кажется, материал получился достаточно исчерпывающим и у читателя должно появиться понимание принципа работы всех внутренних механизмов. Если что-то осталось непонятным или появились вопросы — комментарии внизу 🙂

Источник

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector