पुराने हैश का पुनः उपयोग किए बिना VPN प्रमाणीकरण बैकएंड का माइग्रेशन

उपयोक्तानाम नई निर्देशिका में दिखाई देते हैं, माइग्रेशन पूरा घोषित किया जाता है, और लॉगिन फिर भी विफल होते हैं। गेटवे को अब भी एक समर्थित प्रमाणीकरण पथ और सही अनुमोदन परिणाम चाहिए, और दोनों में से कोई भी ऐसी निर्देशिका से नहीं निकलता जिसमें अब खाते हैं। बैकएंड स्थानांतरण जीवनचक्र वाला कटओवर है, प्रतिलिपि का काम नहीं। नीचे दिया लक्षण वही है जो आम तौर पर अंतर उजागर करता है।

लक्षण: खाते हैं, सत्र नहीं

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

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

खातों को छूने से पहले इन दोनों को अलग करना एक सप्ताह बचाता है। एक रूटिंग और भरोसे का प्रश्न है, दूसरा क्रेडेंशियल रीसेट करने का निर्णय, और इन्हें मिलाने से ऐसे बदलाव पैदा होते हैं जिन्हें कोई जिम्मेदार नहीं ठहरा सकता।

किसी को ले जाने से पहले श्रृंखला का नक्शा बनाएँ

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

साधारण निर्देशिका लॉगिन उस श्रृंखला में से लगभग कुछ नहीं गुज़ारता। यह सिद्ध करता है कि खाता मौजूद है और पासवर्ड काम करता है, यानी ठीक वही हिस्सा जिस पर कभी संदेह नहीं था।

हैश विधियों के बीच यात्रा नहीं करते

क्रेडेंशियल की अनुकूलता एक बार जाँचनी चाहिए, किसी भी समूह को ले जाने से पहले। FreeRADIUS विभाजन स्पष्ट रूप से दस्तावेज़ित करता है: सर्वर जो CHAP जाँच स्वयं करता है उसे वास्तविक पासवर्ड चाहिए, और MS-CHAP वह पासवर्ड या उपयुक्त NT सामग्री स्वीकार करता है। किसी अन्य उद्देश्य के लिए बनाया गया हैश दोनों में से किसी स्थिति में नहीं बैठता, चाहे वह कितना ही मज़बूत हो।

अंतर इस बात में है कि प्रमाण कौन गिनता है। जो विधि निर्देशिका से बंधकर सत्यापित करती है वह निर्देशिका को वह जाँचने देती है जो वह जाँच सकती है। जो विधि चुनौती प्रतिक्रिया की पुनर्गणना करके सत्यापित करती है उसे स्वयं रहस्य चाहिए, क्योंकि सर्वर को वही गणना करनी है।

जहाँ सामग्री नहीं है, वहाँ ईमानदार विकल्प समर्थित रीसेट, पुनः नामांकन, बाहरी सत्यापन सेवा या विधि परिवर्तन हैं। पुनःप्राप्त करने योग्य पासवर्ड का अस्थायी निर्यात उस सूची में नहीं है। यह परियोजना के सबसे अव्यवस्थित सप्ताह में सादे पाठ का क्रेडेंशियल भंडार बनाता है, और आम तौर पर माइग्रेशन से आगे जीता है।

पायलट समूह, फिर जीवनचक्र बदलाव

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

फिर वे बदलाव परखें जिन पर तैनाती वास्तव में निर्भर है। पासवर्ड बदलें, प्रमाणपत्र नवीनीकृत या पुनः नामांकित करें, और एक पायलट खाते से पहुँच हटाएँ। हर एक के बाद पुष्टि करें कि किस सत्यापक ने प्रयास संभाला, क्योंकि कटओवर से पहले बना सत्र काम करता रह सकता है और अगले लॉगिन के बारे में कुछ सिद्ध नहीं करता।

प्रोफ़ाइल वितरण को पहचान परिवर्तन से अलग रखें। हर समूह को अपना इच्छित प्रोफ़ाइल, अपनी क्रेडेंशियल या नामांकन स्थिति, वह प्रमाणीकरण सेवा जो उसे उपयोग करनी चाहिए, और एक सहायता संपर्क चाहिए, और इनमें से किसी अभिलेख में रहस्य नहीं होना चाहिए।

अगर पुराना और नया पथ साथ हैं, तो उन्हें समाप्ति तिथि से सीमित करें। स्वचालित वापसी किसी खाते को पुराने क्रेडेंशियल से अंदर ले सकती है, नए स्वामी द्वारा पहुँच हटाने के बाद, और यह उपलब्धता के वेश में सुरक्षा प्रतिगमन है।

वापसी क्रेडेंशियल बहाल नहीं कर सकती

कटओवर को उलटने पर निर्देशिका ठीक वैसी ही रहती है जैसी अब है। रीसेट किया गया पासवर्ड रीसेट ही रहता है, निरस्त प्रमाणपत्र निरस्त ही रहता है, और बदला हुआ क्रेडेंशियल प्रारूप बदला ही रहता है। ये निर्देशिका में घटनाएँ हैं, और गेटवे कभी उनका स्रोत नहीं था। रिकवरी हर घटना के लिए परिभाषित करनी होगी, और इसमें से कुछ भी असंगत हैश से रहस्य पुनर्निर्मित करने पर निर्भर नहीं हो सकता।

ऐसा प्रशासनिक पथ रखें जो स्थानांतरित हो रहे कनेक्शन का उपयोग न करे। जब नया प्रमाणीकरण विफल हो, तो समूह को रोकें और उसका प्रलेखित रिकवरी पथ उपयोग करें, बजाय इसके कि समयसीमा निभाने के लिए सबके लिए प्रमाणीकरण कमज़ोर करें।

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