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

चरण 1: तीन परिणामलाई अलग-अलग नाम दिनुहोस्

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

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

चरण 2: प्रोक्सीले वास्तवमै प्रयोग गर्ने असफलता मोड पढ्नुहोस्

सेवासँग सम्पर्क गर्न नसकिएको बेला व्यवहार नियन्त्रण गर्ने सेटिङ खोज्नुहोस्, र त्यो टेम्प्लेटबाट नभई चलिरहेको कन्फिगरेसनबाट पढ्नुहोस्। Duo को RADIUS प्रोक्सीमा अभिलेखित failmode मानहरू safe र secure हुन्, जहाँ safe ले प्राथमिक प्रमाणीकरण सफल भएपछि मात्र प्रयासलाई अनुमति दिन्छ, र secure ले त्यो अवस्थामा प्रयास अस्वीकार गर्छ।

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

safe नामले उपलब्धताको छनोट वर्णन गर्छ, हरेक स्वीकृत सत्रमा नयाँ दोस्रो कारक थियो भन्ने ग्यारेन्टी होइन। त्यो वाक्य जोखिम दर्तामा जान्छ, किनभने सेटिङले गर्ने ठ्याक्कै त्यही साटासाट हो। मानलाई अर्को प्रदायक, अर्को एकीकरण वा फरक प्रोक्सी मोडमा सामान्यीकरण नगर्नुहोस्; त्यो उत्पादनको आफ्नै समकक्षका लागि त्यसको कागजात पढ्नुहोस्। यो बुझाइबिना विक्रेताको उदाहरणबाट प्रतिलिपि गरिएको कन्फिगरेसन अर्को अवरोध कुरिरहेको आश्चर्य हो।

कुन मोड सक्रिय छ भनी कसैले भन्न नसके रोक्नुहोस्। मार्गदर्शनको बाँकी भाग त्यही उत्तरमा निर्भर छ।

चरण 3: पुनः प्रयासलाई प्रवाहसँग मिलाउनुहोस्

गेटवेको समयसीमा र पुनः प्रयासको व्यवहारलाई यसले चलाइरहेको प्रमाणीकरण प्रवाहसँग मिलाउनुहोस्। असमन्वित पुनः प्रयासले धेरै अनुरोध बनाउँछ, प्रयास मिलानलाई अलमल्याउँछ र कुन नतिजा कुन लगइनको हो भनी लगले भन्न नसक्ने बनाउँछ। धेरै लामो समयसीमा उपलब्धताको डिजाइन होइन; त्यो एउटै उत्तरका लागि लामो प्रतीक्षा हो।

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

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

यदि दुई घटक दुवैले पुनः प्रयास गर्छन् भने पहिले पुनः प्रयासको स्वामित्व सुधार्नुहोस्। दोहोरा अनुरोध दुई मालिकको लक्षण हो, ढिलो सेवाको होइन।

चरण 4: आपतकालीन पहुँच छुट्टै व्यवस्थापन गर्नुहोस्

आपतकालीन पहुँच आवश्यक भए त्यसलाई आफ्नै दायरा, पहिचान, अधिकार र अडिट ट्रेल दिनुहोस्। सबै प्रयोगकर्ताका लागि MFA चुपचाप बन्द गर्नु आपतकालीन प्रक्रिया होइन; त्यो घटना जोडिएको स्थायी कमजोरी हो। सुरक्षा मालिकले प्रवेश नियम, देखिनेता र एस्केलेसन मार्ग अगावै स्वीकृत गर्छ।

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

गैर-उत्पादन वातावरणमा पूरै म्याट्रिक्स परीक्षण गर्नुहोस्: प्राथमिक असफलता, जानाजान अस्वीकृति, चुनौतीको समय सकिनु र सेवाको अनुपलब्धता। प्रत्येकका लागि प्रवेशको नतिजा र लगमा लेखिएको कारण अभिलेख गर्नुहोस्। कन्फिगर गरिएको व्यवहार पत्ता लगाउन उत्पादनमा अवरोध नबनाउनुहोस्, र जुन घटनाका लागि आपतकालीन मार्ग लेखिएको हो त्यही घटनाको बेला पहिलोपटक त्यो परीक्षण नगर्नुहोस्। कहिल्यै नचलेको पुनरुत्थान प्रक्रिया कागजात हो, नियन्त्रण होइन।

तीन अवस्थाको नाम राखिएपछि, असफलता मोड चलिरहेको प्रणालीबाट पढिएपछि, पुनः प्रयासको एउटै मालिक भएपछि र आपतकालीन पहुँचको आफ्नै स्वीकृति र समीक्षा भएपछि मार्गदर्शन सकिन्छ। पूर्वानुमानयोग्य कार्यान्वयन र ज्ञात पुनरुत्थान मार्ग नै अभिलेख गर्न योग्य नतिजा हो।

सम्बन्धित लेखहरू