PIV-ensaluto malsukcesas en Windows kun EAP-TLS? Kontrolu la subskriban vojon

Montru la atestilon de PIV-karto en ĉiu Windows-dialogo, kaj la VPN-ensaluto tamen povas malsukcesi, ĉar videbleco kaj uzebleco estas malsamaj ecoj. La atestilo estas publika objekto; la ensaluto bezonas privatan ŝlosilan operacion, kiun plenumas la karto laŭ siaj propraj alirreguloj. Inter tiuj du faktoj staras kvar etapoj, kiuj malsukcesas kvar diversmaniere: profil-elekto, atestil-elekto, loka subskribo kaj validigo ĉe la servila flanko. Trapasi ilin laŭorde transformas ĝeneralan manpreman eraron en specifan demandon por tiu, kiu posedas la sekvan pecon.

Komencu per la profilo kaj la EAP-metodo

Malfermu la ecojn de la konekto kaj legu, kiun EAP-metodon la profilo fakte uzas, poste legu, kiun atestilon la metodo estas agordita elekti. Multaj enkondukoj havas kaj atestil-bazitan eksteran metodon kaj internan metodon, kaj atestilo agordita sur la konekta nivelo ne aŭtomate estas tiu prezentata ene de EAP-TLS. Se la profilo elektas atestilon laŭ eldoninto aŭ laŭ subjekta filtrilo, tiu filtrilo elektas el tio, kion Windows povas vidi en la koncerna stokejo, ne el tio, kion la karto hazarde enhavas. Filtrilo, kiu kongruas kun nenio, falas al invito aŭ al silenta malsukceso laŭ la agordo de la profilo, tial indas registri la elektitan fingrospuron antaŭ iu ajn ŝanĝo.

Konstatu ankaŭ, ĉu la konekto funkcias kiel la ensalutinta uzanto aŭ kiel la maŝino. Tiu unu fakto decidas, kiuj atestil-stokejoj estas en la amplekso kaj kiu sekureca kunteksto plenumas la subskribon.

Konfirmu, kiun atestilon oni elektis

Komparu la fingrospuron, kiun Windows elektis, kun la postulo: uzo por klienta aŭtentigo, ĉeno finiĝanta en fidinda radiko, identeco kiun la politiko de la aŭtentiga servilo bildigas, kaj valida periodo kovranta la faktan momenton de la provo. Tiuj estas apartaj kontroloj, kaj la lasta kaptas pli da surprizoj ol homoj atendas, precipe ĉe atestiloj eldonataj daŭre kaj kaŝmemoraj profilo ankoraŭ montrantaj al la hieraŭa elekto.

Uzanta kaj maŝina kuntekstoj estas la alia duono de la kontrolo. Atestilo en la persona stokejo de la uzanto estas nevidebla por servo funkcianta kiel la maŝino, kaj maŝinan atestilon ne prezentas EAP-interŝanĝo en uzanta reĝimo, se la profilo ne diras alie. Reenporti atestilon en la malĝustan stokejon produktas videblan atestilon kaj nevideblan ensalutan legitimilon. Legu la stokejan vojon en la profilo, ne tiun en la dialogo kiu hazarde malfermiĝis.

Testu la ŝlosilan operacion sen diveni la PIN

Post kiam la elekto estas solvita, la demando estas, ĉu la karto plenumos la subskribon. Windows bezonas subtenatan kartprovizanton aŭ minidriver por atingi la privatan ŝlosilon, kaj la aparato aplikas siajn proprajn PIN- kaj ĉeestajn regulojn al la operacio. Karto agordita postuli tuŝon por ĉiu subskribo kondutas malsame ol unu, kiu kaŝmemorigas kontrolon por sesio, kaj ambaŭ estas legitimaj agordoj, kiuj ŝanĝas kiam invito aperas. Tiu diferenco klarigas ensaluton, kiu sukcesas ĉe freŝa enigo kaj malsukcesas post rekomenco, sen ke iu ajn atestilo estu malĝusta.

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

La unua komando inventaras la karton kaj raportas la staton de legilo kaj provizanto, kio estas dokumentita en la gvidilo de Microsoft pri senspertaj kartoj. La dua listigas, kion la uzanta kunteksto fakte povas vidi. Neniu el ili pruvas sukcesan aŭtentigon; ambaŭ mallarĝigas, kie ĝi haltis.

Ne divenu la PIN. Kartoj plenumas limigojn de ripetoj, kaj kelkaj optimismaj provoj transformas permesan problemon en blokitan legitimilon, kiu bezonas administran restarigon. Se loka subskribo malsukcesas, registru la provizantan staton kaj la kartan staton anstataŭ provi variantojn. Ripetu la provon unufoje kun la sama profilo, la sama atestilo kaj konata bona legila vojo, poste komparu la du registraĵojn; ŝanĝi plurajn variablojn samtempe produktas rakonton anstataŭ rezulton.

Legu ambaŭ flankojn de la manpremo

Kompletigita subskribo ankoraŭ ne estas eniro. La aŭtentiga servilo devas akcepti la ĉenon, kontroli revokon, bildigi la identecon laŭ siaj nunaj reguloj kaj rajtigi la peton; la kliento siavice devas validigi la atestilon de la servilo tiel, kiel la profilo postulas. TLS-avizo generita de la servilo aspektas en la klienta protokolo same kiel unu generita loke, tial la flanko, kiu ĝin elsendis, pli gravas ol la teksto de la avizo.

Kolektu la Windows-eventojn kaj la eventojn ĉe la servila flanko kun vicigitaj tempomarkoj, poste identigu, kiu flanko produktis la unuan malsukceson. RFC 5216 priskribas la pruvon de posedo en EAP-TLS, kaj ĝenerala manprema avizo ne nomas per si mem lokan kaŭzon ligitan al ŝlosilo. La komparo de tempomarkoj estas tio, kio transformas du protokolojn en sinsekvon.

Tenu la limojn klaraj en la raporto

Skribu la raporton kiel kvar etapoj kun po unu verdikto: kiu profilo kaj kunteksto funkciis, kiun atestilon Windows elektis, ĉu la karto subskribis kaj kion decidis la servilo. Tiu strukturo faras la sekvan paŝon evidenta kaj malhelpas la kutiman riparon malŝalti validigon por preterpasi etapon, kiun neniu identigis.

Programara atestilo kiel provizora komparo estas legitima administranta testo, sed ĝi ŝanĝas la modelon de legitimilo kaj garantio, do ĝi apartenas al aprobita ŝanĝo, ne al silenta produktada evito. La sama disciplino validas por PIN-provoj kaj por reeldono de legitimiloj antaŭ ol la malsukcesanta etapo estas konata. Anstataŭa karto, kiu malsukcesas idente, estas multekosta pruvo, ke la problemo neniam estis sur la karto.