Mappatura dei gruppi LDAP in ASA rispetto a DAP per i criteri di gruppo VPN
Una mappa di attributi LDAP e un criterio DAP scelgono entrambi criteri di gruppo, ma agiscono in momenti diversi. Scoprite quale ha usato davvero la vostra sessione ASA.
Due record distinti decidono quale criterio di gruppo riceve una sessione AnyConnect, e vivono in parti diverse della configurazione con modalità di errore diverse. Una mappa di attributi LDAP traduce un valore della directory in un attributo di autorizzazione ASA durante l'autenticazione; un record DAP valuta le condizioni in seguito e può aggiungere o sovrascrivere attributi. Entrambi possono finire sullo stesso nome di criterio, quindi un accesso che funziona non vi dice nulla su quale meccanismo lo abbia prodotto. Il senso del confronto è sceglierne uno deliberatamente invece di lasciare che il secondo sovrascriva silenziosamente il primo.
Due meccanismi, due punti di decisione
La scelta si riduce a tre domande. La decisione dipende da un solo valore di attributo della directory, richiede più di quel valore, e quale meccanismo può vincere quando entrambi corrispondono?
Se l'unico input è l'appartenenza al gruppo, la mappa degli attributi è lo strumento più piccolo e quello più facile da verificare: una mappa, collegata a un solo server AAA, con una riga per gruppo. Se la selezione deve considerare la postura, l'identità dell'endpoint, un secondo attributo o una finestra temporale, gli input della mappa finiscono e DAP è il meccanismo in grado di esprimere la regola. Se entrambi sono in gioco, imparate la precedenza sulla vostra versione prima di scrivere l'uno o l'altro, perché una sessione che corrisponde a un record DAP potrebbe non mantenere il criterio restituito dalla mappa. Tutto il resto è contabilità.
Il percorso della mappa degli attributi, nell'ordine della configurazione
Il percorso della mappa inizia dalla definizione del server AAA. La mappa degli attributi deve essere collegata alla voce del server LDAP che il profilo di connessione usa davvero; una mappa che esiste nella configurazione in esecuzione ma non è referenziata da quel server non cambia nulla. È quella riga di collegamento a rendere vivo il resto della configurazione. La guida alla mappatura LDAP di ASA è il riferimento per la sintassi della mappa nelle versioni 9.x.
All'interno della mappa, un'istruzione nomina l'attributo della directory e l'attributo ASA che alimenta, e altre istruzioni traducono valori specifici. map-name memberOf Group-Policy seguito da map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly è la forma: il lato sinistro è ciò che la directory ha restituito, il lato destro è il nome di un criterio di gruppo che deve già esistere. Un nome distinto e un nome visualizzato di criterio non sono intercambiabili, e una quasi corrispondenza in una delle due stringhe non produce alcun errore all'accesso.
Due dettagli mordono qui: memberOf restituisce ogni gruppo a cui appartiene l'account, quindi un utente in due gruppi mappati dà alla mappa due valori candidati, e la regola alfabetica della guida è l'unico spareggio su cui potete contare invece del vostro ordine di priorità. Un valore non mappato non dà nulla, il che ricade silenziosamente sul criterio predefinito del profilo.
Il percorso DAP, e ciò che aggiunge
DAP valuta le condizioni e applica gli attributi sopra il risultato AAA. Un record porta una priorità, un'azione e un insieme di condizioni; i record vengono valutati in ordine di priorità e l'azione decide se la valutazione continua o si ferma. È un modello di esecuzione diverso da una ricerca di valore, ed è proprio per questo che può esprimere regole che la mappa non può.
Ciò che DAP aggiunge sono gli input. Le condizioni possono referenziare attributi della directory, attributi dell'endpoint e stato di postura, e un record corrispondente può portare ACL, elenchi di URL o filtri per quella sessione. Così una regola come il personale di supporto su un portatile gestito che riceve il criterio di sola lettura mentre lo stesso personale su un dispositivo non gestito ne riceve uno limitato è esprimibile in DAP e non in una mappa di attributi. La mappa ha esattamente un input: il valore che la directory ha restituito per l'attributo che avete nominato.
DAP aggiunge anche un secondo posto in cui guardare quando una sessione finisce nel criterio sbagliato. Un record che corrisponde con un'azione di continuazione non termina la valutazione, e un record successivo può ancora cambiare l'esito, quindi ciò che osservate è il prodotto di una sequenza e non di una singola ricerca. Leggete i numeri di priorità in ordine, e ricordate che il record di fallback può essere quello che fa il lavoro. La mappa, al contrario, non ha sequenza: un attributo, un valore, una risposta.
Dove i due sono in disaccordo
La precedenza è la parte che rompe i progetti. Quando una sessione corrisponde sia a una voce della mappa sia a un record DAP, il risultato dipende dalla versione e dall'azione del record, quindi verificatelo sulla vostra ASA invece di presumere che uno dei meccanismi possieda l'esito.
Tre modalità di errore spiegano gran parte della confusione. Una mappa definita ma mai collegata al tag del server usato dal profilo produce il criterio predefinito senza alcun errore da nessuna parte. Una stringa di condizione DAP che differisce dal valore della directory per maiuscole o spazi non corrisponde mai, e il record di fallback si applica silenziosamente. E un criterio di gruppo che non esiste ancora viene accettato dalla mappa, perché la mappa restituisce solo un nome, quindi la sessione non ottiene nessuno dei permessi previsti e nel log non c'è nulla che punti all'oggetto mancante. Controllate tutti e tre prima di toccare l'appartenenza ai gruppi.
Leggere le prove da una sessione attiva
Leggete la risposta da una sessione nuova anziché dalla configurazione. show vpn-sessiondb detail anyconnect filter name jdoe stampa il criterio di gruppo che la sessione ha effettivamente ricevuto, e show running-config ldap attribute-map conferma quali valori la mappa avrebbe potuto restituire. Dal lato della directory, test aaa-server authentication LDAP-AD username jdoe password <password> mostra gli attributi che l'ASA ha ricevuto indietro, e debug ldap 255 mostra lo scambio quando il test non corrisponde a ciò che vi aspettavate.
Poi riconciliate quattro record per iscritto: il valore della directory, la mappa o condizione DAP configurata, il criterio di gruppo locale e la risorsa a cui l'utente è riuscito davvero ad accedere. Se i primi tre coincidono e il quarto no, il problema è nel corpo del criterio e non nella selezione. Se la sessione mostra il nome di criterio corretto ma l'ACL sbagliata, smettete del tutto di guardare LDAP. Cambiate un record alla volta e ricontrollate una nuova sessione, perché una sessione ricollegata è l'unica prova che riflette la configurazione che avete appena scritto.