Беспроводные сети / Мобильные решения : Безопасность беспроводных сетей

Веб-идентификация на диспетчере WLAN

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


Содержание


Введение

Этот документ объясняет процессы для Веб-Идентификации на Радио диспетчере LAN (WLC).

Примечание: внесенный Николасом Дарчисом, Cisco инженер TAC.

Предпосылки

Требования

Cisco рекомендует иметь элементарные знания конфигурации WLC.

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

Информация в этом документе основана на всех моделях аппаратных средств WLC.

Информация в этом документе была создана из устройств в определенной окружающей среде лаборатории. Все устройства, используемые в этом документе, начали с очищенного (неплатеж) конфигурацию. Если ваша сеть жива, удостоверьтесь, что вы понимаете потенциальное воздействие любой команды.

Соглашения

Направьте в Cisco Технические Соглашения Подсказок для получения дополнительной информации о соглашениях документа.

Веб-идентификация внутренние процессы

Веб-позиция идентификации механизма безопасности

Веб-идентификацией (WebAuth) является Слой 3 безопасности. Это допускает легкую в использовании безопасность, которая работает над любой станцией, которая управляет браузером. Это может также быть объединено с любой безопасностью предобщего ключа (PSK) (Слой 2 политики безопасности). Хотя комбинация WebAuth и PSK уменьшает легкую в использовании часть значительно и часто не используется, это все еще имеет преимущество для шифровки движения клиента. WebAuth является методом идентификации без шифрования.

WebAuth не может формироваться с 802.1x/RADIUS (Отдаленные Диски Идентификации - В Пользовательском Обслуживании), пока Выпуск 7.4 программного обеспечения WLC не установлен, где это может формироваться в то же время. Однако знайте, что клиенты должны пройти и dot1x и веб-идентификацию. Это не предназначено для гостя, но для добавления веб-портала для сотрудников (который использует 802.1x). Нет единого сервисного идентификатора набора (SSID) для dot1x для сотрудников или веб-портала для гостей.

Как работает WebAuth

802.11 процесса идентификации открыты, таким образом, можно подтвердить подлинность и связаться без любых проблем. После этого вы связаны, но не в состоянии пробега WLC. С 802.11, вы сохранены в WEBAUTH_REQD, где вы не можете получить доступ ни к какому сетевому ресурсу (никакой звон, и так далее). Необходимо получить IP-адрес DHCP с адресом сервера DNS.

Необходимо напечатать действительный URL в браузере. Клиент решает URL через протокол DNS. Клиент тогда отправляет его запрос HTTP к IP-адресу веб-сайта. Точки пересечения WLC, которые просят и возвращают webauth страницу логина, которая высмеивает IP-адрес веб-сайта. В случае внешнего WebAuth WLC отвечает с ответом HTTP, который включает ваш IP-адрес веб-сайта и заявляет, что переместилась страница. Страница была перемещена во внешний веб-сервер, используемый WLC. Когда вы заверены, вы получаете доступ ко всем сетевым ресурсам и перенаправлены к URL, который первоначально требуют, по умолчанию (если принудительное перенаправление не формировалось на WLC). Таким образом, WLC позволяет клиенту решать DNS и получать IP-адрес автоматически в государстве WEBAUTH_REQD.

Наконечник: Если вы хотите, чтобы WLC наблюдал другой порт вместо порта 80, можно использовать config сеть web-auth-port <число порта> для создания перенаправления на этом порту также. Примером является веб-интерфейс Сервера управления доступом (ACS), который находится на порту 2002 или другие подобные заявления.

Как заставить внутренний (местный) WebAuth работать с внутренней страницей

Если необходимо формировать WLAN с эксплуатационным динамическим интерфейсом, клиенты должны также получить IP-адрес сервера DNS через DHCP. Перед урегулированием любого webauth необходимо проверить тот WLAN работы должным образом, что можно решить запросы DNS (nslookup), и что можно просмотреть веб-страницы. Затем можно установить веб-идентификацию как Слой 3 механизма безопасности. Можно создать пользователей в местной базе данных или на внешнем сервере RADIUS, например. Отошлите к Радио диспетчера LAN ВЕБА ОТЭНТИКЭЙШНА КОНФИГУРЭЙШНА ЭКСЭМПЛА документ.

Как формировать таможенный местный WebAuth с таможенной страницей

Обычай webauth может формироваться с redirectUrl от счета безопасности. Это вызывает перенаправление к определенной веб-странице, в которую вы входите. Когда пользователь заверен, это отвергает оригинальный URL клиент, которого требуют, и показывает страницу, для которой было назначено перенаправление.

