ASA LDAP-groepsmapping versus DAP voor VPN-groepsbeleid

Twee afzonderlijke records bepalen welke groepspolicy een AnyConnect-sessie krijgt, en ze staan op verschillende plaatsen in de configuratie met verschillende faalmodi. Een LDAP-attribuutmap vertaalt tijdens de authenticatie een directorywaarde naar een ASA-autorisatieattribuut; een DAP-record evalueert daarna voorwaarden en kan attributen toevoegen of overschrijven. Beide kunnen op dezelfde policynaam uitkomen, dus een geslaagde login zegt niets over welk mechanisme hem heeft geproduceerd. Het nut van de vergelijking is bewust één te kiezen in plaats van de tweede stilletjes de eerste te laten overrulen.

Twee mechanismen, twee beslismomenten

De keuze komt neer op drie vragen. Hangt de beslissing af van één directory-attribuutwaarde, is er meer nodig dan die waarde, en welk mechanisme mag winnen wanneer beide overeenkomen?

Als de enige invoer groepslidmaatschap is, is de attribuutmap het kleinere gereedschap en het eenvoudigst te auditen: één map, gekoppeld aan één AAA-server, met één regel per groep. Moet de selectie rekening houden met posture, endpoint-identiteit, een tweede attribuut of een tijdvenster, dan raakt de map door zijn invoer heen en is DAP het mechanisme dat de regel kan uitdrukken. Zijn beide in het spel, leer dan de precedentie in uw versie voordat u een van beide schrijft, want een sessie die overeenkomt met een DAP-record behoudt mogelijk niet de policy die de map teruggaf. Al het overige is boekhouding.

Het pad van de attribuutmap, in configuratievolgorde

Het pad van de map begint bij de definitie van de AAA-server. De attribuutmap moet gekoppeld zijn aan de LDAP-serverregel die het verbindingsprofiel daadwerkelijk gebruikt; een map die in de actieve configuratie bestaat maar niet door die server wordt gerefereerd, verandert niets. Juist die koppelregel maakt de rest van de configuratie levend. De ASA LDAP-mappinggids is de referentie voor de mapsyntaxis in de versies 9.x.

Binnen de map benoemt één instructie het directory-attribuut en het ASA-attribuut dat het voedt, en verdere instructies vertalen specifieke waarden. map-name memberOf Group-Policy gevolgd door map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly is de vorm: de linkerkant is wat de directory teruggaf, de rechterkant is de naam van een groepspolicy die al moet bestaan. Een distinguished name en een weergavenaam van een policy zijn niet uitwisselbaar, en een bijna-treffer in een van beide strings levert bij de login geen fout op.

Twee details bijten hier: memberOf geeft elke groep terug waar het account bij hoort, dus een gebruiker in twee gemapte groepen geeft de map twee kandidaatwaarden, en de alfabetische regel in de gids is de enige tiebreak waarop u kunt vertrouwen in plaats van uw eigen prioriteitsvolgorde. Een niet-gemapte waarde levert niets op, wat stil terugvalt op de standaardpolicy van het profiel.

Het DAP-pad, en wat het toevoegt

DAP evalueert voorwaarden en past attributen toe bovenop het AAA-resultaat. Een record draagt een prioriteit, een actie en een set voorwaarden; records worden in prioriteitsvolgorde geëvalueerd en de actie bepaalt of de evaluatie doorgaat of stopt. Dat is een ander uitvoeringsmodel dan een waardezocking, en juist daarom kan het regels uitdrukken die de map niet kan.

Wat DAP toevoegt, zijn invoerwaarden. Voorwaarden kunnen verwijzen naar directory-attributen, endpoint-attributen en apparaatstatus, en een overeenkomend record kan ACL's, URL-lijsten of filters voor die sessie dragen. Een regel als: ondersteunend personeel op een beheerde laptop krijgt de alleen-lezen-policy, terwijl hetzelfde personeel op een niet-beheerd apparaat een beperkte krijgt, is dus uitdrukbaar in DAP en niet in een attribuutmap. De map heeft precies één invoer: de waarde die de directory teruggaf voor het attribuut dat u noemde.

DAP voegt ook een tweede plek toe om te kijken wanneer een sessie in de verkeerde policy belandt. Een record dat overeenkomt met de actie doorgaan beëindigt de evaluatie niet, en een later record kan de uitkomst nog veranderen, dus wat u waarneemt is het product van een reeks en niet van één zoekactie. Lees de prioriteitsnummers op volgorde, en bedenk dat het fallback-record degene kan zijn die het werk doet. De map heeft daarentegen geen reeks: één attribuut, één waarde, één antwoord.

Waar de twee het oneens zijn

Precedentie is het deel dat ontwerpen breekt. Wanneer een sessie zowel op een mapregel als op een DAP-record past, hangt het resultaat af van de versie en van de actie van het record, dus verifieer het op uw eigen ASA in plaats van aan te nemen dat een van de mechanismen de uitkomst bezit.

Drie faalmodi verklaren het grootste deel van de verwarring. Een map die is gedefinieerd maar nooit gekoppeld aan de servertag die het profiel gebruikt, levert de standaardpolicy zonder ergens een fout. Een DAP-voorwaardestring die afwijkt van de directorywaarde in hoofdletters of spaties, komt nooit overeen, en het fallback-record wordt stil toegepast. En een groepspolicy die nog niet bestaat, wordt door de map geaccepteerd, omdat de map alleen een naam teruggeeft, dus de sessie krijgt geen van de bedoelde rechten en er staat niets in het log dat naar het ontbrekende object wijst. Controleer alle drie voordat u het groepslidmaatschap aanraakt.

Het bewijs van een live-sessie aflezen

Lees het antwoord af van een nieuwe sessie en niet van de configuratie. show vpn-sessiondb detail anyconnect filter name jdoe drukt de groepspolicy af die de sessie daadwerkelijk heeft gekregen, en show running-config ldap attribute-map bevestigt welke waarden de map had kunnen teruggeven. Aan de directorykant toont test aaa-server authentication LDAP-AD username jdoe password <password> de attributen die de ASA terugkreeg, en debug ldap 255 toont de uitwisseling wanneer de test niet overeenkomt met wat u verwachtte.

Verzoen daarna vier records schriftelijk: de directorywaarde, de geconfigureerde map of DAP-voorwaarde, de lokale groepspolicy en de resource die de gebruiker daadwerkelijk kon bereiken. Als de eerste drie kloppen en de vierde niet, zit het probleem in de body van de policy en niet in de selectie. Als de sessie de juiste policynaam toont maar de verkeerde ACL, stop dan helemaal met naar LDAP te kijken. Wijzig één record tegelijk en controleer opnieuw een nieuwe sessie, want een opnieuw verbonden sessie is het enige bewijs dat de configuratie weerspiegelt die u zojuist hebt geschreven.