PIV pieteikšanās neizdodas Windows EAP-TLS? Pārbaudiet parakstīšanas ceļu

Rādiet PIV kartes sertifikātu visos Windows dialoglodos, un VPN pieteikšanās joprojām var neizdoties, jo redzamība un lietojamība ir dažādas īpašības. Sertifikāts ir publisks objekts; pieteikšanās prasa privātās atslēgas darbību, ko karte veic saskaņā ar saviem piekļuves noteikumiem. Starp šiem diviem faktiem atrodas četras stadijas, kuras neizdodas četros dažādos veidos: profila izvēle, sertifikāta izvēle, vietējā parakstīšana un servera puses validācija. Sekojot tām secībā, vispārīga rokasspiediena kļūda pārvēršas par konkrētu jautājumu tam, kuram pieder nākamā daļa.

Sāciet ar profilu un EAP metodi

Atveriet savienojuma rekvizītus un izlasiet, kuru EAP metodi profils faktiski izmanto, pēc tam izlasiet, kuru sertifikātu šī metode ir konfigurēta atlasīt. Daudzos izvietojumos ir gan uz sertifikātu balstīta ārējā metode, gan iekšējā metode, un savienojuma līmenī konfigurētais sertifikāts automātiski nav tas, kas tiek uzrādīts EAP-TLS iekšienē. Ja profils izvēlas sertifikātu pēc izdevēja vai pēc subjekta filtra, šis filtrs atlasa no tā, ko Windows redz attiecīgajā krātuvē, nevis no tā, kas kartei faktiski ir. Filtrs, kas neatbilst nekam, atkarībā no profila konfigurācijas pāriet uz uzvedni vai uz klusu neizdošanos, tāpēc atlasīto nospiedumu ir vērts pierakstīt pirms jebkādām izmaiņām.

Tāpat noskaidrojiet, vai savienojums darbojas pieteiktā lietotāja vārdā vai mašīnas vārdā. Šis viens fakts nosaka, kuras sertifikātu krātuves ir iekļautas un kurš drošības konteksts veic parakstīšanu.

Pārbaudiet, kurš sertifikāts tika atlasīts

Salīdziniet nospiedumu, kuru izvēlējās Windows, ar prasībām: lietojums klienta autentifikācijai, ķēde, kas beidzas uzticamā saknē, identitāte, ko kartē autentifikācijas servera politika, un derīguma termiņš, kas aptver faktisko mēģinājuma brīdi. Tās ir atsevišķas pārbaudes, un pēdējā no tām atklāj vairāk pārsteigumu, nekā cilvēki gaida, jo īpaši ar sertifikātiem, kas izsniegti apritē, un kešotiem profiliem, kas joprojām norāda uz vakardienas izvēli.

Lietotāja un mašīnas konteksts ir pārbaudes otrā puse. Sertifikāts lietotāja personīgajā krātuvē ir neredzams pakalpojumam, kas darbojas kā mašīna, un mašīnas sertifikātu lietotāja režīma EAP apmaiņa neuzrāda, ja vien profils to neparedz. Sertifikāta atkārtota importēšana nepareizā krātuvē rada redzamu sertifikātu un neredzamu pieteikšanās akreditācijas datu kopumu. Lasiet krātuves ceļu profilā, nevis tajā dialoglodzā, kas nejauši atvērās.

Pārbaudiet atslēgas darbību, neuzminot PIN

Kad izvēle ir nokārtota, jautājums ir par to, vai karte veiks parakstīšanu. Windows ir nepieciešams atbalstīts kartes nodrošinātājs vai minidraiveris, lai piekļūtu privātajai atslēgai, un ierīce darbībai piemēro savus PIN un klātbūtnes noteikumus. Karte, kas konfigurēta prasīt pieskārienu katram parakstam, uzvedas citādi nekā tā, kas kešo verificēšanu sesijai, un abas ir likumīgas konfigurācijas, kas maina to, kad parādās uzvedne. Šī atšķirība izskaidro pieteikšanos, kas izdodas pēc svaigas ievietošanas un neizdodas pēc atsaukšanas no miega, bez jebkāda nepareiza sertifikāta.

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

Pirmā komanda inventarizē karti un ziņo lasītāja un nodrošinātāja stāvokli, kas dokumentēts Microsoft viedkaršu atkļūdošanas norādēs. Otrā uzskaita to, ko lietotāja konteksts faktiski var redzēt. Neviena no tām nepierāda veiksmīgu autentifikāciju; abas sašaurina vietu, kur tā apstājās.

Neuzminiet PIN. Kartes ievēro atkārtoto mēģinājumu ierobežojumus, un daži optimistiski mēģinājumi pārvērš atļauju problēmu bloķētos akreditācijas datos, kuru atjaunošanai nepieciešama administrācija. Ja vietējā parakstīšana neizdodas, fiksējiet nodrošinātāja statusu un kartes stāvokli, nevis izmēģiniet variācijas. Atkārtojiet mēģinājumu vienu reizi ar to pašu profilu, to pašu sertifikātu un zināmu labu lasītāja ceļu, pēc tam salīdziniet abus ierakstus; vairāku mainīgo maiņa vienlaikus rada stāstu, nevis rezultātu.

Lasiet abas rokasspiediena puses

Pabeigts paraksts joprojām nav pielaide. Autentifikācijas serverim ir jāpieņem ķēde, jāpārbauda atsaukšana, jākartē identitāte saskaņā ar tās pašreizējiem noteikumiem un jāatļauj pieprasījums; klientam savukārt jāvalidē servera sertifikāts, kā to prasa profils. Servera ģenerēts TLS brīdinājums klienta žurnālā izskatās identiski tādam, kas ģenerēts lokāli, tāpēc izstarotāja puse ir svarīgāka par brīdinājuma tekstu.

Apkopojiet Windows notikumus un servera puses notikumus ar saskaņotiem laikspiedoliem, pēc tam nosakiet, kura puse radīja pirmo kļūdu. RFC 5216 apraksta īpašumtiesību pierādīšanas soli EAP-TLS, un vispārīgs rokasspiediena brīdinājums pats par sevi nenosauc vietējo atslēgas cēloni. Laikspiedolu salīdzinājums ir tas, kas pārvērš divus žurnālus secībā.

Turiet robežas skaidri ziņojumā

Rakstiet ziņojumu kā četras stadijas ar vienu spriedumu katrai: kurš profils un konteksts darbojās, kuru sertifikātu Windows izvēlējās, vai karte parakstīja un ko serveris nolēma. Šī struktūra padara nākamo soli acīmredzamu un novērš izplatīto remontu — validācijas atspējošanu, lai tiktu garām stadijai, kuru neviens nav identificējis.

Programmatūras sertifikāts kā pagaidu salīdzinājums ir likumīgs administratora tests, taču tas maina akreditācijas datu un garantiju modeli, tāpēc tas pieder apstiprinātām izmaiņām, nevis klusam ražošanas apietam. Tā pati disciplīna attiecas uz PIN mēģinājumiem un akreditācijas datu atkārtotu izsniegšanu pirms kļūmīgās stadijas noskaidrošanas. Aizvietotā karte, kas neizdodas identiski, ir dārgs pierādījums tam, ka problēma nekad nav bijusi kartē.