La VPN FortiGate finisce nel gruppo sbagliato: corrispondenza RADIUS
Fortinet-Group-Name viene confrontato con la risposta, non con l’etichetta locale del gruppo. Verifica i tre nomi prima di ampliare la corrispondenza ad Any.
L’accesso riesce, il tunnel sale e l’utente finisce sulla politica sbagliata o su nessuna politica. Nulla nel registro di FortiGate annuncia che il gruppo mancava, perché dal suo lato l’autenticazione ha funzionato e la corrispondenza del gruppo semplicemente non è scattata. La catena da ispezionare contiene tre nomi distinti, e di solito non sono la stessa stringa.
Tre nomi con tre compiti
Annota tutti e tre prima di toccare qualsiasi configurazione, perché due di essi vivono su sistemi diversi.
| Record | Illustrative value |
|---|---|
| Directory membership checked by the RADIUS policy | Engineering VPN users |
| Returned Fortinet-Group-Name string | vpn-engineering |
| FortiGate local access group | VPN-Engineering |
Il gruppo della directory è ciò che valuta la tua politica RADIUS. L’attributo restituito è un valore dentro la risposta Access-Accept. Il gruppo locale di FortiGate è un contenitore a cui la politica fa riferimento per nome. Confondere due qualsiasi di questi produce un accesso che funziona e un’autorizzazione che non funziona.
Dove avviene davvero la corrispondenza
La spiegazione della corrispondenza dei gruppi RADIUS di Fortinet indica Fortinet-Group-Name come attributo di gruppo predefinito. FortiGate confronta il server remoto configurato e il valore del nome del gruppo con ciò che porta la risposta, il che significa che il confronto è contro la stringa restituita, non contro l’etichetta visualizzata del tuo gruppo locale.
Per questo un gruppo locale chiamato VPN-Engineering può stare accanto a un valore restituito vpn-engineering e non corrispondere a nulla. Maiuscole e ortografia non sono cosmetiche in questo confronto. Scegli una stringa, usala nella risposta e fai riferimento alla stessa stringa nella regola di corrispondenza del gateway.
Su FortiAuthenticator il gruppo deve essere associato all’attributo e incluso nella politica di servizio RADIUS corrispondente, con il controllo di restituzione dell’attributo di gruppo abilitato dove applicabile.
La risposta può riuscire senza l’attributo
Per NPS o un altro server RADIUS, imponi la condizione del gruppo della directory nella politica e poi configura l’attributo di risposta supportato. Un controllo della password riuscito produce da solo un Access-Accept, e un Access-Accept senza stringa di gruppo è una risposta perfettamente valida che non autorizza nulla sul lato FortiGate. Questa è la forma più comune del problema.
Definire un gruppo non è lo stesso che inviarlo. Sono due passaggi di configurazione su due schermate diverse, e di solito se ne fa solo uno.
Perché la corrispondenza con Any è una trappola
Una corrispondenza di gruppo remoto Any è un progetto legittimo quando il server RADIUS ammette già esattamente la popolazione che vuoi. Scegli quella delega deliberatamente. Ampliare la corrispondenza per far sparire un attributo mancante ammette ogni account che il server RADIUS accetta, compresi quelli che non avrebbero mai dovuto avere accesso alla VPN. Il sintomo sparisce e il controllo degli accessi smette silenziosamente di esistere.
Se non riesci a nominare chi il server RADIUS dovrebbe ammettere, non sei pronto per una corrispondenza Any.
Conserva quattro record per il supporto
Quando ancora non funziona, raccogli quattro cose: la politica RADIUS selezionata, l’attributo di gruppo effettivamente restituito, il server FortiGate e il valore con cui è stato confrontato, e il gruppo locale risultante. Quei quattro record localizzano la rottura senza esporre password né cambiare l’appartenenza ai gruppi per vedere cosa succede.
Prova un account autorizzato e uno fuori ambito con la regola reale, e controlla la politica e l’accesso alle risorse risultanti oltre all’esito dell’autenticazione. Solo la coppia ti dice se la corrispondenza fa ciò che pensi.