PIV-inloggning misslyckas i Windows EAP-TLS? Kontrollera signeringsvägen

Visa ett PIV-korts certifikat i varje Windows-dialog och VPN-inloggningen kan ändå misslyckas, eftersom synlighet och användbarhet är olika egenskaper. Certifikatet är ett offentligt objekt; inloggningen kräver en privatnyckeloperation som kortet utför enligt sina egna åtkomstregler. Mellan dessa två fakta ligger fyra steg som misslyckas på fyra olika sätt: profilval, certifikatval, lokal signering och validering på serversidan. Att gå igenom dem i ordning förvandlar ett allmänt handskakningsfel till en konkret fråga för den som äger nästa del.

Börja med profilen och EAP-metoden

Öppna anslutningens egenskaper och läs vilken EAP-metod profilen faktiskt använder, läs sedan vilket certifikat metoden är konfigurerad att välja. Många utrullningar har både en certifikatbaserad yttre metod och en inre metod, och ett certifikat som konfigurerats på anslutningsnivå är inte automatiskt det som presenteras inne i EAP-TLS. Om profilen väljer certifikat efter utfärdare eller efter ett subjektfilter, väljer det filtret bland det Windows kan se i det relevanta arkivet, inte bland det kortet råkar innehålla. Ett filter som inte matchar något faller tillbaka på en fråga eller på ett tyst fel beroende på profilens konfiguration, och därför är det värt att registrera det valda fingeravtrycket före varje ändring.

Fastställ också om anslutningen körs som den inloggade användaren eller som datorn. Det enda faktumet avgör vilka certifikatarkiv som omfattas och vilken säkerhetskontext som utför signaturen.

Bekräfta vilket certifikat som valdes

Jämför fingeravtrycket Windows valde med kravet: användning för klientautentisering, en kedja som slutar i en betrodd rot, en identitet som autentiseringsserverns princip mappar och en giltighetsperiod som täcker det faktiska ögonblicket för försöket. Det är separata kontroller och den sista fångar fler överraskningar än folk förväntar sig, särskilt med certifikat som utfärdas rullande och cachade profiler som fortfarande pekar på gårdagens val.

Användar- och datorkontext är den andra halvan av kontrollen. Ett certifikat i användarens personliga arkiv är osynligt för en tjänst som körs som datorn, och ett datorcertifikat presenteras inte av ett EAP-utbyte i användarläge om inte profilen säger det. Att importera ett certifikat igen i fel arkiv ger ett synligt certifikat och en osynlig inloggningsuppgift. Läs arkivsökvägen i profilen, inte den i dialogrutan som råkade öppnas.

Testa nyckeloperationen utan att gissa PIN-koden

När urvalet är klart är frågan om kortet kommer att utföra signaturen. Windows behöver en leverantör av kort eller en minidriver som stöds för att nå den privata nyckeln, och enheten tillämpar sina egna PIN- och närvaroregler på operationen. Ett kort som konfigurerats att kräva beröring för varje signatur beter sig annorlunda än ett som cachar en verifiering för en session, och båda är legitima konfigurationer som ändrar när en fråga dyker upp. Den skillnaden förklarar en inloggning som lyckas vid en färsk isättning och misslyckas efter en återupptagning, utan att något certifikat är fel.

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

Det första kommandot inventerar kortet och rapporterar läsarens och leverantörens status, vilket dokumenteras i Microsofts vägledning för felsökning av smartkort. Det andra listar vad användarkontexten faktiskt kan se. Ingen av dem bevisar en lyckad autentisering; båda snävar in var det stannade.

Gissa inte PIN-koden. Kort tillämpar gränser för nya försök, och några optimistiska försök förvandlar ett behörighetsproblem till en blockerad inloggningsuppgift som kräver administrativ återställning. Om en lokal signatur misslyckas, spara leverantörens status och kortets tillstånd i stället för att prova varianter. Upprepa försöket en gång med samma profil, samma certifikat och en känd bra läsarväg, jämför sedan de två registreringarna; att ändra flera variabler samtidigt ger en historia och inte ett resultat.

Läs båda sidor av handskakningen

En slutförd signatur är fortfarande inte tillträde. Autentiseringsservern måste acceptera kedjan, kontrollera återkallelse, mappa identiteten enligt sina nuvarande regler och auktorisera begäran; klienten måste i sin tur validera serverns certifikat som profilen kräver. En TLS-varning som servern genererar ser identisk ut i klientens logg med en som genererats lokalt, och därför betyder den emitterande sidan mer än varningstexten.

Samla Windows-händelserna och händelserna på serversidan med justerade tidsstämplar och identifiera sedan vilken sida som producerade det första felet. RFC 5216 beskriver steget med bevis på innehav i EAP-TLS, och en allmän handskakningsvarning namnger inte en lokal nyckelorsak på egen hand. Tidsstämpeljämförelsen är det som gör två loggar till en sekvens.

Håll gränserna raka i rapporten

Skriv rapporten som fyra steg med en dom var: vilken profil och kontext som körde, vilket certifikat Windows valde, om kortet signerade och vad servern beslutade. Den strukturen gör nästa steg uppenbart och förhindrar den vanliga reparationen att stänga av validering för att komma förbi ett steg som ingen identifierat.

Ett programvarucertifikat som tillfällig jämförelse är ett legitimt administratörstest, men det ändrar inloggningsuppgifternas och försäkringens modell, så det hör hemma i en godkänd ändring och inte i en tyst produktionskringgång. Samma disciplin gäller PIN-försök och ny utfärdning av inloggningsuppgifter innan det felande steget är känt. Ett ersättningskort som misslyckas identiskt är dyrt bevis för att problemet aldrig satt på kortet.