Aggiungere un utente a un gruppo VPN non concede l’accesso da solo

L’account è nel gruppo giusto, l’accesso è riuscito, e la connessione viene comunque rifiutata, oppure si connette e non raggiunge nulla di utile. Il riflesso abituale è aggiungere l’utente ad altri gruppi finché qualcosa cede, e così le organizzazioni concedono molto più di quanto chiedesse il ticket. L’appartenenza è un solo input della decisione di autorizzazione, mai la decisione: il gateway raccoglie alcuni fatti sulla sessione, li confronta con una policy ordinata e solo allora decide. Se è fallita un’altra condizione, cambiare gruppo non cambia nulla tranne la vostra esposizione.

L’appartenenza a un gruppo è una condizione, non un permesso

In RADIUS il gruppo arriva come attributo di autorizzazione, e gli attributi descrivono la sessione invece di concederla. Il server risponde Access-Accept o Access-Reject; in caso di accettazione può allegare Filter-Id, Class o gli attributi tunnel di RFC 2868, che l’apparato di rete dall’altra parte interpreta secondo il produttore. Nulla nel protocollo mappa un gruppo su accesso completo; quella mappatura la scrive chi ha configurato la policy sul gateway o sul server di accesso alla rete.

Per questo uno stesso nome di gruppo si comporta diversamente su due sistemi. Microsoft NPS compone policy di rete da condizioni, vincoli e impostazioni e le valuta in un ordine definito. OpenVPN Access Server ha il proprio modello di gruppi e regole, mentre un server OpenVPN comunitario spesso delega tutto a uno script client-connect o a un file client-config-dir.

Decide la regola che ha corrisposto, non il gruppo che ci si aspettava

La maggior parte dei motori si ferma alla prima policy corrispondente o alla più specifica. Se la policy 3 nega e la policy 7 consente, la sessione può fallire senza mai raggiungere la regola che l’avrebbe lasciata passare. L’ordine è un’impostazione reale su NPS e sulla maggior parte dei prodotti di controllo accessi, e si sposta negli anni.

Le condizioni che accompagnano il gruppo sono l’altra metà. Postura del dispositivo, metodo di autenticazione, MFA completata, rete di origine, soggetto del certificato o finestra oraria possono stare nella stessa policy. Se una manca, la policy non corrisponde, il motore prosegue e si applica il rifiuto predefinito. Dal posto dell’utente il gruppo sembra ignorato; dal posto del motore non è mai stato interrogato.

I dettagli della directory creano la stessa illusione. Una policy basata sull’appartenenza ai gruppi Windows legge i SID nel token, dove sono elencati solo i gruppi di sicurezza: un gruppo di distribuzione non compare mai. Il gruppo primario sta in un campo proprio, non nell’elenco, quindi una policy agganciata ad esso può fallire in silenzio.

Leggete il record di accettazione o rifiuto prima di toccare un gruppo

Fate prima una domanda: la richiesta ha raggiunto la fase di autorizzazione? Su NPS la risposta è nel registro eventi, dove 6272 annota l’accesso concesso, 6273 un rifiuto e 6274 una richiesta scartata prima della valutazione. Quei tre numeri separano tre indagini diverse, e solo una riguarda i gruppi.

Se il registro non è raggiungibile, interrogate il server e leggete la risposta. Una risposta senza Filter-Id e senza attributi tunnel dice che il server considera la sessione ordinaria e che il gateway applica regole proprie. Una risposta con attributi che il punto di applicazione non implementa è un altro guasto: l’autorizzazione è passata e il dispositivo ha ignorato il risultato.

radtest alice 'password' 10.0.0.5 0 testing123

Confrontate gli attributi restituiti con quelli documentati dal gateway, non con ciò che suggerisce il nome del gruppo. Quel confronto di solito separa un problema di policy da un problema di applicazione.

Un cambio di gruppo non è retroattivo

Gli attributi di autorizzazione vengono restituiti una volta, all’autenticazione della sessione. Il gateway li conserva sulla sessione e non rilegge la directory per ogni pacchetto: per questo una sessione stabilita continua dopo aver tolto qualcuno da un gruppo, e una nuova può fallire.

Per rendere effettivo il cambio serve una nuova decisione di autorizzazione, non solo chiavi nuove. Dove il server supporta RFC 5176, una Disconnect-Request o CoA-Request verso UDP 3799 forza la rivalutazione; altrimenti disconnettere il client e lasciarlo riconnettere. La rinegoziazione aggiorna le chiavi del tunnel e di solito lascia intatto l’esito dell’autorizzazione.

Correggete la condizione, non il gruppo

Una volta saputo quale policy è scattata, la riparazione è di solito piccola: riordinare un rifiuto che oscura il permesso voluto, aggiungere la condizione dispositivo o MFA mancante, o scrivere una regola stretta per quella risorsa invece di promuovere l’utente in un gruppo che ne porta altri dieci.

Un ciclo breve tiene onesto il cambiamento:

• Riproducete il rifiuto con l’account originale e annotate l’ID evento prima di cambiare qualsiasi cosa.
• Cambiate un solo oggetto, ordine delle policy, una condizione o un gruppo, e registrate quale.
• Aprite una sessione nuova, confermate che il permesso appare nel registro e che la risorsa si apre davvero.
• Provate un utente che deve restare rifiutato, così la correzione non ha allargato la policy per errore.

Se il permesso è corretto e la risorsa non si apre, il problema è passato a routing o risoluzione dei nomi nel momento in cui l’autorizzazione è passata. Tenete separati i due guasti e il prossimo ticket costerà minuti, non un pomeriggio.