Безопасность : Платформа Cisco Identity Services Engine

Центральная веб-аутентификация на WLC и примере конфигурации ISE

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ описывает пример конфигурации, который используется для завершения Центральной веб-аутентификации (CWA) на Контроллере беспроводной локальной сети (WLC).

Внесенный Николасом Дарчисом, специалистом службы технической поддержки Cisco.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Сведения, содержащиеся в данном документе, касаются следующих версий программного обеспечения и оборудования:

  • Выпуск ПО платформы Cisco Identity Services Engine 1.2

  •  Выпуск 7.3.102.0 программного обеспечения WLC Cisco

Настройка

Первый метод web-аутентификации является локальной web-аутентификацией. В этом случае WLC перенаправляет трафик HTTP к внутреннему или внешнему серверу, где пользователю предлагают аутентифицироваться. WLC тогда выбирает учетные данные (переданный обратно через HTTP-запрос GET в случае внешнего сервера) и делает Проверку подлинности RADIUS. В случае гостя требуется внешний сервер (такой как платформа Identity Services Engine (ISE) или Гостевой сервер NAC (NGS)), потому что портал предоставляет функции, такие как регистрация устройства и самоинициализация. Поток включает эти шаги:

  1. Пользователь связывается к идентификаторам наборов сервисов (SSID) web-аутентификации.

  2. Пользователь открывает браузер.

  3. WLC перенаправляет к гостевому порталу (такому как ISE или НАНОГРАММЫ), как только введен URL.

  4. Пользователь аутентифицируется на портале.

  5. Гостевые перенаправления портала назад к WLC с учетными данными ввели.

  6. WLC аутентифицирует гостя через RADIUS.

  7. WLC перенаправляет назад к исходному URL.

Этот поток включает несколько перенаправлений. Новый подход должен использовать CWA. Этот метод работает с ISE (версии позже, чем 1.1) и WLC (версии позже, чем 7.2). Поток включает эти шаги:

  1. Пользователь связывается к SSID web-аутентификации, который является фактически open+macfiltering и никакая безопасность уровня 3.

  2. Пользователь открывает браузер.

  3. WLC перенаправляет к гостевому порталу.

  4. Пользователь аутентифицируется на портале.

  5. ISE передает Изменение RADIUS Авторизации (CoA - порт UDP 1700), чтобы указать к контроллеру, что пользователь допустим, и в конечном счете выдвигает атрибуты RADIUS, такие как Список контроля доступа (ACL).

  6. Пользователю предлагают повторить исходный URL.

Используемая настройка:

central-web-auth-1.gif

Настройка WLC

Конфигурация WLC является довольно прямой. Прием используется (то же как на коммутаторах) для получения динамического URL аутентификации из ISE (так как это использует изменение авторизации (CoA), сеанс должен быть создан, и идентификатор сеанса является частью URL). SSID настроен для использования фильтрации по MAC-адресам. ISE настроен для возврата access-accept, даже если MAC-адрес не найден, так, чтобы это передало URL перенаправления за всеми пользователями. 

В дополнение к этому должны быть включены Network Admission Control (NAC) RADIUS и Замена Аутентификации, авторизации и учета (AAA). NAC RADIUS позволяет ISE отправлять запрос CoA, который указывает, что пользователь теперь аутентифицируется и в состоянии обратиться к сети. Это также используется для оценки положения, в этом случае ISE изменяет профиль пользователя на основе результата положения.

Гарантируйте, что сервер RADIUS имеет RFC3576 (CoA), включил, который является по умолчанию.

central-web-auth-02.png

central-web-auth-03.gif

central-web-auth-04.gif

central-web-auth-05.png

central-web-auth-06.gif

Заключительный шаг должен создать ACL перенаправления. На этот ACL ссылаются в access-accept ISE и определяет, какой трафик должен быть перенаправлен (запрещенный ACL) и какой трафик не должен быть перенаправлен (разрешенный ACL). Здесь вы просто предотвращаете от трафика перенаправления к ISE. Вы могли бы хотеть быть более определенными и только предотвратить к/от трафика ISE на порту 8443 (гостевой портал), но все еще перенаправить, если пользователь пытается обратиться к ISE на порту 80/443.

