Уваход па 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 і перазапісу ўліковых даных да таго, як вядомы этап збою. Зменная картка, якая збойвае гэтак жа, — дарагое сведчанне таго, што праблема ніколі не была на картцы.