ASA LDAP mapiranje grupa nasuprot DAP-u za VPN grupnu politiku

Dva odvojena zapisa odlučuju koju grupnu politiku prima AnyConnect sesija, i oni žive u različitim dijelovima konfiguracije s različitim načinima kvara. LDAP karta atributa prevodi vrijednost iz imenika u ASA atribut autorizacije tijekom autentikacije; DAP zapis zatim procjenjuje uvjete i može dodati ili nadjačati atribute. Oba mogu završiti na istom imenu politike, pa prijava koja radi ne govori ništa o tome koji je mehanizam to proizveo. Smisao njihove usporedbe je svjesno odabrati jedan, umjesto da drugi tiho nadjača prvi.

Dva mehanizma, dvije točke odluke

Izbor se svodi na tri pitanja. Ovisi li odluka o jednoj vrijednosti atributa iz imenika, treba li joj više od te vrijednosti, i koji mehanizam smije pobijediti kada se oba podudaraju?

Ako je jedini ulaz članstvo u grupi, karta atributa manji je alat i onaj koji se lakše revidira: jedna karta, vezana uz jedan AAA poslužitelj, s jednim retkom po grupi. Ako izbor mora uzeti u obzir stanje uređaja, identitet krajnje točke, drugi atribut ili vremenski prozor, karti ponestaje ulaza i DAP je mehanizam koji može izraziti pravilo. Ako su oba u igri, naučite prvenstvo na svom izdanju prije nego što napišete bilo koji od njih, jer sesija koja se podudara s DAP zapisom možda neće zadržati politiku koju je karta vratila. Sve ostalo je knjigovodstvo.

Put karte atributa, po redu konfiguracije

Put karte počinje kod definicije AAA poslužitelja. Karta atributa mora biti vezana uz unos LDAP poslužitelja koji profil veze stvarno koristi; karta koja postoji u radnoj konfiguraciji ali na koju taj poslužitelj ne upućuje ne mijenja ništa. Upravo taj redak vezivanja čini ostatak konfiguracije živim. Vodič za LDAP mapiranje u ASA referenca je za sintaksu karte u izdanjima 9.x.

Unutar karte jedan iskaz imenuje atribut imenika i ASA atribut koji on hrani, a daljnji iskazi prevode konkretne vrijednosti. map-name memberOf Group-Policy nakon čega slijedi map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly jest oblik: lijeva strana je ono što je imenik vratio, desna strana je ime grupne politike koja mora već postojati. Prepoznatljivo ime i prikazno ime politike nisu zamjenjivi, a gotovo podudaranje u bilo kojem od stringova ne proizvodi grešku pri prijavi.

Dva detalja ovdje grizu: memberOf vraća svaku grupu kojoj račun pripada, pa korisnik u dvije mapirane grupe daje karti dvije kandidat-vrijednosti, a abecedno pravilo u vodiču jedini je način razrješenja izjednačenja na koji se možete osloniti umjesto vlastitog redoslijeda prioriteta. Nemapirana vrijednost ne daje ništa, što tiho pada natrag na zadanu politiku profila.

Put DAP-a i što on dodaje

DAP procjenjuje uvjete i primjenjuje atribute povrh AAA rezultata. Zapis nosi prioritet, akciju i skup uvjeta; zapisi se procjenjuju po redu prioriteta, a akcija odlučuje nastavlja li se procjena ili zaustavlja. To je drukčiji model izvršavanja od traženja vrijednosti, i upravo zato može izraziti pravila koja karta ne može.

Ono što DAP dodaje jesu ulazi. Uvjeti mogu upućivati na atribute imenika, atribute krajnje točke i stanje uređaja, a odgovarajući zapis može nositi ACL-ove, URL popise ili filtre za tu sesiju. Zato je pravilo poput „osoblje podrške na upravljanom prijenosniku dobiva politiku samo za čitanje, a isto osoblje na neupravljanom uređaju dobiva ograničenu“ izrazivo u DAP-u, ali ne u karti atributa. Karta ima točno jedan ulaz: vrijednost koju je imenik vratio za atribut koji ste naveli.

DAP dodaje i drugo mjesto za provjeru kada sesija završi u pogrešnoj politici. Zapis koji se podudara s akcijom nastavljanja ne završava procjenu, a kasniji zapis još može promijeniti ishod, pa je ono što vidite proizvod niza, a ne jednog traženja. Čitajte brojeve prioriteta po redu i zapamtite da rezervni zapis može biti onaj koji obavlja posao. Karta, nasuprot tome, nema niz: jedan atribut, jedna vrijednost, jedan odgovor.

Gdje se njih dvije razilaze

Prvenstvo je dio koji lomi dizajne. Kada se sesija podudara i s unosom karte i s DAP zapisom, ishod ovisi o izdanju i o akciji zapisa, pa to provjerite na svom ASA uređaju umjesto da pretpostavljate da bilo koji mehanizam posjeduje ishod.

Tri načina kvara objašnjavaju većinu zbrke. Karta koja je definirana ali nikada vezana uz oznaku poslužitelja koju profil koristi daje zadanu politiku bez ikakve greške igdje. String uvjeta DAP-a koji se od vrijednosti imenika razlikuje po velikom i malom slovu ili razmacima nikada se ne podudara, i rezervni zapis se tiho primjenjuje. A grupna politika koja još ne postoji biva prihvaćena od karte, jer karta vraća samo ime, pa sesija ne dobiva nijednu od predviđenih dozvola i u zapisniku nema ničega što pokazuje na objekt koji nedostaje. Provjerite sva tri prije nego što dirate članstvo u grupama.

Čitanje dokaza sa žive sesije

Čitajte odgovor sa svježe sesije, a ne iz konfiguracije. show vpn-sessiondb detail anyconnect filter name jdoe ispisuje grupnu politiku koju je sesija stvarno primila, a show running-config ldap attribute-map potvrđuje koje je vrijednosti karta mogla vratiti. Na strani imenika test aaa-server authentication LDAP-AD username jdoe password <password> pokazuje atribute koje je ASA dobio natrag, a debug ldap 255 pokazuje razmjenu kada se test ne slaže s vašim očekivanjem.

Zatim uskladite četiri zapisa napismeno: vrijednost iz imenika, konfiguriranu kartu ili DAP uvjet, lokalnu grupnu politiku i resurs do kojeg je korisnik stvarno mogao stići. Ako se prva tri slažu, a četvrti ne, problem je u tijelu politike, a ne u izboru. Ako sesija pokazuje ispravno ime politike ali pogrešan ACL, prestanite potpuno gledati u LDAP. Mijenjajte jedan zapis po jedan i provjerite novu sesiju, jer je ponovno povezana sesija jedini dokaz koji odražava konfiguraciju koju ste upravo napisali.