दोन लॉगिन तपासण्या दोन घटक नाहीत: VPN आणि RADIUS

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

दुसरे बॅकएंड प्रत्यक्षात काय सिद्ध करते

स्थानिक खात्यातील शोध सिद्ध करतो की नाव डेटाबेसमध्ये आहे आणि पासवर्ड त्याला जुळत होता। RADIUS देवाणघेवाण सिद्ध करते की RADIUS सर्व्हरने मिळालेल्या गुणधर्मांसाठी Access-Accept परत केले। दोन्हीपैकी कोणतेही विधान घटकाचा प्रकार नमूद करत नाही, कारण दोन्ही ज्ञान पडताळतात। आणि NIST चे डिजिटल ओळख मार्गदर्शक वेगवेगळ्या घटक प्रकारांची आणि त्यांच्या प्रमाणकांची गणना करते, सर्व्हर किंवा सूचनांची नाही।

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

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

AND, OR आणि फॉलबॅक वेगवेगळी उत्पादने आहेत

अंमलबजावणींची तुलना करण्यापूर्वी तुमच्या गरजेत दोन्हीचा अर्थ काय आहे ते ठरवा। AND धोरणास प्रत्येक नामनिर्देशित तपासणी उत्तीर्ण होणे आवश्यक आहे, OR धोरण यशस्वी होणारी स्वीकारते, आणि फॉलबॅक दुसरी केवळ घोषित अयशस्वी अटींमध्ये प्रयत्न करते। हे तीन व्यत्ययाच्या वेळी उलट वागतात, आणि सामान्यतः त्यापैकी एकच पुनरावलोकनाचा उद्देश असतो।

कॉन्फिगरेशन स्क्रीनवर दोन बॅकएंड नोंदी जोडल्याने उत्पादन कोणते धोरण राबवते हे उघड होत नाही। काही गेटवे प्लगइन क्रमाने शृंखलाबद्ध करतात आणि पहिल्या नकारावर थांबतात, जे प्रत्येक प्लगइन अनिवार्य असेल तेव्हाच AND असते। इतर स्थानिक खात्याला ओव्हरराइड मानतात, जे मध्यवर्ती व्यत्ययाला बायपास बनवते। विश्वासार्ह उत्तर म्हणजे प्रत्येक मार्गासाठी तुम्ही तैनात करता त्या बिल्डविरुद्ध चालवलेली नोंदवलेली नकारात्मक चाचणी।

फॉलबॅक सर्वाधिक संशयास पात्र आहे, कारण काहीतरी बिघडल्यास काम चालू ठेवण्यासाठी त्याचे अस्तित्व आहे। RADIUS उपलब्ध नसताना स्थानिक पासवर्ड स्वीकारणारा फॉलबॅक मध्यवर्ती धोरणाचे दुसऱ्या, कमकुवत दारात रूपांतर करतो।

OpenVPN ची दुहेरी तपासणी हे ठोस उदाहरण आहे

समुदाय OpenVPN 2.6 दोन्ही सक्षम असताना क्लायंट प्रमाणपत्र आणि कॉन्फिगर केलेली auth-user-pass-verify स्क्रिप्ट दोन्हीची आवश्यकता ठेवतो। हे प्रमाणपत्र पडताळणी आणि ओळखपत्र स्क्रिप्टमधील नोंदवलेले AND आहे, आणि खरोखर दोन तपासण्या आहेत। तरीही ते स्वयंचलितपणे दोन घटक प्रकार नाही, कारण स्क्रिप्ट केवळ पासवर्ड पडताळू शकते।

संयोजन जोडणीचा प्रश्नही खुला ठेवते। प्रमाणपत्र सामान्यतः उपकरणाची ओळख करते तर ओळखपत्रे व्यक्तीची, आणि डीफॉल्ट प्रवाहात दोन्ही एकाच प्रमुखाचा संदर्भ द्यावा अशी काहीही आवश्यकता नाही। कोणत्या जोड्या परवानगीच्या आहेत ते ठरवा, नंतर तो नकाशा पडताळणी स्क्रिप्टमध्ये किंवा नंतरच्या अधिकृतता टप्प्यात लागू करा।

केवळ-प्रमाणपत्र मोड ही एकच तपासणी आहे, जी PIN ने संरक्षित असू शकते किंवा नाही अशा किल्लीवर आधारित आहे। PIN त्याच ओळखपत्राचे ज्ञान अधिक ताबा करते केवळ तेव्हाच जेव्हा किल्ली त्याशिवाय वापरता येत नाही। ती किल्ली डिस्कवर एन्क्रिप्ट न करता ठेवल्यास दुसरा भाग फाइल परवानगीपर्यंत घटतो।

उपकरण उत्पादक स्वतःचे प्लंबिंग बनवतात, बहुतेक वेब कन्सोलमागे PAM मॉड्यूल किंवा RADIUS प्लगइन। समुदायाचे वर्तन दुहेरी तपासण्या कशा दिसतात याचा संदर्भ आहे, उपकरण त्यांचे संयोजन कसे करते याचे वर्णन नाही।

तुमच्या गेटवेवर संयोजन तपासा

कन्सोल सारांशावर विश्वास ठेवण्यापूर्वी कॉन्फिगरेशन वाचा। धोरण ठरवणाऱ्या ओळी प्रमाणपत्र मोड, ओळखपत्र स्क्रिप्ट आणि प्लगइन क्रम आहेत।

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep दाखवते की प्रमाणपत्र आवश्यक आहे का आणि त्यानंतर कोणती स्क्रिप्ट चालते, आणि क्रम नावे सुचवतात त्यापेक्षा अधिक महत्त्वाचा आहे। प्रमाणपत्राचा डंप गेटवे जी ओळख पाहील ती देतो, जोडणी नकाशासाठी आवश्यक CN आणि क्रमांकासह। RADIUS चाचणी नकारात्मक प्रकरण आहे: चुकीच्या पासवर्डने Access-Reject आणि बरोबरने Access-Accept यायला हवे। नाकारलेले ओळखपत्र तरीही सत्र देत असेल, तर स्क्रिप्ट प्रमाणीकरण मार्गावरच नाही।

नंतर प्रयोगशाळेच्या उदाहरणावर व्यत्ययाचे प्रकरण चालवा: आवश्यक बॅकएंड थांबवा आणि वैध ओळखपत्रांसह जोडा। अपेक्षित निकाल नकार आहे, आणि बाकी काहीही हे कोणीही नोंदवले नसलेले फॉलबॅक धोरण आहे।

गरज नकारात्मक प्रकरणे म्हणून लिहा

वापरण्यायोग्य गरज पुरावे, ते सादर करण्यास अधिकृत खाती आणि पडताळणीकर्ता नसल्यास निकाल यांची नावे देते। उपकरण ओळख आणि व्यक्ती ओळख यांतील परवानगीची जोडीही सांगते। हे खरेदी आदेशावरील उत्पादन नावांपेक्षा अधिक अचूक आहे, आणि ते तपासता येते।

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

कोणत्याही प्लगइन किंवा फर्मवेअर बदलानंतर चार नकार पुन्हा चालवा। ते स्वस्त आहेत, आणि ते जे धोरण संरक्षित करतात तेच हल्लेखोर प्रथम तपासतो।