Prijava s PIV ne uspe v Windows EAP-TLS? Preverite pot podpisovanja

Pokažite potrdilo kartice PIV v vsakem pogovornem oknu Windows in prijava v VPN lahko še vedno ne uspe, ker sta vidnost in uporabnost različni lastnosti. Potrdilo je javni objekt; prijava zahteva operacijo z zasebnim ključem, ki jo kartica izvede po svojih pravilih dostopa. Med tema dvema dejstvoma so štiri stopnje, ki odpovedo na štiri različne načine: izbira profila, izbira potrdila, lokalno podpisovanje in preverjanje na strani strežnika. Če jih prehodite po vrsti, se splošna napaka rokovanja spremeni v konkretno vprašanje za tistega, ki skrbi za naslednji del.

Začnite s profilom in metodo EAP

Odprite lastnosti povezave in preberite, katero metodo EAP profil dejansko uporablja, nato preberite, katero potrdilo je metoda nastavljena izbrati. Številne namestitve imajo tako zunanjo metodo na podlagi potrdila kot notranjo metodo, potrdilo, nastavljeno na ravni povezave, pa ni samodejno tisto, ki se predstavi znotraj EAP-TLS. Če profil izbere potrdilo po izdajatelju ali po filtru subjekta, ta filter izbira med tem, kar Windows vidi v ustrezni shrambi, ne med tem, kar ima kartica po naključju. Filter, ki se ne ujema z ničimer, preide na poziv ali na tiho odpoved, odvisno od konfiguracije profila, zato je izbrani odtis vredno zabeležiti pred vsako spremembo.

Ugotovite tudi, ali povezava teče kot prijavljeni uporabnik ali kot računalnik. To eno dejstvo določi, katere shrambe potrdil so v obsegu in kateri varnostni kontekst izvede podpis.

Potrdite, katero potrdilo je bilo izbrano

Primerjajte odtis, ki ga je izbral Windows, z zahtevo: uporaba za preverjanje pristnosti odjemalca, veriga, ki se konča v zaupanja vrednem korenu, identiteta, ki jo preslika pravilnik strežnika za preverjanje pristnosti, in obdobje veljavnosti, ki pokriva dejanski trenutek poskusa. To so ločena preverjanja in zadnje ujame več presenečenj, kot jih ljudje pričakujejo, zlasti pri potrdilih, izdanih v tekočem obdobju, in predpomnjenih profilih, ki še vedno kažejo na včerajšnjo izbiro.

Kontekst uporabnika in računalnika je druga polovica preverjanja. Potrdilo v uporabnikovi osebni shrambi je nevidno za storitev, ki teče kot računalnik, potrdilo računalnika pa se ne predstavi z izmenjavo EAP v uporabniškem načinu, razen če profil tako navaja. Ponovni uvoz potrdila v napačno shrambo ustvari vidno potrdilo in nevidno prijavno poverilnico. Preberite pot shrambe v profilu, ne tiste v pogovornem oknu, ki se je odprlo po naključju.

Preizkusite operacijo ključa brez ugibanja PIN

Ko je izbira določena, je vprašanje, ali bo kartica izvedla podpis. Windows potrebuje podprtega ponudnika kartice ali minidriver, da doseže zasebni ključ, naprava pa za operacijo uporabi svoja pravila PIN in prisotnosti. Kartica, nastavljena tako, da zahteva dotik za vsak podpis, se obnaša drugače od tiste, ki preverjanje predpomni za sejo, in obe sta zakoniti konfiguraciji, ki spremenita, kdaj se pojavi poziv. Ta razlika pojasni prijavo, ki uspe ob svežem vstavljanju in odpove po obnovitvi iz mirovanja, ne da bi bilo katero potrdilo napačno.

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

Prvi ukaz popiše kartico in poroča o stanju bralnika in ponudnika, kar je dokumentirano v Microsoftovih smernicah za odpravljanje napak pametnih kartic. Drugi našteje, kaj uporabniški kontekst dejansko vidi. Noben od njiju ne dokaže uspešnega preverjanja pristnosti; oba zožita, kje se je ustavilo.

Ne ugibajte PIN. Kartice uveljavljajo omejitve ponovnih poskusov in nekaj optimističnih poskusov spremeni težavo z dovoljenji v zaklenjeno poverilnico, ki zahteva skrbniško obnovitev. Če lokalni podpis odpove, zabeležite stanje ponudnika in stanje kartice, namesto da preizkušate različice. Poskus ponovite enkrat z istim profilom, istim potrdilom in znano dobro potjo bralnika, nato primerjajte oba zapisa; spreminjanje več spremenljivk hkrati ustvari zgodbo, ne rezultata.

Preberite obe strani rokovanja

Dokončan podpis še ni sprejem. Strežnik za preverjanje pristnosti mora sprejeti verigo, preveriti preklic, preslikati identiteto po svojih trenutnih pravilih in odobriti zahtevo; odjemalec mora nato potrditi strežnikovo potrdilo, kot zahteva profil. Opozorilo TLS, ki ga ustvari strežnik, je v odjemalčevem dnevniku videti enako kot tisto, ki je bilo ustvarjeno lokalno, zato je stran, ki ga izda, pomembnejša od besedila opozorila.

Zberite dogodke Windows in dogodke na strani strežnika z poravnanimi časovnimi žigi, nato ugotovite, katera stran je povzročila prvo odpoved. RFC 5216 opisuje korak dokazovanja lastništva v EAP-TLS in splošno opozorilo rokovanja samo po sebi ne navaja lokalnega vzroka ključa. Primerjava časovnih žigov je tisto, kar dva dnevnika spremeni v zaporedje.

Držite meje v poročilu naravnost

Poročilo napišite kot štiri stopnje z eno sodbo za vsako: kateri profil in kontekst sta tekla, katero potrdilo je izbral Windows, ali je kartica podpisala in kaj je odločil strežnik. Ta zgradba naredi naslednji korak očiten in prepreči pogosto popravilo z izklopom preverjanja, da bi prišli mimo stopnje, ki je nihče ni prepoznal.

Programsko potrdilo kot začasna primerjava je zakonit skrbniški preizkus, vendar spremeni model poverilnic in zagotovil, zato sodi v odobreno spremembo in ne v tiho produkcijsko obvoznico. Enaka disciplina velja za poskuse PIN in za ponovno izdajo poverilnic, preden je znana stopnja, ki odpove. Nadomestna kartica, ki odpove enako, je drago dokazilo, da težava nikoli ni bila na kartici.