Assignació de grups LDAP a l'ASA enfront de DAP per a la política de grup VPN

Dos registres separats decideixen quina política de grup rep una sessió d'AnyConnect, i viuen en parts diferents de la configuració amb modes de fallada diferents. Un mapa d'atributs LDAP tradueix un valor del directori en un atribut d'autorització de l'ASA durant l'autenticació; un registre DAP avalua condicions després i pot afegir o sobreescriure atributs. Tots dos poden acabar en el mateix nom de política, de manera que un inici de sessió que funciona no us diu res sobre quin mecanisme l'ha produït. El sentit de comparar-los és triar-ne un deliberadament en lloc de deixar que el segon anul·li silenciosament el primer.

Dos mecanismes, dos punts de decisió

L'elecció es redueix a tres preguntes. La decisió depèn d'un sol valor d'atribut del directori, necessita més que aquest valor, i quin mecanisme té permís per guanyar quan tots dos coincideixen?

Si l'única entrada és la pertinença a un grup, el mapa d'atributs és l'eina més petita i la més fàcil d'auditar: un mapa, associat a un servidor AAA, amb una línia per grup. Si la selecció ha de tenir en compte la postura, la identitat de l'extrem, un segon atribut o una finestra temporal, el mapa es queda sense entrades i DAP és el mecanisme que pot expressar la regla. Si tots dos estan en joc, conegueu la precedència a la vostra versió abans d'escriure'n cap, perquè una sessió que coincideix amb un registre DAP pot no conservar la política que va retornar el mapa. La resta és comptabilitat.

El camí del mapa d'atributs, en ordre de configuració

El camí del mapa comença a la definició del servidor AAA. El mapa d'atributs s'ha d'associar a l'entrada del servidor LDAP que el perfil de connexió realment utilitza; un mapa que existeix a la configuració en execució però que aquest servidor no referencia no canvia res. Aquesta línia d'associació és la que fa viva la resta de la configuració. La guia de mapes LDAP de l'ASA és la referència per a la sintaxi del mapa a les versions 9.x.

Dins del mapa, una instrucció anomena l'atribut del directori i l'atribut de l'ASA que alimenta, i altres instruccions tradueixen valors concrets. map-name memberOf Group-Policy seguit de map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly és la forma: el costat esquerre és el que va retornar el directori, el costat dret és el nom d'una política de grup que ja ha d'existir. Un nom distingit i un nom de visualització de política no són intercanviables, i una coincidència gairebé exacta en qualsevol de les dues cadenes no produeix cap error a l'inici de sessió.

Aquí mosseguen dos detalls: memberOf retorna tots els grups als quals pertany el compte, així que un usuari en dos grups mapats dóna al mapa dos valors candidats, i la regla alfabètica de la guia és l'únic desempat amb què podeu comptar en lloc del vostre propi ordre de prioritat. Un valor no mapat no dóna res, cosa que recau silenciosament en la política per defecte del perfil.

El camí DAP i què hi afegeix

DAP avalua condicions i aplica atributs damunt del resultat d'AAA. Un registre porta una prioritat, una acció i un conjunt de condicions; els registres s'avaluen per ordre de prioritat i l'acció decideix si l'avaluació continua o s'atura. És un model d'execució diferent del d'una consulta de valor, i per això mateix pot expressar regles que el mapa no pot.

El que DAP afegeix són entrades. Les condicions poden referenciar atributs del directori, atributs de l'extrem i l'estat de postura, i un registre coincident pot portar ACL, llistes d'URL o filtres per a aquella sessió. Així, una regla com que el personal de suport en un portàtil gestionat rebi la política de només lectura mentre el mateix personal en un dispositiu no gestionat en rep una de restringida és expressable en DAP i no en un mapa d'atributs. El mapa té exactament una entrada: el valor que el directori va retornar per a l'atribut que heu anomenat.

DAP també afegeix un segon lloc on mirar quan una sessió acaba en la política equivocada. Un registre que coincideix amb una acció de continuar no acaba l'avaluació, i un registre posterior encara pot canviar el resultat, així que el que observeu és el producte d'una seqüència i no d'una sola consulta. Llegiu els números de prioritat en ordre i recordeu que el registre de reserva pot ser el que fa la feina. El mapa, en canvi, no té seqüència: un atribut, un valor, una resposta.

On els dos discrepen

La precedència és la part que trenca dissenys. Quan una sessió coincideix amb una entrada del mapa i amb un registre DAP, el resultat depèn de la versió i de l'acció del registre, així que verifiqueu-ho a la vostra pròpia ASA en lloc de suposar que un dels mecanismes posseeix el resultat.

Tres modes de fallada expliquen la major part de la confusió. Un mapa definit però mai associat a l'etiqueta del servidor que utilitza el perfil produeix la política per defecte sense cap error enlloc. Una cadena de condició DAP que difereix del valor del directori en majúscules o espais mai no coincideix, i el registre de reserva s'aplica silenciosament. I una política de grup que encara no existeix és acceptada pel mapa, perquè el mapa només retorna un nom, així que la sessió no rep cap dels permisos previstos i no hi ha res al registre que assenyali l'objecte que falta. Comproveu els tres abans de tocar la pertinença als grups.

Llegir les proves d'una sessió en directe

Llegiu la resposta d'una sessió nova i no de la configuració. show vpn-sessiondb detail anyconnect filter name jdoe imprimeix la política de grup que la sessió va rebre realment, i show running-config ldap attribute-map confirma quins valors podia haver retornat el mapa. Pel costat del directori, test aaa-server authentication LDAP-AD username jdoe password <password> mostra els atributs que l'ASA va rebre, i debug ldap 255 mostra l'intercanvi quan la prova no coincideix amb el que esperàveu.

Després reconcilieu quatre registres per escrit: el valor del directori, el mapa o la condició DAP configurats, la política de grup local i el recurs al qual l'usuari va poder arribar realment. Si els tres primers encaixen i el quart no, el problema és al cos de la política i no a la selecció. Si la sessió mostra el nom de política correcte però l'ACL equivocada, deixeu de mirar LDAP del tot. Canvieu un registre alhora i torneu a comprovar una sessió nova, perquè una sessió reconnectada és l'única prova que reflecteix la configuració que acabeu d'escriure.