जुने हैश पुन्हा न वापरता VPN प्रमाणीकरण बॅकएंडचे स्थलांतर

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

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

नवीन निर्देशिकेत प्रत्येक वापरकर्तानाव आहे, चाचणी बाइंड यशस्वी होते, आणि VPN क्लायंट तरीही प्रमाणीकरण अयशस्वीता परत करतो। हे संयोजन सांगते की ओळख अस्तित्वात आहे, पण गेटवे वापरत असलेला पडताळणी मार्ग तिच्यापर्यंत पोहोचत नाही, किंवा तो पूर्ण करू शकत नाही अशा पद्धतीने पोहोचतो। दोन्ही संरचना आहेत, आणि या वेगळ्या समस्या आहेत।

पहिली तारांची जोडणी आहे: गेटवे उत्तर न देणाऱ्या बॅकएंडकडे निर्देश करतो, दुसऱ्या बाजूला अपेक्षित नसलेले सामायिक रहस्य वापरतो, किंवा नवीन सेवा परत न करणारे गुणधर्म मागतो। दुसरी गूढलेखनाची आहे: पद्धतीला मूळ रहस्य आवश्यक असते, आणि नवीन भांडार त्याचा फक्त हैश ठेवते। त्रुटीचा मजकूर दोन्ही प्रकरणांत सारखाच दिसतो, म्हणून दोन्हींना एकच समस्या मानले जाते।

खात्यांना स्पर्श करण्यापूर्वी या दोन्हींचे विभाजन एक आठवडा वाचवते। एक मार्गनिर्देशन आणि विश्वासाचा प्रश्न आहे, दुसरा क्रेडेन्शियल रीसेट करण्याचा निर्णय, आणि ते मिसळल्याने कोणीही जबाबदार धरू शकत नाही असे बदल घडतात।

कोणालाही हलवण्यापूर्वी साखळी नकाशावर आणा

प्रत्येक क्लायंट प्रोफाइलसाठी सहा गोष्टी लिहा: बाह्य प्रमाणीकरण पद्धत, असल्यास आंतरिक पद्धत, क्लायंट अपेक्षित असलेली सर्व्हर ओळख, गेटवे आणि बॅकएंडमधील इंटरफेस, गेटवे गट सदस्यत्वावर नकाशा करणारा गुणधर्म, आणि त्यातून निघणारे साधन धोरण। त्या क्रमाने वाचल्यास कोणत्या दुव्याचा मालक नाही हे दिसते। प्रत्येक बाबीला जबाबदार असतो, आणि कटओव्हर तिथे अयशस्वी होतो जिथे कोणीही तपासले नाही।

साधारण निर्देशिका लॉगिन त्या साखळीतून जवळजवळ काहीही जात नाही। ते सिद्ध करते की खाते आहे आणि पासवर्ड चालतो, म्हणजे तोच भाग ज्यावर कधी शंका नव्हती।

हैश पद्धतींमध्ये प्रवास करत नाहीत

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

फरक यात आहे की पुरावा कोण मोजतो। निर्देशिकेशी बांधून पडताळणारी पद्धत निर्देशिकेला जे तपासता येते ते तपासू देते। आव्हान प्रतिसाद पुन्हा गणून पडताळणारी पद्धतीला स्वतः रहस्य लागते, कारण सर्व्हरने तीच गणना करायची असते।

जिथे सामग्री नाही, तिथे प्रामाणिक पर्याय समर्थित रीसेट, पुनर्नोंदणी, बाह्य पडताळणी सेवा किंवा पद्धत बदल आहेत। पुनर्प्राप्त करण्यायोग्य पासवर्डची तात्पुरती निर्यात त्या यादीत नाही। ती प्रकल्पाच्या सर्वात गोंधळाच्या आठवड्यात साध्या मजकुरातील क्रेडेन्शियल भांडार तयार करते, आणि सहसा स्थलांतरानंतरही टिकते।

