миграция FQDN, повторное присоединение к AD, сертификаты с подстановочными знаками для конфигурации без перенаправления

[voidray87]

Всем привет! Я планирую сложную миграцию кластера Cisco ISE 3.4 (2 узла, PAN/PSN) и мне нужна «золотая» последовательность шагов, чтобы избежать повреждения базы данных и проблем с обнаружением SSL. Текущая ситуация: FQDN узлов:
srv-ise-0x.user.zvit.local (присоединен к AD).
Режим Posture:
без перенаправления (настроен через профиль Secure Client 5.10).
Сеть:
FTD управляется FMC 7.4 (без перенаправления L7 HTTP). Цели: Изменить имена хостов/FQDN узлов ISE на публичный домен (например, srv-ise-0x.2zvit.xyz).
Повторно присоединить эти узлы к внутреннему Active Directory (user.zvit.local) с использованием новых FQDN.
Использовать другой, выделенный FQDN для портала Posture Portal (например, ise-posture.2zvit.xyz), защищенный
сертификатом
Wildcard
(.2zvit.xyz). Мне нужно разъяснение по следующим техническим вопросам: Вопрос 1: Логика «идентичности» в Posture без перенаправления
В настоящее время, даже когда внутренний корневой центр сертификации добавлен в «Доверенные корневые центры сертификации» в Windows, модуль Posture не может найти сервер политик, если я использую CNAME или URL, отличный от того, который указан в CN сертификата. Почему модуль Posture прерывает соединение, даже если цепочка сертификатов является 100% доверенной?
Процесс обнаружения Posture требует строгого соответствия между тегом DiscoveryHost XML и SAN/CN сертификата, игнорируя способность хранилища доверенных сертификатов ОС проверять цепочку? Вопрос 2: Сертификат с подстановочным знаком для портала Posture Могу ли я использовать сертификат с подстановочным знаком (.2zvit.xyz) для
роли
портала
на порту 8443?
Примет ли модуль Secure Client 5.10 Posture подстановку подстановочного знака для DiscoveryHost (например, если хост — ise-posture.2zvit.xyz, а сертификат — *.2zvit.xyz)? В некоторых документах указано, что для обнаружения SWISS/Posture требуется явное указание полного доменного имени (FQDN) в поле SAN. Вопрос 3: Безопасное изменение FQDN и последовательность повторного присоединения к AD
Моя предыдущая попытка изменить имя хоста привела к состоянию «7-часовая инициализация» (зависание базы данных). Какова правильная процедура изменения FQDN и повторного присоединения к внутреннему AD? Правильна ли следующая последовательность действий:
отмена регистрации узла -> изменение имени хоста -> генерация нового самоподписанного/административного сертификата -> присоединение к AD -> повторная регистрация в кластере
?
Как следует обрабатывать имя службы (SPN) в AD, когда полное доменное имя ISE (.xyz) отличается от домена AD (.local)? Вопрос 4: URL портала и имя хоста системы
Если я использую ise-posture.2zvit.xyz в качестве URL обнаружения, но сам узел ISE — srv-ise-01.2zvit.xyz, как следует настроить сертификат портала? Должен ли сертификат роли «Портал» обязательно включать как FQDN узла, так и FQDN портала в поле SAN, чтобы работала функция Redirectionless Posture? Можно ли использовать сертификат с подстановочным знаком для описанных целей (портал администрирования и портал Posture, но с разными FQDN)? Буду признателен за любые комментарии, особенно касающиеся строгости проверки SSL Secure Client по сравнению со стандартным веб-браузером.

[Cristian Matei]

Привет, @voidray87
Во-первых, убедитесь, что у вас есть резервная копия; во-вторых, сначала выполните все изменения на одном узле, убедитесь, что он функционирует не только на уровне службы, но и может обслуживать все типы клиентов/запрашивающих устройств, которые есть в вашей сети, прежде чем переходить ко второму узлу. Что касается
вопроса 3
, я бы сказал, что вы на правильном пути, однако настоятельно рекомендую использовать специальную команду CLI
reset-config
для изменения имени хоста, а не вручную, после чего в любом случае выполнить перезагрузку (не перезапуск приложения ISE, а чистую перезагрузку): [) На все остальные вопросы, связанные с сертификатом с подстановочными знаками и требованиями к его работе, простой ответ — да, при условии соблюдения некоторых требований. Нет смысла кратко повторять это здесь, поскольку все прекрасно описано в следующих документах. Рекомендую прочитать их все и понять, чтобы было ясно, как нужно действовать: https://www.cisco.com/c/en/us/support/docs/security/policy-access-management/220394-implementing-ise-redirectionless-posture.html https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-22/210523-ISE-posture-style-comparison-for-pre-and.html#anc7 [) Удачи, Кристиан.

[PSM]

@voidray87
Я не проводил точно такую же миграцию, но, основываясь на своем опыте, я хотел бы добавить свои замечания. 1. Да, вы должны использовать оба FQDN в поле SAN. Это требование для многих служб, чтобы доверять сертификатам и иметь явные FQDN в поле SAN. 2. Опять же, я советую использовать оба FQDN в поле SAN. 3. Мы делали это несколько раз и отсоединялись от ISE, а затем убеждались, что объект удален из контроллера домена, прежде чем присоединяться обратно. 4. Использование обоих FQDN в поле SAN решит эту проблему. Вы можете указать имя хоста системы в поле CN, а имя хоста системы и URL порта — в поле SAN. Я все же рекомендую вам дождаться совета от других экспертов.

[voidray87]

@Cristian Matei
, спасибо за ссылки, однако:
сброс
конфигурации
приведет к аннулированию лицензии PLR? Для нас это все равно останется проблемой...

[Cristian Matei]

Привет, @voidray87
Сброс настроек не аннулирует лицензию. Удачи, Кристиан.

[voidray87]

Здравствуйте, спасибо, Кристиан, проблема решена. Мы изменили полные доменные имена с помощью reset-config, обновили сертификаты и повторно присоединились к домену. Режимы без перенаправления работают как ожидалось.