Примечание: Более ранние версии программного обеспечения WLC как 7.2 или 7.3 не потребовали, чтобы вы задали DNS, но более новые версии кода требуют, чтобы вы разрешили трафик DNS на том ACL перенаправления.

central-web-auth-07.png

Конфигурация теперь завершена на WLC.

Конфигурация ISE

Создайте профиль авторизации

На ISE должен быть создан профиль авторизации. Затем политика проверки подлинности и авторизация настроена. WLC должен уже быть настроен как сетевое устройство.

В профиле авторизации введите имя ACL, созданного раньше WLC.

  1. Нажмите Policy, и затем нажмите Policy Elements.

  2. Нажмите Results.

  3. Разверните Авторизацию, и затем нажмите профиль Authorization.

  4. Нажмите кнопку Add для создания нового профиля авторизации для центрального webauth.

  5. В Поле имени введите имя для профиля. Данный пример использует WLC_CWA.

  6. Выберите ACCESS_ACCEPT из выпадающего списка Типа доступа.

  7. Проверьте веб-флажок Redirection и выберите Centralized Web Auth из выпадающего списка.

  8. В поле ACL введите имя ACL на коммутаторе, который определяет трафик, который будет перенаправлен. Данный пример использует cwa_redirect.

  9. Выберите Default из выпадающего списка Перенаправления. (Выберите что-то другое, чем по умолчанию при использовании пользовательского портала кроме по умолчанию.)

central-web-auth-08.png

Создайте опознавательное правило

Гарантируйте, что ISE принимает все проверки подлинности MAC от WLC, и удостоверьтесь, что это будет преследовать аутентификацию, даже если не будет найден пользователь.

В соответствии с меню Policy, нажмите Authentication.

Следующий образ показывает пример того, как настроить правило политики аутентификации. В данном примере правило настроено, что триггеры, когда обнаружен MAB.

  • Введите имя для своего опознавательного правила. Данный пример использует MAB, который уже существует по умолчанию на Версии 1.2 ISE.

  • Выберите плюс (+) значок в Если поле условия.

  • Выберите условие Compound, и затем выберите Wired_MAB OR Wireless_MAB.

  • Нажмите стрелку, расположенную рядом с и... для расширения правила далее.

  • Нажмите + значок в поле Identity Source и выберите Internal endpoints.

  • Выберите Continue из Если пользователь, не найденный выпадающим списком.

central-web-auth-09.png

Создайте политику авторизации

Настройте политику авторизации. Один важный момент для понимания - то, что существует две аутентификации/авторизации:

  • Первое - когда пользователь связывается к SSID и когда профиль центральной веб-аутентификации возвращен (неизвестный MAC-адрес, таким образом, необходимо установить пользователя для перенаправления).

  • Когда пользователь аутентифицируется на веб-портале, второе. Эти соответствия стандартное правило (внутренние пользователи) в этой конфигурации (это может быть настроено для соответствия требованиям). Важно, чтобы часть авторизации не совпадала с профилем центральной веб-аутентификации снова. В противном случае будет петля перенаправления. Сетевой Access:UseCase Равняется Гостевому атрибуту Потока, может использоваться для соответствия с этой второй аутентификацией. Результат похож на это:

central-web-auth-10.png

Примечание: В Выпуске 1.3 ISE, зависящем от типа web-аутентификации, "Гостевой вариант использования" Потока не мог бы больше поражаться. Правило авторизации должно было бы тогда содержать гостевого usergroup как единственное возможное условие.

