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-ის მცდელობებს და სერტიფიკატების ხელახლა გაცემას, სანამ ჩავარდნილი ეტაპი ცნობილი გახდება. იდენტურად ჩავარდნილი შემცვლელი ბარათი ძვირადღირებული მტკიცებაა, რომ პრობლემა არასდროს ყოფილა ბარათზე.