ASA LDAP-gruppmappning kontra DAP för VPN-grupppolicy

Två separata poster avgör vilken grupppolicy en AnyConnect-session får, och de ligger i olika delar av konfigurationen med olika felmoder. En LDAP-attributmappning översätter ett värde från katalogen till ett ASA-auktoriseringsattribut under autentiseringen; en DAP-post utvärderar villkor efteråt och kan lägga till eller åsidosätta attribut. Båda kan sluta på samma policynamn, så en inloggning som fungerar säger ingenting om vilken mekanism som producerade den. Poängen med att jämföra dem är att välja en medvetet i stället för att låta den andra tyst åsidosätta den första.

Två mekanismer, två beslutspunkter

Valet kokar ner till tre frågor. Beror beslutet på ett enda attributvärde från katalogen, behövs mer än det värdet, och vilken mekanism får vinna när båda matchar?

Om det enda indata är gruppmedlemskap är attributmappningen det mindre verktyget och det som är enklast att granska: en mappning, kopplad till en AAA-server, med en rad per grupp. Om valet måste ta hänsyn till enhetsstatus, slutpunktsidentitet, ett andra attribut eller ett tidsfönster tar mappningens indata slut och DAP är mekanismen som kan uttrycka regeln. Om båda används, lär dig prioriteten i din version innan du skriver någon av dem, eftersom en session som matchar en DAP-post kanske inte behåller policyn som mappningen returnerade. Allt annat är bokföring.

Attributmappningens väg, i konfigurationsordning

Mappningens väg börjar vid definitionen av AAA-servern. Attributmappningen måste vara kopplad till den LDAP-serverpost som anslutningsprofilen faktiskt använder; en mappning som finns i den körande konfigurationen men inte refereras av den servern ändrar ingenting. Det är just den kopplingsraden som gör resten av konfigurationen levande. ASAs LDAP-mappningsguide är referensen för mappsyntaxen i versionerna 9.x.

Inuti mappningen namnger en sats katalogattributet och det ASA-attribut det matar, och ytterligare satser översätter specifika värden. map-name memberOf Group-Policy följt av map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly är formen: vänster sida är det katalogen returnerade, höger sida är namnet på en grupppolicy som redan måste finnas. Ett unikt namn och ett visningsnamn för policy är inte utbytbara, och en nästan-träff i endera strängen ger inget fel vid inloggning.

Två detaljer biter här: memberOf returnerar varje grupp som kontot tillhör, så en användare i två mappade grupper ger mappningen två kandidatvärden, och den alfabetiska regeln i guiden är det enda sättet att lösa lika som du kan lita på i stället för din egen prioritetsordning. Ett icke-mappat värde ger ingenting, vilket tyst faller tillbaka på profilens standardpolicy.

DAP-vägen, och vad den tillför

DAP utvärderar villkor och tillämpar attribut ovanpå AAA-resultatet. En post bär en prioritet, en åtgärd och en uppsättning villkor; poster utvärderas i prioritetsordning och åtgärden avgör om utvärderingen fortsätter eller stoppar. Det är en annan exekveringsmodell än en värdeuppslagning, och just därför kan den uttrycka regler som mappningen inte kan.

Det DAP tillför är indata. Villkor kan referera katalogattribut, slutpunktsattribut och enhetsstatus, och en matchande post kan bära ACL:er, URL-listor eller filter för den sessionen. Så en regel som att supportpersonal på en hanterad laptop får skrivskyddad policy medan samma personal på en ohanterad enhet får en begränsad är uttryckbar i DAP och inte i en attributmappning. Mappningen har exakt ett indata: värdet som katalogen returnerade för attributet du namngav.

DAP tillför också en andra plats att titta på när en session hamnar i fel policy. En post som matchar med åtgärden fortsätt avslutar inte utvärderingen, och en senare post kan fortfarande ändra resultatet, så det du observerar är produkten av en sekvens och inte av en enda sökning. Läs prioritetsnumren i ordning, och kom ihåg att det kan vara reservposten som gör jobbet. Mappningen har däremot ingen sekvens: ett attribut, ett värde, ett svar.

Där de två inte är överens

Prioriteten är den del som bryter design. När en session matchar både en mappningspost och en DAP-post beror resultatet på versionen och på postens åtgärd, så verifiera det på din egen ASA i stället för att anta att en av mekanismerna äger resultatet.

Tre felmoder förklarar det mesta av förvirringen. En mappning som är definierad men aldrig kopplad till den servertagg som profilen använder ger standardpolicyn utan något fel någonstans. En DAP-villkorssträng som skiljer sig från katalogvärdet i versaler eller blanksteg matchar aldrig, och reservposten tillämpas tyst. Och en grupppolicy som ännu inte finns accepteras av mappningen, eftersom mappningen bara returnerar ett namn, så sessionen får inga av de avsedda behörigheterna och det finns inget i loggen som pekar på det saknade objektet. Kontrollera alla tre innan du rör gruppmedlemskap.

Att läsa bevisen ur en levande session

Läs svaret ur en ny session i stället för ur konfigurationen. show vpn-sessiondb detail anyconnect filter name jdoe skriver ut den grupppolicy som sessionen faktiskt fick, och show running-config ldap attribute-map bekräftar vilka värden mappningen kunde ha returnerat. På katalogsidan visar test aaa-server authentication LDAP-AD username jdoe password <password> de attribut som ASA fick tillbaka, och debug ldap 255 visar utbytet när testet inte stämmer med det du förväntade dig.

Stäm sedan av fyra poster skriftligt: katalogvärdet, den konfigurerade mappningen eller DAP-villkoret, den lokala gruppolicyn och den resurs som användaren faktiskt kunde nå. Om de tre första stämmer och den fjärde inte, ligger problemet i policykroppen och inte i valet. Om sessionen visar rätt policynamn men fel ACL, sluta helt att titta på LDAP. Ändra en post i taget och kontrollera en ny session, eftersom en återansluten session är det enda beviset som speglar konfigurationen du just skrev.