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 सक्षम है» को ऐसे डिज़ाइन में बदलता है जिसे कोई और चला सके।