PIV-aanmelding misluk op Windows met EAP-TLS? Kyk na die ondertekeningspad
Die sertifikaat van ’n kaart kan sigbaar wees en die aanmelding kan tog misluk. Gaan die vier fases na: profiel, keuse, plaaslike ondertekening en verafgeleë validering.
Wys die sertifikaat van ’n PIV-kaart in elke Windows-dialoogvenster, en die VPN-aanmelding kan steeds misluk, want sigbaarheid en bruikbaarheid is verskillende eienskappe. Die sertifikaat is ’n openbare objek; die aanmelding benodig ’n bewerking met die private sleutel wat deur die kaart onder sy eie toegangsreëls uitgevoer word. Tussen daardie twee feite lê vier fases wat op vier verskillende maniere misluk: profielkeuse, sertifikaatkeuse, plaaslike ondertekening en validering aan die bedienerkant. Om hulle in volgorde te deurloop, verander ’n algemene handdrukfout in ’n spesifieke vraag vir elkeen wat die volgende stuk besit.
Begin by die profiel en die EAP-metode
Maak die verbinding se eienskappe oop en lees watter EAP-metode die profiel werklik gebruik, en lees dan watter sertifikaat die metode gekonfigureer is om te kies. Baie ontplooiings het beide ’n sertifikaatgebaseerde buitenste metode en ’n binneste metode, en ’n sertifikaat wat op verbindingsvlak gekonfigureer is, is nie outomaties die een wat binne EAP-TLS aangebied word nie. As die profiel ’n sertifikaat volgens uitreiker of volgens onderwerpfilter kies, kies daardie filter uit wat Windows in die betrokke stoor kan sien, nie uit wat die kaart toevallig bevat nie. ’n Filter wat niks pas nie, val terug op ’n opdrag of op ’n stil mislukking, afhangende van die profiel se konfigurasie, en daarom is dit die moeite werd om die gekose duimafdruk voor enige verandering aan te teken.
Stel ook vas of die verbinding as die aangemelde gebruiker of as die masjien loop. Daardie enkele feit bepaal watter sertifikaatstore in bereik is en watter sekuriteitskonteks die ondertekening uitvoer.
Bevestig watter sertifikaat gekies is
Vergelyk die duimafdruk wat Windows gekies het met die vereiste: gebruik vir kliëntverifikasie, ’n ketting wat by ’n vertroude wortel eindig, ’n identiteit wat die verifikasiemodule se beleid karteer, en ’n geldigheidsperiode wat die werklike oomblik van die poging dek. Dit is afsonderlike kontroles, en die laaste een vang meer verrassings as wat mense verwag, veral met sertifikate wat op ’n rollende basis uitgereik word en gekaste profiele wat steeds na gister se keuse wys.
Gebruiker- en masjienkonteks is die ander helfte van die kontrole. ’n Sertifikaat in die gebruiker se persoonlike stoor is onsigbaar vir ’n diens wat as die masjien loop, en ’n masjiensertifikaat word nie deur ’n gebruikermodus-EAP-uitruiling aangebied nie, tensy die profiel dit sê. Om ’n sertifikaat in die verkeerde stoor te herinvoer, lewer ’n sigbare sertifikaat en ’n onsigbare aanmeldingstoegangsbewys. Lees die stoorpad in die profiel, nie die een in die dialoogvenster wat toevallig oopgemaak het nie.
Toets die sleutelbewerking sonder om die PIN te raai
Sodra die keuse vasgestel is, is die vraag of die kaart die ondertekening sal uitvoer. Windows benodig ’n ondersteunde kaartverskaffer of minidriver om by die private sleutel uit te kom, en die toestel pas sy eie PIN- en teenwoordigheidsreëls op die bewerking toe. ’n Kaart wat gekonfigureer is om ’n aanraking vir elke ondertekening te vereis, gedra hom anders as een wat ’n verifikasie vir ’n sessie kas, en albei is wettige konfigurasies wat verander wanneer ’n opdrag verskyn. Daardie verskil verklaar ’n aanmelding wat op ’n vars invoeging slaag en ná ’n hervatting misluk, sonder dat enige sertifikaat verkeerd is.
certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'
Die eerste opdrag inventariseer die kaart en rapporteer die leser- en verskafferstatus, wat in Microsoft se handleiding vir slimkaart-ontfouting gedokumenteer is. Die tweede lys wat die gebruikerkonteks werklik kan sien. Nie een bewys ’n suksesvolle verifikasie nie; albei vernou waar dit gestop het.
Moenie die PIN raai nie. Kaarte dwing herhalingslimiete af, en ’n paar optimistiese pogings omskep ’n regteprobleem in ’n geblokkeerde toegangsbewys wat administratiewe herstel nodig het. As ’n plaaslike ondertekening misluk, teken die verskafferstatus en die kaarttoestand aan in plaas daarvan om variante te probeer. Herhaal die poging een keer met dieselfde profiel, dieselfde sertifikaat en ’n bekende goeie leserpad, en vergelyk dan die twee rekords; om verskeie veranderlikes gelyktydig te verander, lewer ’n verhaal eerder as ’n resultaat.
Lees albei kante van die handdruk
’n Voltooide ondertekening is steeds nie toelating nie. Die verifikasiemodule moet die ketting aanvaar, herroeping nagaan, die identiteit volgens sy huidige reëls karteer en die versoek magtig; die kliënt moet op sy beurt die bediener se sertifikaat valideer soos die profiel vereis. ’n TLS-waarskuwing wat deur die bediener gegenereer word, lyk in die kliënt se log dieselfde as een wat plaaslik gegenereer is, en daarom is die emitterende kant belangriker as die waarskuwingsteks.
Versamel die Windows-gebeurtenisse en die bedienerkant-gebeurtenisse met belynde tydstempels, en identifiseer dan watter kant die eerste fout opgelewer het. RFC 5216 beskryf die stap waar die besit bewys word in EAP-TLS, en ’n algemene handdrukwaarskuwing noem nie op sigself ’n plaaslike sleuteloorsaak nie. Die tydstempelvergeliking is wat twee logs in ’n reeks verander.
Hou die grense reguit in die verslag
Skryf die verslag as vier fases met een uitspraak elk: watter profiel en konteks geloop het, watter sertifikaat Windows gekies het, of die kaart onderteken het, en wat die bediener besluit het. Daardie struktuur maak die volgende stap duidelik en verhoed die algemene herstelwerk om validering af te skakel om verby ’n fase te kom wat niemand geïdentifiseer het nie.
’n Sagteware-sertifikaat as ’n tydelike vergelyking is ’n wettige administrateurstoets, maar dit verander die toegangsbewys- en versekeringsmodel, so dit hoort in ’n goedgekeurde verandering eerder as in ’n stil produksiewerkoplossing. Dieselfde dissipline geld vir PIN-pogings en vir die heruitreiking van toegangsbewyse voordat die mislukkende fase bekend is. ’n Vervangingskaart wat identies misluk, is duur bewyse dat die probleem nooit op die kaart was nie.