PIV-kirjautuminen epäonnistuu Windowsissa EAP-TLS:llä? Tarkista allekirjoituspolku

Näytä PIV-kortin varmenne jokaisessa Windowsin valintaikkunassa, ja VPN-kirjautuminen voi silti epäonnistua, koska näkyvyys ja käytettävyys ovat eri ominaisuuksia. Varmenne on julkinen objekti; kirjautuminen tarvitsee yksityisavaintoiminnon, jonka kortti suorittaa omien käyttösääntöjensä mukaan. Näiden kahden tosiasian välissä on neljä vaihetta, jotka epäonnistuvat neljällä eri tavalla: profiilin valinta, varmenteen valinta, paikallinen allekirjoitus ja palvelinpuolen validointi. Niiden läpikäyminen järjestyksessä muuttaa yleisen kättelyvirheen täsmälliseksi kysymykseksi sille, joka omistaa seuraavan osan.

Aloita profiilista ja EAP-menetelmästä

Avaa yhteyden ominaisuudet ja lue, mitä EAP-menetelmää profiili todella käyttää, ja lue sitten, minkä varmenteen menetelmä on määritetty valitsemaan. Monissa käyttöönotoissa on sekä varmenneperusteinen ulompi menetelmä että sisempi menetelmä, eikä yhteystasolla määritetty varmenne ole automaattisesti se, joka esitetään EAP-TLS:n sisällä. Jos profiili valitsee varmenteen myöntäjän tai subjektisuodattimen perusteella, suodatin valitsee siitä, mitä Windows näkee asianmukaisessa säilössä, ei siitä, mitä kortissa sattuu olemaan. Suodatin, joka ei vastaa mitään, palaa kyselyyn tai hiljaiseen epäonnistumiseen profiilin kokoonpanosta riippuen, minkä vuoksi valittu sormenjälki kannattaa kirjata ennen mitään muutosta.

Selvitä myös, ajetaanko yhteys kirjautuneena käyttäjänä vai koneena. Tämä yksi tosiasia ratkaisee, mitkä varmennesäilöt ovat piirissä ja mikä tietoturvayhteys allekirjoituksen suorittaa.

Vahvista, mikä varmenne valittiin

Vertaa Windowsin valitsemaa sormenjälkeä vaatimukseen: käyttö asiakkaan todentamiseen, luotettuun juureen päättyvä ketju, identiteetti, jonka todentamispalvelimen käytäntö kartoittaa, ja voimassaoloaika, joka kattaa yrityksen todellisen hetken. Nämä ovat erillisiä tarkistuksia, ja viimeinen nappaa enemmän yllätyksiä kuin ihmiset odottavat, erityisesti jatkuvasti myönnettyjen varmenteiden ja välimuistiin tallennettujen profiilien kohdalla, jotka osoittavat edelleen eiliseen valintaan.

Käyttäjä- ja konekonteksti on tarkistuksen toinen puoli. Käyttäjän henkilökohtaisessa säilössä oleva varmenne on näkymätön koneena toimivalle palvelulle, eikä koneen varmennetta esitä käyttäjätilassa toimiva EAP-vaihto, ellei profiili niin sano. Varmenteen uudelleentuonti väärään säilöön tuottaa näkyvän varmenteen ja näkymättömän kirjautumistunnisteen. Lue säilön polku profiilista, älä siitä valintaikkunasta, joka sattui avautumaan.

Testaa avaintoiminto arvaamatta PIN-koodia

Kun valinta on selvitetty, kysymys on, suorittaako kortti allekirjoituksen. Windows tarvitsee tuetun korttitarjoajan tai miniajurin päästäkseen yksityisavaimeen, ja laite soveltaa omia PIN- ja läsnäolosääntöjään toimintoon. Kortti, joka on määritetty vaatimaan kosketus jokaista allekirjoitusta varten, käyttäytyy eri tavalla kuin kortti, joka tallentaa vahvistuksen istuntoa varten, ja molemmat ovat sallittuja kokoonpanoja, jotka muuttavat sitä, milloin kysely ilmestyy. Tämä ero selittää kirjautumisen, joka onnistuu tuoreella asetuksella ja epäonnistuu jatkamisen jälkeen, ilman että mikään varmenne olisi väärä.

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

Ensimmäinen komento luettelee kortin ja raportoi lukijan ja tarjoajan tilan, mikä on dokumentoitu Microsoftin älykorttien vianmääritysoppaassa. Toinen luettelee, mitä käyttäjäkonteksti todella näkee. Kumpikaan ei todista onnistunutta todentamista; molemmat rajaavat, mihin se pysähtyi.

Älä arvaa PIN-koodia. Kortit valvovat uudelleenyritysrajoja, ja muutama optimistinen yritys muuttaa käyttöoikeusongelman estetyksi tunnisteeksi, joka vaatii järjestelmänvalvojan palautuksen. Jos paikallinen allekirjoitus epäonnistuu, tallenna tarjoajan tila ja kortin tila sen sijaan, että kokeilisit muunnelmia. Toista yritys kerran samalla profiililla, samalla varmenteella ja tunnetusti hyvällä lukijapolulla ja vertaa sitten kahta kirjausta; usean muuttujan muuttaminen kerralla tuottaa tarinan eikä tulosta.

Lue kättelyn molemmat puolet

Valmis allekirjoitus ei ole vielä pääsy. Todentamispalvelimen on hyväksyttävä ketju, tarkistettava mitätöinti, kartoitettava identiteetti nykyisten sääntöjensä mukaan ja valtuutettava pyyntö; asiakkaan on puolestaan validoitava palvelimen varmenne, kuten profiili vaatii. Palvelimen tuottama TLS-hälytys näyttää asiakkaan lokissa samalta kuin paikallisesti tuotettu, minkä vuoksi sen lähettävä puoli on tärkeämpi kuin hälytyksen teksti.

Kerää Windowsin tapahtumat ja palvelinpuolen tapahtumat kohdistetuilla aikaleimoilla ja selvitä sitten, kumpi puoli tuotti ensimmäisen vian. RFC 5216 kuvaa hallussapidon todistamisen vaiheen EAP-TLS:ssä, eikä yleinen kättelyhälytys nimeä itsessään paikallista avaimeen liittyvää syytä. Aikaleimojen vertailu on se, mikä muuttaa kaksi lokia järjestyksesi.

Pidä rajat selvinä raportissa

Kirjoita raportti neljänä vaiheena, kussakin yksi tuomio: mikä profiili ja konteksti ajettiin, minkä varmenteen Windows valitsi, allekirjoittiko kortti ja mitä palvelin päätti. Tämä rakenne tekee seuraavan vaiheen ilmeiseksi ja estää tavallisen korjauksen eli validoinnin poistamisen käytöstä, jotta päästäisiin ohitse vaiheesta, jota kukaan ei tunnistanut.

Ohjelmistovarmenne väliaikaisena vertailuna on hyväksyttävä järjestelmänvalvojan testi, mutta se muuttaa tunnisteen ja vakuuden mallia, joten se kuuluu hyväksyttyyn muutokseen eikä hiljaiseen tuotannon kiertotiehen. Sama kurinalaisuus koskee PIN-yrityksiä ja tunnisteiden uudelleenmyöntämistä ennen kuin epäonnistuva vaihe on tiedossa. Vaihtokortti, joka epäonnistuu samalla tavalla, on kallis todiste siitä, että ongelma ei ollut koskaan kortissa.