Per què editar un fitxer .ovpn no pot activar l’MFA al servidor

Afegiu auth-user-pass a un perfil, torneu a connectar-vos i el client demana un nom d’usuari i una contrasenya. Sembla que l’MFA estigui activat. Després escriviu un codi del compte equivocat, o un codi que va caducar fa deu minuts, i el túnel encara s’aixeca. Aquest és el símptoma: el client ha canviat, el servidor no. Una contrasenya d’un sol ús només és un factor quan un verificador al servidor decideix si és vàlida per a la identitat que la reclama.

La petició només demostra que el client ha preguntat, res més

Un fitxer .ovpn és un document del costat del client. Pot dir al client que demani credencials, que les desi a la memòria cau o que deixi de fer-ho. No pot registrar un usuari, instal·lar un mòdul PAM ni fer que el servidor exigeixi un segon factor que ara no comprova.

Instal·lar una aplicació d’autenticació al telèfon tampoc no crea aquesta relació. El projecte Google Authenticator PAM és un component de verificació d’OTP que pot seure darrere de OpenVPN; no és una manera d’enganxar l’inici de sessió del compte de Google a un perfil importat.

El registre és la part que un perfil no pot fer

TOTP necessita material de registre compartit entre l’aplicació d’autenticació i el seu verificador. Els sis dígits del telèfon són la sortida; la llavor que hi ha darrere és el secret, i pertany a una sola identitat.

Per tant, l’operador necessita un procés de registre que lligui la llavor correcta a la identitat VPN correcta, més un camí de substitució verificat per a un telèfon perdut. Deixar que els usuaris pugin un fitxer amb el seu propi nom converteix el registre en una oportunitat de segrest de compte, i xifrar la pujada no ho canvia.

Un disseny basat en PAM no ha de crear un compte Unix separat per a cada usuari VPN. La documentació del mòdul admet camins alternatius per als secrets i un compte dedicat per a l’accés a fitxers, que és una identitat del sistema de fitxers i no la identitat d’inici de sessió que es verifica.

L’error habitual és un camí de secret fix que acaba en un sol nom d’usuari, copiat d’un exemple per a un sol usuari. Això és una demostració d’una identitat, no una consulta per usuari, i fer-lo servir per a cada petició no dóna a ningú una aplicació d’autenticació registrada de manera independent. Escriviu el mapatge d’identitats, protegiu els fitxers de llavors i manteniu les comprovacions de contrasenya, certificat i compte a la mateixa pila d’autenticació.

Llegiu la pila PAM per saber què es demana realment

Una línia com account required pam_permit.so no implementa l’elegibilitat del compte ni afegeix cap factor. Permet aquella etapa de gestió de comptes de PAM, que és una afirmació sobre una etapa i no sobre els vostres usuaris.

El mateix passa amb les opcions de registre permissives. Acceptar usuaris sense cap secret registrat pot ser una decisió deliberada de desplegament, però no és prova que l’MFA sigui obligatori, i s’hauria d’anotar com una excepció temporal amb data de finalització.

Feu coincidir la interacció del client amb el disseny del servidor

auth-user-pass

Aquesta directiva demana entrada de nom d’usuari i contrasenya. No configura PAM, no crea cap registre d’inscripció ni diu al servidor que el camp de contrasenya conté un valor TOTP. La integració del servidor i el client han d’acordar una interacció que el desplegament realment admeti: un repte, un format de credencials combinat i documentat, o un flux específic del producte.

No afegiu un codi a la contrasenya només perquè el client mostra un sol camp. Això funciona només on el connector del servidor espera exactament aquest format, i falla de manera confusa a tota la resta.

Manteniu les llavors i el material QR fora dels perfils compartits i dels registres de diagnòstic rutinaris. Un codi enviat pel canal d’inici de sessió autenticat no és el mateix objecte que la llavor lliurada durant un registre controlat, i barrejar-los en un tiquet de suport és com s’escapen els secrets.

Reconnexions, testimonis i la prova que ho resol

Planifiqueu què passa després del primer inici de sessió correcte. Un codi acceptat anteriorment pot haver caducat o ser rebutjat com a repetició a la propera autenticació. auth-nocache controla la retenció de credencials i no instal·la MFA, i reneg-sec 0 no és cap definició de suport TOTP, per molt sovint que aparegui en fils de fòrum.

Alguns desplegaments emeten testimonis d’autenticació després de la comprovació inicial perquè les reconnexions no tornin a preguntar. És una decisió de disseny amb la seva pròpia finestra de validesa i la seva història de revocació, no un valor per defecte que hereteu.

Després proveu la política d’admissió amb el client que la gent fa servir de debò. Un usuari registrat amb la contrasenya, el certificat i el codi actual correctes s’ha de connectar. Un codi incorrecte, un usuari sense registre i un compte prohibit han de fallar cadascun, i el motiu ha de ser visible al registre del servidor. Fins que no hàgiu vist aquests rebuigs, teniu una petició, no una política.