Prihlásenie cez PIV zlyháva vo Windows EAP-TLS? Skontrolujte cestu podpisovania

Zobrazte certifikát karty PIV v každom dialógovom okne Windows a prihlásenie do VPN môže stále zlyhať, pretože viditeľnosť a použiteľnosť sú odlišné vlastnosti. Certifikát je verejný objekt; prihlásenie vyžaduje operáciu so súkromným kľúčom, ktorú karta vykoná podľa svojich vlastných pravidiel prístupu. Medzi týmito dvoma faktami ležia štyri fázy, ktoré zlyhávajú štyrmi rôznymi spôsobmi: výber profilu, výber certifikátu, lokálne podpisovanie a overenie na strane servera. Prechod cez ne v poradí mení všeobecnú chybu podania ruky na konkrétnu otázku pre toho, kto vlastní ďalší diel.

Začnite profilom a metódou EAP

Otvorte vlastnosti pripojenia a prečítajte, ktorú metódu EAP profil skutočne používa, potom prečítajte, ktorý certifikát je metóda nastavená vyberať. Mnohé nasadenia majú vonkajšiu metódu založenú na certifikáte aj vnútornú metódu a certifikát nastavený na úrovni pripojenia nie je automaticky ten, ktorý sa predkladá vnútri EAP-TLS. Ak profil vyberá certifikát podľa vydavateľa alebo podľa filtra subjektu, tento filter vyberá z toho, čo Windows vidí v príslušnom úložisku, nie z toho, čo karta náhodou obsahuje. Filter, ktorý nič nezodpovedá, prejde na výzvu alebo na tiché zlyhanie podľa konfigurácie profilu, a preto sa vybraný odtlačok oplatí zaznamenať pred akoukoľvek zmenou.

Zistite aj, či pripojenie beží ako prihlásený používateľ alebo ako počítač. Tento jediný fakt určuje, ktoré úložiská certifikátov sú v rozsahu a ktorý bezpečnostný kontext vykonáva podpis.

Potvrďte, ktorý certifikát bol vybraný

Porovnajte odtlačok, ktorý Windows vybral, s požiadavkou: použitie na overenie klienta, reťaz končiaca v dôveryhodnom koreni, identita, ktorú mapuje politika overovacieho servera, a obdobie platnosti pokrývajúce skutočný okamih pokusu. To sú samostatné kontroly a posledná zachytí viac prekvapení, než ľudia očakávajú, najmä pri certifikátoch vydávaných priebežne a pri profiloch v medzipamäti, ktoré stále ukazujú na včerajší výber.

Kontext používateľa a počítača je druhá polovica kontroly. Certifikát v osobnom úložisku používateľa je neviditeľný pre službu bežiacu ako počítač, a certifikát počítača sa nepredkladá výmenou EAP v používateľskom režime, ak to profil neuvádza. Opätovný import certifikátu do nesprávneho úložiska vytvorí viditeľný certifikát a neviditeľný prihlasovací údaj. Čítajte cestu úložiska v profile, nie tú v dialógovom okne, ktoré sa náhodou otvorilo.

Otestujte operáciu kľúča bez hádania PIN

Keď je výber ustálený, otázkou je, či karta podpis vykoná. Windows potrebuje podporovaného poskytovateľa karty alebo minidriver, aby sa dostal k súkromnému kľúču, a zariadenie na operáciu uplatňuje vlastné pravidlá PIN a prítomnosti. Karta nastavená tak, aby vyžadovala dotyk pri každom podpise, sa správa inak ako karta, ktorá overenie ukladá do medzipamäti pre reláciu, a obe sú legitímne konfigurácie, ktoré menia, kedy sa objaví výzva. Ten rozdiel vysvetľuje prihlásenie, ktoré uspeje po čerstvom vložení a zlyhá po obnovení, bez toho, aby bol niektorý certifikát nesprávny.

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

Prvý príkaz zinventarizuje kartu a nahlási stav čítačky a poskytovateľa, čo je zdokumentované v usmerneniach Microsoftu na ladenie čipových kariet. Druhý uvádza, čo kontext používateľa skutočne vidí. Ani jeden nepreukazuje úspešné overenie; oba zúžujú miesto, kde sa to zastavilo.

Nehádajte PIN. Karty vynucujú limity opakovaných pokusov a niekoľko optimistických pokusov premení problém oprávnení na zablokovaný prihlasovací údaj, ktorý vyžaduje administratívnu obnovu. Ak lokálny podpis zlyhá, zaznamenajte stav poskytovateľa a stav karty namiesto skúšania variantov. Zopakujte pokus raz s tým istým profilom, tým istým certifikátom a známou dobrou cestou čítačky, potom porovnajte oba záznamy; zmena viacerých premenných naraz vytvorí príbeh, nie výsledok.

Prečítajte obe strany podania ruky

Dokončený podpis ešte nie je prijatie. Overovací server musí prijať reťaz, skontrolovať odvolanie, namapovať identitu podľa svojich aktuálnych pravidiel a autorizovať požiadavku; klient zase musí overiť certifikát servera tak, ako to vyžaduje profil. Upozornenie TLS vytvorené serverom vyzerá v logu klienta rovnako ako to vytvorené lokálne, a preto je strana, ktorá ho vydala, dôležitejšia než text upozornenia.

Zozbierajte udalosti Windows a udalosti na strane servera so zosúladenými časovými značkami a potom určite, ktorá strana vytvorila prvé zlyhanie. RFC 5216 opisuje krok dokazovania vlastníctva v EAP-TLS a všeobecné upozornenie podania ruky samo o sebe nepomenúva lokálnu príčinu kľúča. Práve porovnanie časových značiek mení dva logy na postupnosť.

Držte hranice v správe rovno

Napíšte správu ako štyri fázy s jedným verdiktom pre každú: ktorý profil a kontext bežal, ktorý certifikát Windows vybral, či karta podpísala a čo rozhodol server. Taká štruktúra robí ďalší krok zjavným a zabraňuje bežnej oprave vypnutím overovania, aby sa prešla fáza, ktorú nikto neidentifikoval.

Softvérový certifikát ako dočasné porovnanie je legitímny administratívny test, ale mení model prihlasovacích údajov a záruk, preto patrí do schválenej zmeny a nie do tichého produkčného obchádzania. Rovnaká disciplína platí pre pokusy s PIN a pre opätovné vydanie údajov predtým, než je známa zlyhávajúca fáza. Náhradná karta, ktorá zlyhá rovnako, je drahý dôkaz, že problém nikdy nebol na karte.