Hyrja me PIV dështon në Windows EAP-TLS? Kontrolloni rrugën e nënshkrimit

Shfaqni certifikatën e një karte PIV në çdo dialog të Windows dhe hyrja në VPN mund të dështojë gjithsesi, sepse dukshmëria dhe përdorshmëria janë veti të ndryshme. Certifikata është një objekt publik; hyrja kërkon një veprim me çelës privat që karta e kryen sipas rregullave të saj të aksesit. Midis këtyre dy fakteve qëndrojnë katër faza që dështojnë në katër mënyra të ndryshme: zgjedhja e profilit, zgjedhja e certifikatës, nënshkrimi lokal dhe validimi në anën e serverit. Kalimi i tyre me radhë e kthen një gabim gjenerik shtrëngimi duarsh në një pyetje konkrete për këdo që zotëron pjesën tjetër.

Filloni me profilin dhe metodën EAP

Hapni vetitë e lidhjes dhe lexoni cilin metodë EAP përdor në të vërtetë profili, pastaj lexoni cilën certifikatë metoda është konfiguruar të zgjedhë. Shumë implementime kanë një metodë të jashtme të bazuar në certifikatë dhe një metodë të brendshme, dhe një certifikatë e konfiguruar në nivelin e lidhjes nuk është automatikisht ajo që paraqitet brenda EAP-TLS. Nëse profili zgjedh një certifikatë sipas lëshuesit ose sipas një filtri subjekti, ai filtër zgjedh nga ajo që Windows sheh në depon përkatëse, jo nga ajo që karta përmban rastësisht. Një filtër që nuk përputhet me asgjë kalon në një kërkesë ose në një dështim të heshtur sipas konfigurimit të profilit, prandaj ia vlen të regjistrohet shenja e gishtit e zgjedhur përpara çdo ndryshimi.

Përcaktoni gjithashtu nëse lidhja ekzekutohet si përdoruesi i identifikuar apo si makina. Ky fakt i vetëm vendos cilat depo certifikatash janë në fushë dhe cili kontekst sigurie e kryen nënshkrimin.

Konfirmoni cilën certifikatë u zgjodh

Krahasoni shenjën e gishtit që zgjodhi Windows me kërkesën: përdorimi për vërtetim klienti, një zinxhir që përfundon në një rrënjë të besuar, një identitet që politika e serverit të vërtetimit e harton dhe një periudhë vlefshmërie që mbulon momentin aktual të përpjekjes. Këto janë kontrolle të veçanta dhe e fundit kap më shumë surpriza sesa presin njerëzit, sidomos me certifikata të lëshuara në mënyrë rrotulluese dhe profile të ruajtura në cache që vazhdojnë të tregojnë zgjedhjen e djeshme.

Konteksti i përdoruesit dhe i makinës është gjysma tjetër e kontrollit. Një certifikatë në depon personale të përdoruesit është e padukshme për një shërbim që ekzekutohet si makina, dhe një certifikatë makine nuk paraqitet nga një shkëmbim EAP në modalitetin përdorues nëse profili nuk e thotë këtë. Riimportimi i një certifikate në depon e gabuar prodhon një certifikatë të dukshme dhe një kredencial hyrjeje të padukshme. Lexoni shtegun e depos në profil, jo atë në dialogun që u hap rastësisht.

Provoni veprimin me çelësin pa hamendësuar PIN-in

Pasi zgjedhja është vendosur, pyetja është nëse karta do ta kryejë nënshkrimin. Windows ka nevojë për një ofrues karte të mbështetur ose minidriver për të arritur çelësin privat, dhe pajisja zbaton rregullat e veta të PIN-it dhe të pranisë në veprim. Një kartë e konfiguruar të kërkojë prekje për çdo nënshkrim sillet ndryshe nga një që ruan një verifikim për një sesion, dhe të dyja janë konfigurime legjitime që ndryshojnë kur shfaqet një kërkesë. Ky ndryshim shpjegon një hyrje që ka sukses pas një futjeje të re dhe dështon pas një rinisjeje nga gjumi, pa qenë asnjë certifikatë e gabuar.

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

Komanda e parë inventarizon kartën dhe raporton gjendjen e lexuesit dhe të ofruesit, e cila dokumentohet në udhëzimet e Microsoft për korrigjimin e kartave inteligjente. E dyta liston çfarë mund të shohë vërtet konteksti i përdoruesit. Asnjëra nuk provon një vërtetim të suksesshëm; të dyja e ngushtojnë vendin ku u ndal.

Mos e hamendësoni PIN-in. Kartat zbatojnë kufij përpjekjesh, dhe disa përpjekje optimiste e kthejnë një problem lejesh në një kredencial të bllokuar që kërkon rikuperim administrativ. Nëse një nënshkrim lokal dështon, regjistroni gjendjen e ofruesit dhe gjendjen e kartës në vend që të provoni variante. Përsëriteni përpjekjen një herë me të njëjtin profil, të njëjtën certifikatë dhe një shteg lexuesi të njohur si i mirë, pastaj krahasoni të dy regjistrimet; ndryshimi i disa variablave njëherësh prodhon një histori, jo një rezultat.

Lexoni të dyja anët e shtrëngimit të duarve

Një nënshkrim i përfunduar nuk është ende pranim. Serveri i vërtetimit duhet ta pranojë zinxhirin, të kontrollojë revokimin, ta hartojë identitetin sipas rregullave të tij aktuale dhe ta autorizojë kërkesën; klienti nga ana tjetër duhet ta validonte certifikatën e serverit siç kërkon profili. Një alarm TLS i krijuar nga serveri duket identik në regjistrin e klientit me një të krijuar në nivel lokal, prandaj ana që e lëshon ka më shumë rëndësi sesa teksti i alarmit.

Mblidhni ngjarjet e Windows dhe ngjarjet e anës së serverit me vulë kohore të rreshtuara, pastaj identifikoni cila anë prodhoi dështimin e parë. RFC 5216 përshkruan hapin e provës së zotërimit në EAP-TLS, dhe një alarm gjenerik shtrëngimi duarsh nuk emërton vetë një shkak lokal çelësi. Krahasimi i vulave kohore është ai që i kthen dy regjistra në një sekuencë.

Mbani kufijtë drejt në raport

Shkruajeni raportin si katër faza me nga një verdikt: cili profil dhe kontekst ekzekutuan, cilën certifikatë zgjodhi Windows, a nënshkroi karta dhe çfarë vendosi serveri. Ai strukturim e bën hapin tjetër të qartë dhe parandalon riparimin e zakonshëm të çaktivizimit të validimit për të kaluar një fazë që askush nuk e identifikoi.

Një certifikatë software si krahasim i përkohshëm është një provë administrative legjitime, por ndryshon modelin e kredencialeve dhe të garancisë, prandaj i përket një ndryshimi të miratuar dhe jo një anashkalimi të heshtur në prodhim. E njëjta disiplinë vlen për përpjekjet me PIN dhe për rilëshimin e kredencialeve përpara se të njihet faza që dështon. Një kartë zëvendësuese që dështon në mënyrë identike është provë e shtrenjtë se problemi nuk ishte kurrë në kartë.