Mapovanie skupín LDAP v ASA verzus DAP pre skupinovú politiku VPN

O tom, ktorú skupinovú politiku relácia AnyConnect dostane, rozhodujú dva samostatné záznamy, a žijú v rôznych častiach konfigurácie s rôznymi režimami zlyhania. Mapa atribútov LDAP prekladá počas overovania hodnotu z adresára na autorizačný atribút ASA; záznam DAP potom vyhodnocuje podmienky a môže atribúty pridať alebo prepísať. Oba môžu skončiť na rovnakom názve politiky, takže prihlásenie, ktoré funguje, vám nepovie, ktorý mechanizmus ho vytvoril. Zmyslom porovnania je vybrať jeden vedome, namiesto toho, aby druhý ticho prepísal prvý.

Dva mechanizmy, dva rozhodovacie body

Voľba sa redukuje na tri otázky. Závisí rozhodnutie od jedinej hodnoty atribútu z adresára, potrebuje viac ako túto hodnotu, a ktorý mechanizmus smie vyhrať, keď sa oba zhodujú?

Ak je jediným vstupom členstvo v skupine, mapa atribútov je menší nástroj a ten, ktorý sa ľahšie audituje: jedna mapa pripojená k jednému serveru AAA, jeden riadok na skupinu. Ak musí výber zohľadniť stav zariadenia, identitu koncového bodu, druhý atribút alebo časové okno, mape dôjdu vstupy a DAP je mechanizmus, ktorý pravidlo dokáže vyjadriť. Ak sú v hre oba, zistite prioritu vo svojom vydaní, skôr než napíšete ktorýkoľvek z nich, pretože relácia, ktorá zodpovedá záznamu DAP, nemusí zachovať politiku, ktorú mapa vrátila. Všetko ostatné je účtovníctvo.

Cesta mapy atribútov, v poradí konfigurácie

Cesta mapy začína pri definícii servera AAA. Mapa atribútov musí byť pripojená k záznamu servera LDAP, ktorý profil pripojenia skutočne používa; mapa, ktorá v bežiacej konfigurácii existuje, ale nie je týmto serverom odkazovaná, nič nemení. Práve tento riadok pripojenia oživuje zvyšok konfigurácie. sprievodca mapovaním LDAP v ASA je referenciou pre syntax mapy vo verziách 9.x.

Vnútri mapy jeden príkaz pomenúva atribút adresára a atribút ASA, ktorý zásobuje, a ďalšie príkazy prekladajú konkrétne hodnoty. map-name memberOf Group-Policy nasledované map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly je tvar: ľavá strana je to, čo adresár vrátil, pravá strana je názov skupinovej politiky, ktorá už musí existovať. Rozlišujúce meno a zobrazované meno politiky nie sú zameniteľné a takmer zhoda v ktoromkoľvek z oboch reťazcov nespôsobí pri prihlásení žiadnu chybu.

Dva detaily tu hryzú: memberOf vracia každú skupinu, do ktorej účet patrí, takže používateľ v dvoch mapovaných skupinách dáva mape dve kandidátske hodnoty, a abecedné pravidlo v sprievodcovi je jediné rozhodnutie remízy, na ktoré sa môžete spoľahnúť namiesto vlastného poradia priorít. Nemapovaná hodnota nevracia nič, čo ticho padne späť na predvolenú politiku profilu.

Cesta DAP a čo pridáva

DAP vyhodnocuje podmienky a aplikuje atribúty nad výsledok AAA. Záznam nesie prioritu, akciu a súbor podmienok; záznamy sa vyhodnocujú v poradí priority a akcia rozhoduje, či vyhodnocovanie pokračuje alebo sa zastaví. To je iný model vykonávania ako vyhľadanie hodnoty, a práve preto dokáže vyjadriť pravidlá, ktoré mapa nedokáže.

To, čo DAP pridáva, sú vstupy. Podmienky môžu odkazovať atribúty adresára, atribúty koncového bodu a stav zariadenia a zodpovedajúci záznam môže niesť zoznamy ACL, zoznamy URL alebo filtre pre danú reláciu. Preto pravidlo typu „pracovníci podpory na spravovanom notebooku dostanú politiku iba na čítanie, kým tí istí pracovníci na nespravovanom zariadení dostanú obmedzenú“ je vyjadriteľné v DAP, ale nie v mape atribútov. Mapa má presne jeden vstup: hodnotu, ktorú adresár vrátil pre atribút, ktorý ste pomenovali.

DAP tiež pridáva druhé miesto, kam sa pozrieť, keď relácia skončí v nesprávnej politike. Záznam, ktorý zodpovedá akcii pokračovať, neukončuje vyhodnocovanie a neskorší záznam môže výsledok ešte zmeniť, takže to, čo vidíte, je súčin postupnosti, nie jediného vyhľadania. Čítajte čísla priorít v poradí a pamätajte, že prácu môže vykonávať záložný záznam. Mapa naopak žiadnu postupnosť nemá: jeden atribút, jedna hodnota, jedna odpoveď.

Kde sa oba rozchádzajú

Priorita je časť, ktorá láme návrhy. Keď relácia zodpovedá záznamu mapy aj záznamu DAP, výsledok závisí od vydania a od akcie záznamu, takže si to overte na svojej vlastnej ASA, namiesto toho, aby ste predpokladali, že výsledok vlastní jeden z mechanizmov.

Tri režimy zlyhania vysvetľujú väčšinu zmätku. Mapa, ktorá je definovaná, ale nikdy nie je pripojená k značke servera, ktorú profil používa, dáva predvolenú politiku bez akejkoľvek chyby kdekoľvek. Reťazec podmienky DAP, ktorý sa od hodnoty adresára líši veľkosťou písmen alebo medzerami, nikdy nezodpovedá a záložný záznam sa ticho použije. A skupinová politika, ktorá ešte neexistuje, je mapou prijatá, pretože mapa vracia len názov, takže relácia nezíska žiadne z plánovaných oprávnení a v logu nie je nič, čo by ukazovalo na chýbajúci objekt. Skontrolujte všetky tri, skôr než sa dotknete členstva v skupinách.

Čítanie dôkazov z živej relácie

Čítajte odpoveď z novej relácie, nie z konfigurácie. show vpn-sessiondb detail anyconnect filter name jdoe vypíše skupinovú politiku, ktorú relácia skutočne dostala, a show running-config ldap attribute-map potvrdí, ktoré hodnoty mohla mapa vrátiť. Na strane adresára test aaa-server authentication LDAP-AD username jdoe password <password> ukazuje atribúty, ktoré ASA dostala späť, a debug ldap 255 ukazuje výmenu, keď test nezodpovedá tomu, čo ste očakávali.

Potom zosúlaďte štyri záznamy písomne: hodnotu adresára, nakonfigurovanú mapu alebo podmienku DAP, lokálnu skupinovú politiku a zdroj, ku ktorému sa používateľ skutočne dostal. Ak prvé tri sedia a štvrtý nie, problém je v tele politiky, nie vo výbere. Ak relácia ukazuje správny názov politiky, ale nesprávny ACL, prestaňte sa úplne pozerať na LDAP. Meňte jeden záznam po druhom a znova skontrolujte novú reláciu, pretože znova pripojená relácia je jediný dôkaz, ktorý odráža konfiguráciu, ktorú ste práve napísali.