Minne staattisen haasteen koodi kuuluu OpenVPN-kirjautumisessa

Asiakas näyttää toisen kentän salasanakentän jälkeen, kirjoitat koodin laitteistotunnuksesta, ja kirjautuminen epäonnistuu edelleen todennusvirheeseen. Kenttä on olemassa, joten profiili pyysi sitä. Saiko palvelin arvon koskaan ymmärtämässään muodossa on toinen kysymys, ja siihen kannattaa vastata ensin.

Aloita kehotteesta, jonka asiakkaasi todella näyttää

Profiili voi sisältää staattisen haasteen direktiivin, jossa on kehoteteksti ja lippu, joka ohjaa näytetäänkö vastaus kirjoittaessasi. Kehote on se, jonka näet valintaikkunassa; lippu on saman syötteen näyttöasetus. Kumpikaan niistä ei kerro palvelimelle, miten jotain tarkistetaan.

Laske kentät, jotka todella sait. Yksi kenttä käyttäjänimelle ja yksi peitetty kenttä on tavallinen salasanakirjautuminen ilman minkäänlaista haastetta. Toinen kenttä, joka ilmestyy salasanan jälkeen omalla tunnisteellaan, on asiakas, joka toteuttaa haastevuorovaikutuksen.

Jos toinen kenttä ei koskaan ilmesty käyttämääsi asiakkaaseen, asiakas ei ehkä toteuta vuorovaikutusta tai toteuttaa sen vain toisen käyttöliittymän, kuten hallintaliittymän, kautta. Asiakkaan tarkistaminen on halvempaa kuin profiilin uudelleenkirjoittaminen, ja yleensä juuri siellä epäsuhta todella on.

Mitä palvelimen on jo tuettava

Profiili kuvaa, mitä asiakkaan pitäisi kerätä. Se ei ota tarkistusta käyttöön palvelimella, ja palvelin ilman vastaavaa todennusintegrointia saa yksinkertaisesti salasanan, jota se ei tunnista. Siksi jotkin käyttöönotot näyttävät kehotteen ja hylkäävät jokaisen koodin, ja siksi ylläpitäjän vastaus siitä, mikä mekanismi tarkistuksen tekee, on se vastaus, jolla on merkitystä.

Kysy ylläpitäjältä, mikä mekanismi tarkistuksen tekee. Se voi olla liitännäinen, joka puhuu PAMin kanssa, skriptikoukku, joka validoi vastauksen tunnuspalvelua vasten, tai hallintapohjainen integrointi, joka jäsentää pakatun arvon itse. Jokainen niistä odottaa hieman erilaista syötettä.

Tässä odotukset on myös kalibroitava. Toinen kehote on syöttömekanismi, ei todiste siitä, että toinen tekijä pakotetaan, koska pakottaminen tapahtuu palvelimen puolella ja näkyy vasta, kun testaat väärää koodia.

Koodattu kenttä, jonka hallintaliittymä lähettää

Kun käyttöliittymä ohjaa yhteyttä hallintaliittymän kautta, salasana ja haasteen vastaus pakataan yhteen arvoon ennen lähettämistä. Hallintaliittymän viite dokumentoi muodon: etuliite ja sitten salasana ja vastaus erillisinä Base64-komponentteina.

Base64 on koodaus, ei suoja. Se ei piilota mitään keneltäkään, joka voi lukea kentän, eikä tee kertakäyttöisestä koodista mitään uudelleenkäytettävää. Pakattu arvo ansaitsee saman kohtelun kuin salasana: pois jaetuista profiileista, pois komentoriveiltä ja pois diagnostiikkalokeista.

Tämä koodaus on myös yleisin hämmennksen lähde, koska nyt on kolme muotoa, jotka näyttävät samanlaisilta eivätkä ole vaihdettavissa. Tavallinen tunnistetiedosto sisältää salasanan. Salasanan ja koodin kirjaimellinen yhdistäminen sisältää eri merkkijonon. Hallinta-asiakkaan pakattu vastaus sisältää kolmannen. Vahvista, mitä tarkistuspolkusi odottaa, ennen kuin muutat kenttää vain siksi, että virhe katosi.

Staattinen vastaan dynaaminen: eri ajoitus

Staattinen haaste tiedetään ennen ensimmäisen tunnistetiedon lähettämistä, joten asiakas voi pyytää sitä etukäteen. Dynaaminen haaste saapuu myöhemmin, todennusprosessin lähettämänä sen jälkeen, kun vaihto on jo alkanut, ja se vaatii asiakkaan, joka pystyy käsittelemään pyynnön kesken keskustelua.

Toisen tuki ei anna toista. Staattisen kehotteen määrittävä profiilidirektiivi ei toteuta palvelimen käynnistämää haastetta, ja dynaamisia pyyntöjä käsittelevä käyttöliittymä ei välttämättä silti näytä staattista. Sen lukeminen, kumpi osapuoli pyynnön käynnisti, on nopein tapa erottaa ne.

Valvomaton käyttö on kohta, jossa tästä tulee suunnittelukysymys eikä käyttöliittymäkysymys. Tallennettu koodi ei ole kestävä käynnistysajan tunnistetieto, ja tuntien päästä tapahtuva uudelleenyhdistäminen tarvitsee tuoreen syötteen, ellei käyttöönotto tue tunnusjärjestelyä, jonka ylläpitäjä on tietoisesti ottanut käyttöön.

Testaa onnistumista ja epäonnistumista, ei vain valintaikkunaa

Suorita testin molemmat puolikkaat. Oikeat tunnistetiedot kelvollisella vastauksella pitäisi onnistua; oikeat tunnistetiedot tarkoituksella väärällä vastauksella pitäisi hylätä. Jos molemmat onnistuvat, asiakas kerää syötettä, jota mikään ei tarkista, ja valintaikkuna on luultu ohjaimeksi. Se yksi testi nappaa enemmän käyttöönottoja kuin mikään määrä profiilin tarkastelua.

Toista sitten yhteys uudelleenyhdistämisen jälkeen, tilillä joka ei ole rekisteröitynyt, ja sen asiakkaan kautta, jota käyttäjäsi todella käyttävät. Kehotteen ilmestyminen on asiakkaan käyttäytymistä; väärän koodin hylkääminen on palvelin, joka pakottaa jotain.