PAM मोड्युल अज्ञात छ: वास्तवमा कुन प्रक्रिया असफल भयो
सन्देशले साझा वस्तु र प्रवेश बिन्दुको नाम दिन्छ, पासवर्डको होइन। यसलाई लग गर्ने प्रक्रिया खोज्नुहोस्, त्यसपछि लोडिङ, प्रतीक र स्ट्याकका ग्यारेन्टी जाँच्नुहोस्।
त्यो वाक्यांशलाई पासवर्डको बारेमा नभई साझा वस्तु र फंक्शन सूचकको बारेमा भनिएको कथनका रूपमा पढ्नुहोस्। ती शब्दहरू एउटा OpenVPN प्लगइनबाट, एउटै सेवाका लागि लोड गरिएको PAM स्ट्याकबाट, वा RADIUS डेमनको भित्रबाट आउन सक्छन्, र यी तीन फरक अनुसन्धान हुन्। पहिले प्रक्रिया निर्धारण गर्नुहोस्।
तलका जाँचहरूले सन्देश VPN लगइनमा Linux-PAM एकीकरणमार्फत आएको मान्छ। यदि यो RADIUS सर्भरको आफ्नै कन्फिगरेसनबाट आएको हो भने, त्यही डेमनको प्रमाणबाट सुरु गर्नुहोस्।
प्याकेजको नाम लिनुअघि प्रक्रियाको नाम लिनुहोस्
तीन घटकलाई मोड्युल भनिन्छ र तीमध्ये कुनै पनि अदलबदल गर्न मिल्दैन। OpenVPN प्रमाणीकरण प्लगइन VPN डेमनले लोड गर्छ र त्यो डेमनको कलब्याक इन्टरफेस लागू गर्छ। PAM मोड्युल एउटा साझा वस्तु हो, जसलाई libpam ले नामित सेवाका लागि लोड गर्छ, र जसले यस्ता प्रवेश बिन्दुहरू लागू गर्छ: pam_sm_authenticate। FreeRADIUS मोड्युल त्यो डेमनको आफ्नै कन्फिगरेसनको भाग हो। एउटै शब्द भएको सन्देश तीनमध्ये कुनैबाट पनि आउन सक्छ, त्यसैले पहिलो प्रश्न कुन लग लाइनले यो उत्पन्न गर्यो भन्ने हो।
एक असफल प्रयासको समयछाप VPN लग र प्रणाली प्रमाणीकरण लगबीच मिलाउनुहोस्, त्यसपछि सारांशअघिका लाइनहरू पढ्नुहोस्। विशिष्ट लोडर सन्देश सामान्यतया त्यहीँ पहिले नै हुन्छ।
लोडिङ त्रुटि पढ्नुहोस्, त्यसपछि प्रवेश बिन्दु
PAM ले अज्ञात मोड्युलको रिपोर्ट तब गर्छ जब यो चयन गरिएको साझा वस्तु लोड गर्न सक्दैन, वा जब लोड गरिएको वस्तुले त्यो स्ट्याक प्रविष्टिले आवश्यक ठान्ने फंक्शन उपलब्ध गराउँदैन। यी फरक मर्मत हुन्: पहिलो मार्ग, प्याकेजिङ वा ABI को समस्या हो, र दोस्रो नमिल्ने प्रवेश बिन्दु हो। प्रमाणीकरण लाइनलाई आवश्यक छ pam_sm_authenticate तर खाता लाइनलाई आवश्यक छ pam_sm_acct_mgmt, र जुन पुस्तकालयले तीमध्ये एउटा मात्र लागू गर्छ त्यो अर्कोमा असफल हुन्छ, जसरी पठाउनेको कोड देखाउँछ। डिस्कमा फाइल भेट्नुले दुवैलाई प्रमाणित गर्दैन।
अर्को वितरण वा CPU आर्किटेक्चरबाट समान नामको पुस्तकालय लिनु मर्मत होइन, र यसले प्रक्रियालाई आफ्नो libpam विरुद्ध कहिल्यै परीक्षण नगरिएको मोड्युल लोड गरिरहन छोड्न सक्छ। केही परिवर्तन गर्नुअघि इच्छित मार्गको मालिक प्याकेज र फाइलको वास्तविक आर्किटेक्चर जाँच्नुहोस्।
स्ट्याकले दिइरहेका ग्यारेन्टी कायम राख्नुहोस्
यो त्रुटि सुस्ताउने सबैभन्दा छिटो उपाय सबैभन्दा नराम्रो पनि हो: आवश्यक मोड्युललाई वैकल्पिक चिन्ह लगाउनु, खाता चरण मेटाउनु, वा बिनासर्त अनुमति घुसाउनु। यीमध्ये प्रत्येकले असफल जाँचलाई अनुपस्थित जाँचमा बदल्छ, र त्यसपछि लगइन कसैले नचाहेका कारणले सफल हुन्छ। पासवर्ड रिसेट र साझा गोप्य परिवर्तनले पनि हराएको फंक्शन दिँदैन, किनकि असफलता कुनै पनि प्रमाण ब्याकएन्डसम्म पुग्नुअघि नै हुन्छ।
बहु-मोड्युल स्ट्याकले असफल प्रविष्टिअघि अर्को ब्याकएन्ड चलाएको हुन सक्छ, त्यसैले यो त्रुटिले कुनै RADIUS अनुरोध नपठाइएको प्रमाणित गर्दैन।
मोड्युल होइन, लगइन प्रमाणित गर्नुहोस्
विसंगति सुधारिएपछि वास्तविक प्रवेश मार्ग परीक्षण गर्नुहोस्। मान्य खाता सफल हुनुपर्छ, अमान्य प्रमाणहरू अझै असफल हुनुपर्छ, र निषेधित खाता अझै अस्वीकार हुनुपर्छ। प्रमाणपत्र वा थप कारकको कुनै पनि आवश्यकता अझै लागू छ भनी पुष्टि गर्नुहोस्, किनकि चरण छोड्ने मर्मत गरिएको स्ट्याक ग्राहकको तर्फबाट सफलताजस्तो देखिन्छ।
मोड्युल सफा रूपमा लोड हुनु प्रगति हो, पूरा भएको परीक्षण होइन।
कुन सेवा नाम, कुन नीति फाइलहरू र कुन प्रवेश बिन्दुहरू संलग्न थिए भनी प्रमाणका रूपमा प्रयोग गरिएको एक मात्र प्रयाससँगै अभिलेख गर्नुहोस्। त्यही अभिलेखले अर्को घटनालाई पुरातात्विक अभ्यासको सट्टा खोज बनाउँछ।