Выполните эти шаги для создания правил авторизации как показано в предыдущих образах:

  1. Создайте новое правило и введите имя. Данный пример использует Гостевое Перенаправление.

  2. Нажмите плюс (+) значок в поле условия и примите решение создать новое условие.

  3. Разверните выпадающий список Выражения.

  4. Выберите Network Access и разверните его.

  5. Нажмите AuthenticationStatus и выберите оператора Equals.

  6. Выберите UnknownUser в правом поле.

  7. На странице General Authorization выберите WLC_CWA (Authorization Profile) в поле направо от слова тогда.

    Этот шаг позволяет ISE продолжаться даже при том, что не известен пользователь (или MAC-адрес).

    Неизвестным пользователям теперь предоставляют Страницу входа. Однако, как только они вводят свои учетные данные, который является аутентификацией, которая успешно выполняется, если удостоверения клиента допустимы несмотря на то, что вы настроили на аутентификации/политике авторизации. С Версий 1.1 и 1.2 ISE портала аутентификации не придерживаются аутентификации/правил авторизации и успешно выполняются, если допустимый. Таким образом нет никакой потребности создать правило, что разрешения обращаются после успешного портала входа в систему.

  8. Нажмите кнопку Actions, расположенную в конце Гостевого правила Перенаправления, и примите решение вставить новое правило перед ним.

    Примечание: Очень важно, чтобы это новое правило появилось перед Гостевым правилом Перенаправления.



  9. Введите имя для нового правила. Данный пример использует Гостевую Аутентификацию Портала.

  10. В поле условия нажмите плюс (+) значок и примите решение создать новое условие.

  11. Выберите Network Access и нажмите UseCase.

  12. Выберите Equals в качестве оператора.

  13. Выберите GuestFlow в качестве правильного операнда. (См. примечание, перечисленное перед этими шагами, в отношении Выпуска 1.3 ISE на этом условии.)

  14. На странице авторизации нажмите плюс (+) значок (расположенный рядом с тогда) для выбора результата для правила.

    Можно выбрать опцию Permit Access или создать пользовательский профиль для возврата VLAN или атрибутов, которые вы любите. Обратите внимание на то, что поверх того, Если GuestFlow, можно добавить большие условия для возврата различных профилей authz на основе группы пользователей. Как упомянуто в Шаге 7, это Гостевое правило Аутентификации Портала совпадает на вторую Аутентификацию с использованием MAC-адреса, инициируемую после успешного портала входа в систему и после того, как ISE передал CoA, чтобы повторно аутентифицировать клиента. Различие для этой второй аутентификации - то, что, вместо того, чтобы прибыть в ISE только с ее MAC-адресом, ISE помнит имя пользователя, данное в портале. Можно заставить это правило авторизации принять во внимание, что учетные данные ввели несколько миллисекунд прежде в гостевой портал.

Примечание: Если профилирование Функций включено, оконечные точки могли быть вставлены автоматически в базе данных, в этом случае условие неизвестного пользователя не совпадает. В этом случае лучше совпасть с Wireless_MAB (Встроенное условие) запросы. При использовании Проверки подлинности MAC на контроллере можно или использовать группы оконечной точки для более определенной авторизации или добавить условие, которое совпадает с гостевым SSID.

central-web-auth-10a.png

Включите обновление IP (Необязательно)

При присвоении VLAN заключительный шаг для клиентского компьютера для возобновления его IP-адреса. Этот шаг достигнут гостевым порталом для Windows - клиентов. Если вы сделали "not set", VLAN для 2-го AUTH управляет ранее, можно пропустить этот шаг.

При присвоении VLAN выполните эти шаги для включения обновления IP:

  1. Нажмите Administration, и затем нажмите Guest Management.

  2. Нажмите Settings.

  3. Разверните Гостя, и затем разверните Мультипортала Конфигурацию.

  4. Нажмите DefaultGuestPortal или название пользовательского портала, который вы создали.

  5. Нажмите  флажок VLAN DHCP Release.

    Примечание: Эта опция работает только для Windows - клиентов.

Сценарий привязки внешний

Эта настройка может также работать с функцией автопривязки WLC. Единственная выгода - то, что, так как этим методом web-аутентификации является Уровень 2, необходимо знать, что это будет внешний WLC, который делает весь RADIUS, работают. Только внешний WLC связывается с ISE, и ACL перенаправления должен присутствовать также на внешнем WLC.

