Zergatik .ovpn fitxategi bat editatzeak ezin duen MFA piztu zerbitzarian

auth-user-pass gehitzen diozu profilari, berriro konektatzen zara, eta bezeroak erabiltzaile-izena eta pasahitza eskatzen ditu. Badirudi MFA piztuta dagoela. Gero kontu okerreko kode bat idazten duzu, edo duela hamar minutu iraungi zen kode bat, eta tunela hala ere altxatzen da. Hori da sintoma: bezeroa aldatu da, zerbitzaria ez. Behin-behineko pasahitza faktorea da zerbitzariko egiaztatzaile batek erabakitzen duenean baliozkoa den ala ez hura aldarrikatzen duen identitatearentzat.

Eskaerak bezeroak galdetu duela frogatzen du soilik, ez gehiago

.ovpn fitxategia bezeroaren alderdiko dokumentua da. Bezeroari kredentzialak eskatzeko, gordetzeko edo gordetzeari uzteko esan diezaioke. Ezin du erabiltzailerik erregistratu, PAM modulurik instalatu, edo zerbitzariak gaur egun egiaztatzen ez duen bigarren faktorea eskatzea lortu.

Telefonoan autentifikazio-aplikazio bat instalatzeak ere ez du harreman hori sortzen. Google Authenticator PAM proiektuak OTP egiaztatzeko osagaia da eta OpenVPN-en atzean egon daiteke; ez da Google kontuko saio-hasiera inportatutako profil batera itsasteko modua.

Erregistroa profilak egin ezin duen zatia da

TOTPk autentifikazio-aplikazioaren eta haren egiaztatzailearen artean partekatutako erregistro-materiala behar du. Telefonoko sei zifrak irteera dira; haien atzeko hazia sekretua da, eta identitate bakarrarena da.

Beraz, operadoreak hazia zuzena VPN identitate zuzenera lotzen duen erregistro-prozesua behar du, gehi telefono galdu baterako ordezkatze-bide egiaztatua. Erabiltzaileei beren izeneko fitxategi bat igotzen uzteak erregistroa kontua bereganatzeko aukera bihurtzen du, eta igoera zifratzeak ez du hori aldatzen.

PAMen oinarritutako diseinuak ez du VPN erabiltzaile bakoitzeko Unix kontu bereizi bat sortu behar. Moduluaren dokumentazioak bide sekretu alternatiboak eta fitxategietarako sarbiderako kontu dedikatu bat onartzen ditu, hau da, fitxategi-sistemaren identitatea, ez egiaztatzen ari den saio-hasierako identitatea.

Ohiko akatsa erabiltzaile bakarreko adibide batetik kopiatutako erabiltzaile-izen batean amaitzen den bide sekretu finkoa da. Hori identitate bakarreko erakustaldia da, ez erabiltzaileko bilaketa, eta eskaera bakoitzerako erabiltzeak ez dio inori modu independentean erregistratutako autentifikazio-aplikaziorik ematen. Idatzi identitateen mapaketa, babestu hazi-fitxategiak eta eduki pasahitz, ziurtagiri eta kontu egiaztapenak autentifikazio-pila berean.

Irakurri PAM pila benetan zer eskatzen den jakiteko

account required pam_permit.so bezalako lerro batek ez du kontuaren hautagarritasuna ezartzen eta ez du faktorerik gehitzen. PAM kontu-kudeaketako etapa hori baimentzen du, eta hori etapari buruzko adierazpena da, ez zure erabiltzaileei buruzkoa.

Berdin gertatzen da erregistro-aukeran permisiboekin. Erregistratutako sekreturik gabeko erabiltzaileak onartzea hedapen-erabaki kontzientea izan daiteke, baina ez da MFA derrigorrezkoa denaren froga, eta amaiera-data duen aldi baterako salbuespen gisa idatzi beharko litzateke.

Egokitu bezeroaren interakzioa zerbitzariaren diseinuari

auth-user-pass

Direktiba horrek erabiltzaile-izena eta pasahitza sartzea eskatzen du. Ez du PAM konfiguratzen, ez du erregistro-erregistrorik sortzen, eta ez dio zerbitzariari pasahitz-eremuak TOTP balio bat duenik esaten. Zerbitzariaren integrazioak eta bezeroak adostu behar dute hedapenak benetan onartzen duen interakzioa: erronka bat, dokumentatutako kredentzial konbinatuen formatu bat edo produktuaren berariazko fluxu bat.

Ez gehitu koderik pasahitzari bezeroak eremu bakarra erakusten duelako soilik. Hori zerbitzariko pluginek formatu zehatz hori espero duen lekuan bakarrik funtzionatzen du, eta beste leku guztietan nahasgarriki huts egiten du.

Eduki haziak eta QR materiala profil partekatuetatik eta ohiko diagnostiko-erregistroetatik kanpo. Autentifikatutako saio-hasierako kanaletik bidalitako kodea ez da erregistro kontrolatuan emandako haziaren objektu bera, eta biak laguntza-txartel batean nahastea sekretuak ihes egiteko modua da.

Birkonexioak, tokenak eta auzia argitzen duen proba

Planifikatu lehen saio-hasiera arrakastatsuaren ondoren gertatzen dena. Lehenago onartutako kode bat iraungita egon daiteke edo errepikapen gisa baztertua izan daiteke hurrengo autentifikazioan. auth-nocache kredentzialen atxikipena kontrolatzen du eta ez du MFA instalatzen, eta reneg-sec 0 ez da TOTP onarpenaren definizioa, foro-harietan zenbat eta sarriago agertu.

Hedapen batzuek autentifikazio-tokenak igortzen dituzte hasierako egiaztapenaren ondoren, birkonexioek berriro galde ez dezaten. Hori bere balio-epea eta errebokazio-istorioa dituen diseinu-erabakia da, ez duzun lehenetsitako balioa.

Ondoren probatu onarpen-politika jendeak benetan erabiltzen duen bezeroarekin. Erregistratutako erabiltzaile batek pasahitz, ziurtagiri eta uneko kode zuzenekin konektatu beharko luke. Kode okerrak, erregistrorik gabeko erabiltzaileak eta debekatutako kontuak huts egin behar dute bakoitzak, eta arrazoia zerbitzariaren erregistroan ikusgai egon behar da. Bazterketa horiek ikusi arte, eskaera bat duzu, ez politika bat.