ASA LDAP-groepstoewysing teenoor DAP vir VPN-groepsbeleid
'n LDAP-kenmerkkaart en 'n DAP-beleid kies albei 'n groepsbeleid, maar hulle werk op verskillende punte. Spoor na watter een jou ASA-sessie werklik gebruik het.
Twee afsonderlike rekords bepaal watter groepsbeleid 'n AnyConnect-sessie ontvang, en hulle staan op verskillende plekke in die konfigurasie met verskillende faalwyses. 'n LDAP-kenmerkkaart skakel 'n gidswaarde tydens verifikasie om na 'n ASA-magtigingskenmerk; 'n DAP-rekord evalueer daarna voorwaardes en kan kenmerke byvoeg of oorskryf. Albei kan by dieselfde beleidnaam eindig, so 'n aanmelding wat werk sê niks oor watter meganisme dit opgelewer het nie. Die doel van die vergelyking is om een doelbewus te kies eerder as om die tweede die eerste stilweg te laat oorheers.
Twee meganismes, twee besluitpunte
Die keuse kom op drie vrae neer. Hang die besluit van 'n enkele gidswaarde af, het dit meer as daardie waarde nodig, en watter meganisme mag wen wanneer albei pas?
As die enigste inset groepildmaatskap is, is die kenmerkkaart die kleiner instrument en die maklikste om te ouditeer: een kaart, gekoppel aan een AAA-bediener, met een reël per groep. As die keuse postuur, eindpuntidentiteit, 'n tweede kenmerk of 'n tydvenster moet oorweeg, raak die kaart se insette op en is DAP die meganisme wat die reël kan uitdruk. As albei in die spel is, leer die voorrang op jou weergawe voordat jy enigeen skryf, want 'n sessie wat by 'n DAP-rekord pas, behou dalk nie die beleid wat die kaart teruggegee het nie. Al die res is boekhouding.
Die kenmerkkaart-roete, in konfigurasievolgorde
Die kaartroete begin by die AAA-bedienerdefinisie. Die kenmerkkaart moet gekoppel wees aan die LDAP-bedienerinskrywing wat die verbindingsprofiel werklik gebruik; 'n kaart wat in die lopende konfigurasie bestaan maar nie deur daardie bediener verwys word nie, verander niks. Dit is daardie koppelingsreël wat die res van die konfigurasie lewendig maak. Die ASA LDAP-kaartgids is die verwysing vir die kaartsintaksis op 9.x-weergawes.
Binne die kaart noem een stelling die gidskenmerk en die ASA-kenmerk wat dit voed, en verdere stellings vertaal spesifieke waardes. map-name memberOf Group-Policy gevolg deur map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly is die vorm: die linkerkant is wat die gids teruggegee het, die regterkant is die naam van 'n groepsbeleid wat reeds moet bestaan. 'n Onderskeidende naam en 'n beleidvertoonnaam is nie verwisselbaar nie, en 'n byna-treffer in enige van die twee stringe lewer geen fout by aanmelding nie.
Twee besonderhede byt hier: memberOf gee elke groep terug waaraan die rekening behoort, so 'n gebruiker in twee gekarteerde groepe gee die kaart twee kandidaatwaardes, en die alfabetiese reël in die gids is die enigste gelykop-beslegting waarop jy kan staatmaak eerder as jou eie prioriteitsorde. 'n Ongekarteerde waarde lewer niks, wat stilweg terugval na die profiel se standaardbeleid.
Die DAP-roete, en wat dit byvoeg
DAP evalueer voorwaardes en pas kenmerke bo-op die AAA-resultaat toe. 'n Rekord dra 'n prioriteit, 'n aksie en 'n stel voorwaardes; rekords word in prioriteitsorde geëvalueer en die aksie besluit of evaluering voortgaan of stop. Dit is 'n ander uitvoeringsmodel as 'n waardesoektog, en juis daarom kan dit reëls uitdruk wat die kaart nie kan nie.
Wat DAP byvoeg, is insette. Voorwaardes kan gidskenmerke, eindpuntkenmerke en postuurtoestand verwys, en 'n passende rekord kan ACL's, URL-lyste of filters vir daardie sessie dra. 'n Reël soos ondersteuningspersoneel op 'n bestuurde skootrekenaar kry die leesalleen-beleid, terwyl dieselfde personeel op 'n onbestuurde toestel 'n beperkte een kry, is dus in DAP uitdrukbaar en nie in 'n kenmerkkaart nie. Die kaart het presies een inset: die waarde wat die gids teruggegee het vir die kenmerk wat jy genoem het.
DAP voeg ook 'n tweede plek by om te kyk wanneer 'n sessie in die verkeerde beleid beland. 'n Rekord wat pas met 'n aksie van continue, beëindig nie die evaluering nie, en 'n latere rekord kan die uitkoms steeds verander, so wat jy sien is die produk van 'n reeks eerder as 'n enkele soektog. Lees die prioriteitsnommers in volgorde, en onthou dat dit dalk 'n terugvalrekord is wat die werk doen. Die kaart het daarenteen geen reeks nie: een kenmerk, een waarde, een antwoord.
Waar die twee van mekaar verskil
Voorrang is die deel wat ontwerpe breek. Wanneer 'n sessie by sowel 'n kaartinskrywing as 'n DAP-rekord pas, hang die resultaat van die weergawe en die rekordaksie af, so verifieer dit op jou eie ASA in plaas daarvan om te aanvaar dat een van die meganismes die uitkoms besit.
Drie faalwyses veroorsaak die meeste verwarring. 'n Kaart wat gedefinieer is maar nooit gekoppel is aan die bedieneretiket wat die profiel gebruik nie, lewer die standaardbeleid met geen fout enige plek nie. 'n DAP-voorwaardestring wat in geval of witruimte van die gidswaarde verskil, pas nooit, en die terugvalrekord tree stilweg in werking. En 'n groepsbeleid wat nog nie bestaan nie, word deur die kaart aanvaar, want die kaart gee net 'n naam terug, so die sessie kry nie die beoogde regte nie met niks in die log wat na die ontbrekende objek wys. Kontroleer al drie voordat jy aan groepildmaatskap raak.
Lees die bewyse van 'n lewendige sessie af
Lees die antwoord van 'n vars sessie af eerder as van die konfigurasie. show vpn-sessiondb detail anyconnect filter name jdoe druk die groepsbeleid uit wat die sessie werklik ontvang het, en show running-config ldap attribute-map bevestig watter waardes die kaart kon teruggegee het. Aan die gidskant wys test aaa-server authentication LDAP-AD username jdoe password <password> watter kenmerke die ASA teruggekry het, en debug ldap 255 wys die uitruiling wanneer die toets van jou verwagting verskil.
Versoen dan vier rekords op skrif: die gidswaarde, die gekonfigureerde kaart of DAP-voorwaarde, die plaaslike groepsbeleid, en die hulpbron wat die gebruiker werklik kon bereik. As die eerste drie ooreenstem en die vierde nie, is die probleem in die beleidsliggaam en nie in die keuse nie. As die sessie die regte beleidnaam maar die verkeerde ACL wys, hou heeltemal op om na LDAP te kyk. Verander een rekord op 'n slag en kontroleer 'n nuwe sessie weer, want 'n heropgerigte sessie is die enigste bewys wat die konfigurasie weerspieël wat jy pas geskryf het.