तपाईं 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 सहित, प्रयोगकर्ताको नाम देख्छ। त्यसैले पछिको कलब्याकले एउटै पहिचान दुई पटक प्राप्त गर्छ र प्रस्तुत गरिएको प्रमाणपत्रसँग त्यसको तुलना गर्न सक्दैन।

StageWhat common_name holds
Username and password verification hookThe certificate common name, for example bob-device
After the replacementThe authenticated account, alice
client-connect callbackThe account again, alice

एउटा उदाहरण जडान हेर्नुहोस्: bob-device का लागि जारी प्रमाणपत्र, alice का रूपमा सफल डाइरेक्टरी लगइन, र विकल्प सक्षम। प्रमाणीकरण चरणले अझै दुई फरक स्ट्रिङ देख्न सक्छ। जडान चरणले alice र alice देख्छ।

त्यो उदाहरणले तुलना किन खाली छ देखाउँछ। प्रमाणपत्र प्रमाणीकरण र पासवर्ड प्रमाणीकरण अझै आफै चल्ने हुनाले जडान अन्यथा स्वीकार हुन्थ्यो कि भन्ने देखाउँदैन।

बन्धन त्यहाँ राख्नुहोस् जहाँ दुवै पहिचान अझै छन्

नियम त्यस्तो चरणमा लागू गर्नुपर्छ जसले प्रमाणपत्रको पहिचान र खाता एकैसाथ देख्छ, जसको व्यवहारमा अर्थ प्रयोगकर्ताको नाम र पासवर्ड प्रमाणीकरण हुक वा त्यहाँ लोड गरिएको प्लगइन हो। पहिले नै पासवर्ड प्रमाणीकरण गर्ने समर्थित प्लगइन सामान्यतया जोडी नियम थप्ने सही ठाउँ हो, किनकि यसलाई नामको तुलनाले प्रतिस्थापन गर्दा पासवर्ड जाँच पूर्ण रूपमा हट्न जान्छ।

कोड लेख्नु अघि म्यापिङ परिभाषित गर्नुहोस्, किनकि समानता विरलै वास्तविक नीति हुन्छ। प्रमाणपत्रले प्रायः यन्त्र पहिचान गर्छ भने लगइनले व्यक्ति, र एउटा यन्त्रले वैध रूपमा धेरैलाई सेवा दिन सक्छ। सम्बन्धलाई तपाईंले जारी गर्ने नियन्त्रण गर्ने ढाँचामा भण्डारण गर्नुहोस्, र नाम परिवर्तन, पुनः जारी र डोमेन-योग्य नामहरूमा के हुन्छ निर्णय गर्नुहोस्। डाइरेक्टरी नबुझी सानो अक्षरमा परिणत गर्ने वा डोमेन प्रिफिक्स हटाउने कामले छुट्टै रहनुपर्ने दुई खाता जोड्न सक्छ।

विकल्पले कुन प्रति-क्लाइन्ट कन्फिगरेसन लागू हुन्छ पनि परिवर्तन गर्छ भन्ने सम्झनुहोस्, किनकि client-config-dir सामान्य नामद्वारा निर्धारण गरिन्छ।

दुई वैध प्रमाण-पत्रसहित जोडीको परीक्षण गर्नुहोस्

तपाईंको नीतिले अनुमति दिने जोडीबाट सुरु गर्नुहोस् र त्यो जडान हुन्छ भनी पुष्टि गर्नुहोस्। त्यसपछि उही वैध प्रमाणपत्र अर्को तर अन्यथा वैध खातासँग प्रस्तुत गर्नुहोस्: त्यो प्रयास असफल हुनुपर्छ, र त्यो गलत टाइप गरिएको पासवर्डले होइन, जोडी नियमले असफल हुनुपर्छ। गलत पासवर्डले पासवर्ड जाँच काम गर्छ भनी प्रमाणित गर्छ र प्रमाणपत्र-खाता नियमबारे केही भन्दैन।

प्रमाणपत्र नभएको र अवैध प्रमाणपत्र भएको मार्ग पनि जाँच्नुहोस्, र सर्भरले प्रति-क्लाइन्ट सेटिङका लागि कुन पहिचान प्रयोग गर्छ पुष्टि गर्नुहोस्। यदि तुलना काम गराउने एक मात्र तरिका username-as-common-name बन्द गर्नु हो भने, पहिले त्यो परिवर्तनको लागत हेर्नुहोस्, किनकि यसले हरेक क्लाइन्टको कन्फिगरेसन खोजीलाई प्रमाणपत्रको नाममा फर्काउँछ।

सम्बन्धित लेखहरू