...
Большинство блоков правила предусматривают указание переключателя 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 авторизации следующим образом:
...
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-пакетов:
- Запрос от клиента (сетевого устройства), в котором все данные для аутентификации передаются в запросе, в атрибутах User-Name, User-Password, и других.
- Ответ от сервера WNAM 2, в котором передаётся результат: Access-Reject, Access-Accept (и возможно дополнительные RADIUS-атрибуты, назначенные в ходе авторизации)
Для 802.1Х методов (EAP-TLS, PEAP) типичный цикл аутентификации-авторизации всегда состоит из нескольких RADIUS-пакетов:
...
Обратите внимание, что 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. По его значению ведется поиск владельца сертификата в заданной службе каталога (домене). Проверяется статус действия учётной записи пользователя домена (не заблокирована ли и т.п.).