Таможенная особенность позволяет вам использовать таможенную страницу HTML вместо страницы логина по умолчанию. Загрузите свой HTML и связку файлов изображения диспетчеру. На странице закачки ищите связку webauth в формате смолы. Обычно, PicoZip создает смолы, которые работают совместимо с WLC. Для примера группы WebAuth отошлите к странице программного обеспечения Загрузки для Беспроводного Контроллера Группы WebAuth. Обязательно выберите соответствующий выпуск для вашего WLC. Хорошая рекомендация состоит в том, чтобы настроить связку, которая существует; не создавайте связку с нуля.

Существуют некоторые ограничения с обычаем webauth, которые меняются в зависимости от версий и ошибок. Вещи наблюдать за включают:

  • .tar размер файла (не больше, чем 1 МБ)

  • число файлов в .tar

  • длина имени файла файлов (должны быть не больше, чем 30 знаков),

Если ваш потребительский пакет не работает, попробуйте простым таможенным пакетом. Тогда добавьте файлы и сложность по одному для достижения пакета, который клиент попытался использовать. Это должно помочь вам определить проблему. Для примера о том, как формировать таможенную страницу, обратитесь к Созданию Настроенной Веб-Страницы Логина Идентификации, секции в пределах Радио Cisco диспетчер LAN КОНФИГУРЭЙШН Гид, Выпуск 7.0.

Отвергните глобальный метод конфигурации

Для каждого WLAN вы формируете с отверганием глобальной команды config и устанавливаете тип WebAuth для каждого WLAN. Это означает, что у вас могут быть внутреннее / неплатеж WebAuth с внутренним обычаем / неплатеж WebAuth для другого WLAN. Это также позволяет вам формировать различные таможенные страницы для каждого WLAN. Необходимо объединить все страницы в той же самой связке и загрузить их на WLC. Затем можно установить таможенную страницу с отверганием глобальной команды config на каждом WLAN и избранный, какой файл является страницей логина от всех файлов в пределах связки. Можно выбрать различную страницу логина в связке для каждого WLAN.

Проблема переназначения

Существует переменная в пределах связки HTML, которая позволяет переназначение. Не помещайте свое принудительное переназначение URL там. Для любых проблем переназначения в таможенном WebAuth Cisco рекомендует проверить связку. При входе в перенаправление URL с + = в WLC GUI это могло бы переписать или добавить к URL, определенному в связке. Например, в WLC GUI, redirectURL область установлена в www.cisco.com; однако, в связке это показывает: redirectURL + = 'www.google.com'. + = перенаправляет пользователей к www.cisco.comwww.google.com, который является недействительным URL.

Как заставить внешнюю (местную) веб-идентификацию работать с внешней страницей

Как уже кратко объяснено, использование внешнего сервера WebAuth является просто внешним хранилищем для страницы логина. Пользовательские верительные грамоты все еще заверены WLC. Внешний веб-сервер только позволяет вам использовать специальную или различную страницу логина. Вот шаги, выполненные для внешнего WebAuth:

  1. Клиент (конечный пользователь) открывает веб-браузер и входит в URL.

  2. Если клиент не заверен, и внешняя веб-идентификация используется, WLC перенаправляет пользователя к внешнему веб-серверу URL. Другими словами, WLC посылает перенаправление HTTP клиенту с высмеянным IP-адресом веб-сайта и указывает на внешний IP-адрес сервера. Внешний веб-URL логина идентификации приложена с параметрами, такими как AP_Mac_Address, client_url (www.website.com) и action_URL, что клиент должен связаться с веб-сервером выключателя.

  3. Внешний веб-сервер URL посылает пользователя в страницу логина. Тогда пользователь может использовать список контроля доступа (ACL) перед идентификацией для доступа к серверу. ACL только необходим для Радио Диспетчер LAN 2000 рядов.

  4. Страница логина берет пользовательский мандатный вход и передает запрос обратно в action_URL, такой как http://1.1.1.1/login.html, веб-сервера WLC. Это обеспечено, поскольку входной параметр клиенту перенаправляет URL, где 1.1.1.1 действительный интерфейсный адрес на выключателе.

  5. Веб-сервер WLC представляет имя пользователя и пароль для идентификации.

  6. WLC начинает запрос сервера RADIUS или использует местную базу данных по WLC, и затем подтверждает подлинность пользователя.

  7. Если идентификация успешна, веб-сервер WLC или вперед пользователь к формируемому перенаправлению URL или к URL, клиент вошел.

  8. Если идентификация терпит неудачу, то веб-сервер WLC перенаправляет пользователя назад к потребительскому логину URL.

