Remote Configuration на примере Lenovo T400 (AMT4)

Статья "Remote Configuration на примере Lenovo T400 (AMT4)" из серии "Учебник по Intel AMT", часть девятая.

См. также:

        Часть восьмая: "AMT3 - инициализация с помощью сертификатов"

В прошлый раз мы, наконец, окончательно разделались с "доисторической" PID/PPS-инициализацией и "вступили в АМТ-сертификаты". Это вступление никак не было исчерпывающим, однако широта + сложность темы и не позволила бы это сделать в гуманно-ограниченном формате данных статей (в любом случае). Мне видится правильным больше упирать на практику и так постепенно осваивать нужную для её реализации теорию. А потому продолжим.

Рекомендуемые системы для работы с АМТ

АМТ 2.2 и AMT 2.6 системы с поддержкой Remote Configuration, к сожалению, в реальности очень часто имели серьёзные проблемы для осуществления данной фичи, потому ранее я употребил вариант "ограниченной реализации". Версия АМТ 3 уже "честно" реализовала данный функционал (собственно, там он и появился), однако, всё же, она относится к тому "древнему" списку версий (АМТ1-2-3), которые и сам Intel позиционирует как "устаревшие". В частности, в статье про апдейты Firmware этих старых версий мы говорили, что те же драйвера (официально) не поддерживали Windows 7 (максимум - Vista x64). И хотя я сам начинал активно разбираться с темой vPro как раз системе AMT 3 (а конретно это материнская плата Gigabyte Q35M-S2, 2008-й год), однако, всё же, не стану рекомендовать такие из-за очевидной (и не очень) древности. Вообще, минимально рекомендуемой для "разборок с АМТ" являются системы версии 4 (это в т.ч. и "условная рекомендация" Intel - например, для таких систем будут драйвера и под Windows 7 и под Windows 8) - такой случай и рассмотрим.

Коротко про АМТ 4

Версия AMT4 появилась в 2008-м году как результат "очередной революции" в виде ноутбуков на базе Intel GM45/PM45+ICH9M. Системы АМТ 4.х - только "мобильные", как и их предшественники АМТ 2.5/2.6. Главной новой фичей АМТ4 стал функционал CIRA (Client Initiated Remote Access), которому мы посвятим ещё не одну из следующих частей, однако в данном случае сконцентрируемся на Remote Configuration. Рассмотрим работу, как обычно, на конкретном примере.

Intel AMT 4 система - Lenovo T400

AMT 4 Lenovo T400

Один из распространённых ноутбуков с поддержкой AMT 4 (а конкретно АМТ 4.2 - последней из "подверсий") — Lenovo T400. На момент написания статьи оный уже перешагнул пятилетний рубеж, однако при хорошей комплектации (4Гб памяти и SSD), производительности вполне хватает и на последнюю Windows 8.1, которая на нём в данный момент и успешно трудится. Все эксперименты далее будем проводить только с проводным интерфейсом, несмотря на то, что АМТ 4 обладает рядом важных отличий от АМТ 2.5/2.6 для WiFi (этому тоже посвятим отдельную тему).

Remote Configuration (RC)

В этой статье проведём более простой вариант - One Touch инициализации сертификатом.

Zero Touch более сложен в реализации и актуален скорей для админов с большим парком компьютеров внутри корпоративной сети - рассмотрим отдельно дальше.

В качестве сервера будем использовать Director (MDTK), с которым раньше тренировались в проведении PID/PPS инициализации. Открываем его раздел Certificate Manager:

Certificate Manager

В окошке отображены уже установленные в системе сертификаты (это не "директорные" - это "виндовые" сертификаты, а Director лишь предоставляет более удобный интерфейс работы со стандартным хранилищем сертификтов). У вас там, соответственно, может быть пусто (внимания на мой обращать не стоит).

Итак, задача - создать свой сертификат, с помощью которого можно будет проинициализировать АМТ (т.е. отработать фичу RC).

Root Certificate

