Аутентификация

Аутентификация — проверка подлинности предоставленных учетных данных того, кто запрашивает сетевой доступ. Система WNAM 2 реализует концепцию "профилей" - упорядоченных наборов правил, по которым производится такая проверка. Проверка идет последовательно по правилам, в порядке очереди. Сравниваются различные критерии и атрибуты в поступившем запросе: откуда, когда, каким способом, что при этом передаётся. Можно определить требуемое число профилей, для каждого метода авторизации, источника запроса и других критериев. При проверке списка профилей отсеиваются заведомо не совпавшие, а по окончании проверки выбирается самый первый из оставшихся.

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

• Проводной и беспроводной MAB;
• Проводной и беспроводный 802,1x;
• VPN-подключения.

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

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

Для создания правила аутентификации, необходимо нажать на кнопку "Новое правило аутентификации", для редактирования - необходимо нажать на контекстную кнопку редактирования правила, которая находится справа от имени выбираемого правила.
После, откроется форма создания нового правила:

При редактировании уже имеющегося: 

Правила аутентификации строятся на концепции блоков для более удобного построения правил:

1. Каждый блок может содержать те или иные условия и атрибуты аутентификации (например сетевое устройство, RADIUS атрибут, профилирование, служба каталогов и т.д.).
2. В блоке может находится несколько условий в зависимости от потребности построения правил аутентификации. 
3. Несколько блоков можно сгруппировать в одно комплексное условия с операторами И/ИЛИ, тем самым позволяя построить комплекс условий.

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

Большинство блоков правила предусматривают указание переключателя NOT, что логически обращает условие совпадения.

Все попытки сетевого доступа по протоколу RADIUS можно разделить на три группы:

• Аутентификация с использованием имени пользователя, соответствующего логину (RADIUS-атрибут User-Name), с передачей пароля в запросе. Под эту категорию попадает два типа аутентификации: протокол PAP (plain password) и CHAP (challenge-response).
• Аутентификация с использованием МАС-адреса клиентского устройства, с передачей его в поле логина (RADIUS-атрибут User-Name), и его же - в поле Пароля. Она также называется MAB, или mac address bypass
• Аутентификация с использованием сложных методов, по протоколу 802.1Хю При этом в атрибуте User-Name передаётся имя пользователя, а большинство необходимых данных - в атрибутах EAP-Message

WNAM 2 проводит разделение РАР и MAB авторизации следующим образом:

• Если в атрибуте User-Name присутствует МАС-адрес в любой его форме (AA:AA:AA:AA:AA:AA, aaaaaaaaaaaa, aaaa-aaaa-aaaa и т.п.), то считаем, что проводится MAB-авторизация 
• Если в атрибуте User-Name присутствует логин (не МАС-адрес), то:
  • Если значение атрибута NAS-Port-Type соответствует "Virtual", то данное подключение - попытка аутентификации администратора оборудования для доступа к его консоли управления. Оно в дальнейшем контролируется правилами RADIUS-авторизации в разделе DeviceAdmin.
  • Если значение атрибута NAS-Port-Type соответствует "Virtual" И в обоих атрибутах Called-Station-Id, Calling-Station-Id присутствует IPv4 адрес, то данное подключение - попытка аутентификации VPN доступа
  • Если значение атрибута NAS-Port-Type НЕ соответствует "Virtual", то данное подключение - попытка аутентификации VPN доступа

WNAM 2 проводит разделение MAB и 802.1Х авторизации на основе наличия хотя бы одного атрибута EAP-Message в RADIUS-запросе

WNAM 2 проводит разделение Проводной и Беспроводной MAB и 802.1Х авторизации следующим образом:

• Если значение атрибута NAS-Port-Type соответствует "Wireless-802.11", то данное подключение считается беспроводным
• Если значение атрибута NAS-Port-Type соответствует "Ethernet", то данное подключение считается проводным

Для PAP и MAB методов типичный цикл аутентификации-авторизации всегда состоит только из двух RADIUS-пакетов:

1. Запрос от клиента (сетевого устройства), в котором все данные для аутентификации передаются в запросе, в атрибутах User-Name, User-Password, и других.
2. Ответ от сервера WNAM 2, в котором передаётся результат: Access-Reject, Access-Accept (и возможно дополнительные RADIUS-атрибуты, назначенные в ходе авторизации)

