Log masuk PIV gagal pada Windows EAP-TLS? Semak laluan tandatangan

Tunjukkan sijil kad PIV dalam setiap dialog Windows dan log masuk VPN masih boleh gagal, kerana keterlihatan dan kebolehgunaan ialah sifat yang berbeza. Sijil ialah objek awam; log masuk memerlukan operasi kunci peribadi yang dilakukan oleh kad di bawah peraturan aksesnya sendiri. Antara dua fakta itu terletak empat peringkat yang gagal dalam empat cara berbeza: pemilihan profil, pemilihan sijil, tandatangan setempat dan pengesahan di sebelah pelayan. Menelusurinya mengikut urutan menukar ralat jabat tangan generik menjadi soalan khusus bagi sesiapa yang memiliki bahagian seterusnya.

Mulakan dengan profil dan kaedah EAP

Buka sifat sambungan dan baca kaedah EAP yang sebenarnya digunakan oleh profil, kemudian baca sijil yang dikonfigurasikan untuk dipilih oleh kaedah itu. Banyak pemasangan mempunyai kaedah luar berasaskan sijil dan kaedah dalam, dan sijil yang dikonfigurasikan pada peringkat sambungan tidak secara automatik menjadi sijil yang dibentangkan di dalam EAP-TLS. Jika profil memilih sijil mengikut pengeluar atau mengikut penapis subjek, penapis itu memilih daripada apa yang Windows boleh lihat dalam stor berkaitan, bukan daripada apa yang kebetulan ada pada kad. Penapis yang tidak sepadan dengan apa-apa akan beralih kepada gesaan atau kegagalan senyap bergantung pada konfigurasi profil, sebab itulah cap jari yang dipilih wajar direkodkan sebelum sebarang perubahan.

Tentukan juga sama ada sambungan berjalan sebagai pengguna yang log masuk atau sebagai mesin. Fakta tunggal itu menentukan stor sijil mana yang dalam skop dan konteks keselamatan mana yang melakukan tandatangan.

Sahkan sijil mana yang dipilih

Bandingkan cap jari yang dipilih Windows dengan keperluan: penggunaan pengesahan pelanggan, rantai yang berakhir pada akar dipercayai, identiti yang dipetakan oleh dasar pelayan pengesahan, dan tempoh sah yang meliputi saat percubaan yang sebenar. Itu adalah semakan berasingan dan yang terakhir menangkap lebih banyak kejutan daripada yang dijangka orang, terutamanya dengan sijil yang dikeluarkan secara bergilir dan profil cache yang masih menunjuk kepada pilihan semalam.

Konteks pengguna dan mesin ialah separuh lagi semakan. Sijil dalam stor peribadi pengguna tidak kelihatan kepada perkhidmatan yang berjalan sebagai mesin, dan sijil mesin tidak dibentangkan oleh pertukaran EAP mod pengguna melainkan profil menyatakannya. Mengimport semula sijil ke dalam stor yang salah menghasilkan sijil yang kelihatan dan kelayakan log masuk yang tidak kelihatan. Baca laluan stor dalam profil, bukan yang ada dalam dialog yang kebetulan terbuka.

Uji operasi kunci tanpa meneka PIN

Setelah pemilihan selesai, soalannya ialah sama ada kad akan melakukan tandatangan. Windows memerlukan penyedia kad atau pemandu mini yang disokong untuk mencapai kunci peribadi, dan peranti menggunakan peraturan PIN dan kehadirannya sendiri pada operasi itu. Kad yang dikonfigurasikan untuk memerlukan sentuhan bagi setiap tandatangan berkelakuan berbeza daripada kad yang menyimpan pengesahan untuk sesi, dan kedua-duanya konfigurasi sah yang mengubah bila gesaan muncul. Perbezaan itu menjelaskan log masuk yang berjaya selepas pemasukan baru dan gagal selepas sambung semula, tanpa sebarang sijil yang salah.

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

Perintah pertama menyenaraikan kad dan melaporkan keadaan pembaca dan penyedia, yang didokumenkan dalam panduan nyahpepijat kad pintar Microsoft. Yang kedua menyenaraikan apa yang sebenarnya boleh dilihat oleh konteks pengguna. Kedua-duanya tidak membuktikan pengesahan yang berjaya; kedua-duanya menyempitkan tempat ia berhenti.

Jangan teka PIN. Kad menguatkuasakan had cubaan semula, dan beberapa cubaan optimistik menukar masalah kebenaran menjadi kelayakan tersekat yang memerlukan pemulihan pentadbir. Jika tandatangan setempat gagal, rakam status penyedia dan keadaan kad dan bukan mencuba variasi. Ulang percubaan sekali dengan profil yang sama, sijil yang sama dan laluan pembaca yang diketahui baik, kemudian bandingkan kedua-dua rekod; menukar beberapa pemboleh ubah sekali gus menghasilkan cerita dan bukan hasil.

Baca kedua-dua belah jabat tangan

Tandatangan yang selesai masih bukan kemasukan. Pelayan pengesahan mesti menerima rantai, menyemak pembatalan, memetakan identiti di bawah peraturan semasanya dan membenarkan permintaan; pelanggan pula mesti mengesahkan sijil pelayan seperti yang dikehendaki oleh profil. Amaran TLS yang dijana oleh pelayan kelihatan sama dalam log pelanggan dengan yang dijana secara setempat, sebab itulah bahagian yang memancarkannya lebih penting daripada teks amaran.

Kumpulkan peristiwa Windows dan peristiwa sebelah pelayan dengan cap masa yang sejajar, kemudian kenal pasti bahagian mana yang menghasilkan kegagalan pertama. RFC 5216 menerangkan langkah bukti pemilikan dalam EAP-TLS, dan amaran jabat tangan generik tidak menamakan punca kunci setempat dengan sendirinya. Perbandingan cap masa itulah yang menukar dua log menjadi satu urutan.

Kekalkan sempadan dengan betul dalam laporan

Tulis laporan sebagai empat peringkat dengan satu keputusan setiap satu: profil dan konteks mana yang berjalan, sijil mana yang dipilih Windows, sama ada kad menandatangani, dan apa yang diputuskan oleh pelayan. Struktur itu menjadikan langkah seterusnya jelas dan menghalang pembaikan biasa iaitu mematikan pengesahan untuk melepasi peringkat yang tidak dikenal pasti oleh sesiapa.

Sijil perisian sebagai perbandingan sementara ialah ujian pentadbir yang sah, tetapi ia mengubah model kelayakan dan jaminan, jadi ia tergolong dalam perubahan yang diluluskan dan bukan penyelesaian pengeluaran yang senyap. Disiplin yang sama terpakai pada cubaan PIN dan pada pengeluaran semula kelayakan sebelum peringkat yang gagal diketahui. Kad pengganti yang gagal secara sama ialah bukti mahal bahawa masalah itu tidak pernah ada pada kad.