Waarom die wysiging van ’n .ovpn-lêer nie MFA op die bediener kan aanskakel nie

Jy voeg auth-user-pass by ’n profiel, maak weer verbinding, en die kliënt vra om ’n gebruikersnaam en wagwoord. Dit lyk of MFA aan is. Dan tik jy ’n kode van die verkeerde rekening in, of ’n kode wat tien minute gelede verval het, en die tonnel kom steeds op. Dit is die simptoom: die kliënt het verander, die bediener nie. ’n Eenmalige wagwoord is eers ’n faktor wanneer ’n verifieerder op die bediener besluit of dit geldig is vir die identiteit wat dit opeis.

Die aanvraag bewys net dat die kliënt gevra het, niks meer nie

’n .ovpn-lêer is ’n dokument aan die kliënt se kant. Dit kan die kliënt sê om geloofsbriewe te vra, dit te kas of op te hou kas. Dit kan nie ’n gebruiker registreer, ’n PAM-module installeer, of die bediener ’n tweede faktor laat vereis wat dit tans nie nagaan nie.

Om ’n verifikasieprogram op ’n selfoon te installeer skep ook nie daardie verhouding nie. Die Google Authenticator PAM-projek is ’n OTP-verifikasiekomponent wat agter OpenVPN; dit is nie ’n manier om Google-rekeningaanmelding op ’n ingevoerde profiel te plak nie.

Registrasie is die deel wat ’n profiel nie kan doen nie

TOTP benodig registrasiemateriaal wat tussen die verifikasieprogram en sy verifieerder gedeel word. Die ses syfers op die selfoon is uitset; die saad agter hulle is die geheim, en dit behoort aan een identiteit.

Dus het die operateur ’n registrasieproses nodig wat die regte saad aan die regte VPN-identiteit bind, plus ’n geverifieerde vervangingsroete vir ’n verlore selfoon. Om gebruikers ’n lêer te laat oplaai wat na hulle self vernoem is, maak van registrasie ’n geleentheid vir rekening-oorname, en die opgelaaide lêer versleutel verander dit nie.

’n PAM-gebaseerde ontwerp hoef nie ’n aparte Unix-rekening per VPN-gebruiker te skep nie. Die module-dokumentasie ondersteun alternatiewe geheime paadjies en ’n toegewyde lêertoegangsrekening, wat ’n lêerstelsel-identiteit is eerder as die aanmeldidentiteit wat geverifieer word.

Die algemene fout is ’n vaste geheime pad wat op een gebruikersnaam eindig, gekopieer uit ’n een-gebruiker-voorbeeld. Dit is ’n een-identiteit-demonstrasie, nie ’n per-gebruiker-soektog nie, en om dit vir elke versoek te gebruik gee niemand ’n onafhanklik geregistreerde verifieerder nie. Skryf die identiteitstoewysing neer, beskerm die saadlêers, en hou die wagwoord-, sertifikaat- en rekeningkontroles in dieselfde verifikasiestapel.

Lees die PAM-stapel vir wat werklik vereis word

’n Reël soos account required pam_permit.so implementeer nie rekeningbevoegdheid nie en voeg nie ’n faktor by nie. Dit laat daardie PAM-rekeningbestuurstadium toe, wat ’n stelling oor ’n stadium is eerder as oor jou gebruikers.

Dieselfde geld vir toegeeflike registrasie-opsies. Om gebruikers sonder ’n geregistreerde geheim te aanvaar, kan ’n doelbewuste uitrolkeuse wees, maar dit is nie bewys dat MFA verpligtend is nie, en dit behoort as ’n tydelike uitsondering met ’n einddatum neergeskryf te word.

Pas die kliënt se interaksie by die bediener se ontwerp aan

auth-user-pass

Daardie opdrag vra gebruikersnaam- en wagwoordinvoer. Dit stel nie PAM op nie, skep nie ’n registrasierekord nie, en sê nie vir die bediener dat die wagwoordveld ’n TOTP-waarde bevat nie. Die bedienerintegrasie en die kliënt moet ooreenkom oor ’n interaksie wat die ontplooiing werklik ondersteun: ’n uitdaging, ’n gedokumenteerde gekombineerde geloofsbriefformaat, of ’n produk-spesifieke vloei.

Moenie ’n kode by die wagwoord voeg net omdat die kliënt een veld wys nie. Dit werk net waar die bediener se inprop presies daardie formaat verwag, en dit misluk verwarrend oral elders.

Hou saad en QR-materiaal uit gedeelde profiele en roetine-diagnostiese logboeke. ’n Kode wat oor die geauthentiseerde aanmeldkanaal ingedien word, is nie dieselfde objek as die saad wat tydens beheerde registrasie voorsien is nie, en om hulle in ’n ondersteuningskaartjie te meng, is hoe geheime ontsnap.

Herverbindings, tekens en die toets wat dit besleg

Beplan vir wat ná die eerste suksesvolle aanmelding gebeur. ’n Kode wat vroeër aanvaar is, kan verval het of as ’n herhaling by die volgende verifikasie verwerp word. auth-nocache beheer die behoud van geloofsbriewe en installeer nie MFA nie, en reneg-sec 0 is nie ’n definisie van TOTP-ondersteuning nie, maak nie saak hoe dikwels dit in forumdrade voorkom nie.

Sommige ontplooiings reik verifikasietekens ná die eerste kontrole uit sodat herverbindings nie weer vra nie. Dit is ’n ontwerpbesluit met sy eie geldigheidsvenster en herroepingsverhaal, nie ’n verstek wat jy erf nie.

Toets dan die toelatingsbeleid met die kliënt wat mense werklik gebruik. ’n Geregistreerde gebruiker met die regte wagwoord, sertifikaat en huidige kode behoort te konnekteer. ’n Verkeerde kode, ’n gebruiker sonder registrasie, en ’n verbode rekening behoort elkeen te misluk, en die rede behoort in die bedienerlog sigbaar te wees. Totdat jy daardie verwerppings gesien het, het jy ’n aanvraag, nie ’n beleid nie.