Для 802.1Х методов (EAP-TLS, PEAP) типичный цикл аутентификации-авторизации всегда состоит из нескольких RADIUS-пакетов:

1. Запросы от клиента (сетевого устройства), в котором данные для аутентификации передаются в нескольких последовательных запросах, в атрибутах User-Name, EAP-Message, и других.
2. Промежуточный ответ от сервера WNAM 2, типа Access-Challenge, в котором запрашивается дополнительная информация, и передаются данные (например, сертификат сервера WNAM)
3. Последующие запросы и ответы, в которых передаются сообщения протокола EAP: ключи, части сертификатов, хэши пароля и т.п.
4. Финальный ответ от сервера WNAM 2, в котором передаётся результат: Access-Reject, Access-Accept (и возможно дополнительные RADIUS-атрибуты, назначенные в ходе авторизации)

Количество передаваемых пакетов в ходе 802.1Х авторизации, зависит от длины цепочки сертификатов, размера сертификата (длина публичного ключа), максимального размера блока данных (RADIUS-пакета) и составляет в сумме порядка 10-20 пакетов (в каждую из сторон).

Обратите внимание, что WNAM пробует анализировать все условия, входящие в правило, даже если заведомо известно, что в входящем запросе не может быть критериев для такого условия. Например, если в условие добавлено "Совпадение поля CN сертификата", и при этом само правило описывает РЕАР-авторизацию (в которой не применяются клиентские сертификаты), проверка сертификата всегда будет безуспешной, и правило не совпадёт никогда.

В случае аутентификации с применением учётных данных (логин, пароль), т.е. в схемах с VPN, 802.1X/PEAP и DeviceAdmin доступом, проверке могут подвергаться следующие данные:

• Наличие пользователя в локальной базе данных (Объекты - Учётные записи) с заданными логином и паролем. Такое наличие не проверяется, если в запросе (User-Name) явным образом указана доменная часть, realm: username@domain, DOMAIN\username и т.п.
• Наличие пользователя в домене (службе каталога), при этом проводится поиск во всех подключенных доменах, если в запросе (User-Name) не указана доменная часть, либо только в одном домене (каталоге), если указан realn или его алиас.

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

В случае доменной проверки, возможно указать следующие дополнительные критерии совпадения:

• Членство в определенной группе каталога, с выбором конкретной группы, или подстроки имени группы (частичное соответствие названия)
• Наличие и заданное значение определенного LDAP-атрибута
• Наличие и значение определенного LDAP-атрибута, совпадающего с значением из входящего RADIUS-атрибута
• Нахождение учетной записи в определенной организационной структуре каталога (OU)
• Совпадение логина учетной записи по подстроке

В случае аутентификации с применением TLS-сертификата, т.е. в схемах с 802.1X/TLS доступом, (в будущем и VPN) проверке могут подвергаться следующие данные:

• По умолчанию: валидность сертификата, что подразумевает:
  • Сертификат клиента выпущен доверенным удостоверяющим центром (присутствует в цепочке доверия, в разделе "NAC - Удостоверяющий центр")
  • Сертификат клиента не истёк
  • Сертификат клиента прошел базовую верификацию подписи
  • Сертификат не отозван, если он был выпущен встроенным в WNAM 2 удостоверяющим центром
• Дополнительные критерии проверки:
  • Сертификат не отозван, путём запроса (периодической выгрузки) списка отзывов CRL (Delta CRL), в том числе и с прокси-ресурса. Адреса расположения CRL берутся из выпускающего/корневого сертификата.
  • Сертификат не отозван, путём запроса по протоколу OCSP. Адрес расположения OCSP-сервиса берется из выпускающего/корневого сертификата.
  • В полях сертификата CN, SAN, DN присутствует либо отсутствует заданная строка
  • Сертификат выпущен с применением конкретного шаблона (задан его OID)
  • Сертификат выпущен конкретным удостоверяющим центром (совпадение по полю Issuer)
  • Анализируется заданное поле сертификата (CN, SAN) либо атрибут запроса EAP-Identity. По его значению ведется поиск владельца сертификата в заданной службе каталога (домене). Проверяется статус действия учётной записи пользователя домена (не заблокирована ли и т.п.).