Компания Citrix вместе с релизом Citrix ADC 12.0 (сборка 41.16) анонсировала устаревшие компоненты (Deprecated). Эти компоненты, такие как классические политики (Classic Policy), некоторые темы оформления и классический анализ конечного устройства (EPA) по прежнем поддерживаются в релизах 12.1 и 13.0.
Для подготовки окружений к переходу на релиз 13.1, рекомендуется спланировать отказ от устаревших компонентов и заменить их на поддерживаемые возможности. Некоторые аспекты перехода могут показаться достаточно простыми, с другой стороны, такие задачи, как перемещение аутентификации на виртуальный сервер nFactor, могут потребовать значительных усилий в настройке.
Классические политики (Classic Policies).
Политики Citrix ADC используются для управления проверкой данных компонентами. Классические политики оценивают базовые характеристики трафика, в то время как инфраструктура продвинутых политик (Advanced Policy) позволяет анализировать больше данных и настраивать больше операций в правилах. Об отказе от классических политик впервые было объявлено несколько лет назад, я даже писал об этом в статье «Перевод механизма обработки трафика на инфраструктуру расширенных политик (Advanced Policy) в Citrix ADC».
Примечание.
Классические политики для Gateway и AAA продолжат поддерживаться без изменений функционала вплоть до второго квартала 2023-го года.
Для перехода на продвинутые политики существует инструмент Citrix ADC – nspepi, который можно использовать для конвертации команд, выражений и конфигурации. В качестве альтернативы, редактор выражений в графическом интерфейсе Citrix ADC – это отличный путь для ручной переделки классических выражений в продвинутые.
Необходимо отметить, что рекомендуется конвертировать все классические политики в продвинутые, чтобы использовать полностью поддерживаемую конфигурацию. В том числе, это касается таких политик как LDAP, RADIUS, сертификатов (CERT), syslog и политик сессий (session).
Один из способов проверить наличие классических политик, это выполнить поиск классических выражений в запущенной конфигурации nsconfig. Примерами ключевых слов для поиска могут быть «REQ.HTTP» и «ns_true». Обратите внимание, что эти два примера помогут найти большинство, но далеко не все классические политики.
Убедитесь, что продвинутые политики созданы для замены каждой классической и привязаны к виртуальным серверам.
Продвинутые политики аутентификации (Advanced Authentication Policy).
В случае использования Citrix Gateway для проксирования ICA или VPN, политики аутентификации привязываются как обязательная часть настройки. Классические политики аутентификации могут быть привязаны в секцию базовой аутентификации (Basic Authentication) виртуального сервера Citrix Gateway, но продвинутые политики так не работают. Чтобы использовать продвинутые политики аутентификации, необходимо настроить виртуальный сервер аутентификации и привязать его в профиль аутентификации на виртуальном сервере Citrix Gateway.
В сценарии с одним фактором это также просто как создать виртуальный сервер аутентификации и привязать продвинутую политику аутентификации со схемой входа (Login Schema) к серверу. Для сценариев с несколькими факторами, необходимо настроить аутентификацию nFactor. Поддержка nFactor для Citrix Gateway доступна с релиза 11.1, таким образом достаточно много информации о настройке уже существует. Вместе с релизом Citrix ADC 13.0, сборка 36.27, добавлена новая возможность для упрощения настройки nFactor при помощи графического интерфейса – nFactor Visualizer.
Мобильные политики (Citrix Workspace App).
Для сценариев двухфакторной аутентификации LDAP и RADIUS с мобильными устройствами, может возникнуть потребность в некоторых изменениях, которые необходимо внести в политики сессий. Это связано с тем, что при использовании потока nFactor, нужен только один поток для мобильных и не мобильных соединений. При использовании базовой аутентификации потоки разделены.
Ранее, при настройке Citrix Gateway на использование аутентификации RADIUS и LDAP с мобильными устройствами, LDAP настраивался в качестве основной политики для веб-соединений, а для соединений Receiver/Workspace в качестве вторичной политики. На диаграмме ниже представлен пример настройки двухфакторной базовой аутентификации с LDAP и RADIUS.
В такой конфигурации, индекс учётных данных в политиках сессий, указывающих на LDAP, должен был отличаться для веб и мобильных соединений. Для веб-соединений индекс учётных данных должен быть установлен в значение основного (Primary), а для соединений Citrix Workspace в значение вторичного (Secondary). При использовании потока nFactor и продвинутых политик, единый поток может обрабатывать как мобильные, так и не мобильные устройства. Это значит, что LDAP может являться основной политикой для обоих сценариев использования, а политика RADIUS будет вторичной. Если политика сессий Citrix Workspace ранее указывала на вторичный индекс учётных данных, ее необходимо обновить на первичную, для успешной аутентификации мобильных устройств на Citrix Gateway.
Темы оформления.
Вместе с отказом от классических политик, устаревшими также становятся и ряд тем оформления. При использовании оформления по умолчанию (Default), Green Bubble или X1, вы могли видеть предупреждение, указывающее на устаревание данных тем и их недоступность в будущих релизах.
Рекомендуется использовать тему оформления RFWebUI с конфигурацией nFactor и продвинутыми политиками. При использовании одной из устаревших тем с внесёнными изменениями, необходимо учесть, что изменения не перенесутся на RFWebUI. Механизм внесения изменений RFWebUI отличается и потребует перенастройки. Одним из отличий является то, что страница входа хранится в другом расположении (/var/netscaler/logon/LogonPoint/) в отличии от устаревших тем (/netscaler/ns_gui/vpn/). Файлы, которые необходимо настраивать для RfWebUI, также отличаются: index.html, strings.en.json и theme.css.
Дополнительные рекомендации.
При миграции с классических политик на продвинутые можно столкнуться с проблемой привязки продвинутых политик. Это связано с тем, что некоторые компоненты поддерживают использование как продвинутых, так и классических политик, но при этом они не могут использоваться одновременно с одним компонентом.
Это значит, что при использовании нескольких виртуальных серверов Citrix Gateway, к которым привязаны политики сессий, при попытке привязать продвинутые политики сессий к одному виртуальному серверу, будет возвращаться ошибка, если классически политики используются на других виртуальных серверах Citrix Gateway. В первую очередь необходимо отвязать все классические политики сессий на Citrix ADC, прежде чем появится возможность привязывать продвинутые политики.
Рекомендуется использовать анализ конечного устройства (EPA) с nFactor вместо классического анализа (Classic EPA). Это значит, что любая политика пред-аутентификации или пост-аутентификации, которая привязана напрямую к Citrix Gateway, должна быть удалена и заменена конфигурацией с использованием виртуального сервера аутентификации.
Основные выводы.
Клиенты Citrix, заинтересованные в отказе от устаревших компонентов, должны рассмотреть следующие рекомендации:
- Конвертировать все классические политики в продвинутые.
- Выполнить поиск по активной конфигурации (Running), чтобы убедиться, что классические выражения не были пропущены.
- Использовать виртуальный сервер аутентификации для привязки продвинутых политик к виртуальному серверу Citrix Gateway.
- Использовать nFactor Visualizer (новый компонент в Citrix ADC 13.0) для упрощения настройки nFactor.
- Убедиться, что индекс учётных данных в политике сессий соответствует факторам LDAP.
- Переключить старые неподдерживаемые темы на RfWebUI.
- Отвязать все классические политики от компонентов перед привязкой продвинутых политик.
- Настроить nFactor EPA для любых политик пред и пост-аутентификации.
Обратите внимание, что все пункты выше описывают устаревшие компоненты, необходимые для Citrix Gateway. При использовании других компонентов Citrix ADC, также могут потребоваться действия в связи с выводом из эксплуатации устаревших компонентов.
