PIV-sisselogimine ebaõnnestub Windowsis EAP-TLS-iga? Kontrollige allkirjastamise teed

Näidake PIV-kaardi sertifikaati igas Windowsi dialoogis ja VPN-i sisselogimine võib ikkagi ebaõnnestuda, sest nähtavus ja kasutatavus on erinevad omadused. Sertifikaat on avalik objekt; sisselogimine vajab privaatvõtmega toimingut, mille teeb kaart oma juurdepääsureeglite järgi. Nende kahe fakti vahel on neli etappi, mis ebaõnnestuvad neljal erineval viisil: profiili valik, sertifikaadi valik, kohalik allkirjastamine ja serveripoolne valideerimine. Nende järjestikune läbimine muudab üldise käepigistusvea konkreetseks küsimuseks sellele, kelle käes on järgmine osa.

Alustage profiilist ja EAP-meetodist

Avage ühenduse atribuudid ja lugege, millist EAP-meetodit profiil tegelikult kasutab, seejärel lugege, millise sertifikaadi valimiseks meetod on seadistatud. Paljudes juurutustes on nii sertifikaadipõhine väline meetod kui ka sisemine meetod ning ühenduse tasandil seadistatud sertifikaat ei ole automaatselt see, mida esitatakse EAP-TLS-i sees. Kui profiil valib sertifikaadi väljaandja või subjekti filtri järgi, valib see filter selle hulgast, mida Windows vastavas hoidlas näeb, mitte selle hulgast, mis kaardil juhtub olema. Filter, mis ei vasta millelegi, langeb profiili seadistusest sõltuvalt tagasi viipale või vaiksele ebaõnnestumisele, mistõttu tasub valitud sõrmejälg enne mis tahes muudatust üles märkida.

Tehke kindlaks ka see, kas ühendus töötab sisselogitud kasutajana või masinana. See üks fakt otsustab, millised sertifikaadihoidlad on ulatuses ja milline turbekontekst allkirja teeb.

Kinnitage, milline sertifikaat valiti

Võrrelge sõrmejälge, mille Windows valis, nõudega: kasutamine kliendi autentimiseks, usaldusväärses juures lõppev ahel, identiteet, mille autentimisserveri poliitika vastendab, ja kehtivusaeg, mis katab katse tegeliku hetke. Need on eraldi kontrollid ja viimane püüab rohkem üllatusi, kui inimesed ootavad, eriti jooksvalt välja antud sertifikaatide ja vahemällu salvestatud profiilide puhul, mis osutavad endiselt eilsele valikule.

Kasutaja- ja masinakontekst on kontrolli teine pool. Kasutaja isiklikus hoidlas olev sertifikaat on nähtamatu masinana töötava teenuse jaoks, ja masina sertifikaati ei esita kasutajarežiimis EAP-vahetus, kui profiil ei ütle teisiti. Sertifikaadi valesse hoidlasse uuesti importimine annab nähtava sertifikaadi ja nähtamatu sisselogimistunnuse. Lugege hoidla teed profiilis, mitte selle dialoogi oma, mis juhtumisi avanes.

Testige võtmega toimingut PIN-koodi arvamata

Kui valik on selge, on küsimus selles, kas kaart teeb allkirja. Windows vajab privaatvõtmeni jõudmiseks toetatud kaardipakkujat või minidriverit ning seade rakendab toimingule oma PIN- ja kohalolureegleid. Kaart, mis on seadistatud nõudma puudutust iga allkirja puhul, käitub teisiti kui kaart, mis puhverdab kinnituse sessiooni jaoks, ja mõlemad on õiguspärased seadistused, mis muudavad seda, millal viip ilmub. See erinevus seletab sisselogimist, mis õnnestub värskel sisestamisel ja ebaõnnestub pärast jätkamist, ilma et ükski sertifikaat oleks vale.

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

Esimene käsk loetleb kaardi ja teatab lugeja ning pakkuja oleku, mida on dokumenteeritud Microsofti nutikaardi tõrkeotsingu juhendis. Teine loetleb, mida kasutajakontekst tegelikult näeb. Kumbki ei tõesta edukat autentimist; mõlemad kitsendavad, kuhu see pidama jäi.

Ärge arvake PIN-koodi. Kaardid rakendavad korduskatsete piiranguid ja paar optimistlikku katset muudavad õiguste probleemi blokeeritud sisselogimistunnuseks, mis vajab halduslikku taastamist. Kui kohalik allkiri ebaõnnestub, registreerige pakkuja olek ja kaardi olek, selle asemel et variante proovida. Korrake katset üks kord sama profiili, sama sertifikaadi ja teadaolevalt hea lugejateega ning võrrelge seejärel kahte kirjet; mitme muutuja korraga muutmine annab loo, mitte tulemuse.

Lugege käepigistuse mõlemat poolt

Lõpetatud allkiri ei ole veel lubamine. Autentimisserver peab ahela vastu võtma, tühistamise kontrollima, identiteedi oma kehtivate reeglite järgi vastendama ja taotluse volitama; klient peab omakorda valideerima serveri sertifikaadi nii, nagu profiil nõuab. Serveri loodud TLS-teade näeb kliendi logis välja samasugune nagu kohapeal loodud, mistõttu on seda väljastav pool tähtsam kui teate tekst.

Koguge Windowsi sündmused ja serveripoolsed sündmused joondatud ajatemplitega, seejärel tehke kindlaks, milline pool tekitas esimese tõrke. RFC 5216 kirjeldab valdamise tõestamise sammu EAP-TLS-is ja üldine käepigistusteade ei nimeta iseenesest kohalikku võtmega seotud põhjust. Ajatemplite võrdlemine on see, mis muudab kaks logi järjestuseks.

Hoidke piirid aruandes selged

Kirjutage aruanne nelja etapina, igal üks otsus: milline profiil ja kontekst töötasid, millise sertifikaadi Windows valis, kas kaart allkirjastas ja mida server otsustas. See struktuur teeb järgmise sammu ilmselgeks ja hoiab ära tavapärase paranduse keelata valideerimine, et mööduda etapist, mida keegi ei tuvastanud.

Tarkvarasertifikaat ajutise võrdlusena on õiguspärane administraatori test, kuid see muudab mandaadi ja tagatise mudelit, seega kuulub see kinnitatud muudatusse, mitte vaiksesse tootmise möödaviiki. Sama distsipliin kehtib PIN-katsete ja mandaatide uuesti väljaandmise kohta enne, kui ebaõnnestuv etapp on teada. Asenduskaart, mis ebaõnnestub samamoodi, on kallis tõend selle kohta, et probleem ei olnud kunagi kaardil.