аутентификация CIsco ISE 802.1x EAP-TLS с Entra ID

[cuiL]

В существующей среде нашего клиента все ПК подключаются к Entra ID, и на месте нет никакой инфраструктуры. Сейчас они хотели бы внедрить новую сеть Wi-Fi с помощью подобных решений, но для нас это в новинку, и у нас мало опыта в этой области. Поэтому я хотел бы спросить в этом сообществе, есть ли у кого-нибудь опыт внедрения этого решения в производстве. Есть ли какие-либо проблемы, связанные с этим, или это решение является хорошей идеей?

[Greg Gibbs]

Вы включили и настроили параметры запроса устройства в соответствии с руководством администратора? https://www.cisco.com/c/en/us/td/docs/security/ise/3-5/admin_guide/b_ise_admin_3_5/b_ISE_admin_asset_visibility.html#task_hbc_rwl_qtb

[MaErre21325]

Да, я прочитал ваше руководство, теперь все работает.
Спасибо, как всегда, за ваши советы!

[Greg Gibbs]

В настоящее время ISE не может выполнять авторизацию устройств по Entra ID. Единственным вариантом является аутентификация на основе доверенного сертификата и авторизация на основе значений в сертификате. См.
https://cs.co/ise-entraid

[paulwelchh]

Спасибо, Грег, это полезно. Просто для уточнения: если мы будем использовать EAP TLS и полагаться только на аутентификацию и авторизацию на основе сертификатов, поскольку поиск устройств через Entra ID в настоящее время невозможен, означает ли это, что все решения по политикам в ISE должны будут основываться исключительно на атрибутах сертификатов, таких как SAN или OU? Кроме того, кто-нибудь пробовал интегрировать сторонние решения для соединения контекста устройств Entra ID с политиками ISE, или это по-прежнему в основном ручная работа? Буду благодарен за любые комментарии от тех, кто внедрял что-то подобное.

[Greg Gibbs]

«
Поскольку в настоящее время поиск устройств через Entra ID невозможен, означает ли это, что все решения по политикам в ISE должны основываться исключительно на атрибутах сертификатов, таких как SAN или OU?» Да. Если вам необходимо обеспечить дифференцированные уровни авторизации между устройствами, они должны иметь разные значения сертификатов, которые ISE может сопоставить. В ISE 3.5 (в настоящее время в открытой бета-версии) будет добавлено улучшение для авторизации устройств по Entra ID, поэтому более подробная информация об этом улучшении будет предоставлена, когда оно будет доступно.

[MSJ1]

Здравствуйте
[, @Greg Gibbs] Теперь, когда версия 3.5 стала доступна для общественности, партнеры начали изучать ISE 802.1x для компьютеров, подключенных к Entra ID. Мой вопрос касается следующего заявления, упомянутого в примечаниях к выпуску 3.5 1. https://www.cisco.com/c/en/us/td/docs/security/ise/3-5/release_notes/cisco-ise-release-notes-35.html «
Во время аутентификации Cisco ISE оценивает сертификат, представленный пользователем или устройством, без прямого доступа к Microsoft Entra ID». Какой сертификат будет представлен пользователем/устройством? Поскольку ноутбуки присоединены к Entra ID, они не присоединены к домену, так как PKI не может генерировать сертификат пользователя или устройства для компьютера, не присоединенного к домену. Или я что-то упустил?

[Greg Gibbs]

На ПК с Windows по-прежнему существуют отдельные состояния «Пользователь» и «Компьютер» и отдельные хранилища сертификатов для каждого из них. Если упрощающий запрос настроен на «Аутентификацию пользователя или компьютера», он представит сертификат, соответствующий состоянию. Это описано в моем блоге, упомянутом ранее. Я также обновил этот блог, добавив пример использования авторизации устройств, доступный в ISE 3.5 —
https://cs.co/ise-entraid#DeviceQuery

[MaErre21325]

Привет
[, @Greg Gibbs] Я перешел по
ссылке
, которую ты опубликовал, уже обновился до версии 3.5, но в политике авторизации я не вижу
Device
·ExternalGroups.
Вот скриншот доступных вариантов: ![MaErre21325_0-1759926880739.png] Как я могу получить атрибут устройства из списка? Спасибо С уважением

[MSJ1]

@Грег Гиббс См. следующий URL-адрес и информацию о лицензии — какой тип лицензии нам понадобится, если мы хотим использовать аутентификацию на основе сертификата устройства Entra ID? https://www.cisco.com/c/en/us/td/docs/security/ise/3-5/admin_guide/b_ise_admin_3_5/b_ISE_admin_asset_visibility.html#task_eyb_rz1_gnb «На вкладке
«Атрибуты устройства
» нажмите
«Добавить
». Эти атрибуты отображаются в зависимости от
развернутых лицензий
. Установите флажки рядом с атрибутами устройства, для которых вы хотите получить значения из Entra ID».

[Greg Gibbs]

Это задокументировано в руководстве по лицензированию -
https://www.cisco.com/c/en/us/products/collateral/security/identity-services-engine/ise-licensing-guide-og.html#35ISELicenserequirementsforDisplayingEntraIDDeviceAttributesintheGUI

[MSJ1]

@Greg Gibbs
При интеграции REST ID Store с ISE есть ли возможность использовать сертификат в качестве аутентификации вместо «секретного ключа клиента»? В разделе «Внешние источники идентификации» ISE для REST я не вижу сертификата в качестве опции вместо поля «Секретный ключ клиента». Также, для интеграции REST ID с Azure из ISE, каковы требования к правилам брандмауэра?

[Greg Gibbs]

Нет. Документированный метод с использованием секретных ключей является единственным поддерживаемым методом интеграции. Необходимые URL-адреса указаны в руководстве по установке: https://www.cisco.com/c/en/us/td/docs/security/ise/3-4/install_guide/b_ise_installationGuide34/b_ise_InstallationGuide_chapter_7.html#required-internet-urls

[MSJ1]

@Greg Gibbs
Видите ли вы какие-либо риски для безопасности, поскольку речь идет о секретном ключе клиента? Можете ли вы поделиться информацией о том, будет ли в следующей версии добавлена возможность привязки на основе сертификата вместо секретного ключа клиента?

[Greg Gibbs]

Секрет используется для запроса токена носителя из Graph API, и этот токен носителя используется для последующих вызовов API до истечения его срока действия. Это обычное поведение для многих операций API. Вы можете изучить все «за» и «против», но в настоящее время это то, что поддерживается. Дорожная карта не обсуждается на публичных форумах, таких как этот.