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 सक्षम आहे» याचे दुसऱ्या कोणी चालवू शकेल अशा रचनेत रूपांतर करते.