Maparea grupurilor LDAP în ASA versus DAP pentru politica de grup VPN

Două înregistrări separate decid care politică de grup primește o sesiune AnyConnect, iar ele trăiesc în părți diferite ale configurației cu moduri de eșec diferite. O hartă de atribute LDAP traduce o valoare din director într-un atribut de autorizare ASA în timpul autentificării; o înregistrare DAP evaluează condiții după aceea și poate adăuga sau suprascrie atribute. Ambele pot ajunge la același nume de politică, deci o autentificare care funcționează nu vă spune nimic despre mecanismul care a produs-o. Sensul comparației este să alegeți unul deliberat în loc să lăsați al doilea să îl anuleze silențios pe primul.

Două mecanisme, două puncte de decizie

Alegerea se reduce la trei întrebări. Depinde decizia de o singură valoare de atribut din director, are nevoie de mai mult decât acea valoare, și care mecanism are voie să câștige când ambele se potrivesc?

Dacă singura intrare este apartenența la grup, harta de atribute este instrumentul mai mic și cel mai ușor de auditat: o hartă, legată de un singur server AAA, cu o linie pe grup. Dacă selecția trebuie să țină cont de starea dispozitivului, de identitatea endpointului, de un al doilea atribut sau de o fereastră de timp, harta rămâne fără intrări și DAP este mecanismul care poate exprima regula. Dacă ambele sunt în joc, aflați precedența în versiunea dumneavoastră înainte de a scrie oricare dintre ele, pentru că o sesiune care se potrivește cu o înregistrare DAP poate să nu păstreze politica returnată de hartă. Restul este contabilitate.

Calea hărții de atribute, în ordinea configurației

Calea hărții începe la definiția serverului AAA. Harta de atribute trebuie să fie legată de intrarea serverului LDAP pe care profilul de conexiune o folosește efectiv; o hartă care există în configurația rulantă dar nu este referită de acel server nu schimbă nimic. Acea linie de legare este cea care face vie restul configurației. ghidul de mapare LDAP al ASA este referința pentru sintaxa hărții în versiunile 9.x.

În interiorul hărții, o instrucțiune numește atributul din director și atributul ASA pe care îl alimentează, iar alte instrucțiuni traduc valori concrete. map-name memberOf Group-Policy urmat de map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly este forma: partea stângă este ce a returnat directorul, partea dreaptă este numele unei politici de grup care trebuie să existe deja. Un nume distinctiv și un nume de afișare al politicii nu sunt interschimbabile, iar o aproape-potrivire în oricare dintre cele două șiruri nu produce nicio eroare la autentificare.

Două detalii mușcă aici: memberOf returnează fiecare grup din care face parte contul, așa că un utilizator din două grupuri mapate îi dă hărții două valori candidate, iar regula alfabetică din ghid este singurul departajator pe care vă puteți baza în locul propriei ordini de prioritate. O valoare nemapată nu dă nimic, ceea ce cade silențios pe politica implicită a profilului.

Calea DAP și ce adaugă ea

DAP evaluează condiții și aplică atribute peste rezultatul AAA. O înregistrare poartă o prioritate, o acțiune și un set de condiții; înregistrările sunt evaluate în ordinea priorității, iar acțiunea decide dacă evaluarea continuă sau se oprește. Este un model de execuție diferit de o căutare de valoare, și exact de aceea poate exprima reguli pe care harta nu le poate.

Ce adaugă DAP sunt intrările. Condițiile pot referi atribute din director, atribute ale endpointului și starea dispozitivului, iar o înregistrare potrivită poate purta ACL-uri, liste de URL sau filtre pentru acea sesiune. Astfel, o regulă precum personalul de suport pe un laptop gestionat primește politica doar-citire, în timp ce același personal pe un dispozitiv negestionat primește una restricționată, este exprimabilă în DAP și nu într-o hartă de atribute. Harta are exact o intrare: valoarea pe care directorul a returnat-o pentru atributul pe care l-ați numit.

DAP adaugă și un al doilea loc unde să priviți când o sesiune ajunge în politica greșită. O înregistrare care se potrivește cu acțiunea continuă nu încheie evaluarea, iar o înregistrare ulterioară poate încă schimba rezultatul, așa că ceea ce observați este produsul unei secvențe și nu al unei singure căutări. Citiți numerele de prioritate în ordine și rețineți că înregistrarea de rezervă poate fi cea care face treaba. Harta, dimpotrivă, nu are secvență: un atribut, o valoare, un răspuns.

Unde cele două nu sunt de acord

Precedența este partea care rupe proiectele. Când o sesiune se potrivește atât cu o intrare a hărții, cât și cu o înregistrare DAP, rezultatul depinde de versiune și de acțiunea înregistrării, așa că verificați-l pe propriul ASA în loc să presupuneți că unul dintre mecanisme deține rezultatul.

Trei moduri de eșec explică cea mai mare parte a confuziei. O hartă definită dar niciodată legată de eticheta serverului folosit de profil produce politica implicită fără nicio eroare nicăieri. Un șir de condiție DAP care diferă de valoarea directorului prin majuscule sau spații nu se potrivește niciodată, iar înregistrarea de rezervă se aplică silențios. Și o politică de grup care încă nu există este acceptată de hartă, pentru că harta returnează doar un nume, așa că sesiunea nu primește niciuna dintre permisiunile dorite și nu există nimic în jurnal care să indice obiectul lipsă. Verificați toate trei înainte de a atinge apartenența la grup.

Citirea dovezilor de pe o sesiune activă

Citiți răspunsul de pe o sesiune nouă și nu din configurație. show vpn-sessiondb detail anyconnect filter name jdoe afișează politica de grup pe care sesiunea a primit-o efectiv, iar show running-config ldap attribute-map confirmă ce valori ar fi putut returna harta. Pe partea de director, test aaa-server authentication LDAP-AD username jdoe password <password> arată atributele pe care ASA le-a primit înapoi, iar debug ldap 255 arată schimbul când testul nu se potrivește cu ce ați așteptat.

Apoi reconciliați patru înregistrări în scris: valoarea din director, harta sau condiția DAP configurate, politica de grup locală și resursa la care utilizatorul a ajuns efectiv. Dacă primele trei se potrivesc și a patra nu, problema este în corpul politicii și nu în selecție. Dacă sesiunea arată numele corect al politicii dar ACL-ul greșit, opriți complet să vă uitați la LDAP. Schimbați o înregistrare pe rând și verificați din nou o sesiune nouă, pentru că o sesiune reconectată este singura dovadă care reflectă configurația pe care tocmai ați scris-o.