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 प्रयास र असफल चरण थाहा हुनुअघि प्रमाण पुनः जारी गर्न लागू हुन्छ। समान रूपमा असफल हुने प्रतिस्थापन कार्ड समस्या कहिल्यै कार्डमा थिएन भन्ने महँगो प्रमाण हो।