Для этого сначала потребуется создать корневой сертификат. Жмём Create Root Certificate:

Certificate Manager - Certificate-Generator

Значения полей Organization Name и Country code вообще игнорируются МЕ и попали сюда, скорей, "по привычке", потому там можете писать, что угодно (или совсем ничего). Главное поле - Common name, однако его можно задать любым (не обязательно сюда писать адрес). Лишь не стоит его делать "странно-неудобным", т.к. после его нужно будет указывать (потому желательно покороче и без пробелов).

Если стоит галка "After creation make this a trusted certificate" (а снимать её обычно смысла нет), то после нажатия Generate кроме создания сертификата, он автоматически добавляется в "трастовые" (хранилища сертификатов Windows). Это критичное для ОС действие, потому появится диалог подтверждения:

Certificate Manager - Certificate Generator - Security Warning

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

AMT-сертификат

Создав корневой сертификат мы виртуально стали обладать возможностью "центра сертификации" - можем с его помощью "выдавать" сертификаты, в том числе с возможностью инициализации АМТ. Для этого выделяем строчку только созданного нами корневого сертификата и жмём Issue New Certificate:

Certificate Manager - Certificate Generator - All Permissions

В выпадающем списке сразу сменяем Sub-CA (позволяющее создать промежуточный сертификат - в реальной жизни вам вряд ли он когда-то понадобится) - выбираем пункт "All Permissions", который включает сразу все права (которые при желании можно "вешать" отдельно на разные сертификаты). Последние два поля аналогично предыдущему случаю не важны (можно указывать от балды):

Certificate Manager - Certificate Generator - New Certificate

Поле "Common name" у вас изначально выберется как текущее dns-имя вашего компьютера (или виртуалки). Это потому, что оно должно соответствовать адресу, на который будет отправляться Hello-packet. Как говорилось в предыдущей статье, АМТ-компьютер будет сравнивать сертификат, присланный ему для инициализации с адресом, на который он отправлял свой Hello-packet, чтобы убедиться, что это "правильный" сервер. Соответственно, в поле "Common name" прописываем адрес компьютера (или виртуалки), где стоит Director.

Важно: сервер с MDTK должен располагаться в одной подсети (либо придётся пробрасывать порты 16992-16993) и не должен быть установлен на том же компьютере, который нужно инициализировать (в т.ч. в виде виртуалки). Т.е. это по-любому "физически" другой компьютер (или виртуалка на "физически" другом компьютере).

В частности, для этого примера, я создал поддомен mdtk.vpro.by, прописав в DNS-админке его айпишник внутри локальной сети:

add subdomain mdtk

В принципе, подобное можно сделать другими способами, например, если у вас поднят свой DNS-сервер, однако это уже дело техники, нам важно лишь то, чтобы АМТ-компьютер смог достучаться по адресу mdtk.vpro.by до компьютера/виртуалки с установленным Директором.

Итак, после нажатия Generate у нас на сервере (с MDTK) будут установлены два сертификата - рутовый и подписанный им сертификат для инициализации АМТ. Теперь нам нужно сделать так, чтобы хэш рутового сертификата стал "доверенным" для АМТ-компьютера. Это можно сделать двумя способами.

Настройка Remote Configuration "вручную"

Первый, примитивный - ввести его ручками в MEBx. Там появился, по сравнению с "до RC-версиями", где только PID/PSK (другое название "TLS-PSK") новый пунктик - TLS-PKI:

MEBx TLS PKI

В котором будут настройки инициализации через сертификаты:

MEBx TLS PKI options

• Remote Configuration

Опция, включающая/запрещающая (Enable/Disable) инициализацию через сертификаты. Обычно всегда включен, да и не понятно, зачем его можно выключать. Однако уже точно не вспомню, но, вроде, на какой-то матплате с AMIBIOS видел его по умолчанию отключенным. Потому в случае жестоких проблем - проконтролируйте.

• Manage Certificate Hashes

