Miksi .ovpn-tiedoston muokkaaminen ei voi kytkeä MFA:ta päälle palvelimella

Lisäät auth-user-pass profiiliin, yhdistät uudelleen, ja asiakas pyytää käyttäjänimeä ja salasanaa. Näyttää siltä, että MFA on päällä. Sitten kirjoitat koodin väärästä tilistä tai koodin, joka vanheni kymmenen minuuttia sitten, ja tunneli nousee silti. Se on oire: asiakas muuttui, palvelin ei. Kertakäyttösalasana on tekijä vain silloin, kun palvelimella oleva vahvistaja päättää, onko se kelvollinen sitä vaativalle identiteetille.

Kehote todistaa vain, että asiakas kysyi, ei muuta

.ovpn-tiedosto on asiakaspuolen asiakirja. Se voi käskeä asiakasta pyytämään tunnukset, välimuistiin ne tai lopettaa välimuistiin tallentamisen. Se ei voi rekisteröidä käyttäjää, asentaa PAM-moduulia tai saada palvelinta vaatimaan toista tekijää, jota se ei tällä hetkellä tarkista.

Myöskään todennussovelluksen asentaminen puhelimeen ei luo tuota suhdetta. Google Authenticator PAM -projekti on OTP-varmennuskomponentti, joka voi olla OpenVPN:n takana; se ei ole tapa liittää Google-tilin kirjautumista tuotuun profiiliin.

Rekisteröinti on se osa, jota profiili ei pysty tekemään

TOTP tarvitsee rekisteröintimateriaalin, joka jaetaan todennussovelluksen ja sen vahvistajan kesken. Puhelimen kuusi numeroa ovat tulos; niiden takana oleva siemen on salaisuus, ja se kuuluu yhdelle identiteetille.

Siksi operaattori tarvitsee rekisteröintiprosessin, joka sitoo oikean siemenen oikeaan VPN-identiteettiin, sekä vahvistetun korvauspolun kadonneelle puhelimelle. Jos käyttäjät saavat ladata tiedoston omalla nimellään, rekisteröinnistä tulee tilin kaappauksen mahdollisuus, eikä latauksen salaaminen muuta sitä.

PAM-pohjaisen suunnittelun ei tarvitse luoda erillistä Unix-tiliä jokaiselle VPN-käyttäjälle. Moduulin dokumentaatio tukee vaihtoehtoisia salaisuuden polkuja ja erillistä tiliä tiedostojen käyttöön, mikä on tiedostojärjestelmän identiteetti eikä varmennettava kirjautumisidentiteetti.

Yleinen virhe on kiinteä salaisuuden polku, joka päättyy yhteen käyttäjänimeen ja on kopioitu yhden käyttäjän esimerkistä. Se on yhden identiteetin esittely, ei käyttäjäkohtainen haku, ja sen käyttäminen jokaiseen pyyntöön ei anna kenellekään itsenäisesti rekisteröityä todennussovellusta. Kirjoita identiteettikartoitus muistiin, suojaa siementiedostot ja pidä salasanan, varmenteen ja tilin tarkistukset samassa todennuspinossa.

Lue PAM-pino ja katso, mitä todella vaaditaan

Rivi kuten account required pam_permit.so ei toteuta tilin kelpoisuutta eikä lisää tekijää. Se sallii tuon PAM-tilienhallintavaiheen, mikä on lausunto vaiheesta eikä käyttäjistäsi.

Sama koskee sallivia rekisteröintivalintoja. Käyttäjien hyväksyminen ilman rekisteröityä salaisuutta voi olla tietoinen käyttöönoton valinta, mutta se ei todista, että MFA on pakollinen, ja se olisi kirjattava väliaikaiseksi poikkeukseksi päättymispäivineen.

Sovita asiakkaan vuorovaikutus palvelimen suunnitteluun

auth-user-pass

Tämä direktiivi pyytää käyttäjänimen ja salasanan syöttämistä. Se ei määritä PAM:ia, luo rekisteröintitietuetta eikä kerro palvelimelle, että salasanakentässä on TOTP-arvo. Palvelinintegroinnin ja asiakkaan on sovittava vuorovaikutuksesta, jota käyttöönotto todella tukee: haaste, dokumentoitu yhdistetty tunnusmuoto tai tuotekohtainen kulku.

Älä liitä koodia salasanaan vain siksi, että asiakas näyttää yhden kentän. Se toimii vain siellä, missä palvelimen liitännäinen odottaa täsmälleen sitä muotoa, ja epäonnistuu hämmentävästi kaikkialla muualla.

Pidä siemenet ja QR-materiaali poissa jaetuista profiileista ja rutiininomaisista diagnostiikkalokeista. Todennetun kirjautumiskanavan kautta lähetetty koodi ei ole sama objekti kuin valvotun rekisteröinnin aikana annettu siemen, ja niiden sekoittaminen tukipyynnössä on se tapa, jolla salaisuudet karkaavat.

Uudelleenyhdistämiset, tunnukset ja testi, joka ratkaisee asian

Suunnittele, mitä tapahtuu ensimmäisen onnistuneen kirjautumisen jälkeen. Aiemmin hyväksytty koodi voi olla vanhentunut tai hylätty toistona seuraavassa todennuksessa. auth-nocache säätelee tunnusten säilytystä eikä asenna MFA:ta, ja reneg-sec 0 ei ole TOTP-tuen määritelmä, kuinka usein se sitten esiintyykin foorumiketjuissa.

Jotkin käyttöönotot myöntävät todennustunnuksia alkuperäisen tarkistuksen jälkeen, jotta uudelleenyhdistämiset eivät kysy uudelleen. Se on suunnittelupäätös, jolla on oma voimassaoloikkunansa ja peruutushistoriansa, ei oletus, jonka perit.

Testaa sitten hyväksyntäkäytäntö asiakkaalla, jota ihmiset todella käyttävät. Rekisteröityneen käyttäjän, jolla on oikea salasana, varmenne ja ajantasainen koodi, pitäisi yhdistää. Väärän koodin, käyttäjän ilman rekisteröintiä ja kielletyn tilin pitäisi kunkin epäonnistua, ja syyn pitäisi näkyä palvelimen lokissa. Ennen kuin olet nähnyt ne hylkäykset, sinulla on kehote, ei käytäntö.