Мапирање 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. Мењајте по један запис и проверите нову сесију, јер је поново повезана сесија једини доказ који одражава конфигурацију коју сте управо написали.