Как раз здесь и можно посмотреть прошитые "трастовые руты" (точней их хэши).

MEBx Manage Certificate Hashes

А также и добавить свой.

Для этого сначала нужно ввести имя:

MEBx Manage Certificate Hashes add Certificate Hash

Оно должно точно совпадать с тем, которое вы указывали при создании корневого сертификата (указано стрелочкой поле Common name). А далее ввести сам хэш, который можно посмотреть, кликнув на рутовом сертификате и открыв вторую закладку:

MEBx Manage Certificate Hashes add Certificate Hash 20 bytes

После нажатия ввод будет запрос на активацию добавленного хэша:

MEBx Manage Certificate Hashes add Certificate Hash set active

Жмём "Y", иначе сертификат добавится (т.е. сохранится), будет в списке, но не будет активным, т.е. по нему RC не пройдёт.

Всё теперь наш рут (его хэш) в трастовых - теперь АМТ будет "доверять" и выписанному от его него сертификату на инициализацию.

• Set FQDN

В этом пункте можно добавить адрес инициализационного сервера - куда будет отправляться Hello-packet. Т.е. в нашем случае это mdtk.vpro.by (где стоит Директор).

• Set PKI DNS Suffix

Это очень важный и сложный для понимания пункт. Если коротко - это то значение, которое мы уже не раз прописывали в настройках DHCP-сервера роутера ранее: поле "Option 15", "Домен по умолчанию", "Local domain" и др. названия. Вообще, если у нас нет возможности добраться до настроек DHCP-сервера, то единственный способ использовать инициализацию сертификатом - как раз указание PKI-DNS суффикса в MEBx. Далее, исходя из названия, "суффикс" - это нужно понимать дословно. Т.е. раз у нас сертификат для инициализации АМТ выписан на mdtk.vpro.by, то его "суффикс", это "vpro.by". Что и нужно указать в данном поле. Если бы сертификат был выписан на "amt.guide.vpro.by", то тогда в качестве суффикса можно было бы указать и "guide.vpro.by" или всё тот же "vpro.by".

Правила использования суффиксов весьма сложные, обязательно будем с ними разбираться, просто запомните, что дабы не было проблем - сертификат инициализации АМТ выписываем на домен 3-го и более уровня (условно - "с двумя  точками" и более), а суффикс записываем "на один уровень меньше". Соответственно, домены второго уровня (вида "мой.домен") для инициализации не используем, т.к. суффикс у такого получится "однопалубным", что не столько недопустимо, сколько на такую ситуацию не рассчитано всё ПО для АМТ (как серверное, как приложения для администрирования, так и "внутри" МЕ).

Настройка Remote Configuration с помощью USB-флешки

Конечно, "ручной" вариант настройки Remote Configuration никак не легче "дедовского" PID/PPS. Особенно, если у вас компьютеров больше одного. Потому лучше воспользоваться флешкой и USBFile.exe и последующего "автопровизионинга" (One Touch).

Чтобы не мучаться с получением и вводом хэша рута - просто сохраним его себе в файл. Для этого на вкладке настройки сертификатов в Директоре выделим наш рут-сертификат, нажмём Export и выбрав имя, сохраним:

save root cert

В качестве типа оставляем "*.cer".

Далее кидаем данный файл (в случае выше это "root_AMT-guide.cer") в каталог с USBFile и запускаем следующую командную строчку:

USBfile -create setup.bin admin vPro!by1 -fqdn mdtk.vpro.by -dns vpro.by -hash root_AMT-guide.cer "AMT-guide" -v 2.1

Пройдёмся по новым (по сравнению с рассмотренными ранее) ключикам указанной команды.

-fqdn mdtk.vpro.by
здесь указываем адрес provisioning-сервера, т.е. того, где стоит Manageability Director в нашем случае (или Intel SCS - когда после будем его рассматривать)

-dns vpro.by
указываем PKI-DNS суффикс