पायलट गट, नंतर जीवनचक्र बदल

मंजूर ओळखींचा छोटा गट खऱ्या क्लायंटसह हलवा, आणि चार गोष्टी तपासा: ताजे लॉगिन, हेतुपुरस्सर चुकीचे क्रेडेन्शियल, सत्र ज्या साधनांपर्यंत पोहोचू शकते ती, आणि ज्या साधनांपर्यंत पोहोचू नये ती। क्लायंटने स्वीकारलेली सर्व्हर ओळखही तपासा, कारण प्रमाणपत्र नावाची विसंगती कुणी क्लायंट लॉग वाचेपर्यंत अदृश्य असते।

मग तैनाती खरोखर अवलंबून असलेले बदल तपासा। पासवर्ड बदला, प्रमाणपत्र नूतनीकरण किंवा पुनर्नोंदणी करा, आणि एका पायलट खात्याचा प्रवेश काढा। प्रत्येकानंतर कोणत्या पडताळणीकर्त्याने प्रयत्न हाताळला ते पुष्टी करा, कारण कटओव्हरपूर्वी तयार झालेले सत्र चालू राहू शकते आणि पुढील लॉगिनबद्दल काहीही सिद्ध करत नाही।

प्रोफाइल वितरण ओळख बदलापासून वेगळे ठेवा। प्रत्येक गटाला त्याचे इच्छित प्रोफाइल, क्रेडेन्शियल किंवा नोंदणीची स्थिती, वापरायची प्रमाणीकरण सेवा आणि सहाय्य संपर्क हवा, आणि यापैकी कोणत्याही नोंदीत रहस्य नसावे।

जुना आणि नवा मार्ग सोबत असल्यास त्यांना समाप्ती तारखेने मर्यादित करा। स्वयंचलित पुनरागमन नव्या मालकाने प्रवेश काढल्यानंतर खात्याला जुन्या क्रेडेन्शियलने आत घेऊ शकते, आणि ही उपलब्धतेच्या वेशातील सुरक्षा घट आहे।

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

कटओव्हर उलटल्यावर निर्देशिका अगदी आताच्या स्थितीत राहते। रीसेट केलेला पासवर्ड रीसेटच राहतो, रद्द केलेले प्रमाणपत्र रद्दच राहते, आणि बदललेला क्रेडेन्शियल स्वरूप बदललेलाच राहतो। या निर्देशिकेतील घटना आहेत, आणि गेटवे कधीही त्यांचा स्रोत नव्हता। पुनर्प्राप्ती प्रत्येक घटनेसाठी ठरवावी लागते, आणि यातील काहीही विसंगत हैशमधून रहस्य पुनर्रचित करण्यावर अवलंबून असू शकत नाही।

स्थलांतरित होणारे कनेक्शन न वापरणारा प्रशासकीय मार्ग ठेवा। नवीन प्रमाणीकरण अयशस्वी झाल्यास गट थांबवा आणि त्याचा नोंदवलेला पुनर्प्राप्ती मार्ग वापरा, त्या ऐवजी की मुदत पाळण्यासाठी सर्वांसाठी प्रमाणीकरण कमकुवत करा।

गट झाकल्यानंतर जुने बॅकएंड क्रेडेन्शियल, प्रोफाइल आणि विश्वास संबंध त्यांच्या मालकांमार्फत काढून टाका। जुना मार्ग आता वापरकर्त्यांना आत घेत नाही याची पुष्टी करा, आणि सहाय्याला अजूनही आवश्यक असलेले रहस्यविरहित ओळख-ते-धोरण नकाशन ठेवा। स्थलांतर तेव्हा पूर्ण होते जेव्हा नवे जीवनचक्र चालते आणि कोणीही जुन्या मार्गाने आत येऊ शकत नाही, तेव्हा नाही जेव्हा खात्यांची यादी पूर्ण दिसते।