ASA LDAP grupu kartēšana pret DAP VPN grupas politikai

Divi atsevišķi ieraksti nosaka, kādu grupas politiku saņem AnyConnect sesija, un tie atrodas dažādās konfigurācijas daļās ar atšķirīgiem kļūmes režīmiem. LDAP atribūtu karte autentifikācijas laikā pārvērš direktorija vērtību ASA autorizācijas atribūtā; DAP ieraksts pēc tam izvērtē nosacījumus un var pievienot vai pārrakstīt atribūtus. Abi var beigties ar to pašu politikas nosaukumu, tāpēc veiksmīga pieteikšanās neko nepasaka par to, kurš mehānisms to radīja. To salīdzināšanas jēga ir apzināti izvēlēties vienu, nevis ļaut otrajam klusi pārspēt pirmo.

Divi mehānismi, divi lēmuma punkti

Izvēle reducējas uz trim jautājumiem. Vai lēmums ir atkarīgs no vienas direktorija atribūta vērtības, vai tam vajag vairāk par šo vērtību, un kuram mehānismam ir atļauts uzvarēt, kad abi sakrīt?

Ja vienīgā ievade ir dalība grupā, atribūtu karte ir mazāks instruments un vieglāk auditējams: viena karte, piesaistīta vienam AAA serverim, viena rinda katrai grupai. Ja izvēlei jāņem vērā ierīces stāvoklis, galapunkta identitāte, otrs atribūts vai laika logs, kartes ievades izsīkst un DAP ir mehānisms, kas spēj izteikt noteikumu. Ja tiek lietoti abi, uzziniet prioritāti savā laidienā pirms rakstāt kādu no tiem, jo sesija, kas atbilst DAP ierakstam, var nesaglabāt politiku, ko karte atgrieza. Viss pārējais ir grāmatvedība.

Atribūtu kartes ceļš, konfigurācijas secībā

Kartes ceļš sākas ar AAA servera definīciju. Atribūtu kartei jābūt piesaistītai LDAP servera ierakstam, ko savienojuma profils faktiski izmanto; karte, kas pastāv darbojošā konfigurācijā, bet uz kuru šis serveris neatsaucas, neko nemaina. Tieši šī piesaistes rinda padara pārējo konfigurāciju dzīvu. ASA LDAP kartēšanas rokasgrāmata ir atsauce uz kartes sintaksi 9.x laidienos.

Kartes iekšpusē viens paziņojums nosauc direktorija atribūtu un ASA atribūtu, ko tas baro, un turpmākie paziņojumi pārtulko konkrētas vērtības. map-name memberOf Group-Policy un tam sekojošais map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly ir forma: kreisā puse ir tas, ko atgrieza direktorijs, labā puse ir grupas politikas nosaukums, kam jau jāpastāv. Atšķirīgais nosaukums un politikas attēlojamais nosaukums nav savstarpēji aizstājami, un gandrīz sakritība jebkurā no abām virknēm pieteikšanās laikā neizraisa kļūdu.

Šeit koda divas detaļas: memberOf atgriež katru grupu, kurai konts pieder, tāpēc lietotājs divās kartētās grupās dod kartei divas kandidātvērtības, un rokasgrāmatā minētais alfabētiskais noteikums ir vienīgais neizšķirtā risinājums, uz ko varat paļauties sava prioritāšu secības vietā. Nekartēta vērtība neko nedod, un tas klusi atgriežas pie profila noklusējuma politikas.

DAP ceļš un ko tas pievieno

DAP izvērtē nosacījumus un piemēro atribūtus virs AAA rezultāta. Ieraksts satur prioritāti, darbību un nosacījumu kopu; ieraksti tiek izvērtēti prioritātes secībā un darbība izlemj, vai vērtēšana turpinās vai apstājas. Tas ir cits izpildes modelis nekā vērtības meklēšana, un tieši tāpēc tas spēj izteikt noteikumus, ko karte nevar.

Tas, ko DAP pievieno, ir ievades. Nosacījumi var atsaukties uz direktorija atribūtiem, galapunkta atribūtiem un ierīces stāvokli, un atbilstošs ieraksts var saturēt ACL, URL sarakstus vai filtrus šai sesijai. Tāpēc noteikums, piemēram, ka atbalsta personāls pārvaldītā klēpjdatorā saņem tikai lasīšanas politiku, bet tas pats personāls nepārvaldītā ierīcē saņem ierobežotu, ir izsakāms DAP, nevis atribūtu kartē. Kartei ir tieši viena ievade: vērtība, ko direktorijs atgrieza jūsu nosauktajam atribūtam.

DAP pievieno arī otru vietu, kur skatīties, kad sesija nonāk nepareizajā politikā. Ieraksts, kas atbilst darbībai turpināt, nebeidz vērtēšanu, un vēlāks ieraksts joprojām var mainīt rezultātu, tāpēc tas, ko novērojat, ir secības, nevis vienas meklēšanas rezultāts. Lasiet prioritāšu numurus pēc kārtas un atcerieties, ka darbu var veikt rezerves ieraksts. Kartei turpretī nav secības: viens atribūts, viena vērtība, viena atbilde.

Kur abi nesaskan

Prioritāte ir tā daļa, kas salauž dizainu. Kad sesija atbilst gan kartes ierakstam, gan DAP ierakstam, rezultāts ir atkarīgs no laidiena un no ieraksta darbības, tāpēc pārbaudiet to savā ASA, nevis pieņemiet, ka kāds no mehānismiem pārvalda rezultātu.

Trīs kļūmes režīmi izskaidro lielāko daļu apjukuma. Karte, kas ir definēta, bet nekad nav piesaistīta servera atzīmei, ko izmanto profils, dod noklusējuma politiku bez jebkādas kļūdas nekur. DAP nosacījuma virkne, kas atšķiras no direktorija vērtības lielo un mazo burtu vai atstarpju ziņā, nekad nesakrīt, un rezerves ieraksts tiek klusi piemērots. Un grupas politika, kas vēl neeksistē, tiek pieņemta no kartes, jo karte atgriež tikai nosaukumu, tāpēc sesija nesaņem nevienu no paredzētajām atļaujām un žurnālā nav nekā, kas norādītu uz trūkstošo objektu. Pārbaudiet visus trīs pirms aiztiekat grupas dalību.

Pierādījumu nolasīšana no dzīvas sesijas

Lasiet atbildi no jaunas sesijas, nevis no konfigurācijas. show vpn-sessiondb detail anyconnect filter name jdoe izdrukā grupas politiku, ko sesija faktiski saņēma, un show running-config ldap attribute-map apstiprina, kādas vērtības karte varēja atgriezt. Direktorija pusē test aaa-server authentication LDAP-AD username jdoe password <password> parāda atribūtus, ko ASA saņēma atpakaļ, un debug ldap 255 parāda apmaiņu, kad tests neatbilst tam, ko gaidījāt.

Pēc tam saskaņojiet četrus ierakstus rakstiski: direktorija vērtību, konfigurēto karti vai DAP nosacījumu, vietējo grupas politiku un resursu, ko lietotājs faktiski sasniedza. Ja pirmie trīs sakrīt un ceturtais ne, problēma ir politikas pamattekstā, nevis izvēlē. Ja sesija rāda pareizo politikas nosaukumu, bet nepareizo ACL, pilnībā pārtrauciet skatīties uz LDAP. Mainiet vienu ierakstu vienlaikus un pārbaudiet jaunu sesiju, jo atkārtoti savienota sesija ir vienīgais pierādījums, kas atspoguļo tikko rakstīto konfigurāciju.