Примечание: Если точки доступа (APs) находятся в способе FlexConnect, preauth ACL не важен. Согните ACLs, может использоваться для разрешения доступа к веб-серверу для клиентов, которые не были заверены. Отошлите к Внешней Веб-Идентификации с Радио диспетчеров LAN CONFIGURATION EXAMPLE.

Веб-передача

Это - изменение внутренней веб-идентификации. Это показывает страницу с предупреждением или аварийным заявлением, но не вызывает для верительных грамот. Пользователь должен щелкнуть хорошо. Можно позволить почтовый вход, и пользователь может ввести их адрес электронной почты, который становится их именем пользователя. Когда пользователь связан, проверьте, что ваши активные клиенты перечисляют; тот пользователь перечислен с адресом электронной почты, который они ввели как имя пользователя. Для получения дополнительной информации отошлите к Радио диспетчера LAN ВЕБА ПЭССТРО КОНФИГУРЭЙШНА ЭКСЭМПЛА.

Условное веб-перенаправление

Если вы позволяете условное веб-перенаправление, пользователь условно перенаправлен к особой веб-странице после 802.1x, идентификация успешно закончила. Можно определить страницу перенаправления и условия, при которых перенаправление происходит на сервере RADIUS. Условия могут включать пароль пользователя, когда он достигает срока годности или когда пользователь должен оплатить счет для длительного использования/доступа. Если сервер RADIUS возвращает перенаправление URL AV-пары Cisco, то пользователь перенаправлен к указанному URL, когда они открывают браузер. Если сервер также возвращает AV-пару Cisco url-redirect-acl, то указанный ACL установлен как предварительная идентификация ACL для этого клиента. Клиента не считают полностью уполномоченным в этом пункте и может только передать движение, позволенное предварительной идентификацией ACL. После того, как клиент заканчивает особую операцию в указанном URL (например, изменение пароля или оплата счета), тогда клиент должен повторно подтвердить подлинность. Когда сервер RADIUS не возвращает перенаправление URL, клиента считают полностью уполномоченным и разрешенным передать движение.

Примечание: условная веб-особенность перенаправления доступна только для WLANs, которые формируются для 802.1x или Слой WPA+WPA2 2 безопасности.

После формирования сервера RADIUS можно тогда формировать условное веб-перенаправление на диспетчере с диспетчером GUI или CLI. Обратитесь к этим постепенным гидам: Используя GUI для Формирования Веб-Перенаправления и Используя CLI для Формирования Веб-Перенаправления.

Веб-перенаправление страницы всплеска

Если вы позволяете веб-перенаправление страницы всплеска, пользователь перенаправлен к особой веб-странице после 802.1x, идентификация закончила успешно. После перенаправления у пользователя есть полный доступ к сети. Можно определить страницу перенаправления на сервере RADIUS. Если сервер RADIUS возвращает перенаправление URL AV-пары Cisco, то пользователь перенаправлен к указанному URL, когда они открывают браузер. Даже если сервер RADIUS не возвращает перенаправление URL, клиент считается полностью уполномоченным в этом пункте и разрешен передать движение.

Примечание: веб-особенность перенаправления страницы всплеска доступна только для WLANs, которые формируются для 802.1x или Слой WPA+WPA2 2 безопасности.

После формирования сервера RADIUS можно тогда формировать веб-перенаправление страницы всплеска на диспетчере с диспетчером GUI или CLI.

WebAuth на отказе фильтра MAC

Это требует, чтобы вы формировали фильтры MAC на Слое 2 меню безопасности. Если пользователи успешно утверждены с их Мак адресами, то они идут непосредственно в состояние пробега. Если они не, то они идут в государство WEBAUTH_REQD, и нормальная веб-идентификация происходит.

Центральная веб-идентификация

Центральная Веб-Идентификация обращается к сценарию, где WLC больше не принимает услуг. Различие проживает в факте, что клиента непосредственно посылают в веб-портал ИСЕ и не проходит 1.1.1.1 на WLC. Страница логина и весь портал воплощены.

Центральная Веб-Идентификация имеет место, когда вам позволили Сетевой контроль приема (NAC) RADIUS в расширенных настройках WLAN, и фильтры MAC позволили.

Полное понятие - то, что WLC посылает идентификацию RADIUS (обычно для фильтра MAC) в ИСЕ, который отвечает с парой значения атрибута (AV) URL перенаправления. Пользователь тогда помещен в государство POSTURE_REQD, пока ИСЕ не дает разрешение с запросом Изменения разрешения (CoA). Тот же самый сценарий происходит в Положении или Центральном WebAuth. Центральный WebAuth не совместим с WPA-Enterprise/802.1x, потому что портал гостя не может возвратиться, сеансовые ключи для шифрования как он делает с Расширяемым протоколом аутентификации (EAP).

