Realm di autenticazione VPN: quale namespace account vince?
Un realm instrada un accesso verso un solo sistema di identità, non verso un paese. Correggi la forma del nome, traccia la richiesta attraverso il proxy e annota chi ha risposto.
Ogni accesso VPN finisce in un namespace di account, e il realm è il selettore che decide quale. Non dice nulla sul paese, sulla posizione del server o sul livello di fiducia. Due nomi utente identici possono vivere in realm diversi, ed è per questo che una password corretta a volte autentica l'account sbagliato. Questo runbook corregge prima la forma dell'identità, poi traccia la richiesta fino al sistema che ha effettivamente risposto.
Che cosa seleziona il realm
Un gateway riceve un nome utente e deve decidere dove verificarlo. Il realm è la parte di quel nome, o l'attributo accanto ad esso, che sceglie il database: una directory, un pool RADIUS, un file di account locale. Il servizio NPS di Microsoft lo chiama nome di realm e instrada con esso le richieste di connessione, mentre l'identificatore di accesso alla rete EAP porta la stessa idea come suffisso dopo il segno at in RFC 7542. Entrambi sono selettori, e nessuno dei due decide se la credenziale sia valida.
Questa separazione produce due guasti molto diversi. Un realm che instrada correttamente con una password sbagliata dà un rifiuto, mentre un realm che instrada al database sbagliato può rifiutare una password corretta o accettare quella di qualcun altro. Nessuno degli errori menziona il realm, ed è per questo che la prima diagnosi è sempre la stessa: scoprire quale sistema ha risposto.
La sintassi del realm appartiene alla distribuzione. Alcuni servizi vogliono un nome non qualificato più un attributo, altri vogliono user@domain, e pochi si aspettano una forma con barra rovesciata che la maggior parte delle guide non menziona.
Usare la forma che il backend si aspetta
Chiedere all'operatore quale forma digitare prima di provare suffissi presi da un tutorial. Un nome qualificato dal dominio che arriva a un backend che si aspetta un nome semplice di solito fallisce la ricerca, non il controllo della password. Lo stesso nome breve in due directory è il caso in cui un realm mancante fa più danni.
Non considerare l'account di gestione come prova. La console web con cui amministri il servizio può autenticare contro un file locale, mentre il tunnel controlla una directory completamente diversa. Prova con le credenziali che userebbe un utente reale, sull'interfaccia che userebbe un utente reale. Un accesso riuscito alla console non dice nulla sul realm che il gateway applica all'autenticazione VPN.
I browser e i client di posta a volte memorizzano un'identità precedente e la inviano di nuovo in silenzio. Quando il nome utente segnalato differisce da quello digitato, quella cache è il primo posto da guardare.
Tracciare la richiesta attraverso il proxy
Su un front end FreeRADIUS i realm sono dichiarati nella configurazione del proxy, e il suffisso dichiarato decide quale server domestico riceve la richiesta. Leggi quel file prima di cambiare qualsiasi cosa, perché una richiesta che non corrisponde a nessun realm viene gestita localmente per impostazione predefinita.
grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'
grep mostra quali suffissi esistono e quale pool ciascuno prende di mira. La chiamata radtest invia un nome con un realm e una password volutamente sbagliata, quindi un rifiuto prova che sia l'instradamento sia il controllo delle credenziali sono stati eseguiti. Le righe di log intorno a quel tentativo mostrano se il nome è stato rimosso prima del proxy e quale server domestico lo ha preso. Se il log non mostra alcuna corrispondenza di realm, la richiesta non ha mai lasciato il server locale e il suffisso è il problema, non la password.
Cambia una cosa alla volta e ripeti il tentativo, perché il log separa l'instradamento dal guasto delle credenziali solo quando l'input differisce tra le esecuzioni. Tieni il segreto condiviso fuori dalla cronologia della shell dove lo strumento supporta la lettura da file o da prompt.
Registrare il tentativo senza farlo trapelare
Scrivi il guasto in una forma su cui un amministratore può agire: l'interfaccia, la forma dell'identità, se era presente un realm e l'errore esatto non segreto. Tieni il nome utente attivo fuori dai report pubblici e il realm dentro. Oscurare ogni identità con lo stesso segnaposto nasconde proprio la mancata corrispondenza che stai cercando. Anche la marca temporale conta, perché gateway, proxy e directory tengono log separati.
Poi documenta per gli utenti la forma vincente, perché la prossima persona che la digita male apre lo stesso ticket. Un reset della password non corregge una richiesta che continua ad atterrare nel namespace sbagliato. Il realm è una decisione di instradamento, e le decisioni di instradamento si correggono nominandole correttamente.