Přihlášení PIV ve Windows selhává u EAP-TLS? Prověřte cestu podpisu

Zobrazte certifikát karty PIV v každém dialogu Windows a přihlášení k VPN může přesto selhat, protože viditelnost a použitelnost jsou různé vlastnosti. Certifikát je veřejný objekt; přihlášení potřebuje operaci se soukromým klíčem, kterou provádí karta podle vlastních pravidel přístupu. Mezi těmito dvěma skutečnostmi leží čtyři fáze, které selhávají čtyřmi různými způsoby: volba profilu, volba certifikátu, místní podpis a ověření na straně serveru. Jejich postupné projití promění obecnou chybu handshake v konkrétní otázku pro toho, kdo vlastní další díl.

Začněte profilem a metodou EAP

Otevřete vlastnosti připojení a přečtěte si, kterou metodu EAP profil skutečně používá, poté si přečtěte, který certifikát je metoda nakonfigurována vybírat. Mnohá nasazení mají jak vnější metodu založenou na certifikátu, tak vnitřní metodu, a certifikát nakonfigurovaný na úrovni připojení není automaticky ten, který se předkládá uvnitř EAP-TLS. Pokud profil vybírá certifikát podle vydavatele nebo podle filtru subjektu, tento filtr vybírá z toho, co Windows vidí v příslušném úložišti, ne z toho, co karta náhodou obsahuje. Filtr, který ničemu neodpovídá, se podle konfigurace profilu vrátí k výzvě nebo k tichému selhání, a proto se vyplatí vybraný otisk zaznamenat před jakoukoli změnou.

Zjistěte také, zda připojení běží jako přihlášený uživatel, nebo jako počítač. Tato jediná skutečnost určuje, která úložiště certifikátů jsou v rozsahu a který bezpečnostní kontext podpis provádí.

Potvrďte, který certifikát byl vybrán

Porovnejte otisk, který Windows vybral, s požadavkem: použití pro ověřování klienta, řetězec končící v důvěryhodném kořeni, identita, kterou mapuje zásada ověřovacího serveru, a doba platnosti pokrývající skutečný okamžik pokusu. To jsou oddělené kontroly a poslední z nich zachytí více překvapení, než lidé čekají, zejména u certifikátů vydávaných průběžně a u profilů v mezipaměti, které stále ukazují na včerejší volbu.

Kontext uživatele a počítače je druhá polovina kontroly. Certifikát v osobním úložišti uživatele je neviditelný pro službu běžící jako počítač, a certifikát počítače nepředkládá výměna EAP v uživatelském režimu, pokud to profil neříká. Opětovný import certifikátu do špatného úložiště vytvoří viditelný certifikát a neviditelný přihlašovací údaj. Čtěte cestu úložiště v profilu, ne tu v dialogu, který se náhodou otevřel.

Otestujte operaci s klíčem, aniž byste hádali PIN

Jakmile je volba vyřešena, otázkou je, zda karta podpis provede. Windows potřebuje podporovaného poskytovatele karty nebo minidriver, aby dosáhl soukromého klíče, a zařízení na operaci uplatňuje vlastní pravidla PIN a přítomnosti. Karta nastavená tak, aby vyžadovala dotyk u každého podpisu, se chová jinak než karta, která ukládá ověření pro relaci, a obě jsou legitimní konfigurace, které mění, kdy se objeví výzva. Tento rozdíl vysvětluje přihlášení, které uspěje při čerstvém vložení a selže po obnovení, aniž by byl jakýkoli certifikát špatný.

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

První příkaz inventarizuje kartu a hlásí stav čtečky a poskytovatele, což je zdokumentováno v návodu Microsoftu k ladění čipových karet. Druhý vypisuje, co uživatelský kontext skutečně vidí. Ani jeden neprokazuje úspěšné ověření; oba zužují, kde se to zastavilo.

Nehádejte PIN. Karty vynucují limity opakování a několik optimistických pokusů promění problém s oprávněním v zablokovaný přihlašovací údaj, který vyžaduje administrativní obnovu. Pokud místní podpis selže, zaznamenejte stav poskytovatele a stav karty místo zkoušení variant. Pokus zopakujte jednou se stejným profilem, stejným certifikátem a známou dobrou cestou čtečky, poté oba záznamy porovnejte; změna několika proměnných najednou dává příběh, ne výsledek.

Čtěte obě strany handshake

Dokončený podpis ještě není vpuštění. Ověřovací server musí přijmout řetězec, zkontrolovat odvolání, namapovat identitu podle svých aktuálních pravidel a autorizovat požadavek; klient naopak musí ověřit certifikát serveru, jak profil vyžaduje. Upozornění TLS vytvořené serverem vypadá v klientském protokolu stejně jako to vytvořené místně, a proto je strana, která ho vydala, důležitější než text upozornění.

Shromážděte události Windows a události na straně serveru se srovnanými časovými razítky, poté určete, která strana vytvořila první selhání. RFC 5216 popisuje krok prokázání držení v EAP-TLS a obecné upozornění handshake samo o sobě nepojmenovává místní příčinu související s klíčem. Právě srovnání časových razítek mění dva protokoly v posloupnost.

Držte hranice jasné ve zprávě

Napište zprávu jako čtyři fáze s jedním verdiktem u každé: který profil a kontext běžely, který certifikát Windows vybral, zda karta podepsala a co rozhodl server. Tato struktura zpřehlední další krok a zabrání obvyklé opravě spočívající ve vypnutí ověřování, aby se prošla fáze, kterou nikdo neidentifikoval.

Softwarový certifikát jako dočasné srovnání je legitimní test správce, ale mění model přihlašovacích údajů i záruky, takže patří do schválené změny, ne do tichého produkčního obchvatu. Stejná disciplína platí pro pokusy s PIN a pro opětovné vydání údajů dřív, než je známa selhávající fáze. Náhradní karta, která selhává stejně, je drahý důkaz, že problém nikdy nebyl na kartě.