ASA LDAP-gruppemapping kontra DAP til VPN-gruppepolitik

To separate poster afgør, hvilken gruppepolitik en AnyConnect-session får, og de ligger i forskellige dele af konfigurationen med forskellige fejltilstande. Et LDAP-attributmap oversætter en værdi fra kataloget til et ASA-autorisationsattribut under autentificeringen; en DAP-post vurderer bagefter betingelser og kan tilføje eller tilsidesætte attributter. Begge kan ende på samme politiknavn, så et login, der virker, fortæller dig intet om, hvilken mekanisme der skabte det. Pointen med at sammenligne dem er at vælge den ene bevidst i stedet for at lade den anden stille overtrumfe den første.

To mekanismer, to beslutningspunkter

Valget koger ned til tre spørgsmål. Afhænger beslutningen af en enkelt attributværdi fra kataloget, kræver den mere end den værdi, og hvilken mekanisme har lov til at vinde, når begge matcher?

Hvis det eneste input er gruppemedlemskab, er attributkortet det mindre værktøj og det, der er nemmere at revidere: ét map, knyttet til én AAA-server, med én linje pr. gruppe. Hvis valget skal tage højde for posture, endpoint-identitet, en anden attribut eller et tidsvindue, løber kortet tør for input, og DAP er den mekanisme, der kan udtrykke reglen. Hvis begge er i spil, skal du kende forrangen i din version, før du skriver nogen af dem, fordi en session, der matcher en DAP-post, måske ikke beholder den politik, som kortet returnerede. Alt andet er bogholderi.

Attributkortets vej, i konfigurationsrækkefølge

Kortets vej starter ved AAA-serverdefinitionen. Attributkortet skal være knyttet til den LDAP-serverpost, som forbindelsesprofilen faktisk bruger; et kort, der findes i den kørende konfiguration, men ikke refereres af den server, ændrer intet. Det er netop den vedhæftningslinje, der gør resten af konfigurationen levende. ASA's LDAP-mappingguide er reference for kortsyntaksen på 9.x-versioner.

Inde i kortet navngiver én sætning katalogattributtet og det ASA-attribut, den fodrer, og yderligere sætninger oversætter bestemte værdier. map-name memberOf Group-Policy efterfulgt af map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly er formen: venstre side er det, kataloget returnerede, højre side er navnet på en gruppepolitik, der allerede skal findes. Et distinguished name og et politik-visningsnavn kan ikke udskiftes, og et næsten-hit i en af strengene giver ingen fejl ved login.

To detaljer bider her: memberOf returnerer hver gruppe, kontoen tilhører, så en bruger i to mappede grupper giver kortet to kandidatværdier, og den alfabetiske regel i guiden er det eneste tie-break, du kan regne med i stedet for din egen prioriteringsrækkefølge. En ikke-mappet værdi giver intet, hvilket stille falder tilbage til profilens standardpolitik.

DAP-vejen, og hvad den tilføjer

DAP vurderer betingelser og anvender attributter oven på AAA-resultatet. En post bærer en prioritet, en handling og et sæt betingelser; poster vurderes i prioritetsrækkefølge, og handlingen afgør, om vurderingen fortsætter eller stopper. Det er en anden udførelsesmodel end et værdiopslag, og netop derfor kan den udtrykke regler, som kortet ikke kan.

Det, DAP tilføjer, er input. Betingelser kan referere katalogattributter, endpoint-attributter og posture-tilstand, og en matchende post kan bære ACL'er, URL-lister eller filtre for den session. Så en regel som at supportpersonale på en administreret laptop får politikken med skrivebeskyttelse, mens det samme personale på en ikke-administreret enhed får en begrænset, kan udtrykkes i DAP og ikke i et attributkort. Kortet har præcis ét input: den værdi, kataloget returnerede for det attribut, du navngav.

DAP tilføjer også et andet sted at kigge, når en session ender i den forkerte politik. En post, der matcher med handlingen fortsæt, afslutter ikke vurderingen, og en senere post kan stadig ændre resultatet, så det, du ser, er produktet af en sekvens frem for et enkelt opslag. Læs prioritetstallene i rækkefølge, og husk at det kan være fallback-posten, der udfører arbejdet. Kortet har derimod ingen sekvens: én attribut, én værdi, ét svar.

Hvor de to er uenige

Forrang er den del, der ødelægger design. Når en session matcher både en kortpost og en DAP-post, afhænger resultatet af versionen og af postens handling, så verificer det på din egen ASA i stedet for at antage, at en af mekanismerne ejer resultatet.

Tre fejltilstande forklarer det meste af forvirringen. Et kort, der er defineret, men aldrig knyttet til det servertag, profilen bruger, giver standardpolitikken uden nogen fejl noget steds. En DAP-betingelsesstreng, der afviger fra katalogværdien i store og små bogstaver eller mellemrum, matcher aldrig, og fallback-posten anvendes stille. Og en gruppepolitik, der ikke findes endnu, accepteres af kortet, fordi kortet kun returnerer et navn, så sessionen får ingen af de tilsigtede tilladelser, og der er intet i loggen, der peger på det manglende objekt. Kontroller alle tre, før du rører gruppemedlemskab.

At læse beviserne ud af en live-session

Læs svaret ud af en ny session i stedet for ud af konfigurationen. show vpn-sessiondb detail anyconnect filter name jdoe udskriver den gruppepolitik, sessionen faktisk fik, og show running-config ldap attribute-map bekræfter, hvilke værdier kortet kunne have returneret. På katalogsiden viser test aaa-server authentication LDAP-AD username jdoe password <password> de attributter, ASA fik tilbage, og debug ldap 255 viser udvekslingen, når testen ikke stemmer med det, du forventede.

Afstem derefter fire poster skriftligt: katalogværdien, det konfigurerede kort eller DAP-betingelsen, den lokale gruppepolitik og den ressource, brugeren faktisk kunne nå. Hvis de tre første stemmer, og den fjerde ikke gør, ligger problemet i politikteksten og ikke i valget. Hvis sessionen viser det rigtige politiknavn, men den forkerte ACL, skal du helt holde op med at kigge på LDAP. Skift én post ad gangen, og kontroller en ny session igen, fordi en genoprettet session er det eneste bevis, der afspejler den konfiguration, du netop har skrevet.