-hash root_AMT-guide.cer "AMT-guide"
указываем файл (если он не в локальной папке - плюс путь к нему) корневого сертификата (будет использован чисто для подсчёта хэша) и его название (должно точно совпадать с тем, что вводили при создании корневого сертфиката в CN (Common Name)

-v 2.1
АМТ 4 поддерживает setup.bin-файлы версий до 2.1 включительно. В данной версии есть практически всё, что обычно требуется при работе с АМТ, потому её и указываем как "дефолтную" (с поправкой - для версий АМТ4+)

Выше я привёл ключики для варианта "админ-админ", т.е. когда система "нетронутая" (в MEBx не заходили - пароль "admin"). У меня уже она была "тронута" потому потребуется "сбросить в дефолт". В Lenovo T400 это выглядит следующим образом. Заходим в BIOS Setup:

Lenovo T400 BIOS Setup Utility

Жмём Config:

Lenovo T400 BIOS Setup Config

И подменюшку AMT:

Lenovo T400 BIOS Setup AMT

Выключаем "Intel ® AMT Control", сохраняем, перезагружаемся, потом включаем обратно - получаем "админ-админ".
Всё готово, проводим инициализацию. Для этого стандартно вставляем сделанную флешку с файлом setup.bin и на привычный вопрос про автоконфигурирование жмём "Y".

Бежим в виртуалку с директором, смотрим логи сервера, через некоторое время увидим:

Configuring TLS PKI

Это значит, что пришёл Hello-packet и прошла TLS-PKI инициализация (т.е. с помощью нами созданного сертификата, а TLS-PSK, которую мы делали раньше). Как видно, был применён профайл из седьмой части, который мы использовали при первом знакомстве с MDTK. Можно было при желании создать другой, но особого смысла нет - после можно будет "донастроить" всё нужное с помощью Manageability Commander (как/что опишем в следующих частях).

Итак, получили стандартно "синенький значок" вновь появившегося проинициализированного компьютера - можно пользоваться.

В качестве "контрольного выстрела", раскроем на подключённом АМТ-компьютере подменюшку "Remote Configuration Settings" и увидим следующее:

added Hash

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

Комментарии

Спасибо за статью, очень информативно и доходчиво.

В принципе перелопатив кучу статей по технологии vPro у меня тоже примерно воссоздалась похожая картина настройки в One-touch режиме. Правда нигде не видел упоминания о том, что имя сертификата в MEBx должно быть идентичным Common Name самозаверенного рут-сертификата (может из-за этого у меня и не проходила инициализация).

Вопрос на смежную тему. С помощью Open MDTK нельзя проинициализировать AMT с интеграцией в Active Directory (и судя по ответу на е-mail, Юлиан Сайнт-Хилари не собирается в ближайшее время допиливать эту функцию в MDTK). Единственный бесплатный софт для такого рода инициализации является Intel SCS. Так вот собственно вопрос можно ли как-то использовать созданные в MDTK сертификаты в SCS (а у меня огромное подозрение по этому поводу, что сделать это нельзя) ?

Аватар пользователя apple_rom

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

Ваша задача, скорей, может быть сформулирована как желание использования "кастомных" сертификатов для SCS. В то время, как он задуман на то, чтобы сертификаты получать (выписывать) при каждом запросе на инициализацию-конфигурирование. Хочется по-другому - придётся писать самому (править исходники тех версий SCS, что были открыты - до восьмой). Это точно возможно (у нас так работает), однако, понятно, ни команда Intel SCS, ни команда Ylian-а не будет заниматься подобным, потому нужно будет искать обходные пути.

Возможно после прочтения основной части статей по работе Intel SCS (в ближайшие пару месяцев, думаю, напишу) у вас найдётся решение и своей проблемы, таки там есть некоторые возможности. Однако, конечно, их не шибко много, лучше ориентироваться на исходники (если "глубина ваших проблем" заслуживает такой обширной и сложной темы).

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

Filtered HTML

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Доступные HTML теги: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.
Anti-bot.