Внешняя пользовательская идентификация (RADIUS)

Это только действительно для Местного WebAuth, когда WLC обращается с верительными грамотами, или когда позволен Слой 3 веб-политики. Можно тогда или подтвердить подлинность пользователей в местном масштабе на WLC или внешне через RADIUS.

Существует заказ, в котором WLC проверяет на верительные грамоты пользователя.

  1. В любом случае это сначала смотрит в его собственной базе данных.

  2. Если это не находит пользователей там, это идет в сервер RADIUS, формируемый в госте WLAN (если существует формируемый тот).

  3. Это тогда регистрируется в глобальном списке сервера RADIUS против серверов RADIUS, где проверен сетевой пользователь.

Этот третий пункт очень важен и отвечает на вопрос многих, кто не формирует RADIUS для этого WLAN, но замечает, что это все еще проверяет против RADIUS, когда пользователь не найден на диспетчере. Это вызвано тем, что сетевой пользователь проверен против ваших серверов RADIUS в глобальном списке.

WLC может подтвердить подлинность пользователей к серверу RADIUS с Протоколом аутентификации пароля (PAP), Протоколом аутентификации рукопожатия проблемы (CHAP) или EAP-MD5 (сообщение Digest5). Это - глобальный параметр и конфигурируемо от GUI или CLI:

От GUI: проведите Диспетчеру> Сеть Идентификация RADIUS

От CLI: войдите в config таможенную сеть RADIUSauth <pap|chap|md5chap>

Примечание: сервер гостя NAC только использует PAP.

Как установить Зашитого Гостя WLAN

Легко формировать и очень близко к беспроводной конфигурации гостя. Можно формировать его с одним или двумя диспетчерами (только если каждый - автоякорь).

Выберите VLAN в качестве VLAN, в который вы размещаете телеграфированных пользователей-гостей, например, на VLAN 50. Когда зашитый гость будет хотеть получить доступ к Интернету, включите ноутбук к порту на выключателе, формируемом для VLAN 50. Этот VLAN 50 должен быть позволен и существовать на пути через порт ствола WLC. В случае двух WLCs (один якорь и один иностранный), этот зашитый гость VLAN должен привести к иностранному WLC (названный WLC1) а не к якорю. WLC1 тогда заботится о туннелировании движение к DMZ WLC (якорь, названный WLC2), который выпускает торговлю разбитой сетью.

