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 विनंती पाठवली गेली नाही।

मॉड्यूल नाही, लॉगिन सत्यापित करा

विसंगती दुरुस्त केल्यानंतर प्रत्यक्ष प्रवेश मार्ग तपासा। वैध खाते यशस्वी व्हायला हवे, अवैध क्रेडेन्शियल अजूनही अयशस्वी व्हायला हवेत, आणि प्रतिबंधित खाते अजूनही नाकारले जायला हवे। प्रमाणपत्र किंवा अतिरिक्त घटकाची कोणतीही अट अजूनही लागू आहे याचीही खात्री करा, कारण टप्पा वगळणारा दुरुस्त केलेला स्टॅक क्लायंटच्या बाजूने यशासारखा दिसतो।

मॉड्यूल स्वच्छपणे लोड होणे ही प्रगती आहे, पूर्ण झालेली चाचणी नाही।

कोणते सेवा नाव, कोणत्या धोरण फाइल्स आणि कोणते एंट्री पॉइंट सहभागी होते ते नोंदवा, पुरावा म्हणून वापरलेल्या एकाच प्रयत्नासह। तीच नोंद पुढील घटनेला पुरातत्त्व अभ्यासाऐवजी शोधात बदलते।