ASA LDAP-groepsmapping tsjin DAP foar VPN-groepsbelied
In LDAP-attribute-map en in DAP-belied kieze beide in groepsbelied, mar se rinne op ferskate punten. Spoarje nei hokker jo ASA-sesje echt brûkt hat.
Twa aparte records beslisse hokker groepsbelied in AnyConnect-sesje krijt, en se libje op ferskate plakken yn 'e konfiguraasje mei ferskate faalmodi. In LDAP-attribute-map set by de autentikaasje in wearde út it adresboek om yn in ASA-autorisaasje-attribute; in DAP-record beheart dêrnei betingsten en kin attributen tafoegje of oerskriuwe. Beide kinne by deselde beliedsnamme einigje, dat in oanmelding dy't wurket seit jo neat oer hokker meganisme it makke hat. It doel fan it ferlykjen is bewust ien te kiezen ynstee fan de twadde stil de earste oerhearsje te litten.
Twa meganismen, twa beslissingspunten
De kar komt del op trije fragen. Hinget de beslissing ôf fan ien inkelde adresboekattribute-wearde, hat it mear as dy wearde nedich, en hokker meganisme mei winne as beide oerienkomme?
As de iennige ynfier groeplidmaatskip is, is de attribute-map it lytsere ark en it maklikst te auditearjen: ien map, ferbûn oan ien AAA-tsjinner, mei ien rigel per groep. As de seleksje postuer, identiteit fan it einpunt, in twadde attribute of in tiidfinster yn acht nimme moat, reitsje de ynfieren fan 'e map út en is DAP it meganisme dat de regel útdrukke kin. As beide yn it spul binne, lear dan de foarrang yn jo ferzje foardat jo ien fan beide skriuwe, want in sesje dy't oerienkomt mei in DAP-record hâldt miskien net it belied dat de map weromjoech. Al it oare is boekhâlding.
It paad fan 'e attribute-map, yn konfiguraasje-oarder
It paad fan 'e map begjint by de definysje fan 'e AAA-tsjinner. De attribute-map moat ferbûn wêze oan 'e LDAP-tsjinnerrigel dy't it ferbiningsprofyl echt brûkt; in map dy't yn 'e rinnende konfiguraasje bestiet mar net troch dy tsjinner ferwiisd wurdt, feroaret neat. Krekt dy ferbiningsrigel makket de rest fan 'e konfiguraasje libben. De ASA LDAP-mappinggids is de referinsje foar de mapsyntaksis yn ferzjes 9.x.
Binnen de map neamt ien ferklearring de adresboekattribute en de ASA-attribute dy't er fiedt, en fierdere ferklearringen sette spesifike wearden om. map-name memberOf Group-Policy folge troch map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly is de foarm: de lofterkant is wat it adresboek weromjoech, de rjochterkant is de namme fan in groepsbelied dat al bestean moat. In ûnderskiedende namme en in werjeftenamme fan in belied binne net útwikselber, en in hast-treffer yn ien fan beide strings jout gjin flater by oanmelding.
Twa details bite hjir: memberOf jout elke groep werom dêr't it akkount by heart, dat in brûker yn twa mapte groepen jout de map twa kandidaatwearden, en de alfabetyske regel yn 'e gids is de iennige tie-break dêr't jo op fertrouwe kinne ynstee fan jo eigen prioriteitsfoarder. In net-mapte wearde jout neat, wat stil weromfalt op it standertbelied fan it profyl.
It DAP-paad, en wat it tafoeget
DAP beheart betingsten en past attributen ta boppe op it AAA-resultaat. In record draacht in prioriteit, in aksje en in set betingsten; records wurde yn prioriteitsfoarder beheard en de aksje beslút oft de beheardering trochgiet of stopt. Dat is in oar útfieringsmodel as in weardesyksyk, en krekt dêrom kin it regels útdrukke dy't de map net kin.
Wat DAP tafoeget, binne ynfieren. Betingsten kinne adresboekattributen, einpuntattributen en postuersteat ferwize, en in oerienkommend record kin ACL's, URL-listen of filters foar dy sesje drage. Sa is in regel lykas stiperspersoniel op in beheard laptop krijt it lês-allinnich-belied wylst itselde personiel op in net-beheard apparaat in beheind belied krijt, útdrukber yn DAP en net yn in attribute-map. De map hat krekt ien ynfier: de wearde dy't it adresboek weromjoech foar de attribute dy't jo neamden.
DAP tafoeget ek in twadde plak om te sjen as in sesje yn it ferkearde belied telâne komt. In record dat oerienkomt mei in aksje fan trochgean einiget de beheardering net, en in letter record kin de útkomst noch feroarje, dat wat jo observearje is it produkt fan in sekwinsje ynstee fan ien syk. Lês de prioriteitsnûmers yn oarder, en tink derom dat it fallback-record dejinge wêze kin dy't it wurk docht. De map hat dêrfoaroer gjin sekwinsje: ien attribute, ien wearde, ien antwurd.
Wêr't de twa faninoar ferskille
Foarrang is it part dat ûntwerpen brekt. As in sesje sawol mei in maprigel as mei in DAP-record oerienkomt, hinget it resultaat ôf fan 'e ferzje en fan 'e aksje fan it record, dat ferifiearje it op jo eigen ASA ynstee fan oan te nimmen dat ien fan 'e meganismen de útkomst hat.
Trije faalmodi ferklearje it measte fan 'e betizing. In map dy't definiearre is mar nea ferbûn oan 'e tsjinnertag dy't it profyl brûkt, jout it standertbelied sûnder earne in flater. In DAP-betingststring dy't fan 'e adresboekwearde ferskilt yn haad- en lytse letters of spaasjes komt nea oerien, en it fallback-record jildt stil. En in groepsbelied dat noch net bestiet wurdt troch de map akseptearre, want de map jout allinnich in namme werom, dat de sesje krijt gjin fan 'e bedoelde tastimmingen en der is neat yn it log dat nei it ûntbrekkende objekt wiist. Kontrolearje alle trije foardat jo groeplidmaatskip oanreitsje.
It bewiis fan in libbene sesje ôflêze
Lês it antwurd fan in nije sesje ôf, net fan 'e konfiguraasje. show vpn-sessiondb detail anyconnect filter name jdoe prints it groepsbelied dat de sesje echt krige hat, en show running-config ldap attribute-map befêstiget hokker wearden de map weromjaan kinnen hie. Oan 'e adresboekkant lit test aaa-server authentication LDAP-AD username jdoe password <password> de attributen sjen dy't de ASA weromkrige, en debug ldap 255 lit de útwikseling sjen as de test net oerienkomt mei wat jo ferwachten.
Bring dan fjouwer records skriftlik byinoar: de adresboekwearde, de konfigurearre map of DAP-betingst, it lokale groepsbelied en de boarne dy't de brûker echt berikke koe. As de earste trije oerienkomme en de fjirde net, sit it probleem yn it beliedslichem en net yn 'e seleksje. As de sesje de juste beliedsnamme sjen lit mar de ferkearde ACL, stopje dan hielendal mei it sjen nei LDAP. Feroarje ien record tagelyk en kontrolearje in nije sesje, want in opnij ferbûne sesje is it iennige bewiis dat de konfiguraasje wjerstrielet dy't jo krekt skreaun hawwe.