Perché modificare un file .ovpn non può attivare l’MFA sul server

Aggiungete auth-user-pass a un profilo, vi riconnettete e il client chiede un nome utente e una password. Sembra che l’MFA sia attivo. Poi digitate un codice dell’account sbagliato, o un codice scaduto dieci minuti fa, e il tunnel si alza lo stesso. Questo è il sintomo: il client è cambiato, il server no. Una password monouso è un fattore solo quando un verificatore sul server decide se è valida per l’identità che la rivendica.

La richiesta dimostra solo che il client ha chiesto, nulla di più

Un file .ovpn è un documento lato client. Può dire al client di richiedere le credenziali, di metterle in cache o di smettere di farlo. Non può registrare un utente, installare un modulo PAM né far pretendere al server un secondo fattore che al momento non controlla.

Neppure installare un’app di autenticazione su un telefono crea quel rapporto. Il progetto Google Authenticator PAM è un componente di verifica OTP che può stare dietro OpenVPN; non è un modo per incollare l’accesso all’account Google su un profilo importato.

La registrazione è la parte che un profilo non può fare

TOTP ha bisogno di materiale di registrazione condiviso tra l’app di autenticazione e il suo verificatore. Le sei cifre sul telefono sono l’output; il seme dietro di esse è il segreto, e appartiene a una sola identità.

L’operatore ha quindi bisogno di un processo di registrazione che leghi il seme giusto all’identità VPN giusta, più un percorso di sostituzione verificato per un telefono smarrito. Lasciare che gli utenti carichino un file con il proprio nome trasforma la registrazione in un’occasione di appropriazione dell’account, e cifrare il caricamento non cambia la cosa.

Un progetto basato su PAM non deve creare un account Unix separato per ogni utente VPN. La documentazione del modulo supporta percorsi alternativi per i segreti e un account dedicato per l’accesso ai file, cioè un’identità del file system e non l’identità di accesso che viene verificata.

L’errore comune è un percorso del segreto fisso che termina con un solo nome utente, copiato da un esempio a utente singolo. È una dimostrazione per una sola identità, non una ricerca per utente, e usarlo per ogni richiesta non dà a nessuno un’app di autenticazione registrata in modo indipendente. Scrivete la mappatura delle identità, proteggete i file dei semi e tenete i controlli di password, certificato e account nella stessa pila di autenticazione.

Leggete la pila PAM per vedere che cosa è realmente richiesto

Una riga come account required pam_permit.so non implementa l’idoneità dell’account e non aggiunge un fattore. Consente quella fase di gestione degli account PAM, che è un’affermazione su una fase e non sui vostri utenti.

Lo stesso vale per le opzioni di registrazione permissive. Accettare utenti senza alcun segreto registrato può essere una scelta di distribuzione deliberata, ma non è prova che l’MFA sia obbligatorio, e andrebbe annotato come eccezione temporanea con una data di fine.

Allineate l’interazione del client al progetto del server

auth-user-pass

Questa direttiva chiede l’inserimento di nome utente e password. Non configura PAM, non crea un record di registrazione e non dice al server che il campo password contiene un valore TOTP. L’integrazione lato server e il client devono concordare un’interazione che la distribuzione supporta davvero: una sfida, un formato di credenziali combinato documentato o un flusso specifico del prodotto.

Non aggiungete un codice alla password solo perché il client mostra un unico campo. Funziona solo dove il plugin del server si aspetta esattamente quel formato, e fallisce in modo confuso ovunque altrove.

Tenete i semi e il materiale QR fuori dai profili condivisi e dai log diagnostici di routine. Un codice inviato sul canale di accesso autenticato non è lo stesso oggetto del seme fornito durante una registrazione controllata, e mescolarli in un ticket di assistenza è il modo in cui i segreti sfuggono.

Riconnessioni, token e il test che risolve la questione

Pianificate che cosa succede dopo il primo accesso riuscito. Un codice accettato in precedenza può essere scaduto o rifiutato come replay alla successiva autenticazione. auth-nocache controlla la conservazione delle credenziali e non installa l’MFA, e reneg-sec 0 non è una definizione di supporto TOTP, per quanto spesso compaia nei thread dei forum.

Alcune distribuzioni rilasciano token di autenticazione dopo il controllo iniziale, così le riconnessioni non richiedono di nuovo. È una decisione di progetto con la propria finestra di validità e la propria storia di revoca, non un valore predefinito che ereditate.

Poi provate la politica di ammissione con il client che le persone usano davvero. Un utente registrato con la password, il certificato e il codice attuale corretti dovrebbe connettersi. Un codice errato, un utente senza registrazione e un account vietato dovrebbero fallire ciascuno, e il motivo dovrebbe essere visibile nel log del server. Finché non avete visto quei rifiuti, avete una richiesta, non una politica.