Не удалось отправить запрос на аутентификацию сертификата в хранилище идентификаторов: Azure_EntraI

[mzarli]

В настоящее время я работаю над
аутентификацией и авторизацией на основе устройств
для
устройств
,
подключенных
к
Microsoft Entra ID,
с использованием
Cisco ISE 3.4 Patch 4
. Я следовал официальной документации Cisco для настройки
интеграции
REST ID Store с Entra ID
(включая регистрацию приложений, разрешения и настройку политик). Аутентификация с помощью
EAP-TLS
проходит успешно, однако
авторизация на основе устройств с использованием групп устройств Entra ID не работает
. Политики аутентификации и авторизации построены в соответствии с описанием в документации. На
узле служб политик (PSN)
во время авторизации постоянно появляется следующая ошибка: cisco.cpm.restidstore.auth.RestAuthenticator — Не удалось отправить запрос на аутентификацию сертификата в хранилище REST ID: Azure_EntraID_ProDevice для пользователя: DE-N81298.netz.tuev-nord.de В журналах RADIUS live нет соответствующих ошибок
, что затрудняет устранение неполадок. Буду благодарен за любые рекомендации или предложения по устранению неполадок. @Greg Gibbs

[Greg Gibbs]

Если значение сертификата в поле SAN является «DNS
Name

DeviceName.netz.tuev-nord.de», то ваше регулярное выражение не соответствует этому значению. Вам нужно использовать регулярное выражение, подобное тому, которое приведено в моем блоге и на которое есть ссылки в обоих ответах: ^DNS Name=([a-zA-Z0-9-]+).netz.tuev-nord.de Вам необходимо использовать проверку, чтобы проверить
точное
совпадение содержимого поля сертификата для одного из ваших сертификатов с настраиваемой строкой регулярного выражения.
Если вы обновили регулярное выражение, успешно проверили его с помощью реального значения в вашем сертификате, но оно по-прежнему не работает, вам необходимо открыть заявку в службу поддержки TAC для расследования. Имейте в виду, что это очень новая и сложная функция (с точки зрения кода), поэтому в анализе все еще могут быть некоторые ошибки, которые необходимо устранить. Я сам протестировал ряд перестановок, но не смог охватить все.

[Greg Gibbs]

Это, вероятно, указывает на то, что парсер не находит в сертификате ожидаемую идентификацию или шаблон, чтобы запустить поиск устройства с помощью Graph API. Для устранения неполадки нам потребуется гораздо более подробная информация: Какие именно настройки запроса устройства вы сконфигурировали?
Какую строку регулярного выражения вы используете для сопоставления с нужной идентификацией?
Какие точные значения вы указали в сертификате устройства (CN, SAN)?
Какие настройки вы определили для профиля аутентификации сертификата? Вы можете посмотреть пример такого случая использования в моем блоге здесь, чтобы сравнить с вашей средой:
https://cs.co/ise-entraid#DeviceQuery Если вы не можете поделиться этой информацией на этом форуме или эта проблема является срочной, откройте заявку TAC для расследования.

[mzarli]

Спасибо за ответ Какие именно настройки запроса устройства вы сконфигурировали? Введите название устройства Какую строку регулярного выражения вы используете для сопоставления нужной идентичности? Я использую предопределенное регулярное выражение для
SAN-DNS
: ^[a-zA-Z0-9-]+(.[a-zA-Z0-9-]+)+$ В поле значения я настроил: netz.tuev-nord.de Сертификат содержит следующее
имя SAN-DNS
: DeviceName.netz.tuev-nord.de Какие точные значения указаны в сертификате устройства (CN, SAN)? Сертификат содержит следующее
имя SAN-DNS
: DeviceName.netz.tuev-nord.de Какие настройки вы определили для профиля аутентификации сертификата? Атрибут сертификата SAN - DNS

[mzarli]

Спасибо за подробное объяснение и за то, что поделились своей записью в блоге — это было очень полезно. Я понимаю вашу точку зрения о необходимости
точного
соответствия
значению
,
указанному в сертификате
, включая полную строку DNS Name=, и использовании регулярного выражения, такого как: ^DNS
Name
=([a-zA-Z0-
9
-]+).netz.tuev-nord.de После соответствующего обновления регулярного выражения я могу подтвердить, что
проверка прошла успешно и предыдущие ошибки исчезли
. Таким образом, с точки зрения сопоставления, регулярное выражение теперь работает как ожидалось. Однако в моем случае остается проблема, заключающаяся в том, что
имя
устройства в Entra ID хранится без FQDN
(например, DeviceName), в то время как SAN сертификата содержит полное FQDN (DeviceName.netz.tuev-nord.de). Несмотря на то, что регулярное выражение успешно сопоставляется, ISE по-прежнему пересылает
полное FQDN
в Entra ID, что приводит к
отсутствию совпадения устройств
на стороне Entra. По результатам моего тестирования, похоже, что текущая реализация Azure / Entra Device Query в ISE использует регулярное выражение только для
проверки/сопоставления
и не поддерживает извлечение или использование группы захвата (например, только имени хоста) в качестве идентификатора устройства. Знаете ли вы, планируется ли или рассматривается ли возможность
использования групп захвата для извлечения только имени устройства
в будущих версиях ISE? Это было бы очень полезно в средах, где идентификаторы сертификатов и соглашения об именовании устройств Entra не полностью совпадают. Еще раз спасибо за ваше время и за информацию, которой вы уже поделились.

[Greg Gibbs]

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

[Cristian Matei]

Здравствуйте, Это может быть вызвано несколькими причинами. Во-первых, можете ли вы внимательно следовать этому руководству по внедрению, а также разделу по устранению неполадок и вставить соответствующие журналы из проведенного исследования? https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/216182-configure-ise-3-0-rest-id-with-azure-act.html Кроме того, убедитесь, что вы соответствуете требованиям, указанным в этом документе, для вашей версии ISE и уровня патча, найдите «
Аутентификация/авторизация устройства, присоединенного к Entra, с использованием EAP-TLS (ISE 3.4p4 или 3.5 и более поздние версии)». [) После этого у нас будет больше релевантных данных для анализа. Спасибо, Кристиан.