Вот пять шагов для формирования телеграфированного доступа гостя:

  1. Формируйте динамический интерфейс (VLAN) для зашитого доступа пользователя-гостя.

    На WLC1 создайте динамический интерфейс VLAN50. На интерфейсной странице конфигурации проверьте Гостя коробка LAN. Затем исчезают области, такие как IP-адрес и ворота. Единственная вещь, которую ваш WLC должен знать об этом интерфейсе, состоит в том, что движение разбито от VLAN 50. Эти клиенты являются телеграфированными гостями.

  2. Создайте зашитый LAN для доступа пользователя-гостя.

    На диспетчере интерфейс используется, когда связано с WLAN. Второй шаг должен создать WLAN на ваших главных офисных диспетчерах. Проведите к WLANs и нажмите New. В Типе WLAN выберите Гостя LAN.

    На Имя Профиля и WLAN SSID, введите имя, которое определяет этот WLAN. Эти имена могут отличаться, но не могут содержать места. Термин WLAN использован, но этот сетевой профиль не связан с профилем беспроводной сети.

    Вкладка "Общие" предлагает два выпадающих списка: Вход и Выход. Вход является VLAN, из которого пользователи происходят (VLAN 50); Выход является VLAN, в который вы хотите послать их.

    Для Входа выберите VLAN50.

    Для Выхода это отличается. Если у вас есть только один диспетчер, необходимо создать другой динамический интерфейс, стандартный на сей раз (не гость LAN), и вы посылаете своих зашитых пользователей в этот интерфейс. В этом случае пошлите их диспетчеру DMZ. Поэтому, для интерфейса Egress, выберите управленческий Интерфейс.

    Способ безопасности для этого Гостя, LAN "WLAN" является WebAuth, который приемлем. Нажмите Ok для утверждения.

  3. Формируйте иностранного диспетчера (главный офис).

    Из списка WLAN нажмите Mobility Anchor в конце Гостя линия LAN и выберите своего диспетчера DMZ. Предполагается здесь, что оба диспетчера знают друг друга. Если они еще не знают друг друга, пойдите к Диспетчеру> управление Подвижностью> группа Подвижности и добавьте DMZWLC на WLC1. Тогда добавьте WLC1 на DMZ. Оба диспетчера не должны быть в той же самой группе подвижности. Иначе, основные правила безопасности нарушены.

  4. Формируйте якорного диспетчера (диспетчер DMZ).

    Ваш главный офисный диспетчер готов. Теперь необходимо подготовить диспетчера DMZ. Откройте сессию веб-браузера для своего диспетчера DMZ и проведите к WLANs. Создайте новый WLAN. В Типе WLAN выберите Гостя LAN.

    На Имя Профиля и WLAN SSID, введите имя, которое определяет этот WLAN. Используйте те же самые ценности, как вступили главный офисный диспетчер.

    Интерфейс Ingress здесь не Ни один. Это фактически не имеет значения, потому что движение получено через Ethernet по IP (EoIP) тоннель. Это - то, почему вы не должны определять интерфейс Ingress.

    Интерфейс Egress является тем, на котором клиентов, как предполагается, посылают. Например, DMZ VLAN является VLAN 9. Создайте стандартный динамический интерфейс для VLAN 9 на вашем DMZWLC, затем выберите VLAN 9 в качестве интерфейса Egress.

    Необходимо формировать конец тоннеля Якоря Подвижности. Из списка WLAN выберите Якорь Подвижности для Гостя LAN. Пошлите движение в локальный контроллер, DMZWLC. Оба конца теперь готовы.

  5. Точно настройте гостя LAN.

    Можно также точно настроить параметры настройки WLAN на обоих концах. Будьте осторожны, параметры настройки должны быть идентичными на обоих концах. Например, если вы принимаете решение щелкнуть во Вкладке "Дополнительно" WLAN, Позволить AAA, отвергают на WLC1, необходимо поставить тот же самый флажок на DMZWLC. Если существуют какие-либо различия в выборах в WLAN с обеих сторон, туннельных разрывах. DMZWLC отказывается от движения; вы видите при управлении подвижностью отладки.

    Следует иметь в виду, что все ценности фактически получены из DMZWLC: IP-адреса, ценности VLAN, и так далее. Формируйте сторону WLC1 тождественно, так, чтобы она передала запрос к WLCDMZ.

Свидетельства для страницы логина

Эта секция обеспечивает процессы, за которыми необходимо следовать, если вы хотите поместить свое собственное свидетельство на странице WebAuth, или если вы хотите скрыть 1.1.1.1 WebAuth URL и показать названный URL.

Загрузите свидетельство для веб-идентификации диспетчера

Через GUI (WebAuth> Свидетельство) или CLI (передача печатают webauthcert) можно загрузить свидетельство на диспетчере. Является ли это свидетельством, которое вы создали со своим центром сертификации (CA) или сторонним официальным свидетельством, это должно быть в формате .pem. Перед отправкой необходимо также войти в ключ свидетельства.

После закачки перезагрузка требуется для свидетельства существовать. После того, как перезагруженный, пойдите в страницу свидетельства WebAuth в GUI, и это показывает вам детали свидетельства, которое вы загрузили (законность и так далее). Важная область является общим названием (CN), которое является именем, выпущенным к свидетельству. Эта область обсуждена в этом документе согласно секции "Центр сертификации и Другие Свидетельства на Диспетчере".

После того, как вы перезагрузили и проверили детали свидетельства, вам дарят новое свидетельство диспетчера на странице логина WebAuth. Однако может быть две ситуации.

  1. Если ваше свидетельство было выпущено одним из некоторых главный корень CAs, которому доверяет каждый компьютер, то это хорошо. Примером является VeriSign, но с вами обычно заключает контракт Verisign подCA, а не корень Приблизительно можно зарегистрироваться магазине свидетельства браузера, если вы видите CA, упомянутый там, как доверяется.

  2. Если вы получили свое свидетельство от меньшей компании/CA, все компьютеры не доверяют им. Необходимо предоставить свидетельство компании/CA клиенту также, и надо надеяться один из корня, CAs выпустит то свидетельство. В конечном счете вы заканчиваете с цепью, такой как “Свидетельство, был выпущен CA x>, CA x свидетельство был выпущен CA y> CA y, свидетельство было выпущено этим корнем, которому доверяют, CA”. Конечная цель должна достигнуть CA, которому действительно доверяет клиент.

Центр сертификации и другие свидетельства на диспетчере

