Подлинность не проверена в центре управления сетями: Сетевое подключение выводит сообщение «Подлинность не проверена» в центре управления сетями!

Содержание

Сертификаты сервера—ArcGIS Server | Документация для ArcGIS Enterprise

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

Для создания HTTPS-соединения между веб-сервером и клиентом веб-серверу требуется сертификат сервера. Сертификат – это цифровой файл, содержащий информацию об удостоверении веб-сервера. Он также содержит метод шифрования, который используется при создании защищенного канала между веб-сервером и клиентом. Сертификат должен создаваться владельцем веб-сайта и иметь цифровую подпись. Существует три типа сертификатов, подписанные центром сертификации (CA), домена и самозаверенный, которые описываются ниже.

Сертификаты, подписанные центром сертификации (ЦС)

Сертификаты, подписанные центром сертификации (CA), следует использовать для производственных систем, особенно если к развертыванию ArcGIS Server предполагается доступ пользователей извне вашей организации. Если сервер доступен через Интернет, использование сертификата, подписанного центром сертификации (CA) гарантирует пользователям вне организации, что подлинность веб-сайта подтверждена.

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

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

Чтобы просмотреть подробные шаги, см. следующие темы:

Если сертификат, подписанный центром сертификации, уже есть, см. раздел Настройка ArcGIS Server с существующим сертификатом, подписанным центром сертификации.

Если вам нужно создать сертификат и подписать его в центре сертификации, см. раздел Настройка ArcGIS Server с новым сертификатом, подписанным центром сертификации.

Если вы будете использовать ArcGIS Web Adaptor для пересылки запросов на свой сайт, см. раздел Настройка сертификата, подписанного центром сертификации, для ArcGIS Server при доступе через ArcGIS Web Adaptor.

Сертификаты домена

Если сервер находится за файрволом и использование подписанного CA сертификата невозможно, воспользуйтесь сертификатом домена. Доменный сертификат – это внутренний сертификат, подписанный ЦС вашей организации. Использование сертификатов домена помогает снизить стоимость выпуска сертификатов и облегчает их развертывание, поскольку сертификаты быстро генерируются в вашей организации для доверительного внутреннего пользования.

Пользователи, находящиеся в вашем домене, не увидят предупреждений или неожиданного поведения веб-браузера, обычно связанных с использованием самозаверенных сертификатов, поскольку веб-сайт был проверен сертификатом домена. Однако сертификаты домена не проверяются внешней CA, это означает, что пользователи, заходящие на сайт извне домена, не смогут проверить подлинность вашего сертификата. Внешние пользователи увидят в веб-браузере сообщения об отсутствии доверия к сайту, пользователь может считать, что зашел на вредоносный сайт и уйти с него.

Самозаверенные сертификаты

Сертификат, подписанный только владельцем веб-сайта, называется самозаверенным сертификатом. Самозаверенные сертификаты обычно используются на веб-сайтах, которые доступны только пользователям внутренней сети организации (LAN). Поскольку нет необходимости проверять идентичность веб-сайта, использование самозаверенного сертификата обеспечивает безопасность передачи данных внутри организации.

Создание самозаверенного сертификата не подходит для производственной среды, поскольку приводит к непредсказуемым результатам и неудобствам в работе для всех пользователей сайта.

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

Чтобы просмотреть подробные шаги, см. следующие темы:

Настройка ArcGIS Server с помощью самозаверенного сертификата по умолчанию

Настройка ArcGIS Server с помощью самозаверенного сертификата

Отзыв по этому разделу?

Что такое контроль доступа к сети (NAC) 802.

1X?

Что такое контроль доступа к сети (NAC) 802.1X?

Контроль доступа к сети (NAC) 802.1X предоставляет администраторам унифицированные возможности управления доступом к проводным и беспроводным сетям. Он широко применяется в кампусных и филиальных корпоративных сетях и состоит из двух основных элементов.

  • Протокол 802.1X — это стандарт IEEE для контроля доступа к сети на основе портов (PNAC) в точках доступа к проводным и беспроводным сетям. 802.1X определяет элементы аутентификации для любого пользователя или устройства, которые пытаются получить доступ к локальным или беспроводным сетям.
  • Контроль доступа к сети (NAC) — это проверенная сетевая концепция, которая определяет пользователей и устройства посредством управления доступом к сети. NAC контролирует доступ к корпоративным ресурсам с помощью авторизации и применения политик.

