Mapado de LDAP-grupoj en ASA kontraŭ DAP por VPN-grupa politiko

Du apartaj rikordoj decidas, kiun grupan politikon ricevas AnyConnect-kunsido, kaj ili loĝas en malsamaj partoj de la agordo kun malsamaj fiaskmanieroj. LDAP-atributmapo tradukas valoron el la adresaro en ASA-rajtigan atributon dum aŭtentikigo; DAP-rikordo taksas kondiĉojn poste kaj povas aldoni aŭ anstataŭigi atributojn. Ambaŭ povas fini ĉe la sama politika nomo, do sukcesa ensaluto diras al vi nenion pri tio, kiu mekanismo ĝin produktis. La senco de la komparo estas elekti unu konscie anstataŭ lasi la duan silente superregi la unuan.

Du mekanismoj, du decido-punktoj

La elekto reduktiĝas al tri demandoj. Ĉu la decido dependas de unu sola adresara atributvaloro, ĉu ĝi bezonas pli ol tiu valoro, kaj kiu mekanismo rajtas venki kiam ambaŭ kongruas?

Se la sola enigo estas grupano, la atributmapo estas la pli malgranda ilo kaj la pli facile aŭdebla: unu mapo, ligita al unu AAA-servilo, kun unu linio por grupo. Se la elekto devas konsideri la staton de la aparato, la identecon de la finpunkto, duan atributon aŭ tempfenestron, la enigoj de la mapo elĉerpiĝas kaj DAP estas la mekanismo, kiu povas esprimi la regulon. Se ambaŭ estas en ludo, lernu la prioritaton en via eldono antaŭ ol vi skribos iun ajn el ili, ĉar kunsido kongruanta kun DAP-rikordo eble ne konservos la politikon, kiun la mapo redonis. Ĉio alia estas librotenado.

La vojo de la atributmapo, laŭ agorda ordo

La vojo de la mapo komenciĝas ĉe la difino de la AAA-servilo. La atributmapo devas esti ligita al la LDAP-servila enskribo, kiun la konekta profilo efektive uzas; mapo, kiu ekzistas en la funkcianta agordo sed ne estas referencata de tiu servilo, ŝanĝas nenion. Ĝuste tiu liga linio igas la reston de la agordo viva. La ASA-gvidilo pri LDAP-mapado estas la referenco por la mapa sintakso en la eldonoj 9.x.

Ene de la mapo, unu deklaro nomas la adresaran atributon kaj la ASA-atributon, kiun ĝi nutras, kaj pliaj deklaroj tradukas specifajn valorojn. map-name memberOf Group-Policy sekvata de map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly estas la formo: la maldekstra flanko estas tio, kion la adresaro redonis, la dekstra flanko estas la nomo de grupa politiko, kiu devas jam ekzisti. Distinga nomo kaj montra nomo de politiko ne estas interŝanĝeblaj, kaj preskaŭ-kongruo en iu ajn el la du ĉenoj produktas nenian eraron ĉe ensaluto.

Du detaloj mordas ĉi tie: memberOf redonas ĉiun grupon, al kiu la konto apartenas, do uzanto en du mapitaj grupoj donas al la mapo du kandidatajn valorojn, kaj la alfabeta regulo en la gvidilo estas la sola egaliga solvo, je kiu vi povas fidi anstataŭ via propra prioritata ordo. Nemapita valoro donas nenion, kio silente falas reen al la defaŭlta politiko de la profilo.

La DAP-vojo, kaj kion ĝi aldonas

DAP taksas kondiĉojn kaj aplikas atributojn sur la AAA-rezulton. Rikordo portas prioritaton, agon kaj aron da kondiĉoj; rikordoj estas taksataj laŭ prioritata ordo kaj la ago decidas, ĉu la taksado daŭras aŭ haltas. Tio estas alia plenummodelo ol valorserĉo, kaj ĝuste tial ĝi povas esprimi regulojn, kiujn la mapo ne povas.

Kion DAP aldonas, estas enigoj. Kondiĉoj povas referenci adresarajn atributojn, finpunktajn atributojn kaj aparatan staton, kaj kongrua rikordo povas porti ACL-ojn, URL-listojn aŭ filtrilojn por tiu kunsido. Do regulo kiel: subtena personaro sur administrata tekkomputilo ricevas la nurlegan politikon, dum la sama personaro sur neadministrata aparato ricevas limigitan, estas esprimebla en DAP kaj ne en atributmapo. La mapo havas precize unu enigon: la valoron, kiun la adresaro redonis por la atributo, kiun vi nomis.

DAP ankaŭ aldonas duan lokon por rigardi, kiam kunsido finiĝas en la malĝusta politiko. Rikordo kongruanta kun ago daŭrigi ne finas la taksadon, kaj posta rikordo ankoraŭ povas ŝanĝi la rezulton, do tio, kion vi observas, estas la produkto de sinsekvo anstataŭ de unuopa serĉo. Legu la prioritatajn numerojn laŭ ordo, kaj memoru, ke la rezerva rikordo eble estas tiu, kiu faras la laboron. La mapo, kontraste, havas neniun sinsekvon: unu atributo, unu valoro, unu respondo.

Kie la du malkonsentas

Prioreco estas la parto, kiu rompas projektojn. Kiam kunsido kongruas kaj kun mapa enskribo kaj kun DAP-rikordo, la rezulto dependas de la eldono kaj de la ago de la rikordo, do kontrolu tion sur via propra ASA anstataŭ supozi, ke unu el la mekanismoj posedas la rezulton.

Tri fiaskmanieroj klarigas la plej grandan parton de la konfuzo. Mapo difinita sed neniam ligita al la servila etikedo, kiun la profilo uzas, produktas la defaŭltan politikon sen iu ajn eraro ie ajn. DAP-kondiĉa ĉeno, kiu diferencas de la adresara valoro laŭ uskleco aŭ spacetoj, neniam kongruas, kaj la rezerva rikordo aplikiĝas silente. Kaj grupa politiko, kiu ankoraŭ ne ekzistas, estas akceptata de la mapo, ĉar la mapo redonas nur nomon, do la kunsido ricevas neniun el la celitaj permesoj kaj nenio en la protokolo montras al la mankanta objekto. Kontrolu ĉiujn tri antaŭ ol tuŝi grupan membrecon.

Legi la pruvojn el viva kunsido

Legu la respondon el freŝa kunsido anstataŭ el la agordo. show vpn-sessiondb detail anyconnect filter name jdoe presas la grupan politikon, kiun la kunsido efektive ricevis, kaj show running-config ldap attribute-map konfirmas, kiujn valorojn la mapo povus esti redoninta. Sur la adresara flanko, test aaa-server authentication LDAP-AD username jdoe password <password> montras la atributojn, kiujn ASA ricevis reen, kaj debug ldap 255 montras la interŝanĝon, kiam la testo malkongruas kun tio, kion vi atendis.

Poste akordu kvar rikordojn skribe: la adresaran valoron, la agorditan mapon aŭ DAP-kondiĉon, la lokan grupan politikon kaj la rimedon, kiun la uzanto efektive povis atingi. Se la unuaj tri kongruas kaj la kvara ne, la problemo estas en la korpo de la politiko, ne en la elekto. Se la kunsido montras la ĝustan politikan nomon sed la malĝustan ACL, tute ĉesu rigardi LDAP. Ŝanĝu unu rikordon samtempe kaj rekontrolu novan kunsidon, ĉar rekonektita kunsido estas la sola pruvo, kiu reflektas la agordon, kiun vi ĵus skribis.