Чтобы быть избавленным от предупреждения “этого свидетельства, не доверяется”, необходимо также войти в свидетельство о CA, который выпустил свидетельство диспетчера на диспетчере. Тогда диспетчер представляет оба свидетельства (свидетельство диспетчера и его свидетельство CA). Свидетельство CA должно быть CA, которому доверяют, или имеет ресурсы для подтверждения Приблизительно, можно фактически построить цепь свидетельств CA, которые приводят к CA, которому доверяют, на вершине.

Необходимо поместить всю цепь в тот же самый файл. Это означает, что ваш файл содержит содержание, такое как этот пример:

BEGIN CERTIFICATE ------

 
device certificate* 
 
 
END CERTIFICATE ------

 
BEGIN CERTIFICATE ------

 
intermediate CA certificate* 
 
 
END CERTIFICATE ------

 
BEGIN CERTIFICATE ------

 
Root CA certificate* 
 
 
END CERTIFICATE ------

Как заставить свидетельство соответствовать URL

WebAuth URL установлен в 1.1.1.1 для подтверждения себя, и свидетельство выпущено (это - область CN свидетельства WLC). Если вы хотите изменить WebAuth URL на 'myWLC.com', например, войдите в действительную интерфейсную конфигурацию (эти 1.1.1.1 интерфейса), и там можно войти в действительный DNS hostname, такой как myWLC.com. Это заменяет 1.1.1.1 в вашем баре URL. Это имя должно также быть разрешимым. След наркомана показывает, как все это работает, но когда WLC посылает страницу логина, WLC показывает адрес myWLC.com, и клиент решает это имя с их DNS. Это имя должно решить как 1.1.1.1. Это означает, что, если вы также используете имя управления WLC, необходимо использовать другое имя для WebAuth. Другими словами, при использовании myWLC.com, нанесенного на карту для управленческого IP-адреса WLC необходимо использовать другое имя для WebAuth, такого как myWLCwebauth.com.

Расследуйте проблемы свидетельства

Эта секция объясняет, как и что проверить для поиска неисправностей проблем свидетельства.

Как проверить

Можно загрузить OpenSSL (для Windows, поиск OpenSSL Win32) и установить его. Без любой конфигурации можно войти в bin-папку и попробовать openssl s_client - соединяют www.mywebauthpage.com:443, если этим URL является URL, где страница WebAuth связана на DNS. Обратитесь к, "Что Проверить" часть этого документа для примера.

Что проверить

Вы видите то, какие свидетельства посылают клиенту, когда это соединяется. Прочитайте свидетельство устройства — CN должен быть URL, где веб-страница достижима. Читайте “выпущенный” линией свидетельства устройства. Это должно соответствовать CN второго свидетельства. Тогда это второе свидетельство, “выпущенное”, должно соответствовать CN следующего свидетельства и так далее. Иначе, это не делает реальную цепь. В продукции OpenSSL, показанной здесь, вы видите, что openssl не может проверить свидетельство устройства, потому что его “выпущенный” не соответствует названию предоставленного свидетельства CA.

Продукция SSL

При погрузке 'экрана' в случайное государство - сделанный CONNECTED (00000760) depth=0/O = <компания> .ac.uk/OU=Domain Контроль, который проверяют Validated/CN = <компания> .ac.uk, error:num=20:unable для получения местного свидетельства выпускающего проверяют return:1 depth=0/O = <компания> .ac.uk/OU=Domain Контроль, Validated/CN = <компания> .ac.uk проверяют, что error:num=27:certificate, которым не доверяют, проверяют return:1 depth=0/O = <компания> .ac.uk/OU=Domain Контроль, Validated/CN = <компания> .ac.uk проверяют error:num=21:unable, чтобы проверить, что первое свидетельство проверяет return:1---цепь Свидетельства

0 s:/O=<company>.ac.uk/OU=Domain Control Validated/CN=<company>.ac.uki:/C=US/
   ST=Arizona/L=Scottsdale/O=.com/OU=http://certificates.go

Сертификация Authority/serialNumber=079 69287 company.com/repository/CN=Secure

1 s:/C=US/O=Company/OU=Class 2 Certification Authorit

y

  i:/C=US/O=Company/OU=Class 2 Certification Authorit

y-Свидетельство сервера