Проблемы, решаемые с помощью контроля доступа к сети 802.1X

Доступ к беспроводным сетям, мобильность, концепция «принеси свое устройство», социальные сети и облачные вычисления оказывают сильное влияние на корпоративные сетевые ресурсы. Такая расширенная мобильность увеличивает подверженность сетей угрозам и цифровой эксплуатации, как показано на следующем рисунке. Использование 802.1X помогает укрепить входящую безопасность такого типа среды, а также сократить совокупную стоимость владения.

Что можно сделать с помощью контроля доступа к сети 802.1X?

Существует много способов развертывания контроля доступа к сети, но основными из них являются следующие.

  • Контроль перед предоставлением доступа — блокировка сообщений, подлинность которых не проверена.
  • Обнаружение устройств и пользователей — определение пользователей и устройств с предопределенными учетными данными или идентинтификационными номерами машин.
  • Аутентификация и авторизация — проверка и предоставление доступа.
  • Подключение — предоставление устройству программного обеспечения для обеспечения безопасности, возможностей управления и проверки узлов.
  • Профилирование — сканирование конечных устройств.
  • Применение политик — присваивание роли и предоставление доступа на основе разрешения.
  • Контроль после предоставления доступа — принудительное завершение сессии и очистка.

802.1X обеспечивает контроль доступа к сети уровня 2 посредством проверки пользователя или устройства, которые пытаются получить доступ к физическому порту.

Как работает контроль доступа к сети 802.1X?

Порядок действий процедуры контроля доступа к сети (NAC) 802.1X следующий.

1.  Инициация:  средство проверки подлинности (обычно коммутатор) или запрашивающее устройство (клиентское устройство) посылает запрос на инициацию сессии. Запрашивающее устройство отправляет EAP-ответ средству проверки подлинности, которое инкапсулирует сообщение и направляет его серверу аутентификации.

2.  Аутентификация: сообщения передаются между сервером аутентификации и запрашивающим устройством через средство проверки подлинности с целью проверить некоторые фрагменты информации.

3.  Авторизация: если учетные данные действительны, сервер аутентификации уведомляет средство проверки подлинности о необходимости предоставления доступа запрашивающему устройству.

4.  Учет: средство учета RADIUS хранит записи о сессии, в том числе сведения о пользователе и устройстве, типе сессии, а также информацию о сервисе.

5.  Завершение сессии: сессия завершается путем отключения конечного устройства или с помощью программного обеспечения для управления.

Внедрение устройств Juniper Networks

Семейство Ethernet-коммутаторов серии EX— это устройства компании Juniper, обеспечивающие доступ к кампусной и филиальной корпоративной сети. Коммутаторы серии EX обеспечивают расширенную поддержку средства учета RADIUS и протокола 802.1X, а также несколько усовершенствований для протокола 802.1X. Они предоставляют дополнительные способы для решения задач, связанных с поступающими запросами на предоставление доступа, а также упрощают широкомасштабное развертывание решения для контроля доступа к сети. Кроме того, решения, предлагаемые определенными поставщиками Juniper, такие как платформа ClearPass Policy Management компании Aruba Networks и продукция компании Pulse Secure, обеспечивают комплексное управление контролем доступа к сети.

Проверка подлинности сетевого трафика (Windows)

Редактировать

Твиттер

LinkedIn

Фейсбук

