ASA LDAP-gruppide vastendamine versus DAP VPN-grupi poliitika jaoks

Kaks eraldi kirjet otsustavad, millise grupipoliitika AnyConnecti sessioon saab, ja need asuvad konfiguratsiooni eri osades erinevate tõrkerežiimidega. LDAP-i atribuudikaart tõlgib autentimise ajal kataloogi väärtuse ASA autoriseerimisatribuudiks; DAP-i kirje hindab seejärel tingimusi ning võib atribuute lisada või üle kirjutada. Mõlemad võivad lõppeda sama poliitika nimega, seega töötav sisselogimine ei ütle teile midagi selle kohta, milline mehhanism selle tekitas. Nende võrdlemise mõte on valida teadlikult üks, selle asemel et lasta teisel esimest vaikselt üle trumbata.

Kaks mehhanismi, kaks otsustuspunkti

Valik taandub kolmele küsimusele. Kas otsus sõltub ühest kataloogi atribuudiväärtusest, kas see vajab rohkemat kui see väärtus, ja millisel mehhanismil on lubatud võita, kui mõlemad sobivad?

Kui ainus sisend on grupiliikmelisus, on atribuudikaart väiksem tööriist ja see, mida on lihtsam auditeerida: üks kaart, seotud ühe AAA-serveriga, üks rida grupi kohta. Kui valik peab arvestama seadme seisundit, lõpp-punkti identiteeti, teist atribuuti või ajavahemikku, saavad kaardi sisendid otsa ja DAP on mehhanism, mis suudab reegli väljendada. Kui mõlemad on mängus, õppige oma versiooni prioriteet selgeks enne, kui kirjutate kummagi, sest DAP-i kirjega sobiv sessioon ei pruugi säilitada poliitikat, mille kaart tagastas. Kõik muu on raamatupidamine.

Atribuudikaardi tee, konfiguratsiooni järjekorras

Kaardi tee algab AAA-serveri definitsioonist. Atribuudikaart tuleb siduda selle LDAP-serveri kirjega, mida ühenduse profiil tegelikult kasutab; kaart, mis on töötavas konfiguratsioonis olemas, kuid millele see server ei viita, ei muuda midagi. Just see sidumisrida teeb ülejäänud konfiguratsiooni elavaks. ASA LDAP-i kaardistamise juhend on viide kaardi süntaksile versioonides 9.x.

Kaardi sees nimetab üks lause kataloogi atribuudi ja ASA atribuudi, mida see toidab, ning edasised laused tõlgivad konkreetseid väärtusi. map-name memberOf Group-Policy millele järgneb map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly on vorm: vasak pool on see, mille kataloog tagastas, parem pool on grupipoliitika nimi, mis peab juba olemas olema. Eristav nimi ja poliitika kuvanimi ei ole vahetatavad, ja peaaegu sobivus kummaski stringis ei tekita sisselogimisel ühtegi viga.

Siin hammustavad kaks detaili: memberOf tagastab iga grupi, kuhu konto kuulub, seega kahes kaardistatud grupis olev kasutaja annab kaardile kaks kandidaatväärtust, ja juhendis olev tähestikureegel on ainus viigi lahendus, millele saate loota oma prioriteedijärjestuse asemel. Kaardistamata väärtus ei anna midagi, mis langeb vaikselt tagasi profiili vaikepoliitikale.

DAP-i tee ja mida see lisab

DAP hindab tingimusi ja rakendab atribuute AAA tulemuse peale. Kirje kannab prioriteeti, tegevust ja tingimuste kogumit; kirjeid hinnatakse prioriteedi järjekorras ja tegevus otsustab, kas hindamine jätkub või lõpeb. See on teistsugune täitmismudel kui väärtuse otsing, ja just seepärast suudab see väljendada reegleid, mida kaart ei suuda.

See, mida DAP lisab, on sisendid. Tingimused võivad viidata kataloogi atribuutidele, lõpp-punkti atribuutidele ja seadme seisundile, ning sobiv kirje võib kanda selle sessiooni jaoks ACL-e, URL-loendeid või filtreid. Nii on reegel nagu see, et tugitöötajad haldatud sülearvutis saavad kirjutuskaitstud poliitika, samal ajal kui samad töötajad haldamata seadmes saavad piiratud poliitika, väljendatav DAP-is, mitte aga atribuudikaardis. Kaardil on täpselt üks sisend: väärtus, mille kataloog tagastas teie nimetatud atribuudi jaoks.

DAP lisab ka teise koha, kuhu vaadata, kui sessioon satub valesse poliitikasse. Kirje, mis sobib tegevusega jätka, ei lõpeta hindamist, ja hilisem kirje võib tulemust veel muuta, seega see, mida näete, on järjestuse, mitte üksiku otsingu tulemus. Lugege prioriteedinumbrid järjekorras ja pidage meeles, et töö võib ära teha varukirje. Kaardil seevastu järjestust ei ole: üks atribuut, üks väärtus, üks vastus.

Kus need kaks lahknevad

Prioriteet on see osa, mis disainid puruneb. Kui sessioon sobib nii kaardi kirje kui ka DAP-i kirjega, sõltub tulemus versioonist ja kirje tegevusest, seega kontrollige seda oma ASA peal, selle asemel et eeldada, et üks mehhanismidest omab tulemust.

Kolm tõrkerežiimi seletavad suuremat osa segadusest. Kaart, mis on defineeritud, kuid mida ei ole kunagi seotud profiili kasutatava serverisildiga, annab vaikepoliitika ilma ühegi veata kusagil. DAP-i tingimuse string, mis erineb kataloogi väärtusest suur- ja väiketähtede või tühikute poolest, ei sobi kunagi, ja varukirje rakendub vaikselt. Ja grupipoliitika, mida veel ei ole, võetakse kaardi poolt vastu, sest kaart tagastab ainult nime, seega ei saa sessioon ühtegi kavandatud õigust ja logis ei ole midagi, mis osutaks puuduvale objektile. Kontrollige kõiki kolme enne, kui puudutate grupiliikmelisust.

Tõendite lugemine elavast sessioonist

Lugege vastust värskest sessioonist, mitte konfiguratsioonist. show vpn-sessiondb detail anyconnect filter name jdoe prindib grupipoliitika, mille sessioon tegelikult sai, ja show running-config ldap attribute-map kinnitab, milliseid väärtusi oleks kaart võinud tagastada. Kataloogi poolel näitab test aaa-server authentication LDAP-AD username jdoe password <password> atribuute, mille ASA tagasi sai, ja debug ldap 255 näitab vahetust, kui test ei ühti teie ootusega.

Seejärel viige neli kirjet kirjalikult kooskõlla: kataloogi väärtus, konfigureeritud kaart või DAP-i tingimus, kohalik grupipoliitika ja ressurss, milleni kasutaja tegelikult jõudis. Kui kolm esimest klapivad ja neljas mitte, on probleem poliitika kehas, mitte valikus. Kui sessioon näitab õiget poliitika nime, kuid valet ACL-i, lõpetage LDAP-i vaatamine täielikult. Muutke üks kirje korraga ja kontrollige uut sessiooni, sest uuesti ühendatud sessioon on ainus tõend, mis peegeldab konfiguratsiooni, mille just kirjutasite.