Migrare un backend di autenticazione VPN senza riutilizzare hash vecchi

I nomi utente compaiono nella nuova directory, la migrazione viene dichiarata conclusa e gli accessi continuano a fallire. Il gateway ha ancora bisogno di un percorso di autenticazione supportato e di un risultato di autorizzazione corretto, e nessuno dei due deriva da una directory che ora contiene gli account. Un trasferimento di backend è un passaggio con ciclo di vita, non un lavoro di copia. Il sintomo qui sotto è quello che di solito rivela la differenza.

Il sintomo: gli account esistono, le sessioni no

La nuova directory contiene ogni nome utente, un bind di prova riesce e il client VPN restituisce comunque un errore di autenticazione. Questa combinazione significa che l'identità esiste, ma il percorso di verifica usato dal gateway non la raggiunge, oppure la raggiunge con un metodo che non può soddisfare. Entrambe sono configurazione, e sono problemi diversi.

Il primo è impiantistica: il gateway punta a un backend che non risponde, usa un segreto condiviso che l'altra parte non si aspetta o chiede un attributo che il nuovo servizio non restituisce. Il secondo è crittografico: il metodo richiede il segreto originale e il nuovo archivio contiene solo un hash dello stesso. Il testo dell'errore è simile in entrambi i casi, per questo i due vengono trattati come un solo problema.

Separare i due prima di toccare gli account fa risparmiare una settimana. Uno è una questione di instradamento e fiducia, l'altro è una decisione sul ripristino delle credenziali, e mescolarli produce modifiche che nessuno riesce ad attribuire.

Mappa la catena prima di spostare qualcuno

Annota sei cose per ogni profilo client: il metodo di autenticazione esterno, un eventuale metodo interno, l'identità del server che il client si aspetta, l'interfaccia tra gateway e backend, l'attributo che il gateway mappa sull'appartenenza ai gruppi e la politica delle risorse risultante. Leggerli in ordine mostra quale anello non ha proprietario. Ogni voce ha un responsabile, e il passaggio fallisce su quella che nessuno ha controllato.

Un normale accesso alla directory non attraversa quasi nulla di quella catena. Dimostra che l'account esiste e che la password funziona, cioè proprio la parte che non è mai stata in dubbio.

Gli hash non viaggiano tra i metodi

La compatibilità delle credenziali va verificata una volta, prima che si sposti qualsiasi coorte. FreeRADIUS documenta la divisione con chiarezza: un controllo CHAP che il server esegue da sé richiede la password reale, e MS-CHAP accetta quella password o materiale NT adeguato. Un hash creato per un altro scopo non va bene in nessuno dei due casi, per quanto sia robusto.

La distinzione riguarda chi calcola la prova. Un metodo che verifica vincolandosi alla directory lascia che la directory controlli ciò che può controllare. Un metodo che verifica ricalcolando una risposta alla sfida ha bisogno del segreto stesso, perché il server deve eseguire lo stesso calcolo.

Dove il materiale manca, le opzioni oneste sono un reset supportato, una nuova registrazione, un servizio di verifica esterno o un cambio di metodo. Un'esportazione temporanea di password recuperabili non è in quell'elenco. Crea un archivio di credenziali in testo semplice nella settimana più caotica del progetto e di solito sopravvive alla migrazione.

Coorte pilota, poi modifiche al ciclo di vita

Sposta una piccola coorte di identità approvate con il client reale e prova quattro cose: un accesso nuovo, una credenziale deliberatamente errata, le risorse che la sessione può raggiungere e le risorse che non deve raggiungere. Controlla anche l'identità del server accettata dal client, perché una discordanza nel nome del certificato è invisibile finché qualcuno non legge il log del client.

Poi esercita le modifiche da cui dipende davvero la distribuzione. Cambia una password, rinnova o registra di nuovo un certificato e togli l'accesso a un account pilota. Dopo ciascuna, conferma quale verificatore ha gestito il tentativo, perché una sessione creata prima del passaggio può continuare a funzionare e non dimostra nulla sul prossimo accesso.

Separa la consegna del profilo dal cambio di identità. Ogni coorte ha bisogno del profilo previsto, del proprio stato di credenziale o registrazione, del servizio di autenticazione che deve usare e di un contatto di supporto, e nessuno di questi dati deve contenere un segreto.

Se i percorsi vecchio e nuovo coesistono, delimitali con una data di fine. Un ritorno automatico può ammettere un account con una credenziale vecchia dopo che il nuovo proprietario ha rimosso l'accesso, e questa è una regressione di sicurezza mascherata da disponibilità.

Il rollback non può ripristinare una credenziale

Annullare il passaggio lascia la directory esattamente com'è ora. Una password reimpostata resta reimpostata, un certificato revocato resta revocato e un formato di credenziale cambiato resta cambiato. Sono eventi nella directory, e il gateway non è mai stato la loro origine. Il ripristino va definito per evento, e nulla di ciò può dipendere dalla ricostruzione di un segreto da un hash incompatibile.

Mantieni un percorso amministrativo che non usi la connessione in migrazione. Quando la nuova autenticazione fallisce, metti in pausa la coorte e usa il suo percorso di ripristino documentato invece di indebolire l'autenticazione per tutti solo per rispettare una scadenza.

Quando le coorti sono coperte, ritira le credenziali, i profili e le relazioni di fiducia vecchi del backend tramite i loro proprietari. Conferma che il vecchio percorso non ammette più utenti e conserva la mappatura da identità a politica priva di segreti che il supporto ancora necessita. Una migrazione è finita quando il nuovo ciclo di vita funziona e nessuno entra più dal vecchio percorso, non quando l'elenco degli account sembra completo.