Съпоставяне на 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. Променяйте по един запис наведнъж и проверявайте нова сесия, защото пресвързаната сесия е единственото доказателство, което отразява конфигурацията, която току-що сте написали.