ASA LDAP-gruppemapping kontra DAP for VPN-gruppepolitikk

To separate oppføringar avgjer kva gruppepolitikk ei AnyConnect-økt får, og dei ligg i ulike delar av konfigurasjonen med ulike feilmodusar. Eit LDAP-attributtkart omset ein verdi frå katalogen til eit ASA-autorisasjonsattributt under autentisering; ei DAP-oppføring vurderer vilkår etterpå og kan leggje til eller overstyre attributt. Begge kan enda på same policy namn, så ei innlogging som verkar fortel deg ingenting om kva mekanisme som laga henne. Poenget med å samanlikne dei er å velje éin medvite i staden for å la den andre stille overstyre den første.

To mekanismar, to avgjerdsdspunkt

Valet kokar ned til tre spørsmål. Er avgjerda avhengig av éin einaste attributtverdi frå katalogen, treng ho meir enn den verdien, og kva mekanisme har lov til å vinne når begge passar?

Viss det einaste inndataet er gruppemedlemskap, er attributtkartet det minste verktøyet og det som er enklast å revidere: eitt kart, knytt til éin AAA-tenar, med éi line per gruppe. Viss valet må ta omsyn til einheitstilstand, endepunktidentitet, ein annan attributt eller eit tidsvindauge, går kartet tomt for inndata, og DAP er mekanismen som kan uttrykkje regelen. Viss begge er i spel, lær presedensen i din versjon før du skriv nokon av dei, fordi ei økt som passar med ei DAP-oppføring kanskje ikkje held på policyen kartet returnerte. Alt anna er bokføring.

Vegen til attributtkartet, i konfigurasjonsrekkjefølgje

Vegen til kartet startar ved definisjonen av AAA-tenaren. Attributtkartet må vere knytt til LDAP-tenaroppføringa som tilkoplingsprofilen faktisk brukar; eit kart som finst i den køyrande konfigurasjonen, men ikkje er referert av den tenaren, endrar ingenting. Det er nettopp den knytningslina som gjer resten av konfigurasjonen levande. ASAs LDAP-mappingrettleiing er referansen for kartsyntaksen i versjonane 9.x.

Inne i kartet namngjev éi setning katalogattributtet og det ASA-attributtet ho mater, og fleire setningar omset bestemte verdiar. map-name memberOf Group-Policy etterfølgd av map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly er forma: venstre side er det katalogen returnerte, høgre side er namnet på ein gruppepolitikk som allereie må finnast. Eit distinkt namn og eit visingsnamn for policy er ikkje utbyttbare, og ein nesten-treff i ein av dei to strengane gir ingen feil ved innlogging.

To detaljar bit her: memberOf returnerer kvar gruppe kontoen høyrer til, så ein brukar i to mappa grupper gir kartet to kandidatverdiar, og den alfabetiske regelen i rettleiinga er den einaste tie-breaken du kan stole på i staden for din eigen prioriteringsrekkjefølgje. Ein ikkje-mappa verdi gir ingenting, noko som stille fell tilbake til standardpolicyen til profilen.

DAP-vegen, og kva han tilfører

DAP vurderer vilkår og legg attributt på toppen av AAA-resultatet. Ei oppføring har ein prioritet, ei handling og eit sett vilkår; oppføringane blir vurderte i prioritetsrekkjefølgje, og handlinga avgjer om vurderinga held fram eller stoppar. Det er ein annan utføringsmodell enn eit verdioppslag, og nettopp difor kan han uttrykkje reglar kartet ikkje kan.

Det DAP tilfører, er inndata. Vilkår kan referere katalogattributt, endepunktattributt og einheitstilstand, og ei samsvarande oppføring kan bere ACL-ar, URL-lister eller filter for den økta. Så ein regel som at støttepersonale på ein administrert berbar PC får skriveverna policy medan det same personalet på ein ikkje-administrert einheit får ein avgrensa, er uttrykkeleg i DAP og ikkje i eit attributtkart. Kartet har nøyaktig eitt inndata: verdien katalogen returnerte for attributtet du namngav.

DAP tilfører også ein annan stad å sjå når ei økt hamnar i feil policy. Ei oppføring som samsvarar med handlinga hald fram, avsluttar ikkje vurderinga, og ei seinare oppføring kan framleis endre resultatet, så det du observerer er produktet av ein sekvens og ikkje av eitt oppslag. Les prioritetstala i rekkjefølgje, og hugs at det kan vere reserveoppføringa som gjer jobben. Kartet har derimot ingen sekvens: éin attributt, éin verdi, eitt svar.

Der dei to er usamde

Presedensen er den delen som øydelegg design. Når ei økt samsvarar både med ei kartoppføring og ei DAP-oppføring, er resultatet avhengig av versjonen og av handlinga til oppføringa, så verifiser det på din eigen ASA i staden for å anta at ein av mekanismane eig resultatet.

Tre feilmodusar forklarar det meste av forvirringa. Eit kart som er definert, men aldri knytt til tenartaggen profilen brukar, gir standardpolicyen utan nokon feil nokon stad. Ein DAP-vilkårsstreng som avvik frå katalogverdien i store og små bokstavar eller mellomrom, samsvarar aldri, og reserveoppføringa blir brukt stille. Og ein gruppepolitikk som enno ikkje finst, blir godteken av kartet, fordi kartet berre returnerer eit namn, så økta får ingen av dei tiltenkte løyva, og det er ingenting i loggen som peikar på det manglande objektet. Sjekk alle tre før du rører gruppemedlemskap.

Å lese prova ut av ei levande økt

Les svaret ut av ei ny økt i staden for ut av konfigurasjonen. show vpn-sessiondb detail anyconnect filter name jdoe skriv ut gruppepolicyen økta faktisk fekk, og show running-config ldap attribute-map stadfester kva verdiar kartet kunne ha returnert. På katalogsida viser test aaa-server authentication LDAP-AD username jdoe password <password> attributta ASA fekk tilbake, og debug ldap 255 viser utvekslinga når testen ikkje stemmer med det du venta.

Deretter avstem fire oppføringar skriftleg: katalogverdien, det konfigurerte kartet eller DAP-vilkåret, den lokale gruppepolitikken og ressursen brukaren faktisk kunne nå. Viss dei tre første stemmer og den fjerde ikkje, ligg problemet i kroppen til policyen og ikkje i valet. Viss økta viser rett policynamn, men feil ACL, slutt heilt å sjå på LDAP. Endre éi oppføring om gongen, og kontroller ei ny økt, fordi ei gjenoppkopla økt er det einaste provet som speglar konfigurasjonen du nettopp skreiv.