You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Для реализации некоторых корпоративных сценариев аутентификации WNAM предлагает возможность получения, и проверки значения, некоторого LDAP-атрибута пользователя, взятого из Active Directory.

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

Напомним, что в Windows Active Directory у любого объекта (но нас интересует объект типа "Пользователь") есть некоторый набор атрибутов. Они выглядят как пары "ключ-значение", причем значением может быть строка/число/дата/массив и т.п.

Набор возможных атрибутов определяется схемой Active Directory, которая может быть расширена либо администратором, либо при установке сложного ПО (например, Exchange).

Атрибуты проще всего смотреть инструментом ADSI Editor:

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

  1. Настроить взаимодействие с Active Directory
  2. Выбрать интересующие вас атрибуты

Настроить условия матчинга атрибута в правиле (правилах) аутентификации

Для примера мы сделаем два правила:

  1. совпадающее при условии, что запрашивающий доступ пользователь авторизовался в домене более 10 раз. 
  2. совпадающее при условии, что в RADIUS-атрибуте "Cisco-AVPair-mdm-tlv-device-uid" в запросе пользователя значение совпадает с значением AD-атрибута extensionAttribute1

Для настройки взаимодействия обратитесь к этому разделу документации. Обратите внимание, что поддерживается только новый (через flask-сервис) способ.

Вы можете использовать:

  • Только LDAP-взаимодействие. При этом проверка учетной записи (пароля) будет происходить по LDAP, т.е. вы должны применять РАР авторизацию (VPN) либо локальную базу данных учетных записей с учётками, совпадающими с доменными.
  • LDAP и NTLM-взаимодействие. При этом проверка атрибута учетной записи будет происходить по LDAP, а проверка пароля при EAP-PEAP авторизации - по NTLM.

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

и затем отметить интересующие вас (в примере: extensionAttribute1 и logonCount) чекбоксами, не забыв сохранить этот список.

Теперь следует перейти в настройки профилей аутентификации, и создать (клонировать) два новых профиля.

Правила сопоставления SSID, сервера доступа и т.п. настройте, как обычно.

В "Методах" в разделе "EAP-PEAP" выберите ваш домен, ранее настроенный в интеграции с Active Directory. 

В "Методах" отметьте чекбокс "Совпадение в атрибуре в Active Directory (домен выбран ниже)". При этом выпадающий список атрибутов заполнится названиями, которые вы выбрали чекбоксами на стадии интеграции ("интересующие").

Выберите способ сравнения из выпадающего списка. Допустимые способы: равно, содержит, не равно, равно (мак адрес) и численные сравнения.

Теперь выберите радио-переключателем один из двух источников данных для сравнения: заданное здесь же значение, или динамическое значение, получаемое из радиус атрибута.

Соответственно укажите здесь значение дня сравнения, или имя RADIUS-атрибута.

Для способа типа "Содержит" важно, чтобы значение, которое настроено в правиле (фиксированное или из атрибута) содержалось в AD-атрибуте пользователя (поиск по подстроке).

Для способа "Равно (МАС адрес)" значение из AD-атрибута, и значение из правила (например, полученное из RADIUS-атрибута User-Name или Calling-Station-Id), будут оба приведены к единому внутреннему формату МАС-адреса ХХ-ХХ-ХХ-ХХ-ХХ-ХХ, а затем сравнены.

Для способов "Численно..."  значение из AD-атрибута, и значение из правила, оба будут приведены к типу long integer, а затем сравнены арифметически.

Если в ходе обработки аутентификационного запроса  происходит проверка данного правила, производится запрос AD-атрибута в LDAP (возможно, асинхронный). Затем будет проведена проверка совпадения, в результате которой данное правило может быть оставлено, или убрано из списка правил-кандидатов.

В лог-файле WNAM с включенном режиме трассировки появятся такие записи: 

17:20:14.073 TRACE [A12Service.java:1056] - requestAttributeCheckInAd domain lab.wnam.ru lookup time 22 ms.
17:20:14.073 TRACE [ASession.java:152] - log [25] requestAttributeCheckInAd - username 'vpupkin@lab.wnam.ru' is found in 'lab.wnam.ru'
17:20:14.073 TRACE [ASession.java:152] - log [26] requestAttributeCheckInAd - attribute logonCount, value '67'
17:20:14.422 TRACE [A12Service.java:921] - filterForAdAttribute user: vpupkin@lab.wnam.ru, dom_req: null, attrs: [DomainAttribute [name=logonCount, value=67]]
17:20:14.422 TRACE [A12Service.java:947] - filterForAdAttribute user: vpupkin@lab.wnam.ru, rule: NumericGte, found with attr: DomainAttribute [name=logonCount, value=67], compare to: 10
17:20:14.422 TRACE [ASession.java:152] - log [91] filterForAdAttribute - a1profiles candidates: 1, removed 0

Полученный в ходе LDAP-запроса список атрибутов кэшируется (по умолчанию на 10 минут). Просмотреть кэш можно по кнопке внизу таблицы "Диагностика - Корпоративные подключения":

17:23:42.321 INFO [A12Service.java:2299] - Dump AD user-group mapping cache, 1 entries: 
17:23:42.322 INFO [A12Service.java:2307] - username: 'vpupkin' groups [1]: [Wi-Fi Test Users]
17:23:42.322 INFO [A12Service.java:2309] - Dump AD user-attribute mapping cache, 1 entries: 
17:23:42.322 INFO [A12Service.java:2319] - username: 'vpupkin@lab.wnam.ru' a_v: [logonCount='67']


  • No labels