Электронная почта

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

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

  • Зона изоляции основного домена. Прежде чем преобразовать правило IPsec изоляции основного домена из режима запроса в режим требования, необходимо убедиться, что сетевой трафик защищен в соответствии с вашим проектом. Настроив правила так, чтобы они запрашивали и не требовали проверки подлинности в начале операций, устройства в сети могут продолжать обмениваться данными, даже если проверка подлинности в основном режиме или правила проверки целостности и шифрования в быстром режиме работают неправильно. Например, если ваша зона шифрования содержит правила, требующие определенного алгоритма шифрования, но этот алгоритм не включен в комбинацию методов безопасности на клиентах, то эти клиенты не смогут успешно согласовать сопоставление безопасности в быстром режиме, и сервер откажет. принимать сетевой трафик от клиента. Если сначала использовать только режим запросов, у вас есть возможность развернуть свои правила, а затем проверить сетевой трафик, чтобы убедиться, что они работают должным образом, без риска потери связи.

  • Пограничная зона. Подтверждение правильной работы IPsec — это последний шаг, если вы работаете с GPO пограничной зоны. Вы никогда не конвертируете объект групповой политики в требуемый режим.

  • Зона шифрования. Как и в случае с основной зоной изоляции, после подтверждения того, что сетевой трафик к членам зоны правильно аутентифицирован и зашифрован, необходимо преобразовать правила зоны из режима запроса в режим требования.

Примечание

В дополнение к шагам, показанным в этой процедуре, вы также можете использовать средства захвата сетевого трафика, такие как Microsoft Network Monitor. Сетевой монитор и аналогичные инструменты позволяют захватывать, анализировать и отображать сетевые пакеты, полученные сетевым адаптером на вашем устройстве. Текущие версии этих инструментов включают полную поддержку IPsec. Они могут идентифицировать зашифрованные сетевые пакеты, но не могут их расшифровать.

Учетные данные администратора

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

Чтобы убедиться, что сетевые подключения проходят проверку подлинности с помощью консоли брандмауэра Защитника Windows в режиме повышенной безопасности

  1. Откройте брандмауэр Защитника Windows в режиме повышенной безопасности
    консоль.

  2. В области навигации разверните Мониторинг и щелкните Правила безопасности подключения .

    В области сведений отображаются правила, действующие на устройстве в данный момент.

  3. Для отображения столбца Источник правила

    1. На панели Действия щелкните Вид , а затем щелкните Добавить/удалить столбцы .

    2. В списке Доступные столбцы выберите Источник правила и нажмите Добавить .

    3. Используйте кнопки Вверх и Вниз для изменения порядка. Нажмите OK , когда закончите.

      Обновление списка новым добавленным столбцом может занять некоторое время.

  4. Просмотрите список правил из объектов групповой политики, которые вы ожидаете применить к этому устройству.

    Примечание:   Если правила не отображаются в списке, устраните неполадки в группе безопасности объекта групповой политики и фильтрах WMI, применяемых к объекту групповой политики. Убедитесь, что локальное устройство входит в соответствующие группы и соответствует требованиям фильтров WMI.

  5. На панели навигации разверните Сопоставления безопасности , а затем нажмите Основной режим .

    Текущий список ассоциаций основного режима, которые были согласованы с другими устройствами, отображается в столбце сведений.

  6. Просмотрите список сопоставлений безопасности основного режима для сеансов между локальным устройством и удаленным устройством. Убедитесь, что столбцы 1st Authentication Method и 2nd Authentication Method содержат ожидаемые значения. Если в ваших правилах указан только первый метод аутентификации, то В столбце 2nd Authentication Method отображается Нет аутентификации . Если дважды щелкнуть строку, появится диалоговое окно Properties с дополнительными сведениями о сопоставлении безопасности.

  7. На панели навигации щелкните Быстрый режим .

  8. Просмотрите список сопоставлений безопасности быстрого режима для сеансов между локальным устройством и удаленным устройством. Убедитесь, что AH Integrity , ESP Integrity и Столбцы ESP Confidentiality содержат ожидаемые значения.

Обратная связь

Просмотреть все отзывы о странице

