Bumabagsak ang pag-login sa PIV sa Windows EAP-TLS? Suriin ang landas ng pagpirma

Ipakita ang sertipiko ng PIV card sa bawat dialog ng Windows at maaari pa ring bumagsak ang pag-login sa VPN, dahil magkaibang katangian ang nakikita at nagagamit. Ang sertipiko ay pampublikong bagay; kailangan ng pag-login ang operasyon ng pribadong susi na ginagawa ng card ayon sa sarili nitong mga patakaran sa pag-access. Sa pagitan ng dalawang katotohanang ito ay may apat na yugto na bumabagsak sa apat na magkaibang paraan: pagpili ng profile, pagpili ng sertipiko, lokal na pagpirma at beripikasyon sa panig ng server. Ang pagsunod sa kanila nang sunud-sunod ay ginagawang tiyak na tanong para sa may hawak ng susunod na bahagi ang isang pangkalahatang error sa handshake.

Magsimula sa profile at paraan ng EAP

Buksan ang mga katangian ng koneksyon at basahin kung aling paraan ng EAP ang talagang ginagamit ng profile, pagkatapos basahin kung aling sertipiko ang naka-configure na piliin ng paraan. Maraming deployment ang may parehong panlabas na paraang nakabatay sa sertipiko at panloob na paraan, at ang sertipikong naka-configure sa antas ng koneksyon ay hindi awtomatikong iyon ang ipinapakita sa loob ng EAP-TLS. Kung ang profile ay pumipili ng sertipiko ayon sa issuer o ayon sa subject filter, ang filter na iyon ay pumipili mula sa nakikita ng Windows sa kaugnay na store, hindi mula sa nagkataong laman ng card. Ang filter na walang katugma ay bumabagsak sa isang prompt o sa tahimik na pagkabigo depende sa configuration ng profile, kaya sulit irekord ang napiling thumbprint bago ang anumang pagbabago.

Alamin din kung tumatakbo ang koneksyon bilang naka-sign in na user o bilang makina. Ang nag-iisang katotohanang iyon ang nagtatakda kung aling mga store ng sertipiko ang saklaw at aling security context ang gumagawa ng pirma.

Kumpirmahin kung aling sertipiko ang napili

Ihambing ang thumbprint na pinili ng Windows sa pangangailangan: paggamit para sa client authentication, isang chain na nagtatapos sa pinagkakatiwalaang root, isang identity na minamapa ng patakaran ng authentication server, at panahon ng validity na sumasaklaw sa aktwal na sandali ng pagtatangka. Ito ay magkakahiwalay na pagsusuri at ang huli ay humuhuli ng mas maraming sorpresa kaysa inaasahan ng mga tao, lalo na sa mga sertipikong inilalabas nang paikot at mga naka-cache na profile na tumuturo pa rin sa pinili kahapon.

Ang konteksto ng user at makina ang kabilang kalahati ng pagsusuri. Ang sertipiko sa personal na store ng user ay hindi nakikita ng serbisyong tumatakbo bilang makina, at ang sertipiko ng makina ay hindi ipinapakita ng EAP exchange sa user mode maliban kung sinasabi ng profile. Ang muling pag-import ng sertipiko sa maling store ay gumagawa ng nakikitang sertipiko at hindi nakikitang kredensyal sa pag-login. Basahin ang landas ng store sa profile, hindi ang nasa dialog na nagkataong bumukas.

Subukan ang operasyon ng susi nang hindi hinuhulaan ang PIN

Kapag napagpasyahan na ang pagpili, ang tanong ay kung gagawin ng card ang pirma. Kailangan ng Windows ng sinusuportahang card provider o minidriver upang maabot ang pribadong susi, at inilalapat ng device ang sarili nitong mga patakaran sa PIN at presensya sa operasyon. Ang card na naka-configure na mangailangan ng paghipo sa bawat pirma ay kakaiba ang asal sa isang nag-cache ng beripikasyon para sa isang session, at pareho silang lehitimong configuration na nagbabago kung kailan lumilitaw ang prompt. Ipinapaliwanag ng pagkakaibang iyon ang pag-login na nagtagumpay matapos sariwang isaksak at bumabagsak matapos ang resume, nang walang maling sertipiko.

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

Inililista ng unang command ang card at iniuulat ang kalagayan ng reader at provider, na nakadokumento sa patnubay ng Microsoft sa pag-debug ng smart card. Inililista ng pangalawa kung ano talaga ang nakikita ng konteksto ng user. Wala sa kanila ang nagpapatunay ng matagumpay na authentication; pareho nilang pinapaliit kung saan ito tumigil.

Huwag hulaan ang PIN. Ipinatutupad ng mga card ang limitasyon sa pagtatangka, at ang ilang optimistikong pagtatangka ay ginagawang naka-block na kredensyal na nangangailangan ng administratibong pagbawi ang isang problema sa pahintulot. Kung bumagsak ang lokal na pirma, itala ang kalagayan ng provider at ng card sa halip na subukan ang mga baryante. Ulitin ang pagtatangka isang beses gamit ang parehong profile, parehong sertipiko at kilalang mahusay na landas ng reader, pagkatapos ihambing ang dalawang tala; ang pagbabago ng ilang variable nang sabay ay gumagawa ng kuwento at hindi resulta.

Basahin ang dalawang panig ng handshake

Ang natapos na pirma ay hindi pa pagtanggap. Dapat tanggapin ng authentication server ang chain, suriin ang revoke, imapa ang identity ayon sa kasalukuyang mga patakaran nito at pahintulutan ang kahilingan; dapat naman beripikahin ng client ang sertipiko ng server ayon sa hinihingi ng profile. Ang TLS alert na nilikha ng server ay mukhang kapareho sa log ng client ng isang nilikha nang lokal, kaya mas mahalaga ang panig na naglalabas nito kaysa teksto ng alert.

Kolektahin ang mga kaganapan sa Windows at ang mga kaganapan sa panig ng server na may naka-align na timestamp, pagkatapos tukuyin kung aling panig ang gumawa ng unang pagkabigo. Inilalarawan ng RFC 5216 ang hakbang ng patunay ng pagmamay-ari sa EAP-TLS, at ang pangkalahatang handshake alert ay hindi nagbabanggit ng lokal na dahilan ng susi nang mag-isa. Ang paghahambing ng timestamp ang gumagawa ng dalawang log na maging isang sekwensya.

Panatilihing tuwid ang mga hangganan sa ulat

Isulat ang ulat bilang apat na yugto na may isang hatol bawat isa: aling profile at konteksto ang tumakbo, aling sertipiko ang pinili ng Windows, nagpirma ba ang card, at ano ang pinagpasyahan ng server. Ginagawang malinaw ng estrukturang iyon ang susunod na hakbang at pinipigilan ang karaniwang pag-aayos na patayin ang beripikasyon upang malampasan ang yugtong walang nakilala.

Ang sertipiko ng software bilang pansamantalang paghahambing ay lehitimong pagsubok ng administrador, ngunit binabago nito ang modelo ng kredensyal at garantiya, kaya kabilang ito sa aprubadong pagbabago at hindi sa tahimik na paglampas sa produksyon. Ang parehong disiplina ay nalalapat sa mga pagtatangka sa PIN at sa muling paglabas ng kredensyal bago malaman ang yugtong bumabagsak. Ang kapalit na card na bumabagsak nang kapareho ay mamahaling ebidensya na hindi kailanman nasa card ang problema.