Сопоставление групп 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. Меняйте по одной записи и проверяйте новый сеанс, потому что переподключённый сеанс — единственное доказательство, отражающее только что написанную конфигурацию.