VPN उपयोगकर्ता का नामांकन: पहले पहचान का स्वामी खोजें

कोई VPN पहुँच माँगता है, और पहली प्रवृत्ति सर्वर पर adduser चलाने की होती है। यह प्रवृत्ति केवल कुछ गिने-चुने परिनियोजनों में सही है। कुछ भी बनाने से पहले, सर्वर का कॉन्फ़िगरेशन खोलें और पता करें कि वहाँ कौन सा उत्पाद चलता है और वह क्रेडेंशियल कहाँ सत्यापित करता है, क्योंकि खाता उत्पाद के डेटाबेस में, किसी पहचान प्रदाता के पास या मेज़बान की अपनी प्रमाणीकरण स्टैक में रह सकता है। गलत प्रकार का खाता बनाने से व्यक्ति के पास काम करता लॉगिन रहता है और टनल नहीं।

जो क्लाइंट प्रोफ़ाइल OpenVPN कहती है, वह प्रोटोकॉल का वर्णन करती है, उसके पीछे की पहचान प्रणाली का नहीं।

adduser से नहीं, सर्वर से शुरू करें

पहले उत्पाद की पहचान करें। Community OpenVPN वह डेमॉन है जिसमें आपने जो भी प्रमाणीकरण जोड़ा है, जबकि Access Server अपनी अलग उपयोगकर्ता परत वाला उत्पाद है। कॉन्फ़िगरेशन, यूनिट का नाम और पैकेज सूची माँगें, और जाँचें कि उपयोगकर्ता प्रबंधन के लिए कोई वेब इंटरफ़ेस है या नहीं। फिर देखें कि तैनात प्रोफ़ाइल क्लाइंट से कैसे अपनी पहचान साबित करने की अपेक्षा करती है: प्रमाणपत्र, उपयोगकर्ता नाम और पासवर्ड, या दोनों। वही उत्तर उस प्रणाली का नाम बताता है जो खाते की स्वामी है।

उसके बाद ही उपयोगकर्ता बनाने का वाक्यांश अर्थ रखता है। केवल प्रमाणपत्र वाले परिनियोजन में इसका अर्थ स्वीकृत प्रक्रिया से डिवाइस पहचान जारी करना है, और Unix लॉगिन कुछ नहीं बदलता। पासवर्ड वाले परिनियोजन में इसका अर्थ वह बैकएंड है जो वास्तव में पासवर्ड सत्यापित करता है।

चार बैकएंड, खाता बनाने के चार स्थान

Access Server का स्थानीय प्रमाणीकरण खातों को अपने डेटाबेस में रखता है, इसलिए उन्हें बनाने का इंटरफ़ेस मेज़बान का नहीं, उत्पाद का है। PAM सत्यापन का भार ऑपरेटिंग सिस्टम की स्टैक को सौंपता है, इसीलिए स्थानीय Unix खाता नामांकन का हिस्सा हो सकता है जब सेवा ने वही स्टैक चुना हो। LDAP, RADIUS और SAML सत्यापन को बाहरी सेवा में ले जाते हैं, जहाँ प्रोविज़निंग, पासवर्ड नीति और MFA रहते हैं। Access Server चारों स्थितियों में प्रति-उपयोगकर्ता प्रमाणपत्र और अनुमतियाँ रख सकता है, और यही विभाजन को उलझन भरा बनाता है।

इस विशिष्ट उपयोगकर्ता के लिए प्रभावी विधि जाँचें, वैश्विक डिफ़ॉल्ट नहीं। Access Server 2.10 और बाद के संस्करण समूह या उपयोगकर्ता के अनुसार अलग-अलग प्रमाणीकरण विधियाँ लागू कर सकते हैं, इसलिए डिफ़ॉल्ट स्थानीय होना यह साबित नहीं करता कि आपके सामने का खाता स्थानीय रूप से सत्यापित होता है।

अधिकार एक अलग निर्णय है

प्रमाणीकरण बताता है व्यक्ति कौन है; अधिकार बताता है वह कहाँ तक पहुँच सकता है। इन्हें दो चरणों के रूप में रखें, क्योंकि सफल लॉगिन अनुदान नहीं है। इच्छित रूट, संसाधन अनुमतियाँ और प्रशासनिक अधिकार जानबूझकर दें, और पुष्टि करें कि असंबंधित पहुँच अस्वीकृत ही रहती है। जहाँ परिनियोजन व्यक्तिगत पहचान का समर्थन करता है, वहाँ किसी और की प्रोफ़ाइल आगे भेजने के बजाय प्रत्येक व्यक्ति के लिए एक जारी करें, क्योंकि साझा प्रोफ़ाइल किसी एक व्यक्ति के लिए रद्द नहीं की जा सकती।

क्लाइंट सामग्री भी मायने रखती है। ऑटो-लॉगिन प्रोफ़ाइल और इंटरैक्टिव उपयोगकर्ता लॉगिन अलग-अलग प्रमाणीकरण संबंध दर्शाते हैं, और एक को दूसरे से बदलने पर सर्वर वास्तव में क्या सत्यापित करता है, वह बदल जाता है।

पहुँच निरस्त करना नामांकन का हिस्सा है

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

फिर नामांकन को उसी तरह जाँचें जैसे कोई हमलावर करता: नई पहचान से एक बार जुड़ें, इच्छित संसाधन तक पहुँच की पुष्टि करें, और पुष्टि करें कि असंबंधित संसाधन अब भी मना करता है। काम करता पहला कनेक्शन और एक नकारात्मक परीक्षण मिलकर पूर्ण नामांकन है।

रिकॉर्ड को उस प्रोफ़ाइल के साथ रखें जिसकी वह है। अगला लेखा-परीक्षक पूछेगा कि किसी महीने में कौन जुड़ सकता था, और उत्तर उन तीन स्वामियों में है।