Preslikava skupin LDAP v ASA proti DAP za skupinsko politiko VPN

Dva ločena zapisa odločata, katero skupinsko politiko prejme seja AnyConnect, in živita v različnih delih konfiguracije z različnimi načini odpovedi. Zemljevid atributov LDAP med preverjanjem pristnosti pretvori vrednost iz imenika v atribut avtorizacije ASA; zapis DAP nato oceni pogoje in lahko atribute doda ali prepiše. Oba se lahko končata z istim imenom politike, zato uspešna prijava ne pove ničesar o tem, kateri mehanizem jo je ustvaril. Smisel primerjave je zavestno izbrati enega, namesto da bi drugi tiho preglasil prvega.

Dva mehanizma, dve točki odločitve

Izbira se zvede na tri vprašanja. Ali je odločitev odvisna od ene same vrednosti atributa iz imenika, ali potrebuje več kot to vrednost, in kateri mehanizem sme zmagati, ko se oba ujemata?

Če je edini vnos članstvo v skupini, je zemljevid atributov manjše orodje in tisto, ki ga je lažje pregledati: en zemljevid, vezan na en strežnik AAA, z eno vrstico na skupino. Če mora izbira upoštevati stanje naprave, identiteto končne točke, drugi atribut ali časovno okno, zemljevidu zmanjka vnosov in DAP je mehanizem, ki lahko izrazi pravilo. Če sta v igri oba, spoznajte prednost v svoji izdaji, preden napišete katerega od njiju, ker seja, ki se ujema z zapisom DAP, morda ne bo ohranila politike, ki jo je vrnil zemljevid. Vse ostalo je knjigovodstvo.

Pot zemljevida atributov, v vrstnem redu konfiguracije

Pot zemljevida se začne pri definiciji strežnika AAA. Zemljevid atributov mora biti vezan na vnos strežnika LDAP, ki ga profil povezave dejansko uporablja; zemljevid, ki v delujoči konfiguraciji obstaja, a se ta strežnik nanj ne sklicuje, ne spremeni ničesar. Prav ta vrstica vezave oživi preostalo konfiguracijo. vodnik za preslikavo LDAP v ASA je referenca za sintakso zemljevida v različicah 9.x.

Znotraj zemljevida ena izjava poimenuje atribut imenika in atribut ASA, ki ga napaja, nadaljnje izjave pa pretvorijo določene vrednosti. map-name memberOf Group-Policy ki mu sledi map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly je oblika: leva stran je tisto, kar je vrnil imenik, desna stran je ime skupinske politike, ki mora že obstajati. Razločevalno ime in prikazno ime politike nista zamenljiva, in skoraj ujemanje v katerem koli od obeh nizov ne povzroči nobene napake pri prijavi.

Dve podrobnosti tu ugrizneta: memberOf vrne vsako skupino, ki ji račun pripada, zato uporabnik v dveh preslikanih skupinah zemljevidu da dve kandidatni vrednosti, in abecedno pravilo v vodniku je edino razreševanje izenačenja, na katero se lahko zanesete namesto lastnega vrstnega reda prednostnih nalog. Nepreslikana vrednost ne da ničesar, kar tiho pade nazaj na privzeto politiko profila.

Pot DAP in kaj doda

DAP ocenjuje pogoje in uporablja atribute nad rezultatom AAA. Zapis nosi prednost, dejanje in niz pogojev; zapisi se ocenjujejo po vrstnem redu prednosti, dejanje pa odloči, ali se ocenjevanje nadaljuje ali ustavi. To je drugačen izvedbeni model kot iskanje vrednosti, in prav zato lahko izrazi pravila, ki jih zemljevid ne more.

Kar DAP doda, so vnosi. Pogoji se lahko sklicujejo na atribute imenika, atribute končne točke in stanje naprave, ujemajoči zapis pa lahko nosi sezname ACL, sezname URL ali filtre za to sejo. Zato je pravilo, da osebje za podporo na upravljanem prenosniku prejme politiko samo za branje, isto osebje na neupravljani napravi pa omejeno, izrazljivo v DAP in ne v zemljevidu atributov. Zemljevid ima natanko en vnos: vrednost, ki jo je imenik vrnil za atribut, ki ste ga navedli.

DAP doda tudi drugo mesto za pogled, ko seja pristane v napačni politiki. Zapis, ki se ujema z dejanjem nadaljevanja, ne konča ocenjevanja, in poznejši zapis lahko še vedno spremeni izid, zato je tisto, kar opazujete, produkt zaporedja in ne enega iskanja. Berite številke prednosti po vrsti in ne pozabite, da je delo morda opravil nadomestni zapis. Zemljevid nasprotno nima zaporedja: en atribut, ena vrednost, en odgovor.

Kjer se oba ne strinjata

Prednost je del, ki lomi zasnove. Ko se seja ujema tako z vnosom zemljevida kot z zapisom DAP, je izid odvisen od izdaje in od dejanja zapisa, zato to preverite na svojem ASA, namesto da bi domnevali, da izid pripada enemu od mehanizmov.

Trije načini odpovedi pojasnjujejo večino zmede. Zemljevid, ki je definiran, a nikoli vezan na oznako strežnika, ki jo uporablja profil, da privzeto politiko brez kakršne koli napake kjer koli. Niz pogoja DAP, ki se od vrednosti imenika razlikuje po velikih in malih črkah ali presledkih, se nikoli ne ujema, in nadomestni zapis se tiho uporabi. In skupinska politika, ki še ne obstaja, je s strani zemljevida sprejeta, ker zemljevid vrne samo ime, zato seja ne prejme nobenega od predvidenih dovoljenj in v dnevniku ni ničesar, kar bi kazalo na manjkajoči objekt. Preverite vse tri, preden se dotaknete članstva v skupinah.

Branje dokazov iz žive seje

Odgovor berite iz nove seje in ne iz konfiguracije. show vpn-sessiondb detail anyconnect filter name jdoe izpiše skupinsko politiko, ki jo je seja dejansko prejela, in show running-config ldap attribute-map potrdi, katere vrednosti bi zemljevid lahko vrnil. Na strani imenika test aaa-server authentication LDAP-AD username jdoe password <password> pokaže atribute, ki jih je ASA prejela nazaj, in debug ldap 255 pokaže izmenjavo, ko se test ne ujema s tem, kar ste pričakovali.

Nato uskladite štiri zapise pisno: vrednost iz imenika, konfigurirani zemljevid ali pogoj DAP, lokalno skupinsko politiko in vir, do katerega je uporabnik dejansko lahko prišel. Če se prvi trije ujemajo, četrti pa ne, je težava v telesu politike in ne v izbiri. Če seja pokaže pravilno ime politike, a napačen ACL, prenehajte povsem gledati v LDAP. Spreminjajte en zapis naenkrat in znova preverite novo sejo, ker je ponovno povezana seja edini dokaz, ki odraža konfiguracijo, ki ste jo pravkar napisali.