PIV-innlogging sviktar på Windows EAP-TLS? Sjekk signeringsvegen

Vis sertifikatet til eit PIV-kort i kvar Windows-dialog, og VPN-innlogginga kan framleis svikte, fordi synlegheit og brukbarheit er ulike eigenskapar. Sertifikatet er eit offentleg objekt; innlogginga krev ein privatnøkkeloperasjon som kortet utfører etter sine eigne tilgangsreglar. Mellom desse to fakta ligg fire trinn som sviktar på fire ulike måtar: profilval, sertifikatval, lokal signering og validering på serversida. Å gå gjennom dei i rekkjefølgje gjer ein generisk handtrykkfeil om til eit konkret spørsmål for den som eig neste del.

Start med profilen og EAP-metoden

Opne eigenskapane til tilkoplinga og les kva EAP-metode profilen faktisk brukar, og les så kva sertifikat metoden er konfigurert til å velje. Mange utrullingar har både ein sertifikatbasert ytre metode og ein indre metode, og eit sertifikat som er konfigurert på tilkoplingsnivå er ikkje automatisk det som vert presentert inne i EAP-TLS. Viss profilen vel sertifikat etter utferdar eller etter eit subjektfilter, vel det filteret blant det Windows kan sjå i det relevante lageret, ikkje blant det kortet tilfeldigvis inneheld. Eit filter som ikkje treff noko, fell tilbake til ei førespurnad eller til ein stille feil avhengig av konfigurasjonen til profilen, og difor er det verd å notere det valde fingeravtrykket før kvar endring.

Fastslå òg om tilkoplinga køyrer som den pålogga brukaren eller som maskina. Det eine faktumet avgjer kva sertifikatlagre som er i omfang, og kva tryggingskontekst som utfører signaturen.

Stadfest kva sertifikat som vart valt

Samanlikn fingeravtrykket Windows valde, med kravet: bruk for klientautentisering, ei kjede som endar i ei klarert rot, ein identitet som policyen til autentiseringsserveren mappar, og ein gyldigheitsperiode som dekkjer det faktiske augneblinken for forsøket. Dette er separate kontrollar, og den siste fangar fleire overraskingar enn folk ventar, særleg med sertifikat som vert gjevne ut rullerande og snøgt lagra profilar som framleis peikar på valet frå i går.

Brukar- og maskinkontekst er den andre halvparten av kontrollen. Eit sertifikat i den personlege lagra til brukaren er usynleg for ein teneste som køyrer som maskina, og eit maskinsetifikat vert ikkje presentert av ein EAP-utveksling i brukarmodus med mindre profilen seier det. Å importere eit sertifikat på nytt i feil lager gjev eit synleg sertifikat og ein usynleg innloggingslegitimasjon. Les lagerstigen i profilen, ikkje den i dialogen som tilfeldigvis opna seg.

Test nøkkeloperasjonen utan å gjete PIN-koden

Når valet er avklart, er spørsmålet om kortet vil utføre signaturen. Windows treng ein støtta kortleverandør eller minidriver for å nå privatnøkkelen, og eininga legg sine eigne PIN- og tilstadeverereglar på operasjonen. Eit kort konfigurert til å krevje berøring for kvar signatur oppfører seg annleis enn eit som bufrer ei stadfesting for ei økt, og begge er legitime konfigurasjonar som endrar når ei førespurnad dukkar opp. Den skilnaden forklarer ei innlogging som lukkast ved fersk innsetting og sviktar etter gjenopptaking, utan at noko sertifikat er gale.

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

Den første kommandoen kartlegg kortet og rapporterer lesar- og leverandørstatus, som er dokumentert i rettleiinga til Microsoft for feilsøking av smartkort. Den andre listar opp kva brukarkonteksten faktisk kan sjå. Ingen av dei beviser ei vellukka autentisering; begge snevrar inn kvar ho stoppa.

Ikkje gjete PIN-koden. Kort handhevar grenser for nye forsøk, og nokre optimistiske forsøk gjer eit løyveproblem om til ein blokkert legitimasjon som krev administrativ attoppretting. Viss ein lokal signatur sviktar, ta vare på leverandørstatusen og tilstanden til kortet i staden for å prøve variantar. Gjenta forsøket éin gong med same profil, same sertifikat og ein kjend god lesarveg, og samanlikn så dei to registreringane; å endre fleire variablar samstundes gjev ei historie og ikkje eit resultat.

Les begge sider av handtrykket

Ein fullført signatur er framleis ikkje tilgang. Autentiseringsserveren må godta kjeda, kontrollere tilbakekalling, mappe identiteten etter sine gjeldande reglar og autorisere førespurnaden; klienten må på si side validere sertifikatet til serveren slik profilen krev. Eit TLS-varsel generert av serveren ser identisk ut i loggen til klienten med eit som er generert lokalt, og difor tyder den emitterande sida meir enn varselteksten.

Samle Windows-hendingane og hendingane på serversida med justerte tidsstempel, og finn så ut kva side som produserte den første feilen. RFC 5216 skildrar trinnet med prov på eigarskap i EAP-TLS, og eit generisk handtrykkvarsel nemner ikkje ei lokal nøkkelårsak på eiga hand. Tidsstempelet er det som gjer to loggar om til ein sekvens.

Hald grensene rette i rapporten

Skriv rapporten som fire trinn med éin dom kvar: kva profil og kontekst som køyrde, kva sertifikat Windows valde, om kortet signerte, og kva serveren avgjorde. Den strukturen gjer neste steg opplagt og hindrar den vanlege reparasjonen med å slå av validering for å kome forbi eit trinn ingen har identifisert.

Eit programsertifikat som mellombels samanlikning er ein legitim administratortest, men det endrar legitimasjons- og tryggingsmodellen, så det høyrer heime i ei godkjend endring og ikkje i ein stille produksjonsomveg. Den same disiplinen gjeld PIN-forsøk og ny utferding av legitimasjon før det sviktande trinnet er kjent. Eit erstatningskort som sviktar identisk, er dyrt prov for at problemet aldri var på kortet.