Зіставлення груп LDAP у ASA та DAP для групової політики VPN

Два окремі записи вирішують, яку групову політику отримає сеанс AnyConnect, і вони живуть у різних частинах конфігурації з різними режимами відмови. Карта атрибутів LDAP під час автентифікації перетворює значення з каталогу на атрибут авторизації ASA; запис DAP потім оцінює умови та може додавати або перекривати атрибути. Обидва можуть закінчитися на однаковій назві політики, тому успішний вхід нічого не каже про те, який механізм його створив. Сенс порівняння — свідомо вибрати один, а не дозволяти другому тихо перекривати перший.

Два механізми, дві точки рішення

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

Якщо єдиний вхід — членство в групі, карта атрибутів є меншим інструментом і тим, який легше перевіряти: одна карта, прив'язана до одного сервера AAA, по одному рядку на групу. Якщо вибір має враховувати стан пристрою, ідентичність кінцевої точки, другий атрибут або часове вікно, входи карти вичерпуються, і DAP — це механізм, здатний виразити правило. Якщо використовуються обидва, дізнайтеся пріоритет у своїй версії, перш ніж писати будь-який із них, бо сеанс, що відповідає запису DAP, може не зберегти політику, яку повернула карта. Усе інше — бухгалтерія.

Шлях карти атрибутів, у порядку конфігурації

Шлях карти починається з визначення сервера AAA. Карта атрибутів має бути прив'язана до запису сервера LDAP, який профіль підключення справді використовує; карта, що існує в робочій конфігурації, але не згадується цим сервером, нічого не змінює. Саме цей рядок прив'язки оживляє решту конфігурації. посібник із зіставлення LDAP в ASA є довідкою щодо синтаксису карти у версіях 9.x.

Усередині карти один оператор називає атрибут каталогу та атрибут ASA, який він живить, а подальші оператори перекладають конкретні значення. map-name memberOf Group-Policy за яким іде map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly і є форма: ліва частина — те, що повернув каталог, права частина — назва групової політики, яка вже має існувати. Відмітне ім'я та відображувана назва політики не є взаємозамінними, і майже збіг у будь-якому з двох рядків не дає помилки під час входу.

Тут кусаються дві деталі: memberOf повертає кожну групу, до якої належить обліковий запис, тому користувач у двох зіставлених групах дає карті два кандидатні значення, а алфавітне правило з посібника — єдиний спосіб розв'язання рівності, на який можна покластися замість власного порядку пріоритетів. Не зіставлене значення не дає нічого, і це тихо повертається до політики профілю за замовчуванням.

Шлях DAP і що він додає

DAP оцінює умови та застосовує атрибути поверх результату AAA. Запис несе пріоритет, дію та набір умов; записи оцінюються в порядку пріоритету, а дія вирішує, чи оцінювання продовжується, чи зупиняється. Це інша модель виконання, ніж пошук значення, і саме тому вона може виразити правила, які карта не може.

Те, що додає DAP, — це входи. Умови можуть посилатися на атрибути каталогу, атрибути кінцевої точки та стан пристрою, а відповідний запис може нести ACL, списки URL або фільтри для цього сеансу. Тому правило на кшталт того, що працівники підтримки на керованому ноутбуці отримують політику лише для читання, а ті самі працівники на некерованому пристрої — обмежену, виразне в DAP, але не в карті атрибутів. Карта має рівно один вхід: значення, яке каталог повернув для названого вами атрибута.

DAP також додає друге місце для перевірки, коли сеанс потрапляє в неправильну політику. Запис, що відповідає дії продовження, не завершує оцінювання, і пізніший запис усе ще може змінити результат, тому те, що ви спостерігаєте, — це добуток послідовності, а не одного пошуку. Читайте номери пріоритетів по порядку і пам'ятайте, що роботу може виконувати резервний запис. Карта, навпаки, не має послідовності: один атрибут, одне значення, одна відповідь.

Де вони розходяться

Пріоритет — це та частина, що ламає проєкти. Коли сеанс відповідає і запису карти, і запису DAP, результат залежить від версії та від дії запису, тому перевірте це на своїй ASA, а не припускайте, що результат належить одному з механізмів.

Три режими відмови пояснюють більшу частину плутанини. Карта, яка визначена, але ніколи не прив'язана до тегу сервера, що його використовує профіль, дає політику за замовчуванням без жодної помилки будь-де. Рядок умови DAP, що відрізняється від значення каталогу регістром або пробілами, ніколи не збігається, і резервний запис тихо застосовується. А групова політика, якої ще немає, приймається картою, бо карта повертає лише назву, тому сеанс не отримує жодного з передбачених дозволів, і в журналі немає нічого, що вказувало б на відсутній об'єкт. Перевірте всі три, перш ніж торкатися членства в групах.

Читання доказів із живого сеансу

Читайте відповідь із нового сеансу, а не з конфігурації. show vpn-sessiondb detail anyconnect filter name jdoe друкує групову політику, яку сеанс справді отримав, а show running-config ldap attribute-map підтверджує, які значення карта могла повернути. На боці каталогу test aaa-server authentication LDAP-AD username jdoe password <password> показує атрибути, які ASA отримала назад, а debug ldap 255 показує обмін, коли тест розходиться з вашими очікуваннями.

Потім узгодьте чотири записи письмово: значення з каталогу, налаштовану карту або умову DAP, локальну групову політику та ресурс, до якого користувач справді зміг дістатися. Якщо перші три збігаються, а четвертий ні, проблема в тілі політики, а не у виборі. Якщо сеанс показує правильну назву політики, але неправильний ACL, повністю припиніть дивитися на LDAP. Змінюйте по одному запису і перевіряйте новий сеанс, бо перепідключений сеанс — єдиний доказ, що відображає щойно написану конфігурацію.