Mapování skupin LDAP v ASA versus DAP pro zásady skupin VPN

Dva samostatné záznamy rozhodují o tom, kterou zásadu skupiny relace AnyConnect dostane, a žijí v různých částech konfigurace s různými režimy selhání. Mapa atributů LDAP překládá hodnotu z adresáře na autorizační atribut ASA během ověřování; záznam DAP poté vyhodnocuje podmínky a může atributy přidat nebo přepsat. Oba mohou skončit u stejného názvu zásady, takže přihlášení, které funguje, vám neřekne, který mechanismus ho vytvořil. Smyslem srovnání je vybrat jeden vědomě, místo aby druhý tiše přebil první.

Dva mechanismy, dva rozhodovací body

Volba se redukuje na tři otázky. Závisí rozhodnutí na jediné hodnotě atributu z adresáře, potřebuje víc než tuto hodnotu, a který mechanismus smí vyhrát, když se oba shodují?

Pokud je jediným vstupem členství ve skupině, je mapa atributů menší nástroj a ten, který se snáze audituje: jedna mapa připojená k jednomu serveru AAA, jeden řádek na skupinu. Pokud musí výběr zohlednit stav zařízení, identitu koncového bodu, druhý atribut nebo časové okno, mapě dojdou vstupy a DAP je mechanismsus, který pravidlo dokáže vyjádřit. Pokud jsou ve hře oba, zjistěte prioritu ve svém vydání, než napíšete kterýkoli z nich, protože relace, která odpovídá záznamu DAP, nemusí zachovat zásadu, kterou mapa vrátila. Vše ostatní je účetnictví.

Cesta mapy atributů, v pořadí konfigurace

Cesta mapy začíná u definice serveru AAA. Mapa atributů musí být připojena k záznamu serveru LDAP, který profil připojení skutečně používá; mapa, která v běžící konfiguraci existuje, ale není tímto serverem odkazována, nic nemění. Právě tento řádek připojení oživuje zbytek konfigurace. Průvodce mapováním LDAP v ASA je referencí pro syntaxi mapy ve verzích 9.x.

Uvnitř mapy jeden příkaz pojmenovává atribut adresáře a atribut ASA, který zásobuje, a další příkazy překládají konkrétní hodnoty. map-name memberOf Group-Policy následované map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly je tvar: levá strana je to, co adresář vrátil, pravá strana je název zásady skupiny, která už musí existovat. Rozlišující jméno a zobrazované jméno zásady nejsou zaměnitelné a téměř shoda v kterémkoli z obou řetězců nevyvolá při přihlášení žádnou chybu.

Dva detaily tu koušou: memberOf vrací každou skupinu, do níž účet patří, takže uživatel ve dvou mapovaných skupinách dává mapě dvě kandidátní hodnoty, a abecední pravidlo v průvodci je jediné rozhodnutí remízy, na které se můžete spolehnout místo vlastního pořadí priorit. Nemapovaná hodnota nevrací nic, což tiše spadne zpět na výchozí zásadu profilu.

Cesta DAP a co přidává

DAP vyhodnocuje podmínky a aplikuje atributy nad výsledek AAA. Záznam nese prioritu, akci a sadu podmínek; záznamy se vyhodnocují v pořadí priority a akce rozhoduje, zda vyhodnocování pokračuje, nebo se zastaví. To je jiný model provádění než vyhledání hodnoty, a právě proto dokáže vyjádřit pravidla, která mapa neumí.

Co DAP přidává, jsou vstupy. Podmínky mohou odkazovat atributy adresáře, atributy koncového bodu a stav zařízení a odpovídající záznam může nést seznamy ACL, seznamy URL nebo filtry pro danou relaci. Pravidlo typu „pracovníci podpory na spravovaném notebooku dostanou zásadu pouze pro čtení, zatímco stejní pracovníci na nespravovaném zařízení dostanou omezenou“ je proto vyjádřitelné v DAP, ale ne v mapě atributů. Mapa má přesně jeden vstup: hodnotu, kterou adresář vrátil pro atribut, který jste pojmenovali.

DAP také přidává druhé místo, kam se dívat, když relace skončí ve špatné zásadě. Záznam, který odpovídá s akcí pokračovat, neukončuje vyhodnocování a pozdější záznam může výsledek ještě změnit, takže to, co vidíte, je součin posloupnosti, ne jediného vyhledání. Čtěte čísla priorit v pořadí a pamatujte, že práci může odvádět záložní záznam. Mapa naopak žádnou posloupnost nemá: jeden atribut, jedna hodnota, jedna odpověď.

Kde se oba rozcházejí

Priorita je část, která láme návrhy. Když relace odpovídá jak záznamu mapy, tak záznamu DAP, výsledek závisí na vydání a na akci záznamu, takže si to ověřte na své vlastní ASA, místo abyste předpokládali, že výsledek vlastní jeden z mechanismů.

Tři režimy selhání vysvětlují většinu zmatku. Mapa, která je definovaná, ale nikdy není připojena ke značce serveru, kterou profil používá, dává výchozí zásadu bez jakékoli chyby kdekoli. Řetězec podmínky DAP, který se od hodnoty adresáře liší velikostí písmen nebo mezerami, nikdy neodpovídá a záložní záznam se tiše použije. A zásada skupiny, která ještě neexistuje, je mapou přijata, protože mapa vrací jen název, takže relace nedostane žádné z zamýšlených oprávnění a v logu není nic, co by ukazovalo na chybějící objekt. Zkontrolujte všechny tři, než se dotknete členství ve skupinách.

Čtení důkazů ze živé relace

Čtěte odpověď z nové relace, ne z konfigurace. show vpn-sessiondb detail anyconnect filter name jdoe vypíše zásadu skupiny, kterou relace skutečně dostala, a show running-config ldap attribute-map potvrdí, které hodnoty mohla mapa vrátit. Na straně adresáře test aaa-server authentication LDAP-AD username jdoe password <password> ukazuje atributy, které ASA dostala zpět, a debug ldap 255 ukazuje výměnu, když test nesouhlasí s tím, co jste očekávali.

Poté slučte čtyři záznamy písemně: hodnotu adresáře, nakonfigurovanou mapu nebo podmínku DAP, místní zásadu skupiny a zdroj, ke kterému se uživatel skutečně dostal. Pokud první tři souhlasí a čtvrtý ne, problém je v těle zásady, ne ve výběru. Pokud relace ukazuje správný název zásady, ale špatný ACL, přestaňte se na LDAP dívat úplně. Měňte jeden záznam po druhém a znovu kontrolujte novou relaci, protože znovu připojená relace je jediným důkazem, který odráží konfiguraci, kterou jste právě napsali.