Точно так же, как в других сценариях, внешний WLC быстро показывает клиенту, чтобы быть в состоянии ВЫПОЛНЕНИЯ, которое не совсем истинно. Это просто означает, что трафик передается привязке оттуда. Состояние реального клиента может быть замечено на привязке, где это должно отобразить CENTRAL_WEBAUTH_REQD.

Примечание: Настройка привязки внешняя с Центральной веб-аутентификацией (CWA) только работает в Версиях 7.3 или позже.

Примечание: Из-за идентификатора ошибки Cisco CSCuo56780 (даже в версиях, которые включают, исправляет), вы не можете выполнить учет и на привязке и на внешний, потому что это заставляет профилирование становиться неточным из-за потенциального отсутствия привязки IP К MAC. Это также создает много проблем с идентификатором сеанса для гостевых порталов. Если вы желаете настроить учет, то настройте его на внешнем контроллере.

Проверка

Как только пользователь привязан к SSID, авторизация отображена на странице ISE.

Клиентские подробные данные в WLC показывают, что применены URL перенаправления и ACL.

central-web-auth-11.png

Теперь, когда любой адрес открыт на клиенте, браузер перенаправлен к ISE. Гарантируйте, что Система доменных имен (DNS) установлена правильно.

central-web-auth-12.png

Доступ к сети предоставляют после того, как пользователь принимает политику.

central-web-auth-13.png

central-web-auth-14.png

Как показано в ISE в качестве примера, аутентификации, изменение авторизации и примененный профиль являются permitAccess.

central-web-auth-15.gif

Предыдущий снимок экрана взят от Версии 1.1.x ISE, где каждый одиночный опознавательный шаг показывает ясно.

Следующий снимок экрана взят от Версии 1.2 ISE, где ISE суммирует несколько аутентификаций, выполненных тем же клиентом в одной линии. Несмотря на то, что более практичный в реальной жизни, снимок экрана Версии 1.1.x показывает более ясно, что точно происходит ради ясности в данном примере.

central-web-auth-16.png

На контроллере, Менеджер Политики состояние и изменения состояния NAC RADIUS от POSTURE_REQD для ВЫПОЛНЕНИЯ.

Примечание: В Выпуске 7.3 или позже, состояние больше не называют POSTURE_REQD, но теперь называют CENTRAL_WEBAUTH_REQD.

Устранение неполадок

Выполните эти шаги, чтобы устранить неполадки или изолировать проблему CWA:

  1. Введите команду <mac address of client> клиента отладки в контроллер и монитор, чтобы определить, достигает ли клиент состояния CENTRAL_WEBAUTH_REQD. Типичная проблема наблюдается, когда ISE возвращает ACL перенаправления, который не существует (или не является должным образом входным) на WLC. Если это верно, тогда клиент является deauthenticated, как только состояние CENTRAL_WEBAUTH_REQD достигнуто, который заставляет процесс начинаться снова.

  2. Если корректное состояние клиента может быть достигнуто, затем перейти, чтобы контролировать> клиенты на веб-GUI WLC и проверить, что корректный ACL перенаправления и URL применены для клиента.

  3. Проверьте, что используется корректный DNS. У клиента должна быть способность решить интернет-веб-сайты и имя хоста ISE. Можно проверить это через nslookup.

  4. Проверьте, что все шаги аутентификаций происходят на ISE:

    • Проверка подлинности MAC должна произойти сначала, к которому возвращены атрибуты CWA.

    • Портала login authentication происходит.

    • Динамическая авторизация происходит.

    • Заключительная аутентификация является проверкой подлинности MAC, которая показывает портала имя пользователя на ISE, к которому заключительные результаты авторизации возвращены (такие как заключительная VLAN и ACL).

Специальные вопросы для связывания сценариев

Рассмотрите эти идентификаторы ошибок Cisco, которые ограничивают эффективность процесса CWA в сценарии мобильности (особенно, когда учет настроен):

  • CSCuo56780 - Уязвимость типа отказ в обслуживании сервиса RADIUS ISE

  • CSCul83594 - Если сеть открыта, идентификатор сеанса "not synchronized" через мобильность


Document ID: 115732