PIV prijava ne uspijeva na Windowsu s EAP-TLS? Provjerite putanju potpisivanja

Pokažite certifikat PIV kartice u svakom dijalogu sustava Windows i VPN prijava ipak može propasti, jer su vidljivost i upotrebljivost različita svojstva. Certifikat je javni objekt; prijava zahtijeva operaciju privatnim ključem koju kartica izvodi po vlastitim pravilima pristupa. Između tih dviju činjenica stoje četiri faze koje propadaju na četiri različita načina: odabir profila, odabir certifikata, lokalno potpisivanje i provjera na strani poslužitelja. Prolazak kroz njih redom pretvara općenitu pogrešku rukovanja u konkretno pitanje za onoga koji drži sljedeći dio.

Počnite s profilom i EAP metodom

Otvorite svojstva veze i pročitajte koju EAP metodu profil zapravo koristi, zatim pročitajte koji je certifikat metoda konfigurirana odabrati. Mnoge implementacije imaju i vanjsku metodu temeljenu na certifikatu i unutarnju metodu, a certifikat konfiguriran na razini veze nije automatski onaj koji se predstavlja unutar EAP-TLS. Ako profil bira certifikat po izdavatelju ili po filtru subjekta, taj filtar bira iz onoga što Windows vidi u odgovarajućem spremištu, a ne iz onoga što kartica slučajno sadrži. Filtar koji se ni s čim ne podudara vraća se na upit ili na tihi neuspjeh, ovisno o konfiguraciji profila, zato je odabrani otisak vrijedno zabilježiti prije bilo kakve promjene.

Utvrdite i radi li veza kao prijavljeni korisnik ili kao računalo. Ta jedna činjenica određuje koja su spremišta certifikata u opsegu i koji sigurnosni kontekst izvodi potpis.

Potvrdite koji je certifikat odabran

Usporedite otisak koji je Windows odabrao sa zahtjevom: upotreba za provjeru autentičnosti klijenta, lanac koji završava u pouzdanom korijenu, identitet koji preslikava pravilnik poslužitelja za provjeru autentičnosti i razdoblje valjanosti koje pokriva stvarni trenutak pokušaja. To su odvojene provjere, a posljednja hvata više iznenađenja nego što ljudi očekuju, osobito s certifikatima izdanima na tekućoj osnovi i predmemoriranim profilima koji još uvijek pokazuju na jučerašnji odabir.

Kontekst korisnika i računala druga je polovica provjere. Certifikat u korisnikovu osobnom spremištu nevidljiv je usluzi koja radi kao računalo, a certifikat računala ne predstavlja se u EAP razmjeni u korisničkom načinu rada ako profil ne kaže drukčije. Ponovni uvoz certifikata u pogrešno spremište daje vidljiv certifikat i nevidljive vjerodajnice za prijavu. Čitajte putanju spremišta u profilu, a ne onu u dijalogu koji se slučajno otvorio.

Testirajte operaciju ključa bez nagađanja PIN-a

Kad je odabir riješen, pitanje je hoće li kartica izvesti potpis. Windows treba podržanog pružatelja kartice ili miniupravljački program da dosegne privatni ključ, a uređaj primjenjuje vlastita pravila PIN-a i prisutnosti na operaciju. Kartica konfigurirana da zahtijeva dodir za svaki potpis ponaša se drukčije od one koja predmemorira provjeru za sesiju, i obje su legitimne konfiguracije koje mijenjaju kada se pojavljuje upit. Ta razlika objašnjava prijavu koja uspijeva pri svježem umetanju i propada nakon nastavka, a da nijedan certifikat nije pogrešan.

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

Prva naredba popisuje karticu i izvješćuje o stanju čitača i pružatelja, što je dokumentirano u Microsoftovu vodiču za otklanjanje poteškoća sa pametnim karticama. Druga naredba navodi što korisnički kontekst zapravo vidi. Nijedna ne dokazuje uspješnu provjeru autentičnosti; obje sužavaju gdje se zaustavilo.

Ne nagađajte PIN. Kartice provode ograničenja ponovnih pokušaja, a nekoliko optimističnih pokušaja pretvara problem dopuštenja u blokiranu vjerodajnicu koja zahtijeva administrativni oporavak. Ako lokalni potpis propadne, zabilježite stanje pružatelja i stanje kartice umjesto isprobavanja varijanti. Ponovite pokušaj jednom s istim profilom, istim certifikatom i poznatom ispravnom putanjom čitača, zatim usporedite dva zapisa; mijenjanje nekoliko varijabli odjednom daje priču, a ne rezultat.

Pročitajte obje strane rukovanja

Dovršen potpis još nije dopuštenje. Poslužitelj za provjeru autentičnosti mora prihvatiti lanac, provjeriti opoziv, preslikati identitet prema svojim trenutačnim pravilima i odobriti zahtjev; klijent zauzvrat mora provjeriti poslužiteljev certifikat kako profil zahtijeva. TLS upozorenje koje generira poslužitelj izgleda u klijentovu zapisu jednako kao ono generirano lokalno, zato je strana koja ga je emitirala važnija od teksta upozorenja.

Prikupite događaje sustava Windows i događaje na strani poslužitelja s poravnatim vremenskim oznakama, zatim utvrdite koja je strana proizvela prvi neuspjeh. RFC 5216 opisuje korak dokazivanja posjeda u EAP-TLS, a općenito upozorenje rukovanja samo po sebi ne imenuje lokalni uzrok vezan uz ključ. Usporedba vremenskih oznaka pretvara dva zapisa u slijed.

Držite granice jasnima u izvješću

Napišite izvješće kao četiri faze s po jednom presudom: koji su profil i kontekst radili, koji je certifikat Windows odabrao, je li kartica potpisala i što je poslužitelj odlučio. Ta struktura čini sljedeći korak očitim i sprječava uobičajeni popravak isključivanjem provjere da bi se prošla faza koju nitko nije identificirao.

Softverski certifikat kao privremena usporedba legitiman je administratorski test, ali mijenja model vjerodajnica i jamstva, pa pripada u odobrenu promjenu, a ne u tihu produkcijsku zaobilaznicu. Ista disciplina vrijedi za pokušaje PIN-a i za ponovno izdavanje vjerodajnica prije nego što je poznata faza koja propada. Zamjenska kartica koja propada jednako skup je dokaz da problem nikada nije bio na kartici.