Устранение неполадок веб-аутентификации на контроллере беспроводной локальной сети (WLC)

    Введение

    В этом документе описаны советы по устранению неполадок веб-аутентификации в среде контроллера беспроводной локальной сети (WLC).

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

    Требования

    Cisco рекомендует иметь знания по следующим темам:

    • Контроль и настройка точек беспроводного доступа (CAPWAP).

    • Как настроить облегченную точку доступа (LAP) и WLC для базовой работы.

    • Базовые знания о веб-аутентификации и настройке веб-аутентификации на WLC.

    Для получения информации о том, как настроить веб-аутентификацию на WLC, обратитесь к Примеру настройки веб-аутентификации контроллера беспроводной локальной сети.

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

    Информация в этом документе основывается на WLC 5500, на котором работает микропрограмма версии 8.3.121.

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

    Сопутствующие товары

    Этот документ также можно использовать с этим оборудованием:

    • Беспроводные контроллеры Cisco серии 5500

    • Беспроводные контроллеры Cisco серии 8500

    • Беспроводные контроллеры Cisco серии 2500

    • Контроллер беспроводной локальной сети Cisco Airespace серии 3500

    • Контроллер беспроводной локальной сети Cisco Airespace серии 4000

    • Беспроводные контроллеры Cisco Flex серии 7500

    • Модуль беспроводных услуг Cisco 2 (WiSM2)

    Веб-аутентификация на WLC

    Веб-аутентификация — это функция безопасности уровня 3, которая заставляет контроллер не разрешать IP-трафик, за исключением пакетов, связанных с DHCP/системой доменных имен (DNS), от определенного клиента до тех пор, пока этот клиент не правильно предоставил правильное имя пользователя и пароль, за исключением трафика, разрешенного через список управления доступом до аутентификации (ACL). Веб-аутентификация — это единственная политика безопасности, которая позволяет клиенту получить IP-адрес до аутентификации. Это простой метод аутентификации, не требующий запрашивающей или клиентской утилиты. Веб-аутентификация может выполняться либо локально на WLC, либо через сервер RADIUS. Веб-аутентификация обычно используется клиентами, которые хотят развернуть сеть с гостевым доступом.

    Веб-аутентификация начинается, когда контроллер перехватывает первый пакет GET TCP HTTP (порт 80) от клиента. Чтобы веб-браузер клиента зашел так далеко, клиент должен сначала получить IP-адрес и выполнить преобразование URL-адреса в IP-адрес (разрешение DNS) для веб-браузера. Это позволяет веб-браузеру узнать, какой IP-адрес отправлять HTTP GET.

    Если в WLAN настроена веб-аутентификация, контроллер блокирует весь трафик (до завершения процесса аутентификации) от клиента, за исключением трафика DHCP и DNS. Когда клиент отправляет первый HTTP GET на TCP-порт 80, контроллер перенаправляет клиента на https://19. 2.0.2.1/login.html (если это настроенный виртуальный IP-адрес) для обработки. Этот процесс в конечном итоге вызывает веб-страницу входа в систему.

    Примечание : Когда вы используете внешний веб-сервер для веб-аутентификации, платформам WLC требуется ACL предварительной аутентификации для внешнего веб-сервера.

    В этом разделе подробно объясняется процесс перенаправления веб-аутентификации.

    • Вы открываете веб-браузер и вводите URL-адрес, например, http://www.site.com. Клиент отправляет DNS-запрос для этого URL-адреса, чтобы получить IP-адрес назначения. WLC передает DNS-запрос DNS-серверу, а DNS-сервер отвечает ответом DNS, который содержит IP-адрес получателя www.site.com , который, в свою очередь, перенаправляется беспроводным клиентам.

    • Затем клиент пытается открыть TCP-соединение с IP-адресом назначения. Он отправляет пакет TCP SYN, предназначенный для IP-адреса www.site.com.

    • WLC имеет правила, настроенные для клиента, и, следовательно, может действовать как прокси для www. site.com. Он отправляет клиенту пакет TCP SYN-ACK с источником в качестве IP-адреса www.site.com. Клиент отправляет обратно пакет TCP ACK, чтобы завершить трехстороннее рукопожатие TCP, и соединение TCP полностью установлено.

    • Клиент отправляет пакет HTTP GET, предназначенный для www.site.com. WLC перехватывает этот пакет и отправляет его для обработки перенаправления. Шлюз приложений HTTP подготавливает тело HTML и отправляет его обратно в качестве ответа на запрос HTTP GET, запрошенный клиентом. Этот HTML-код заставляет клиента перейти к URL-адресу веб-страницы WLC по умолчанию, например, http:///login.html.

    • Клиент закрывает TCP-соединение с IP-адресом, например www.site.com.

    • Теперь клиент хочет перейти на http:///login.html и пытается открыть TCP-соединение с виртуальным IP-адресом WLC. Он отправляет пакет TCP SYN для 192.0.2.1 (здесь это наш виртуальный IP-адрес) на WLC.

    • WLC отвечает TCP SYN-ACK, и клиент отправляет обратно TCP ACK на WLC для завершения квитирования.

    • Клиент отправляет HTTP GET для /login.html, предназначенного для 192.0.2.1 для запроса страницы входа.

    • Этот запрос разрешен до веб-сервера WLC, и сервер отвечает страницей входа по умолчанию. Клиент получает страницу входа в окно браузера, где пользователь может войти в систему.

    В этом примере IP-адрес клиента — 192.168.68.94. Клиент разрешил URL-адрес веб-сервера, к которому он обращался, 10.1.0.13. Как видите, клиент выполнил трехэтапное рукопожатие, чтобы запустить TCP-соединение, а затем отправил пакет HTTP GET, начинающийся с пакета 9.6 (00 — HTTP-пакет). Это не было инициировано пользователем, а было триггером автоматического обнаружения портала операционной системой (как мы можем догадаться по запрошенному URL-адресу). Контроллер перехватывает пакеты и отвечает кодом 200. Пакет с кодом 200 содержит URL-адрес перенаправления:

    .

      
      Перенаправление веб-аутентификации 
      
      
      
      0.2.1/login.html?redirect=http: //captive.apple.com/hotspot-detect.html">

    Затем он закрывает TCP-соединение через трехстороннее рукопожатие.

    Затем клиент запускает соединение HTTPS с URL-адресом перенаправления, который отправляет его на 192.0.2.1, который является виртуальным IP-адресом контроллера. Клиент должен подтвердить сертификат сервера или проигнорировать его, чтобы запустить туннель SSL. В данном случае это самозаверяющий сертификат, поэтому клиент его проигнорировал. Веб-страница входа отправляется через этот туннель SSL. Пакет 112 начинает транзакции.

    У вас есть возможность настроить доменное имя для виртуального IP-адреса WLC. Если вы настраиваете имя домена для виртуального IP-адреса, это имя домена возвращается в пакете HTTP OK от контроллера в ответ на пакет HTTP GET от клиента. Затем вам необходимо выполнить разрешение DNS для этого доменного имени. Как только он получает IP-адрес из разрешения DNS, он пытается открыть сеанс TCP с этим IP-адресом, который является IP-адресом, настроенным на виртуальном интерфейсе контроллера.

    В конце концов, веб-страница передается через туннель клиенту, и пользователь отправляет обратно имя пользователя/пароль через туннель Secure Sockets Layer (SSL).

    Веб-аутентификация выполняется одним из следующих трех методов:

    • Использовать внутреннюю веб-страницу (по умолчанию).

    • Используйте настраиваемую страницу входа.

    • Используйте страницу входа с внешнего веб-сервера.

    Примечания :
    — Настраиваемый пакет веб-аутентификации имеет ограничение до 30 символов для имен файлов. Убедитесь, что имена файлов в пакете не длиннее 30 символов.

     — Начиная с версии 7.0 WLC, если веб-аутентификация включена в WLAN и у вас также есть правила ACL ЦП, клиентские правила веб-аутентификации всегда имеют более высокий приоритет, если клиент не прошел аутентификацию в состоянии WebAuth_Reqd. Как только клиент переходит в состояние RUN, применяются правила ACL процессора.

    — Таким образом, если в WLC включены списки ACL ЦП, требуется разрешающее правило для IP-адреса виртуального интерфейса (В ЛЮБОМ направлении) в следующих условиях:
    — Когда в ACL ЦП нет разрешающего правила ВСЕ для обоих направлений.
      – когда существует разрешающее правило ALL, но также существует правило DENY для порта 443 или 80 с более высоким приоритетом.

    — Разрешающее правило для виртуального IP-адреса должно быть для протокола TCP и порта 80, если SecureWeb отключен, или порта 443, если SecureWeb включен. Это необходимо для того, чтобы разрешить доступ клиента к IP-адресу виртуального интерфейса после успешной аутентификации при наличии списков ACL ЦП.

    Устранение неполадок веб-аутентификации

    После настройки веб-аутентификации и если функция не работает должным образом, выполните следующие действия:

    1. Проверьте, получает ли клиент IP-адрес. Если нет, пользователи могут снять флажок DHCP Required в WLAN и присвоить беспроводному клиенту статический IP-адрес. Это предполагает связь с точкой доступа.
    2. Следующим шагом в этом процессе является DNS-разрешение URL-адреса в веб-браузере. Когда клиент WLAN подключается к WLAN, настроенной для веб-аутентификации, клиент получает IP-адрес от DHCP-сервера. Пользователь открывает веб-браузер и вводит адрес веб-сайта. Затем клиент выполняет разрешение DNS для получения IP-адреса веб-сайта. Теперь, когда клиент пытается получить доступ к веб-сайту, WLC перехватывает сеанс HTTP GET клиента и перенаправляет пользователя на страницу входа в систему веб-аутентификации.
    3. Поэтому убедитесь, что клиент может выполнить разрешение DNS для работы перенаправления. В Microsoft Windows выберите Start > Run , введите CMD , чтобы открыть командное окно, выполните «nslookup www.cisco.com» и посмотрите, возвращается ли IP-адрес.

      В Mac/Linux откройте окно терминала и выполните «nslookup www.cisco.com» и посмотрите, возвращается ли IP-адрес.

      Если вы считаете, что клиент не получает разрешение DNS, вы можете:

      • Введите либо IP-адрес URL-адреса (например, http://www. cisco.com — это http://192.168.219.25).
      • Попробуйте ввести любой (даже несуществующий) IP-адрес, который должен разрешаться через беспроводной адаптер.

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

    4. Для веб-аутентификации с настраиваемой веб-страницей убедитесь, что HTML-код для настраиваемой веб-страницы подходит.

      Образец сценария веб-аутентификации можно загрузить с сайта Cisco Software Downloads. Например, для контроллеров 5508 выберите Products > Wireless > Wireless LAN Controller > Standalone Controllers > Cisco 5500 Series Wireless LAN Controllers > Cisco 5508 Wireless LAN Controller > Software on Chassis > Wireless Lan Controller Web Authentication Bundle и загрузите файл webauth_bundle.zip .

      Эти параметры добавляются к URL-адресу, когда интернет-браузер пользователя перенаправляется на настраиваемую страницу входа:

      • ap_mac — MAC-адрес точки доступа, с которой связан беспроводной пользователь.
      • switch_url — URL-адрес контроллера, на который должны быть отправлены учетные данные пользователя.
      • перенаправление — URL-адрес, на который перенаправляется пользователь после успешной аутентификации.
      • statusCode — код состояния, возвращенный сервером веб-аутентификации контроллера.
      • wlan — SSID WLAN, с которым связан пользователь беспроводной сети.

      Доступные коды состояния:

      • Код состояния 1 — «Вы уже вошли в систему. Никаких дальнейших действий с вашей стороны не требуется».
      • Код состояния 2 — «Вы не настроены для аутентификации на веб-портале. Никаких дополнительных действий с вашей стороны не требуется».
      • Код состояния 3 — «Указанное имя пользователя нельзя использовать в данный момент. Возможно, это имя пользователя уже выполнено в системе?»
      • Код состояния 4 — «Вы исключены».
      • Код состояния 5 — «Введенная вами комбинация имени пользователя и пароля недействительна. Повторите попытку».
    5. Все файлы и изображения, которые должны отображаться на настроенной веб-странице, должны быть объединены в файл .tar перед его загрузкой на WLC. Убедитесь, что одним из файлов, включенных в пакет .tar, является login.html. Вы получите это сообщение об ошибке, если не включите файл login.html:

      Дополнительную информацию о том, как создать настраиваемое окно веб-аутентификации, см. в разделе «Рекомендации по индивидуальной веб-аутентификации» примера конфигурации веб-аутентификации контроллера беспроводной локальной сети.

      Примечание : Большие файлы и файлы с длинными именами могут привести к ошибке извлечения. Рекомендуется, чтобы изображения были в формате .jpg.

    6. Убедитесь, что опция Scripting не заблокирована в клиентском браузере, поскольку настраиваемая веб-страница на WLC в основном является сценарием HTML.
    7. Если у вас есть имя хоста , настроенное для виртуального интерфейса WLC, убедитесь, что разрешение DNS доступно для имени хоста виртуального интерфейса.

      Примечание : Перейдите в меню Controller > Interfaces из графического пользовательского интерфейса WLC, чтобы назначить DNS-имя хоста виртуальному интерфейсу.

    8. Иногда брандмауэр, установленный на клиентском компьютере, блокирует страницу входа в систему через веб-аутентификацию. Отключите брандмауэр, прежде чем пытаться получить доступ к странице входа. Брандмауэр можно снова включить после завершения веб-аутентификации.
    9. Межсетевой экран топологии/решения может быть размещен между клиентом и сервером веб-аутентификации, что зависит от сети. Что касается каждого реализованного сетевого проекта/решения, конечный пользователь должен убедиться, что эти порты разрешены в сетевом брандмауэре.
      Протокол Порт
      Трафик HTTP/HTTPS TCP-порт 80/443
      Данные CAPWAP/трафик управления UDP-порт 5247/5246
      Трафик данных/управления LWAPP (до версии 5. 0) UDP-порт 12222/12223
      Пакеты EOIP IP-протокол 97
      Мобильность Порт UDP 16666 (незащищенный) Порт UDP 16667 (защищенный туннель IPSEC)
    10. Для веб-аутентификации клиент должен сначала связать с соответствующей WLAN на WLC. Перейдите к меню Monitor> Clients в графическом интерфейсе WLC, чтобы увидеть, связан ли клиент с WLC. Проверьте, имеет ли клиент действительный IP-адрес.
    11. Отключите настройки прокси-сервера в браузере клиента до завершения веб-аутентификации.
    12. Методом веб-аутентификации по умолчанию является протокол аутентификации по паролю (PAP). Убедитесь, что аутентификация PAP разрешена на сервере RADIUS, чтобы это работало. Чтобы проверить статус аутентификации клиента, проверьте отладки и сообщения журнала с сервера RADIUS. Можно использовать команду debug aaa all на WLC для просмотра отладок с сервера RADIUS.
    13. Обновите драйвер оборудования на компьютере до последнего кода с веб-сайта производителя.
    14. Проверьте настройки в саппликанте (программа на ноутбуке).
    15. При использовании встроенного в Windows запрашивающего устройства Windows Zero Config:
      • Убедитесь, что у пользователя установлены последние исправления.
      • Запустите отладку на запрашивающей стороне.
    16. На клиенте включите журналы EAPOL (WPA+WPA2) и RASTLS из командного окна. Выберите Пуск > Выполнить > CMD 9.0014 :
       netsh ras set tracing eapol enable
      netsh ras установить трассировку rastls включить

      Чтобы отключить журналы, выполните ту же команду, но замените enable на disable. Для XP все журналы могут находиться в папке C:\Windows\tracing.

    17. Если у вас все еще нет веб-страницы входа, соберите и проанализируйте эти выходные данные от одного клиента:
       клиент отладки 
включить сообщение отладки dhcp
отлаживать ааа все включить
отладка dot1x aaa включить
включить отладку мобильности
    18. Если проблема не решена после выполнения этих шагов, соберите эти отладки и используйте диспетчер обращений в службу поддержки, чтобы открыть запрос на обслуживание.

Читайте также: