FortiGate VPN MFA: स्थानीय टोकन, RADIUS वा SAML?

प्रत्येक FortiGate VPN MFA डिजाइनले पहिले एउटा प्रश्नको उत्तर दिन्छ: दोस्रो कारक कसले प्रमाणित गर्छ? गेटवे आफैंले स्थानीय टोकन वा इमेलमा पठाइएको कोडबाट त्यो गर्न सक्छ, RADIUS ब्याकएन्डले त्यसलाई लागू गरी चुनौती फर्काउन सक्छ, वा SAML पहिचान प्रदायकले सम्पूर्ण विधि ब्राउजरमा लिन सक्छ। यीमध्ये प्रत्येकले फरक लगइन क्रम, फरक असफलताको छाप र फरक पुनःप्राप्ति प्रक्रिया उत्पन्न गर्छ, र तिनीहरूबीच कमाण्ड ब्लक प्रतिलिपि गर्दा विश्वसनीय देखिने तर कसैलाई पनि प्रमाणित नगर्ने कन्फिगरेसन बन्छ। यो कार्यविधिबारेको लेख हो: लगइनको क्रममा प्रत्येक डिजाइनले वास्तवमा के गर्छ र कहाँ भाँचिन्छ।

लगइन विधिले कारक कसको स्वामित्वमा छ भनी निर्धारण गर्छ

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

यही भिन्नताले तपाईं कुन प्रमाण संकलन गर्न सक्नुहुन्छ भनी निर्धारण गर्छ। गेटवेले प्रमाणित गर्दा यसको आफ्नै डिबग आउटपुटले के भयो भनी बताउँछ। पहिचान प्रदायकले प्रमाणित गर्दा गेटवेले दाबी आयो भन्ने मात्र जान्छ, र «MFA साँच्चै आवश्यक थियो कि» भन्ने प्रश्नको उत्तर प्रदायकको लगमा हुन्छ, फायरवालको लगमा होइन। गलत लग पढ्नु डिजाइनअनुसार चलिरहेको तैनातीलाई गलत निदान गर्ने सबैभन्दा सामान्य तरिका हो। सेवा आफैंले पनि विधिलाई सीमित गर्छ: FortiOS 7.6.3 ले SSL VPN टनेल मोड हटाउँछ र IPsec तर्फ जान्छ, जबकि वेब मोड समर्थित मोडेलमा Agentless VPN का रूपमा जारी रहन्छ, त्यसैले एउटा सेवामा प्रमाणित विधि अर्कोमा स्वतः उपलब्ध हुँदैन।

स्थानीय प्रमाणीकरण: टोकन र इमेल कोड

FortiGate ले व्यवस्थापन गर्ने कारकहरू प्रयोगकर्ता वस्तुमा जोडिन्छन्। FortiToken वा कागजातीकृत टोकन एकीकरणका लागि दर्ता, समर्थित प्रमाणीकरण विधि, लागू हुने ठाउँमा इजाजतपत्र र प्रतिस्थापन प्रक्रिया आवश्यक हुन्छ। इमेलबाट पठाइएको कोडका लागि काम गर्ने SMTP मार्ग र सुरुङ बन्नुअघि प्रयोगकर्ता पुग्न सक्ने मेलबक्स आवश्यक हुन्छ; यो क्रिप्टोग्राफीसँग कुनै सम्बन्ध नभएको र कोही लगइन गर्न सक्छ कि भन्नेसँग पूर्ण सम्बन्ध भएको निर्भरता हो।

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

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

आश्वासनका आवश्यकताहरू पनि यहीँ पर्छन्, उत्पादन छनोटअघि। NIST SP 800-63B ले इमेललाई आउट-अफ-ब्यान्ड प्रमाणीकरणका लागि अस्वीकार्य मान्छ, त्यसैले अनुपालनको दाबी गर्ने तैनातीले जतिसुकै सुविधाजनक भए पनि इमेल कोडलाई दोस्रो कारकका रूपमा प्रयोग गर्न सक्दैन। यन्त्रमा सुविधा हुनु भनेको त्यो सुविधाले तोकिएको मापदण्ड पूरा गर्छ भन्ने कथन होइन।

RADIUS: गेटवे सोध्छ, ब्याकएन्ड निर्णय गर्छ

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

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

सुरुङलाई दोष दिनुअघि ब्याकएन्ड स्वतन्त्र रूपमा परीक्षण गर्नुहोस्। authserver परीक्षण सफल भई VPN लगइन नभएमा भिन्नता प्रमाणमा होइन, चुनौतीको व्यवस्थापनमा हुन्छ, र गेटवेको प्रमाणीकरण डिमनको डिबग त्यो देखिने ठाउँ हो:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: ब्राउजरले गेटवे छोड्छ

SAML डिजाइनमा ग्राहकलाई पहिचान प्रदायकतर्फ पठाइन्छ, त्यहाँ प्रमाणीकरण हुन्छ, र गेटवेले विश्वास सम्बन्ध र समूह म्यापिङविरुद्ध प्रमाणित गर्ने दाबीसहित फर्किन्छ। गेटवेले पासवर्ड वा दोस्रो कारक कहिल्यै देख्दैन, जुन एकै समयमा सुरक्षा सुधार र सञ्चालन जटिलता हो: असफलता अब फायरवालले जाँच गर्न नसक्ने ब्राउजर सत्रमा हुन्छ।

दाबी स्वीकार गर्नु भनेको प्रदायकले त्यो लगइनका लागि MFA माग्यो भन्ने प्रमाण होइन। केही अनुप्रयोगमा MFA लागू गर्ने र अरूमा नगर्ने प्रदायक नीतिले ठ्याक्कै तपाईंले मागेको लगइन दिन्छ र तपाईंले अनुमान गरेको आश्वासनमध्ये केही पनि दिँदैन। यो विशेष अनुप्रयोगका लागि प्रदायकको नीति जाँच्नुहोस्, र कुनै पनि पक्षमा नाम परिवर्तन भएपछि पनि समूह दाबीहरूको FortiGate समूहसँगको म्यापिङ मिल्छ कि भनी जाँच्नुहोस्।

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

पुनःप्राप्ति कार्यविधिको भाग हो

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

त्यसपछि तैनातीअघि तीन लगइन परीक्षण गर्नुहोस्: सामान्य, अस्वीकृत वा म्याद सकिएको कारक, र स्वीकृत हराएको प्रमाणकको पुनःप्राप्ति। प्रत्येक कुन लगमा देखिन्छ लेख्नुहोस्। त्यही अभिलेखले «MFA सक्षम छ» लाई अरू कसैले चलाउन सक्ने डिजाइनमा बदल्छ।