PIV-login fejler på Windows med EAP-TLS? Kontroller signeringsvejen

Vis et PIV-korts certifikat i hver Windows-dialog, og VPN-login kan stadig fejle, fordi synlighed og anvendelighed er forskellige egenskaber. Certifikatet er et offentligt objekt; login kræver en privatnøgleoperation, som kortet udfører efter sine egne adgangsregler. Mellem de to kendsgerninger ligger fire trin, som fejler på fire forskellige måder: profilvalg, certifikatvalg, lokal signering og validering på serversiden. At gennemgå dem i rækkefølge gør en generisk håndtryksfejl til et konkret spørgsmål for den, der ejer den næste del.

Start med profilen og EAP-metoden

Åbn forbindelsens egenskaber, og læs hvilken EAP-metode profilen faktisk bruger, og læs derefter hvilket certifikat metoden er konfigureret til at vælge. Mange udrulninger har både en certifikatbaseret ydre metode og en indre metode, og et certifikat, der er konfigureret på forbindelsesniveau, er ikke automatisk det, der præsenteres inde i EAP-TLS. Hvis profilen vælger et certifikat efter udsteder eller efter subjektfilter, vælger det filter blandt det, Windows kan se i det relevante lager, ikke blandt det, kortet tilfældigt indeholder. Et filter, der ikke matcher noget, falder tilbage til en prompt eller til en lydløs fejl afhængigt af profilens konfiguration, og derfor er det værd at notere det valgte fingeraftryk før enhver ændring.

Fastslå også, om forbindelsen kører som den loggede bruger eller som maskinen. Den ene kendsgerning afgør, hvilke certifikatlagre der er i spil, og hvilken sikkerhedskontekst der udfører signaturen.

Bekræft, hvilket certifikat der blev valgt

Sammenlign det fingeraftryk, Windows valgte, med kravet: anvendelse til klientgodkendelse, en kæde, der ender i en betroet rod, en identitet, som godkendelsesserverens politik mapper, og en gyldighedsperiode, der dækker det faktiske øjeblik for forsøget. Det er separate kontroller, og den sidste fanger flere overraskelser, end folk forventer, især med certifikater, der udstedes løbende, og cachelagrede profiler, der stadig peger på gårsdagens valg.

Bruger- og maskinekontekst er den anden halvdel af kontrollen. Et certifikat i brugerens personlige lager er usynligt for en tjeneste, der kører som maskinen, og et maskincertifikat præsenteres ikke af en EAP-udveksling i brugertilstand, medmindre profilen siger det. At genimportere et certifikat i det forkerte lager giver et synligt certifikat og en usynlig loginlegitimation. Læs lagerstien i profilen, ikke den i den dialog, der tilfældigvis åbnede.

Test nøgleoperationen uden at gætte PIN-koden

Når valget er afklaret, er spørgsmålet, om kortet vil udføre signaturen. Windows har brug for en understøttet kortudbyder eller minidriver for at nå den private nøgle, og enheden anvender sine egne PIN- og tilstedeværelsesregler på operationen. Et kort, der er konfigureret til at kræve en berøring for hver signatur, opfører sig anderledes end et, der cacher en verifikation for en session, og begge er legitime konfigurationer, der ændrer, hvornår en prompt vises. Den forskel forklarer et login, der lykkes ved en frisk isætning og fejler efter en genoptagelse, uden at noget certifikat er forkert.

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

Den første kommando laver en fortegnelse over kortet og rapporterer læser- og udbyderstatus, hvilket er dokumenteret i Microsofts vejledning til fejlfinding af smartkort. Den anden viser, hvad brugerkonteksten faktisk kan se. Ingen af dem beviser en vellykket godkendelse; begge indsnævrer, hvor det stoppede.

Gæt ikke PIN-koden. Kort håndhæver grænser for gentagne forsøg, og et par optimistiske forsøg gør et tilladelsesproblem til en blokeret legitimation, der kræver administrativ genopretning. Hvis en lokal signatur fejler, skal du registrere udbyderstatus og kortets tilstand i stedet for at prøve varianter. Gentag forsøget én gang med samme profil, samme certifikat og en kendt god læsersti, og sammenlign derefter de to registreringer; at ændre flere variabler på én gang giver en historie i stedet for et resultat.

Læs begge sider af håndtrykket

En gennemført signatur er stadig ikke adgang. Godkendelsesserveren skal acceptere kæden, kontrollere tilbagekaldelse, mappe identiteten efter sine aktuelle regler og autorisere anmodningen; klienten skal til gengæld validere serverens certifikat, som profilen kræver. En TLS-advarsel, der genereres af serveren, ser i klientens log ud som en, der genereres lokalt, og derfor betyder den side, der udsender den, mere end advarselsteksten.

Indsaml Windows-hændelserne og hændelserne på serversiden med justerede tidsstempler, og identificer derefter, hvilken side der producerede den første fejl. RFC 5216 beskriver trinnet med bevis for besiddelse i EAP-TLS, og en generisk håndtryksadvarsel angiver ikke i sig selv en lokal nøgleårsag. Tidsstempelssammenligningen er det, der gør to logfiler til en sekvens.

Hold grænserne klare i rapporten

Skriv rapporten som fire trin med én dom hver: hvilken profil og kontekst der kørte, hvilket certifikat Windows valgte, om kortet signerede, og hvad serveren besluttede. Den struktur gør næste skridt indlysende og forhindrer den almindelige reparation at deaktivere validering for at komme forbi et trin, som ingen har identificeret.

Et softwarecertifikat som midlertidig sammenligning er en legitim administratortest, men det ændrer legitimationens og sikkerhedens model, så det hører i en godkendt ændring frem for i en stille produktionsomvej. Den samme disciplin gælder for PIN-forsøg og for at genudstede legitimationer, før det fejlende trin er kendt. Et erstatningskort, der fejler identisk, er et dyrt bevis på, at problemet aldrig var på kortet.