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 प्रयासों और विफल चरण ज्ञात होने से पहले क्रेडेंशियल फिर से जारी करने पर लागू होता है। समान रूप से विफल होने वाला प्रतिस्थापन कार्ड महँगा प्रमाण है कि समस्या कभी कार्ड पर नहीं थी।