A PIV-bejelentkezés meghiúsul Windowson EAP-TLS-sel? Ellenőrizze az aláírási útvonalat

Jelenítse meg egy PIV-kártya tanúsítványát minden Windows-párbeszédablakban, és a VPN-bejelentkezés mégis meghiúsulhat, mert a láthatóság és a használhatóság különböző tulajdonságok. A tanúsítvány nyilvános objektum; a bejelentkezéshez olyan privátkulcs-művelet kell, amelyet a kártya a saját hozzáférési szabályai szerint végez. E két tény között négy szakasz van, amelyek négy különböző módon hibáznak: profilválasztás, tanúsítványválasztás, helyi aláírás és kiszolgálóoldali ellenőrzés. Ezek sorrendben történő végigjárása egy általános kézfogási hibát konkrét kérdéssé alakít annak számára, akié a következő darab.

Kezdje a profillal és az EAP-módszerrel

Nyissa meg a kapcsolat tulajdonságait, és olvassa el, melyik EAP-módszert használja a profil valójában, majd olvassa el, melyik tanúsítvány kiválasztására van beállítva a módszer. Sok telepítésben van tanúsítványalapú külső módszer és belső módszer is, és a kapcsolat szintjén beállított tanúsítvány nem automatikusan az, amelyet az EAP-TLS-en belül bemutatnak. Ha a profil kibocsátó vagy tárgy szerinti szűrő alapján választ tanúsítványt, a szűrő abból választ, amit a Windows a megfelelő tárolóban lát, nem abból, ami véletlenül a kártyán van. A semmivel nem egyező szűrő a profil beállításától függően visszaesik egy kérésre vagy egy csendes hibára, ezért érdemes a kiválasztott ujjlenyomatot bármilyen változtatás előtt feljegyezni.

Azt is állapítsa meg, hogy a kapcsolat bejelentkezett felhasználóként vagy számítógépként fut-e. Ez az egyetlen tény dönti el, mely tanúsítványtárolók esnek a hatókörbe, és melyik biztonsági környezet végzi az aláírást.

Erősítse meg, melyik tanúsítvány lett kiválasztva

Hasonlítsa össze a Windows által választott ujjlenyomatot a követelménnyel: ügyfél-hitelesítési használat, megbízható gyökérben végződő lánc, a hitelesítési kiszolgáló házirendje által leképezett identitás, és a kísérlet tényleges pillanatát lefedő érvényességi idő. Ezek külön ellenőrzések, és az utolsó több meglepetést fog meg, mint amennyire az emberek számítanak, különösen folyamatosan kiadott tanúsítványok és a tegnapi választásra még mindig mutató gyorsítótárazott profilok esetén.

A felhasználói és gépi környezet az ellenőrzés másik fele. A felhasználó személyes tárolójában lévő tanúsítvány láthatatlan a számítógépként futó szolgáltatás számára, és a gépi tanúsítványt nem mutatja be a felhasználói módú EAP-csere, hacsak a profil nem mondja így. A tanúsítvány rossz tárolóba történő újraimportálása látható tanúsítványt és láthatatlan bejelentkezési hitelesítő adatot eredményez. A profilban olvassa a tároló útvonalát, ne a véletlenül megnyílt párbeszédablakét.

Tesztelje a kulcsműveletet a PIN kitalálása nélkül

Miután a kiválasztás eldőlt, a kérdés az, hogy a kártya végrehajtja-e az aláírást. A Windowsnak támogatott kártyaszolgáltatóra vagy minidriverre van szüksége a privátkulcs eléréséhez, és az eszköz a saját PIN- és jelenléti szabályait alkalmazza a műveletre. Az a kártya, amely minden aláíráshoz érintést kér, másképp viselkedik, mint az, amely egy munkamenetre gyorsítótáraz egy ellenőrzést, és mindkettő jogszerű beállítás, amely megváltoztatja, mikor jelenik meg egy kérés. Ez a különbség magyarázza azt a bejelentkezést, amely friss behelyezéskor sikerül és folytatás után meghiúsul, anélkül hogy bármely tanúsítvány hibás lenne.

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

Az első parancs leltározza a kártyát, és jelentést ad az olvasó és a szolgáltató állapotáról, amit a Microsoft okoskártya-hibakeresési útmutatója dokumentál. A második felsorolja, mit lát valójában a felhasználói környezet. Egyik sem bizonyít sikeres hitelesítést; mindkettő szűkíti, hol állt meg.

Ne találgassa a PIN-t. A kártyák korlátozzák az újrapróbálkozásokat, és néhány optimista kísérlet egy jogosultsági problémát zárolt hitelesítő adattá alakít, amely rendszergazdai helyreállítást igényel. Ha a helyi aláírás meghiúsul, rögzítse a szolgáltató állapotát és a kártya állapotát ahelyett, hogy változatokat próbálgatna. Ismételje meg a kísérletet egyszer ugyanazzal a profillal, ugyanazzal a tanúsítvánnyal és ismert jó olvasóútvonallal, majd hasonlítsa össze a két feljegyzést; több változó egyszerre történő módosítása történetet ad, nem eredményt.

Olvassa el a kézfogás mindkét oldalát

Egy befejezett aláírás még nem beengedés. A hitelesítési kiszolgálónak el kell fogadnia a láncot, ellenőriznie kell a visszavonást, le kell képeznie az identitást a jelenlegi szabályai szerint, és engedélyeznie kell a kérést; az ügyfélnek pedig a profil által megkövetelt módon ellenőriznie kell a kiszolgáló tanúsítványát. A kiszolgáló által előállított TLS-riasztás az ügyfél naplójában ugyanúgy néz ki, mint a helyben előállított, ezért a kibocsátó oldal fontosabb, mint a riasztás szövege.

Gyűjtse össze a Windows-eseményeket és a kiszolgálóoldali eseményeket összehangolt időbélyegekkel, majd állapítsa meg, melyik oldal állította elő az első hibát. Az RFC 5216 leírja a birtoklás bizonyításának lépését az EAP-TLS-ben, és egy általános kézfogási riasztás önmagában nem nevez meg helyi kulcsokot. Az időbélyegek összehasonlítása az, ami két naplót sorrenddé alakít.

Tartsa egyenesen a határokat a jelentésben

Írja meg a jelentést négy szakaszként, egy-egy ítélettel: melyik profil és környezet futott, melyik tanúsítványt választotta a Windows, aláírt-e a kártya, és mit döntött a kiszolgáló. Ez a szerkezet nyilvánvalóvá teszi a következő lépést, és megakadályozza azt a szokásos javítást, hogy kikapcsolják az ellenőrzést egy olyan szakasz átlépéséhez, amelyet senki nem azonosított.

A szoftveres tanúsítvány ideiglenes összehasonlításként jogszerű rendszergazdai teszt, de megváltoztatja a hitelesítő adat és a biztosíték modelljét, ezért jóváhagyott változtatásba tartozik, nem csendes termelési megkerülésbe. Ugyanez a fegyelem érvényes a PIN-kísérletekre és a hitelesítő adatok újrakiadására, mielőtt ismert lenne a meghiúsuló szakasz. Az azonos módon meghiúsuló cserekártya drága bizonyíték arra, hogy a probléma soha nem a kártyán volt.