PIV пријава не успева на Windows EAP-TLS? Проверите путању потписивања

Прикажите сертификат PIV картице у сваком Windows дијалогу, а VPN пријава ипак може да не успе, јер су видљивост и употребљивост различита својства. Сертификат је јавни објекат; пријава захтева операцију приватним кључем коју картица обавља по сопственим правилима приступа. Између те две чињенице стоје четири фазе које не успевају на четири различита начина: избор профила, избор сертификата, локално потписивање и провера на страни сервера. Пролазак кроз њих по реду претвара општу грешку руковања у конкретно питање за онога ко поседује следећи део.

Почните са профилом и EAP методом

Отворите својства везе и прочитајте коју EAP методу профил заиста користи, затим прочитајте који је сертификат метода подешена да изабере. Многа увођења имају и спољашњу методу засновану на сертификату и унутрашњу методу, а сертификат подешен на нивоу везе није аутоматски онај који се представља унутар EAP-TLS. Ако профил бира сертификат по издаваоцу или по филтеру субјекта, тај филтер бира из онога што Windows види у одговарајућем складишту, а не из онога што картица случајно садржи. Филтер који се ни са чим не поклапа прелази на упит или на тихи неуспех зависно од подешавања профила, зато је изабрани отисак вредан бележења пре било какве измене.

Такође утврдите да ли веза ради као пријављени корисник или као машина. Та једна чињеница одређује која су складишта сертификата у обухвату и који безбедносни контекст обавља потпис.

Потврдите који је сертификат изабран

Упоредите отисак који је Windows изабрао са захтевом: намена за проверавање идентитета клијента, ланац који се завршава у поузданом корену, идентитет који политика сервера за проверавање идентитета мапира и период важења који покрива стварни тренутак покушаја. То су одвојене провере и последња хвата више изненађења него што људи очекују, нарочито са сертификатима издатим у текућем циклусу и кешираним профилима који још показују на јучерашњи избор.

Контекст корисника и машине је друга половина провере. Сертификат у личном складишту корисника је невидљив за услугу која ради као машина, а сертификат машине се не представља разменом EAP у корисничком режиму осим ако профил то не наводи. Поновни увоз сертификата у погрешно складиште даје видљив сертификат и невидљиве пријавне податке. Читајте путању складишта у профилу, не ону у дијалогу који се случајно отворио.

Проверите рад кључа без погађања PIN-а

Када је избор утврђен, питање је да ли ће картица обавити потпис. Windows-у је потребан подржан добављач картице или минидрајвер да би дошао до приватног кључа, а уређај на операцију примењује сопствена правила PIN-а и присутности. Картица подешена да захтева додир за сваки потпис понаша се другачије од оне која кешира проверу за сесију, и обе су легитимне конфигурације које мењају када се појави упит. Та разлика објашњава пријаву која успева при свежем уметању а не успева после буђења из мировања, без иједног погрешног сертификата.

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

Прва команда пописује картицу и извештава стање читача и добављача, што је документовано у Microsoft смерницама за отклањање грешака паметних картица. Друга наводи шта кориснички контекст заиста може да види. Ниједна не доказује успешну проверу идентитета; обе сужавају где се зауставило.

Не погађајте PIN. Картице спроводе ограничења покушаја, а неколико оптимистичних покушаја претвара проблем дозвола у блокиране пријавне податке којима је потребан административни опоравак. Ако локални потпис не успе, забележите стање добављача и стање картице уместо да испробавате варијанте. Поновите покушај једном са истим профилом, истим сертификатом и познатом добром путањом читача, затим упоредите оба записа; промена више променљивих одједном даје причу, а не резултат.

Прочитајте обе стране руковања

Завршен потпис још није пријем. Сервер за проверавање идентитета мора да прихвати ланац, провери опозив, мапира идентитет по својим актуелним правилима и одобри захтев; клијент заузврат мора да провери серверов сертификат како профил захтева. TLS упозорење које генерише сервер изгледа исто у клијентовом дневнику као оно генерисано локално, зато је страна која га емитује важнија од текста упозорења.

Прикупите Windows догађаје и догађаје на страни сервера са поравнатим временским ознакама, затим утврдите која је страна произвела први неуспех. RFC 5216 описује корак доказивања поседовања у EAP-TLS, а опште упозорење руковања само по себи не именује локални узрок кључа. Упоређивање временских ознака је оно што два дневника претвара у низ.

Држите границе јасно у извештају

Напишите извештај као четири фазе са по једном пресудом: који су профил и контекст радили, који је сертификат Windows изабрао, да ли је картица потписала и шта је сервер одлучио. Та структура чини следећи корак очигледним и спречава уобичајену поправку искључивањем провере да би се прешла фаза коју нико није идентификовао.

Софтверски сертификат као привремено поређење је легитиман администраторски тест, али мења модел пријавних података и гаранција, па припада одобреној измени, а не тихом продукционом заобилажењу. Иста дисциплина важи за покушаје са PIN-ом и за поновно издавање пријавних података пре него што се сазна фаза која не успева. Заменска картица која не успева идентично скупо је доказ да проблем никада није био на картици.