Вхід за 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 і перевипуску облікових даних до того, як відомий збійний етап. Заміна картки, яка зривається так само, — дорогий доказ того, що проблема ніколи не була на картці.