ASA LDAP-gruppemapping kontra DAP for VPN-gruppepolicy

To separate oppføringer avgjør hvilken gruppepolicy en AnyConnect-økt får, og de ligger i ulike deler av konfigurasjonen med ulike feilmoduser. Et LDAP-attributtkart oversetter en verdi fra katalogen til et ASA-autorisasjonsattributt under autentisering; en DAP-oppføring vurderer betingelser etterpå og kan legge til eller overstyre attributter. Begge kan ende på samme policynavn, så en innlogging som virker forteller deg ingenting om hvilken mekanisme som produserte den. Poenget med å sammenligne dem er å velge én bevisst i stedet for å la den andre stille overstyre den første.

To mekanismer, to beslutningspunkter

Valget koker ned til tre spørsmål. Avhenger beslutningen av én enkelt attributtverdi fra katalogen, trenger den mer enn den verdien, og hvilken mekanisme har lov til å vinne når begge passer?

Hvis det eneste inndataet er gruppemedlemskap, er attributtkartet det minste verktøyet og det som er enklest å revidere: ett kart, knyttet til én AAA-server, med én linje per gruppe. Hvis valget må ta hensyn til enhetstilstand, endepunktidentitet, en andre attributt eller et tidsvindu, går kartet tom for inndata, og DAP er mekanismen som kan uttrykke regelen. Hvis begge er i spill, lær presedensen i din versjon før du skriver noen av dem, fordi en økt som passer med en DAP-oppføring kanskje ikke beholder policyen kartet returnerte. Alt annet er bokføring.

Veien til attributtkartet, i konfigurasjonsrekkefølge

Kartets vei starter ved definisjonen av AAA-serveren. Attributtkartet må være knyttet til LDAP-serveroppføringen som tilkoblingsprofilen faktisk bruker; et kart som finnes i den kjørende konfigurasjonen, men ikke refereres av den serveren, endrer ingenting. Det er nettopp den knytningslinjen som gjør resten av konfigurasjonen levende. ASAs LDAP-mappingveiledning er referansen for kartsyntaksen i versjonene 9.x.

Inne i kartet navngir én setning katalogattributtet og det ASA-attributtet den mater, og flere setninger oversetter bestemte verdier. map-name memberOf Group-Policy etterfulgt av map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly er formen: venstre side er det katalogen returnerte, høyre side er navnet på en gruppepolicy som allerede må finnes. Et distinkt navn og et visningsnavn for policy er ikke utbyttbare, og en nesten-treff i en av de to strengene gir ingen feil ved innlogging.

To detaljer biter her: memberOf returnerer hver gruppe kontoen tilhører, så en bruker i to mappede grupper gir kartet to kandidatverdier, og den alfabetiske regelen i veiledningen er den eneste tie-breaken du kan stole på i stedet for din egen prioriteringsrekkefølge. En ikke-mappet verdi gir ingenting, noe som stille faller tilbake til profilens standardpolicy.

DAP-veien, og hva den tilfører

DAP vurderer betingelser og anvender attributter på toppen av AAA-resultatet. En oppføring har en prioritet, en handling og et sett betingelser; oppføringer vurderes i prioritetsrekkefølge, og handlingen avgjør om vurderingen fortsetter eller stopper. Det er en annen utførelsesmodell enn et verdioppslag, og nettopp derfor kan den uttrykke regler kartet ikke kan.

Det DAP tilfører, er inndata. Betingelser kan referere katalogattributter, endepunktattributter og enhetstilstand, og en samsvarende oppføring kan bære ACL-er, URL-lister eller filtre for den økten. Så en regel som at støttepersonale på en administrert bærbar PC får skrivebeskyttet policy mens det samme personalet på en ikke-administrert enhet får en begrenset, er uttrykkbar i DAP og ikke i et attributtkart. Kartet har nøyaktig ett inndata: verdien katalogen returnerte for attributtet du navnga.

DAP tilfører også et andre sted å se når en økt havner i feil policy. En oppføring som samsvarer med handlingen fortsett, avslutter ikke vurderingen, og en senere oppføring kan fortsatt endre resultatet, så det du observerer er produktet av en sekvens og ikke av ett oppslag. Les prioritetsnumrene i rekkefølge, og husk at det kan være reserveoppføringen som gjør jobben. Kartet har derimot ingen sekvens: én attributt, én verdi, ett svar.

Der de to er uenige

Presedensen er den delen som ødelegger design. Når en økt samsvarer både med en kartoppføring og en DAP-oppføring, avhenger resultatet av versjonen og av oppføringens handling, så verifiser det på din egen ASA i stedet for å anta at en av mekanismene eier resultatet.

Tre feilmoduser forklarer det meste av forvirringen. Et kart som er definert, men aldri knyttet til servertaggen profilen bruker, gir standardpolicyen uten noen feil noe sted. En DAP-betingelsesstreng som avviker fra katalogverdien i store og små bokstaver eller mellomrom, samsvarer aldri, og reserveoppføringen brukes stille. Og en gruppepolicy som ennå ikke finnes, godtas av kartet, fordi kartet bare returnerer et navn, så økten får ingen av de tiltenkte tillatelsene, og det er ingenting i loggen som peker på det manglende objektet. Sjekk alle tre før du rører gruppemedlemskap.

Å lese bevisene ut av en levende økt

Les svaret ut av en ny økt i stedet for ut av konfigurasjonen. show vpn-sessiondb detail anyconnect filter name jdoe skriver ut gruppepolicyen økten faktisk fikk, og show running-config ldap attribute-map bekrefter hvilke verdier kartet kunne ha returnert. På katalogsiden viser test aaa-server authentication LDAP-AD username jdoe password <password> attributtene ASA fikk tilbake, og debug ldap 255 viser utvekslingen når testen ikke stemmer med det du forventet.

Deretter avstem fire oppføringer skriftlig: katalogverdien, det konfigurerte kartet eller DAP-betingelsen, den lokale gruppepolicyen og ressursen brukeren faktisk kunne nå. Hvis de tre første stemmer og den fjerde ikke, ligger problemet i policyens kropp og ikke i valget. Hvis økten viser riktig policynavn, men feil ACL, slutt helt å se på LDAP. Endre én oppføring om gangen, og kontroller en ny økt, fordi en gjenoppkoblet økt er det eneste beviset som gjenspeiler konfigurasjonen du nettopp skrev.