OpenVPN username-as-common-name: आपकी CN जाँच खाली क्यों रहती है
common_name की username से तुलना करने वाली client-connect स्क्रिप्ट नाम की तुलना स्वयं से कर सकती है। बदलाव लागू होने से पहले प्रमाणपत्र को खाते से जोड़ें।
आप client-connect स्क्रिप्ट जोड़ते हैं जो ऐसे हर कनेक्शन को अस्वीकार करती है जहाँ common_name username से अलग हो, और यह प्रमाणपत्र तथा खाते के बीच बंधन जैसा दिखता है। username-as-common-name चलाने वाले सर्वर पर स्क्रिप्ट के चलने तक वह तुलना अपना अर्थ खो चुकी होती है। दोनों मान एक ही स्ट्रिंग हैं, इसलिए यह परीक्षण पूरी तरह किसी और को जारी किए गए प्रमाणपत्र के लिए भी पास हो जाता है।
जाँच इसलिए गलत नहीं है कि स्क्रिप्ट बुरी तरह लिखी गई है। यह इसलिए गलत है कि जो मान वह पढ़ती है वह उसी कनेक्शन में पहले बदल दिया गया था।
यह तुलना क्या सिद्ध करती दिखती है
प्रमाणपत्र प्रमाणीकरण और पासवर्ड प्रमाणीकरण अलग-अलग प्रमाण हैं, और सर्वर दोनों की माँग कर सकता है बिना यह माँगे कि वे एक ही व्यक्ति के हों। यह अंतराल वास्तविक है: एक वैध डिवाइस प्रमाणपत्र के साथ कोई भी वैध खाता उसी डिवाइस प्रमाणपत्र के साथ एक नामित खाते से अलग दावा है। common_name की username से तुलना करने वाली स्क्रिप्ट दोनों के बीच की खोई कड़ी जैसी पढ़ी जाती है। यह वैसी ही होती, अगर common_name अब भी वही अर्थ रखता जो प्रमाणपत्र कहता था।
ऐसा है या नहीं, यह एक सर्वर विकल्प पर निर्भर करता है, और वह विकल्प आमतौर पर किसी असंबंधित कारण से चालू किया जाता है, जैसे प्रति उपयोगकर्ता कॉन्फ़िगरेशन फ़ाइलों के नाम रखना आसान बनाना।
username-as-common-name नाम के साथ क्या करता है
username-as-common-name सक्षम होने पर, OpenVPN उपयोगकर्ता नाम और पासवर्ड सत्यापित होने के बाद प्रमाणपत्र के सामान्य नाम के स्थान पर प्रमाणीकृत उपयोगकर्ता नाम रख देता है। उस जाँच के दौरान चलने वाला सत्यापन हुक अब भी प्रमाणपत्र का सामान्य नाम ही प्राप्त करता है, क्योंकि बदलाव अभी हुआ ही नहीं। उसके बाद का सब कुछ, client-connect सहित, उपयोगकर्ता नाम देखता है। इसलिए बाद वाला कॉलबैक एक ही पहचान दो बार प्राप्त करता है और प्रस्तुत प्रमाणपत्र से उसकी तुलना नहीं कर सकता।
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
एक उदाहरण कनेक्शन देखें: bob-device के लिए जारी प्रमाणपत्र, alice के रूप में सफल डायरेक्टरी लॉगिन, और विकल्प सक्षम। सत्यापन चरण अब भी दो अलग स्ट्रिंग देख सकता है। कनेक्ट चरण alice और alice देखता है।
यह उदाहरण दिखाता है कि तुलना खाली क्यों है। यह नहीं दिखाता कि कनेक्शन अन्यथा स्वीकार हो जाता, क्योंकि प्रमाणपत्र सत्यापन और पासवर्ड सत्यापन अब भी अपने आप चलते हैं।
बंधन वहाँ रखें जहाँ दोनों पहचानें अब भी मौजूद हैं
नियम ऐसे चरण पर लागू होना चाहिए जो प्रमाणपत्र की पहचान और खाते को एक साथ देखे, जिसका व्यवहार में अर्थ उपयोगकर्ता नाम और पासवर्ड सत्यापन हुक या वहाँ लोड किया गया प्लगइन है। पहले से पासवर्ड सत्यापन करने वाला समर्थित प्लगइन आमतौर पर जोड़ी नियम जोड़ने की सही जगह है, क्योंकि उसे नाम की तुलना से बदलने पर पासवर्ड जाँच पूरी तरह हट जाएगी।
कोड लिखने से पहले मैपिंग परिभाषित करें, क्योंकि समानता शायद ही कभी वास्तविक नीति होती है। प्रमाणपत्र अक्सर किसी डिवाइस की पहचान करता है जबकि लॉगिन किसी व्यक्ति की, और एक डिवाइस वैध रूप से कई लोगों की सेवा कर सकता है। संबंध को ऐसे रूप में संग्रहित करें जिसका जारी करना आपके नियंत्रण में हो, और तय करें कि नाम बदलने, फिर से जारी करने और डोमेन-योग्य नामों पर क्या होगा। डायरेक्टरी को समझे बिना लोअरकेस करना या डोमेन उपसर्ग हटाना दो ऐसे खातों को जोड़ सकता है जो अलग रहने के लिए थे।
याद रखें कि विकल्प यह भी बदलता है कि कौन-सा प्रति-क्लाइंट कॉन्फ़िगरेशन लागू होता है, क्योंकि client-config-dir सामान्य नाम से जुड़ा है।
दो वैध क्रेडेंशियल के साथ जोड़ी का परीक्षण करें
उस जोड़ी से शुरू करें जिसे आपकी नीति अनुमति देती है और पुष्टि करें कि वह कनेक्ट होती है। फिर वही वैध प्रमाणपत्र किसी भिन्न पर वैध खाते के साथ प्रस्तुत करें: वह प्रयास विफल होना चाहिए, और उसे जोड़ी नियम के कारण विफल होना चाहिए, गलत टाइप किए गए पासवर्ड के कारण नहीं। गलत पासवर्ड सिद्ध करता है कि पासवर्ड जाँच काम करती है और प्रमाणपत्र-खाता नियम के बारे में कुछ नहीं कहता।
गुम प्रमाणपत्र और अमान्य प्रमाणपत्र के रास्ते भी जाँचें, और पुष्टि करें कि सर्वर प्रति-क्लाइंट सेटिंग्स के लिए कौन-सी पहचान उपयोग करता है। अगर तुलना को काम कराने का एकमात्र तरीका username-as-common-name बंद करना है, तो पहले उस बदलाव की कीमत आँकें, क्योंकि यह हर क्लाइंट की कॉन्फ़िगरेशन खोज को प्रमाणपत्र के नाम पर वापस ले जाता है।