पुराना ह्यास पुनः प्रयोग नगरी VPN प्रमाणीकरण ब्याकएन्डको माइग्रेसन
VPN पहिचानहरू सार्नु कटओभर हो, प्रतिलिपि होइन: प्रमाणीकरण शृंखलाको नक्सा बनाउनुहोस्, एउटा पाइलट समूह सार्नुहोस्, प्रमाणपत्र परिवर्तनहरू परख्नुहोस् र रिसेटले मेटाउन नसक्ने पुनःप्राप्तिको योजना बनाउनुहोस्।
प्रयोगकर्तानामहरू नयाँ निर्देशिकामा देखा पर्छन्, माइग्रेसन पूरा भएको घोषणा गरिन्छ, र लगइनहरू अझै असफल हुन्छन्। गेटवेलाई अझै समर्थित प्रमाणीकरण मार्ग र सही अनुमतिको नतिजा चाहिन्छ, र दुवैमध्ये कुनै पनि अब खाताहरू राख्ने निर्देशिकाबाट आउँदैन। ब्याकएन्ड सार्नु जीवनचक्र भएको कटओभर हो, प्रतिलिपिको काम होइन। तलको लक्षण त्यही हो जसले सामान्यतया फरक देखाउँछ।
लक्षण: खाताहरू छन्, सत्रहरू छैनन्
नयाँ निर्देशिकामा हरेक प्रयोगकर्तानाम छ, परीक्षण बाइन्ड सफल हुन्छ, र VPN क्लाइन्टले अझै प्रमाणीकरण असफलता फर्काउँछ। यो संयोजन भन्छ कि पहिचान अवस्थित छ, तर गेटवेले प्रयोग गर्ने प्रमाणीकरण मार्ग त्यहाँसम्म पुग्दैन, वा त्यो पूरा गर्न नसक्ने विधिले पुग्छ। दुवै कन्फिगरेसन हुन्, र यी फरक समस्या हुन्।
पहिलो तार जोडाइ हो: गेटवे उत्तर नदिने ब्याकएन्डतिर देखाउँछ, अर्को पक्षले नअपेक्षा गरेको साझा रहस्य प्रयोग गर्छ, वा नयाँ सेवाले नफर्काउने गुण माग्छ। दोस्रो क्रिप्टोग्राफिक हो: विधिले मूल रहस्य माग्छ, र नयाँ भण्डारले त्यसको ह्यास मात्र राख्छ। त्रुटि पाठ दुवै अवस्थामा उस्तै देखिन्छ, त्यसैले दुवैलाई एउटै समस्या मानिन्छ।
खाताहरूलाई छुनुअघि यी दुईलाई अलग गर्नु एक हप्ता बचाउँछ। एउटा राउटिङ र विश्वासको प्रश्न हो, अर्को प्रमाणपत्र रिसेट गर्ने निर्णय, र तिनीहरूलाई मिसाउँदा कसैले जिम्मा लगाउन नसक्ने परिवर्तनहरू उत्पन्न हुन्छन्।
कसैलाई सार्नुअघि शृंखलाको नक्सा बनाउनुहोस्
हरेक क्लाइन्ट प्रोफाइलका लागि छ वटा कुरा लेख्नुहोस्: बाहिरी प्रमाणीकरण विधि, भए आन्तरिक विधि, क्लाइन्टले अपेक्षा गर्ने सर्भर पहिचान, गेटवे र ब्याकएन्डबीचको इन्टरफेस, गेटवेले समूह सदस्यतामा नक्सा गर्ने गुण, र त्यसबाट निस्कने स्रोत नीति। तिनलाई क्रममा पढ्दा कुन कडीको मालिक छैन देखिन्छ। हरेक वस्तुको जिम्मेवार हुन्छ, र कटओभर त्यहीँ असफल हुन्छ जहाँ कसैले जाँच गरेन।
| Link | Question it answers |
|---|---|
| Client profile | Which method and server name does the client use? |
| Inner method | Is there a second authentication step? |
| Server identity | Which certificate or name must the client accept? |
| Gateway to backend | Which protocol, port and shared secret? |
| Attribute mapping | Which returned value becomes group membership? |
| Resource policy | What the resulting session may reach |
साधारण निर्देशिका लगइन त्यो शृंखलाबाट लगभग केही पनि जाँदैन। यसले प्रमाणित गर्छ कि खाता छ र पासवर्ड चल्छ, अर्थात् त्यही भाग जसमा कहिल्यै शंका थिएन।
ह्यासहरू विधिहरूबीच यात्रा गर्दैनन्
प्रमाणपत्रको अनुकूलता एक पटक जाँच्नुपर्छ, कुनै पनि समूह सर्नुअघि। FreeRADIUS ले विभाजन स्पष्ट रूपमा लेख्छ: सर्भर आफैले गर्ने CHAP जाँचलाई वास्तविक पासवर्ड चाहिन्छ, र MS-CHAP ले त्यो पासवर्ड वा उपयुक्त NT सामग्री स्वीकार्छ। अर्को उद्देश्यका लागि बनाइएको ह्यास दुवै अवस्थामा मिल्दैन, त्यो जतिसुकै बलियो भए पनि।
फरक यसमा छ कि प्रमाण कसले गणना गर्छ। निर्देशिकासँग बाँधिएर प्रमाणित गर्ने विधिले निर्देशिकालाई जे जाँच्न सक्छ त्यो जाँच्न दिन्छ। चुनौती प्रतिक्रिया पुनः गणना गरेर प्रमाणित गर्ने विधिलाई आफै रहस्य चाहिन्छ, किनकि सर्भरले पनि त्यही गणना गर्नुपर्छ।
जहाँ सामग्री छैन, त्यहाँ इमानदार विकल्प समर्थित रिसेट, पुनः भर्ना, बाह्य प्रमाणीकरण सेवा वा विधि परिवर्तन हुन्। पुनःप्राप्त गर्न सकिने पासवर्डको अस्थायी निर्यात त्यो सूचीमा छैन। यसले परियोजनाको सबैभन्दा अव्यवस्थित हप्तामा सादा पाठको प्रमाणपत्र भण्डार बनाउँछ, र सामान्यतया माइग्रेसनपछि पनि रहन्छ।
पाइलट समूह, त्यसपछि जीवनचक्र परिवर्तन
स्वीकृत पहिचानहरूको सानो समूह वास्तविक क्लाइन्टसँग सार्नुहोस्, र चार कुरा परख्नुहोस्: ताजा लगइन, जानाजानी गलत प्रमाणपत्र, सत्र पुग्न सक्ने स्रोतहरू, र पुग्न नहुने स्रोतहरू। क्लाइन्टले स्वीकार गरेको सर्भर पहिचान पनि जाँच्नुहोस्, किनकि प्रमाणपत्र नामको बेमेल कसैले क्लाइन्ट लग नपढेसम्म अदृश्य हुन्छ।
त्यसपछि तैनाथी साँच्चै अवलम्बित परिवर्तनहरू परख्नुहोस्। पासवर्ड बदल्नुहोस्, प्रमाणपत्र नवीकरण वा पुनः भर्ना गर्नुहोस्, र एउटा पाइलट खाताबाट पहुँच हटाउनुहोस्। हरेकपछि कुन प्रमाणकले प्रयास सम्हाल्यो पुष्टि गर्नुहोस्, किनकि कटओभरअघि बनेको सत्र चलिरहन सक्छ र अर्को लगइनबारे केही पनि प्रमाणित गर्दैन।
प्रोफाइल वितरणलाई पहिचान परिवर्तनबाट अलग राख्नुहोस्। हरेक समूहलाई आफ्नो इच्छित प्रोफाइल, आफ्नो प्रमाणपत्र वा भर्नाको स्थिति, प्रयोग गर्नुपर्ने प्रमाणीकरण सेवा र सहयोग सम्पर्क चाहिन्छ, र यीमध्ये कुनै अभिलेखमा रहस्य हुनु हुँदैन।
पुरानो र नयाँ मार्ग सँगै छन् भने तिनलाई अन्त्य मितिले सीमित गर्नुहोस्। स्वचालित फर्किने क्रमले नयाँ मालिकले पहुँच हटाएपछि खातालाई पुरानो प्रमाणपत्रबाट भित्र लिन सक्छ, र यो उपलब्धताको भेषमा सुरक्षा प्रतिगमन हो।
फर्काउनुले प्रमाणपत्र पुनर्स्थापित गर्न सक्दैन
कटओभर उल्ट्याउँदा निर्देशिका ठ्याक्कै अहिलेको अवस्थामा रहन्छ। रिसेट गरिएको पासवर्ड रिसेट नै रहन्छ, रद्द गरिएको प्रमाणपत्र रद्द नै रहन्छ, र बदलिएको प्रमाणपत्र ढाँचा बदलिएकै रहन्छ। यी निर्देशिकामा घटना हुन्, र गेटवे कहिल्यै तिनको स्रोत थिएन। पुनःप्राप्ति हरेक घटनाका लागि परिभाषित गर्नुपर्छ, र यसमध्ये केही पनि असंगत ह्यासबाट रहस्य पुनर्निर्माणमा अवलम्बित हुन सक्दैन।
सारिँदै गरेको जडान प्रयोग नगर्ने प्रशासनिक मार्ग राख्नुहोस्। नयाँ प्रमाणीकरण असफल हुँदा समूह रोक्नुहोस् र त्यसको अभिलेखित पुनःप्राप्ति मार्ग प्रयोग गर्नुहोस्, म्याद पुग्न सबैका लागि प्रमाणीकरण कमजोर पार्नुको सट्टा।
समूहहरू ढाकिएपछि पुराना ब्याकएन्ड प्रमाणपत्र, प्रोफाइल र विश्वास सम्बन्ध तिनका मालिकमार्फत हटाउनुहोस्। पुरानो मार्गले अब प्रयोगकर्ता भित्र नलिने पुष्टि गर्नुहोस्, र सहयोगलाई अझै चाहिने रहस्यरहित पहिचान-देखि-नीति नक्सांकन राख्नुहोस्। माइग्रेसन तब पूरा हुन्छ जब नयाँ जीवनचक्र चल्छ र कोही पुरानो मार्गबाट भित्र पस्न सक्दैन, तब होइन जब खाताको सूची पूरा देखिन्छ।