BEGIN CERTIFICATE-----
MIIE/zCCA+egAwIBAgIDRc2iMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJV
output cut*
YMaj/NACviEU9J3iot4sfreCQSKkBmjH0kf/Dg1l0kmdSbc=
END CERTIFICATE-----
subject=/O=<company>.ac.uk/OU=Domain Control Validated/CN=<company>c.ac.uk 
issuer=/C=US/ST=Arizona/L=Scottsdale/O=.com/OU=http://certificates. 
.com/repository/CN=Secure Certification Authority/serialNumber=
0 7969287 --- No client certificate CA names sent --- SSL handshake has read 
2476 bytes and written 322 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA 
Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session:
Protocol  : TLSv1
Cipher    : AES256-SHA
Session-ID: A32DB00A7AB7CD1CEF683980F3696C2BBA31A1453324F711F50EF4B86A4A7F03
Session-ID-ctx:Master-Key: C95E1BDAC7B1A964ED7324955C985CAF186B92EA34CD69E10
   5F95D969D557E19

939C6A77C72350AB099B3736D168AB22

   Key-Arg   : None
Start Time: 1220282986
Timeout   : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---

Другой возможной проблемой является свидетельство, не может быть загружен на диспетчера. В этой ситуации нет никакого вопроса законности, CA, и так далее. Для подтверждения этого можно сначала проверить возможность соединения Тривиального протокола передачи файлов (TFTP) и попытку передать конфигурационный файл. Затем если вы входите в передачу отладки, все позволяют команду, вы видите, что проблемой является установка свидетельства. Это могло произойти из-за неправильного ключа, используемого со свидетельством. Могло также случиться так, что свидетельство находится в неправильном формате или испорчено.

Cisco рекомендует сравнить содержание свидетельства с известным, действительным свидетельством. Это позволяет вам видеть, показывает ли признак LocalkeyID весь 0s (уже произошел). Если так, тогда свидетельство должно быть повторно преобразовано. Существует две команды с OpenSSL, которые позволяют вам возвращаться от .pem до .p12, и затем переиздавать .pem с ключом по Вашему выбору.

Предварительный шаг: Если вы получили .pem, который содержит свидетельство, сопровождаемое ключом, скопировать/вставить ключевая роль:----BEGIN KEY----до-------END KEY------от .pem в "key.pem".

  1. openssl pkcs12 - экспорт - в certificate.pem-inkey key.pem - newcert.p12 — Вы побуждены с ключом; войдите в check123.

  2. openssl pkcs12 - в newcert.p12 - workingnewcert.pem-passin pass:check123-passout pass:check123 Это приводит к эксплуатационному .pem с паролем check123.

Другие ситуации для поиска неисправностей

Хотя якорь подвижности не был обсужден в этом документе, если вы находитесь в закрепленной ситуации гостя, удостоверьтесь, что обмен подвижности происходит правильно и что вы видите, что клиент прибывает в якорь. Дальнейшие проблемы WebAuth должны расследовать на якоре.

