PIV prisijungimas nepavyksta „Windows“ su EAP-TLS? Patikrinkite pasirašymo kelią

Rodykite PIV kortelės sertifikatą kiekviename „Windows“ dialoge, o VPN prisijungimas vis tiek gali nepavykti, nes matomumas ir tinkamumas naudoti yra skirtingos savybės. Sertifikatas yra viešas objektas; prisijungimui reikia privataus rakto operacijos, kurią kortelė atlieka pagal savo prieigos taisykles. Tarp šių dviejų faktų yra keturi etapai, kurie nepavyksta keturiais skirtingais būdais: profilio pasirinkimas, sertifikato pasirinkimas, vietinis pasirašymas ir tikrinimas serverio pusėje. Nuoseklus jų perėjimas bendrą rankos paspaudimo klaidą paverčia konkrečiu klausimu tam, kam priklauso kita dalis.

Pradėkite nuo profilio ir EAP metodo

Atidarykite ryšio savybes ir perskaitykite, kurį EAP metodą profilis iš tikrųjų naudoja, tada perskaitykite, kurį sertifikatą metodas sukonfigūruotas pasirinkti. Daugelyje diegimų yra ir sertifikatu pagrįstas išorinis metodas, ir vidinis metodas, o ryšio lygmenyje sukonfigūruotas sertifikatas nebūtinai yra tas, kuris pateikiamas EAP-TLS viduje. Jei profilis pasirenka sertifikatą pagal išdavėją arba subjekto filtrą, tas filtras renkasi iš to, ką „Windows“ mato atitinkamoje saugykloje, o ne iš to, ką kortelė atsitiktinai turi. Filtras, kuris nieko neatitinka, priklausomai nuo profilio konfigūracijos grįžta prie raginimo arba tylios nesėkmės, todėl verta užfiksuoti pasirinktą kontrolinį kodą prieš bet kokį pakeitimą.

Taip pat nustatykite, ar ryšys veikia kaip prisijungęs naudotojas, ar kaip kompiuteris. Šis vienas faktas nulemia, kurios sertifikatų saugyklos patenka į apimtį ir koks saugos kontekstas atlieka parašą.

Patvirtinkite, kuris sertifikatas buvo pasirinktas

Palyginkite „Windows“ pasirinktą kontrolinį kodą su reikalavimu: naudojimas kliento autentifikacijai, grandinė, besibaigianti patikimoje šaknyje, tapatybė, kurią susieja autentifikacijos serverio politika, ir galiojimo laikotarpis, apimantis tikrąjį bandymo momentą. Tai atskiri patikrinimai, o paskutinis pagauna daugiau netikėtumų, nei žmonės tikisi, ypač su nuolat išduodamais sertifikatais ir talpykloje laikomais profiliais, kurie vis dar nurodo vakar dienos pasirinkimą.

Naudotojo ir kompiuterio kontekstas yra kita patikrinimo pusė. Sertifikatas naudotojo asmeninėje saugykloje yra nematomas paslaugai, veikiančiai kaip kompiuteris, o kompiuterio sertifikatas nepateikiamas naudotojo režimo EAP apsikeitime, nebent profilis taip sako. Iš naujo importavus sertifikatą į netinkamą saugyklą, gaunamas matomas sertifikatas ir nematomas prisijungimo liudijimas. Skaitykite saugyklos kelią profilyje, o ne tame dialoge, kuris atsidarė atsitiktinai.

Išbandykite rakto operaciją neatspėdami PIN

Kai pasirinkimas nustatytas, kyla klausimas, ar kortelė atliks parašą. „Windows“ reikia palaikomo kortelės teikėjo arba minidriver, kad pasiektų privatų raktą, o įrenginys operacijai taiko savo PIN ir buvimo taisykles. Kortelė, sukonfigūruota reikalauti prisilietimo prie kiekvieno parašo, elgiasi kitaip nei ta, kuri talpykloje saugo patvirtinimą sesijai, ir abi yra teisėtos konfigūracijos, keičiančios, kada pasirodo raginimas. Šis skirtumas paaiškina prisijungimą, kuris pavyksta įstačius iš naujo ir nepavyksta po tęsimo, nė vienam sertifikatui nesant klaidingam.

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

Pirmoji komanda inventorizuoja kortelę ir praneša skaitytuvo bei teikėjo būseną, kas dokumentuota „Microsoft“ išmaniųjų kortelių derinimo gairėse. Antroji išvardija, ką naudotojo kontekstas iš tikrųjų gali matyti. Nė viena neįrodo sėkmingos autentifikacijos; abi susiaurina, kur tai sustojo.

Neatspėkite PIN. Kortelės taiko pakartojimų limitus, o keli optimistiniai bandymai leidimų problemą paverčia užblokuotu liudijimu, kuriam reikia administracinio atkūrimo. Jei vietinis parašas nepavyksta, užfiksuokite teikėjo būseną ir kortelės būseną, o ne bandykite variantus. Pakartokite bandymą vieną kartą su tuo pačiu profiliu, tuo pačiu sertifikatu ir žinomu geru skaitytuvo keliu, tada palyginkite du įrašus; keičiant kelis kintamuosius iš karto gaunama istorija, o ne rezultatas.

Skaitykite abi rankos paspaudimo puses

Užbaigtas parašas dar nėra priėmimas. Autentifikacijos serveris turi priimti grandinę, patikrinti atšaukimą, susieti tapatybę pagal galiojančias taisykles ir leisti užklausą; klientas savo ruožtu turi patikrinti serverio sertifikatą, kaip reikalauja profilis. Serverio sugeneruotas TLS įspėjimas kliento žurnale atrodo taip pat, kaip sugeneruotas vietoje, todėl jį išsiuntusi pusė svarbesnė už įspėjimo tekstą.

Surinkite „Windows“ įvykius ir serverio pusės įvykius su suderintomis laiko žymomis, tada nustatykite, kuri pusė sukėlė pirmąją nesėkmę. RFC 5216 aprašo valdymo įrodymo žingsnį EAP-TLS, o bendras rankos paspaudimo įspėjimas savaime neįvardija vietinės rakto priežasties. Būtent laiko žymų palyginimas paverčia du žurnalus seka.

Laikykite ribas tiesiai ataskaitoje

Rašykite ataskaitą kaip keturis etapus, kiekvienam po vieną verdiktą: koks profilis ir kontekstas veikė, kurį sertifikatą pasirinko „Windows“, ar kortelė pasirašė ir ką nusprendė serveris. Ši struktūra padaro kitą žingsnį akivaizdų ir užkerta kelią įprastam taisymui išjungti tikrinimą, kad būtų pereitas etapas, kurio niekas nenustatė.

Programinės įrangos sertifikatas kaip laikinas palyginimas yra teisėtas administratoriaus testas, bet jis keičia liudijimo ir garantijos modelį, todėl priklauso patvirtintam pakeitimui, o ne tylai produkcijos apėjimui. Ta pati disciplina taikoma PIN bandymams ir liudijimų pakartotiniam išdavimui prieš žinant nepavykstantį etapą. Identiškai nepavykstanti pakaitinė kortelė yra brangus įrodymas, kad problema niekada nebuvo kortelėje.