स्थानीय VPN खाते को उसकी अनुमतियाँ खोए बिना घुमाएँ
स्थानीय VPN खाते ऐसा प्राधिकरण ले जाते हैं जिसे हटाना और दोबारा बनाना मिटा देता है। जगह पर रोटेशन की तुलना पुनर्निर्माण से करें, फिर जाँचें कि CHAP वास्तव में क्या हैश कर सकता है।
चल रहे VPN पासवर्ड को बदलना दो पंक्तियों का बदलाव लगता है, जब तक कि पुनर्निर्मित खाता डिफ़ॉल्ट अनुमतियों के साथ वापस न आ जाए और एकमात्र प्रबंधन सत्र चला न जाए। सुरक्षित प्रक्रिया इस पर निर्भर करती है कि क्रेडेंशियल कहाँ संग्रहीत है और कौन-सा प्रोटोकॉल उसका उपयोग करता है, इस पर नहीं कि कौन-सा आदेश सबसे छोटा है। उपकरण छूने से पहले दोनों दृष्टिकोणों की तुलना करें। जगह पर रोटेशन खाता ऑब्जेक्ट को सुरक्षित रखता है; हटाना और दोबारा बनाना उसे बदल देता है, और उसकी ओर इशारा करने वाला सब कुछ उसके साथ चला जाता है।
पता लगाएँ कि कौन-सा भंडार वास्तव में सत्र का प्रमाणीकरण करता है
उपयोगकर्ता डेटाबेस से नहीं, टनल या कनेक्शन प्रोफ़ाइल से शुरू करें। प्रोफ़ाइल एक प्रमाणीकरण विधि और अक्सर एक सर्वर समूह बताता है, और यदि वह समूह RADIUS या TACACS+ की ओर इशारा करता है, तो बॉक्स पर स्थानीय उपयोगकर्ता नाम केवल सजावट है। कुछ भी योजना बनाने से पहले प्रोफ़ाइल की प्रमाणीकरण सूची और उसके द्वारा संदर्भित AAA समूह पढ़ें। केवल जब प्रोफ़ाइल स्थानीय कहे तभी बॉक्स पर का खाता मायने रखता है। इसमें गलती करें और आप ऐसा क्रेडेंशियल घुमाएँगे जिसका कोई उपयोग नहीं करता, जबकि वास्तविक निर्देशिका प्रविष्टि ठीक वैसी ही बनी रहेगी।
एक ही उपकरण आमतौर पर दो आबादियाँ रखता है: वे प्रशासक जो उसमें लॉग इन करते हैं, और वे VPN उपयोगकर्ता जो टनल समाप्त करते हैं। वे एक भंडार साझा कर सकते हैं, और यह मानना नहीं चाहिए कि वे करते हैं।
जगह पर अद्यतन बनाम हटाना और दोबारा बनाना
जगह पर रोटेशन मौजूदा ऑब्जेक्ट की एक विशेषता बदलता है। विशेषाधिकार स्तर, समूह सदस्यता, प्राधिकरण विशेषताएँ और खाते का संदर्भ देने वाली कोई भी नीति बची रहती हैं, क्योंकि कुछ भी हटाया नहीं गया। हटाना और दोबारा बनाना ऑब्जेक्ट को कमांड लाइन से फिर से बनाता है, इसलिए जो फ़ील्ड आपने नहीं दोहराया वह अपने डिफ़ॉल्ट पर लौट आता है। ऐसे उपकरण पर जहाँ प्रति-उपयोगकर्ता विशेषताएँ स्प्लिट-टनल या पता-पूल असाइनमेंट ले जाती हैं, वही अंतर पूरा जोखिम है।
पुनर्निर्माण का एक वैध उपयोग है: जब संग्रहीत प्रारूप को ही बदलना हो और प्लेटफ़ॉर्म कोई रूपांतरण न देता हो। फिर भी, पहले मौजूदा प्रविष्टि दर्ज करें, क्योंकि चल रहा कॉन्फ़िगरेशन ही इस बात की एकमात्र सटीक सूची है कि खाता क्या ले जाता था। बदलाव से पहले ली गई उस कॉन्फ़िगरेशन की प्रति स्मृति से लिखी रोलबैक योजना से बेहतर है।
आपके पास मौजूद हैश वह गुप्त न हो सकता है जिसकी उसे ज़रूरत है
संग्रह प्रारूप इस तरह भिन्न होते हैं जो उत्तर तय करता है। एकतरफ़ा हैश पासवर्ड सत्यापित कर सकता है जब सर्वर उसे टनल के अंदर स्पष्ट रूप में प्राप्त करता है, लेकिन चुनौती-प्रतिक्रिया विधि को डाइजेस्ट गणना के लिए साझा गुप्त ही चाहिए। इसलिए हर खाते को सबसे मज़बूत एकतरफ़ा प्रारूप में बदलना ठीक उन्हीं उपयोगकर्ताओं के लिए CHAP या MS-CHAP तोड़ सकता है जो उस पर निर्भर हैं।
नारे से नहीं, प्रोटोकॉल से निर्णय लें। जहाँ विधि को पुनःप्राप्य गुप्त चाहिए, वह आवश्यकता डिज़ाइन पर बाधा है, साफ़ करने योग्य चूक नहीं।
क्रेडेंशियल से अधिक जीने वाले सत्र
क्रेडेंशियल बदलना उन सत्रों को समाप्त नहीं करता जो पहले ही प्रमाणित हो चुके हैं। स्थापित टनल वाला साथी कुंजी नवीनीकरण, पुनःप्रमाणीकरण या स्पष्ट डिस्कनेक्ट तक काम करता रहता है।
उस हिस्से की योजना अलग से बनाएँ, और बदलाव से पहले बनाएँ। यदि क्रेडेंशियल लीक हो गया है, तो जीवित सत्र चलते रहने से रोटेशन व्यर्थ हो जाता है। यदि वह केवल पुराना हो गया है, तो हर साथी को ऑफ़लाइन मजबूर करना एक रुकावट है जिसकी आपको ज़रूरत नहीं थी। काम करते समय दूसरा प्रशासनिक रास्ता खुला रखें, अधिमानतः ऐसा जो संपादित किए जा रहे खाते पर निर्भर न हो, क्योंकि यहाँ की विफलता का तरीका आपकी पहुँच ठीक तभी हटा देता है जब आपको उसकी ज़रूरत होती है। फिर नया साइन-इन और उन संसाधनों का सत्यापन करें जिन तक वह पहुँच सकता है।
साबित करें कि अनुमतियाँ बची रहीं
घुमाए गए उपयोगकर्ता के रूप में साइन इन करें और देखें कि सत्र क्या देता है, केवल यह नहीं कि वह खुला। ऐसे संसाधन तक पहुँचें जिसके लिए खाते को ले जाने वाला प्राधिकरण आवश्यक है, और ऐसा आज़माएँ जहाँ उसे नहीं पहुँचना चाहिए। सीमित या विस्तारित पहुँच के साथ सफल लॉगिन एक असफल बदलाव है।
चल रहे कॉन्फ़िगरेशन की प्राधिकरण विशेषताओं की तुलना शुरुआत में ली गई प्रति से करें। समूह सदस्यता, पता पूल, DNS और स्प्लिट-टनल सेटिंग्स, और खाते का नाम लेने वाले किसी भी नीति ऑब्जेक्ट को देखें। फिर उस रिकॉर्ड को अद्यतन करें कि वह क्रेडेंशियल कहाँ रहता है, क्योंकि अगला रोटेशन उसी नोट से शुरू होता है। जिस रोटेशन को कोई दस्तावेज़ीकरण से दोहरा नहीं सकता, वह केवल एक बार पार हुआ है।