PIV-pålogging feiler i Windows EAP-TLS? Kontroller signeringsstien

Vis sertifikatet til et PIV-kort i hver Windows-dialog, og VPN-påloggingen kan likevel feile, fordi synlighet og anvendelighet er forskjellige egenskaper. Sertifikatet er et offentlig objekt; påloggingen krever en privatnøkkeloperasjon som kortet utfører etter sine egne tilgangsregler. Mellom disse to fakta ligger fire faser som feiler på fire forskjellige måter: profilutvalg, sertifikatutvalg, lokal signering og validering på tjenersiden. Å gjennomgå dem i rekkefølge gjør en generisk håndtrykkfeil om til et konkret spørsmål for den som eier neste del.

Begynn med profilen og EAP-metoden

Åpne egenskapene for tilkoblingen og les hvilken EAP-metode profilen faktisk bruker, og les deretter hvilket sertifikat metoden er satt opp til å velge. Mange utplasseringer har både en sertifikatbasert ytre metode og en indre metode, og et sertifikat som er satt opp på tilkoblingsnivå er ikke automatisk det samme som presenteres inne i EAP-TLS. Dersom profilen velger sertifikat etter utsteder eller etter et subjektfilter, velger dette filteret blant det Windows kan se i det aktuelle lageret, ikke blant det kortet tilfeldigvis inneholder. Et filter som ikke treffer noe, faller tilbake til en forespørsel eller til en stille feil avhengig av oppsettet av profilen, og derfor er det verdt å notere det valgte fingeravtrykket før enhver endring.

Avgjør også om tilkoblingen kjører som den innloggede brukeren eller som maskinen. Det ene faktumet bestemmer hvilke sertifikatlagre som er innenfor rekkevidde, og hvilken sikkerhetskontekst som utfører signaturen.

Bekreft hvilket sertifikat som ble valgt

Sammenlign fingeravtrykket Windows valgte, mot kravet: bruk til klientautentisering, en kjede som avsluttes i en klarert rot, en identitet som policyen til autentiseringstjeneren mapper, og en gyldighetsperiode som dekker det faktiske øyeblikket for forsøket. Dette er atskilte kontroller, og den siste fanger flere overraskelser enn folk forventer, særlig med sertifikater som utstedes rullerende og hurtiglagrede profiler som fortsatt peker på gårsdagens valg.

Bruker- og maskinkontekst er den andre halvdelen av kontrollen. Et sertifikat i den personlige lagra til brukeren er usynlig for en tjeneste som kjører som maskinen, og et maskinsetifikat presenteres ikke av en EAP-utveksling i brukermodus med mindre profilen sier det. Å importere et sertifikat på nytt i feil lager gir et synlig sertifikat og en usynlig påloggingslegitimasjon. Les lagerstien i profilen, ikke den i dialogen som tilfeldigvis åpnet seg.

Test nøkkeloperasjonen uten å gjette PIN-koden

Når utvalget er avklart, er spørsmålet om kortet vil utføre signaturen. Windows trenger en støttet kortleverandør eller minidriver for å nå privatnøkkelen, og enheten anvender sine egne PIN- og tilstedeværelsesregler på operasjonen. Et kort satt opp til å kreve berøring for hver signatur oppfører seg annerledes enn et som bufrer en bekreftelse for en økt, og begge er legitime oppsett som endrer når en forespørsel dukker opp. Den forskjellen forklarer en pålogging som lykkes ved fersk innsetting og feiler etter gjenopptakelse, uten at noe sertifikat er galt.

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

Den første kommandoen kartlegger kortet og rapporterer leser- og leverandørstatus, som er dokumentert i veiledningen fra Microsoft for feilsøking av smartkort. Den andre lister opp hva brukerkonteksten faktisk kan se. Ingen av dem beviser en vellykket autentisering; begge snevrer inn hvor den stoppet.

Ikke gjett PIN-koden. Kort håndhever grenser for nye forsøk, og noen optimistiske forsøk gjør et tillatelsesproblem om til en blokkert legitimasjon som krever administrativ gjenoppretting. Dersom en lokal signatur feiler, ta vare på leverandørstatusen og tilstanden til kortet i stedet for å prøve varianter. Gjenta forsøket én gang med samme profil, samme sertifikat og en kjent god lesersti, og sammenlign deretter de to registreringene; å endre flere variabler samtidig gir en historie og ikke et resultat.

Les begge sider av håndtrykket

En fullført signatur er fortsatt ikke adgang. Autentiseringstjeneren må godta kjeden, kontrollere tilbakekalling, mappe identiteten etter sine gjeldende regler og autorisere forespørselen; klienten må på sin side validere sertifikatet til tjeneren slik profilen krever. Et TLS-varsel generert av tjeneren ser identisk ut i loggen til klienten med et som er generert lokalt, og derfor betyr den utstedende siden mer enn varselteksten.

Samle Windows-hendelsene og hendelsene på tjenersiden med justerte tidsstempler, og identifiser deretter hvilken side som produserte den første feilen. RFC 5216 beskriver trinnet med bevis på eierskap i EAP-TLS, og et generisk håndtrykkvarsel navngir ikke en lokal nøkkelårsak på egen hånd. Sammenligningen av tidsstempler er det som gjør to logger om til en sekvens.

Hold grensene rette i rapporten

Skriv rapporten som fire faser med én dom hver: hvilken profil og kontekst som kjørte, hvilket sertifikat Windows valgte, om kortet signerte, og hva tjeneren bestemte. Den strukturen gjør neste steg åpenbart og hindrer den vanlige reparasjonen med å slå av validering for å komme forbi en fase ingen har identifisert.

Et programsertifikat som midlertidig sammenligning er en legitim administratortest, men det endrer legitimasjons- og forsikringsmodellen, så det hører hjemme i en godkjent endring og ikke i en stille produksjonsomvei. Den samme disiplinen gjelder PIN-forsøk og ny utstedelse av legitimasjon før den feilende fasen er kjent. Et erstatningskort som feiler identisk, er dyrt bevis for at problemet aldri var på kortet.