Вот некоторые общие вопросы, которые можно расследовать:

  • Пользователи не могут связать гостю WLAN.

    Это не связано с WebAuth. Проверьте конфигурацию клиента, параметры настройки безопасности на WLAN, если это позволено, и являются ли радио активными и действующими и так далее.

  • Пользователи не получают IP-адрес.

    В ситуации с якорем гостя это чаще всего, потому что иностранное и якорное не формировались точно тот же самый путь. Иначе, проверьте конфигурацию DHCP, возможность соединения, и так далее. Подтвердите, может ли другой WLANs использовать тот же самый сервер DHCP без проблемы. Это все еще не связано с WebAuth.

  • Пользователь не перенаправлен к странице логина.

    Это - наиболее распространенный признак, но более точно. Существует два возможных сценария.

    1. Пользователь не перенаправлен (пользователь входит в URL и никогда не достигает страницы WebAuth). Для этой ситуации проверьте:

      • то, что действительный сервер DNS был назначен на клиента через DHCP (ipconfig / все),

      • то, что DNS достижим от клиента (nslookup <www.website.com>),

      • то, что пользователь вошел в действительный URL, чтобы быть перенаправленным,

      • то, что пользователь пошел на URL HTTP на порту 80 (например, для достижения ACS с http://, localhost:2002 не перенаправляет вас, так как вы послали на порту 2002 вместо 80).

    2. Пользователь перенаправлен к 1.1.1.1 правильно, но сама страница не показывает.

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

      Рекомендация: Возьмите след наркомана на клиенте PC. Нет никакой потребности в специальном беспроводном программном обеспечении, только Wireshark, который работает на беспроводном адаптере и показывает вам если ответы WLC и попытки перенаправить. У вас есть две возможности: или от WLC нет никакого ответа, или что-то неправильно с рукопожатием SSL для страницы WebAuth. Для проблемы рукопожатия SSL можно проверить, допускает ли пользовательский браузер SSLv3 (некоторые только позволяют SSLv2), и если это слишком агрессивно на проверке свидетельства.

      Это - общий шаг для ручного входа в http://1.1.1.1, чтобы проверить, появляется ли веб-страница без DNS. Фактически, можно напечатать http://6.6.6.6 и получить тот же самый эффект. WLC перенаправляет любой IP-адрес, в который вы входите. Поэтому при входе в http://1.1.1.1 он не заставляет вас работать вокруг веб-переназначения. При входе в https://1.1.1.1 (безопасный) это не работает, потому что WLC не перенаправляет движение HTTPS. Лучший способ загрузить страницу непосредственно без перенаправления состоит в том, чтобы войти в https://1.1.1.1/login.html.

  • Пользователи не могут подтвердить подлинность.

    Посмотрите часть этого документа, который обсуждает идентификацию. Проверьте верительные грамоты в местном масштабе на RADIUS.

  • Пользователи могут успешно подтвердить подлинность через WebAuth, но у них нет доступа в Интернет впоследствии.

    Можно удалить WebAuth из безопасности WLAN, и затем у вас должен быть открытый WLAN. Можно тогда попытаться получить доступ к сети, DNS и так далее. Если вы испытываете проблемы там также, удаляете параметры настройки WebAuth в целом и проверяете вашу конфигурацию интерфейсов.

Для получения дополнительной информации обратитесь к: Поиск неисправностей Веб-Идентификации на Радио диспетчере LAN (WLC).

Сервер Полномочия HTTP и Как это Работы

Можно использовать сервер по доверенности HTTP. Если вы нуждаетесь в клиенте для добавления исключения в его браузере, который 1.1.1.1 не должен проходить сервер по доверенности, можно заставить WLC прислушаться к движению HTTP на порту сервера по доверенности (обычно 8080).

Для понимания этого сценария необходимо знать то, что делает полномочие HTTP. Это - что-то, что вы формируете на стороне клиента (IP-адрес и порт) в браузере.

Обычный сценарий, когда пользователь посещает веб-сайт, должен решить имя к IP с DNS, и затем это спрашивает веб-страницу к веб-серверу. Процесс должен всегда отправлять запрос HTTP для страницы к полномочию. Полномочие обрабатывает DNS при необходимости и вперед к веб-серверу (если страница уже не припряталась про запас на полномочии). Обсуждение является клиентом к полномочию только. Получает ли полномочие реальную веб-страницу, не важно клиенту.

Вот веб-процесс идентификации:

  • Пользователь печатает в URL.

  • Клиент PC посылает в сервер По доверенности.

  • Точки пересечения WLC и сервер Полномочия обманов IP; это отвечает на PC с перенаправлением к 1.1.1.1.

На данном этапе, если PC не формируется для него, это просит страницу 1.1.1.1 WebAuth к полномочию, таким образом, это не работает. PC должен сделать исключение для 1.1.1.1; тогда это отправляет запрос HTTP к 1.1.1.1 и возобновляет WebAuth. Когда заверено, все коммуникации проходят полномочие снова. Конфигурация исключения обычно находится в браузере близко к конфигурации сервера по доверенности. Необходимо видеть сообщение: "Не используйте полномочие для тех IP-адресов".

С Выпуском 7.0 WLC и позже, опция webauth перенаправление по доверенности может быть активирована в глобальных параметрах конфигурации WLC. Когда позволено, WLC проверяет, формируются ли клиенты для ручного использования полномочия. В этом случае они перенаправляют клиента к странице, которая показывает им, как изменить их параметры настройки по доверенности, чтобы заставить все работать. Перенаправление полномочия WebAuth может формироваться для работы над множеством портов и совместимо с Центральной Веб-Идентификацией.

Для примера на переназначении полномочия WebAuth отошлите к Веб-Полномочию Идентификации на Радио диспетчера LAN КОНФИГУРЭЙШНА ЭКСЭМПЛА.

Веб-идентификация на HTTP вместо HTTPS

Вы можете логин на веб-идентификации на HTTP вместо HTTPS. Если вы логин на HTTP, вы не получаете тревоги свидетельства.

Для ранее, чем кодекс Выпуска 7.2 WLC, необходимо искалечить управление HTTPS WLC и оставить управление HTTP. Однако это только разрешает веб-управление WLC по HTTP.

Для кодекса Выпуска 7.2 WLC config сетевой подлинный сетью secureweb использование, отключают команду для выведения из строя. Это только отключает HTTPS для веб-идентификации а не управления.

На Выпуске 7.3 WLC и более позднем кодексе, можно позволить/отключить HTTPS для WebAuth только через GUI и CLI.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Соответствующая информация


Document ID: 115951