PIV-innlogging feiler på Windows EAP-TLS? Sjekk signeringsveien

Vis et PIV-korts sertifikat i alle Windows-dialoger, og VPN-innloggingen kan fortsatt feile, fordi synlighet og brukbarhet er ulike egenskaper. Sertifikatet er et offentlig objekt; innloggingen krever en privatnøkkeloperasjon som kortet utfører etter sine egne tilgangsregler. Mellom disse to fakta ligger fire trinn som feiler på fire ulike måter: profilvalg, sertifikatvalg, lokal signering og validering på serversiden. Å gå gjennom dem i rekkefølge gjør en generisk håndtrykkfeil om til et konkret spørsmål for den som eier neste del.

Start med profilen og EAP-metoden

Åpne egenskapene til tilkoblingen og les hvilken EAP-metode profilen faktisk bruker, og les deretter hvilket sertifikat metoden er konfigurert til å velge. Mange utrullinger har både en sertifikatbasert ytre metode og en indre metode, og et sertifikat som er konfigurert på tilkoblingsnivå er ikke automatisk det som presenteres inne i EAP-TLS. Hvis profilen velger sertifikat etter utsteder eller etter et subjektfilter, velger det filteret blant det Windows kan se i det relevante 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 profilens konfigurasjon, og derfor er det verdt å notere det valgte fingeravtrykket før noen endring.

Fastslå også om tilkoblingen kjører som den påloggede brukeren eller som maskinen. Det ene faktumet avgjør hvilke sertifikatlagre som er i omfang, og hvilken sikkerhetskontekst som utfører signaturen.

Bekreft hvilket sertifikat som ble valgt

Sammenlign fingeravtrykket Windows valgte, med kravet: bruk for klientautentisering, en kjede som ender i en klarert rot, en identitet som autentiseringsserverens policy mapper, og en gyldighetsperiode som dekker det faktiske øyeblikket for forsøket. Dette er separate 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 brukerens personlige lager er usynlig for en tjeneste som kjører som maskinen, og et maskinsertifikat 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 innloggingslegitimasjon. Les lagerstien i profilen, ikke den i dialogen som tilfeldigvis åpnet seg.

Test nøkkeloperasjonen uten å gjette PIN-koden

Når valget 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 konfigurert til å kreve berøring for hver signatur oppfører seg annerledes enn et som bufrer en verifisering for en økt, og begge er legitime konfigurasjoner som endrer når en forespørsel dukker opp. Den forskjellen forklarer en innlogging 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 Microsofts veiledning 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. Hvis en lokal signatur feiler, ta vare på leverandørstatusen og korttilstanden i stedet for å prøve varianter. Gjenta forsøket én gang med samme profil, samme sertifikat og en kjent god leserstil, 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. Autentiseringsserveren må godta kjeden, kontrollere tilbakekalling, mappe identiteten etter sine gjeldende regler og autorisere forespørselen; klienten må på sin side validere serverens sertifikat slik profilen krever. Et TLS-varsel generert av serveren ser identisk ut i klientens logg med et som er generert lokalt, og derfor betyr den emitterende siden mer enn varselteksten.

Samle Windows-hendelsene og hendelsene på serversiden 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. Tidsstempelsammenligningen er det som gjør to logger om til en sekvens.

Hold grensene rette i rapporten

Skriv rapporten som fire trinn med én dom hver: hvilken profil og kontekst som kjørte, hvilket sertifikat Windows valgte, om kortet signerte, og hva serveren bestemte. Den strukturen gjør neste steg åpenbart og hindrer den vanlige reparasjonen med å slå av validering for å komme forbi et trinn 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 det feilende trinnet er kjent. Et erstatningskort som feiler identisk, er dyrt bevis for at problemet aldri var på kortet.