Windows-এ EAP-TLS দিয়ে PIV লগইন ব্যর্থ? সাইনিং পথটি যাচাই করুন

প্রতিটি Windows ডায়ালগে PIV কার্ডের সার্টিফিকেট দেখানো যায়, তবুও 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 প্রচেষ্টা এবং ব্যর্থ ধাপ জানার আগে ক্রেডেনশিয়াল পুনরায় ইস্যু করার ক্ষেত্রেও প্রযোজ্য। অভিন্নভাবে ব্যর্থ প্রতিস্থাপন কার্ড একটি ব্যয়বহুল প্রমাণ যে সমস্যাটি কখনোই কার্ডে ছিল না।