मुख्य सामग्री पर जाएं

Okta और RADIUS: अपने आइडेंटिटी प्रोवाइडर को WiFi ऑथेंटिकेशन तक विस्तारित करना

यह गाइड उन Okta-केंद्रित संगठनों के IT एडमिनिस्ट्रेटर के लिए एक व्यापक तकनीकी संदर्भ प्रदान करती है जो Okta RADIUS एजेंट का उपयोग करके अपने क्लाउड आइडेंटिटी प्रोवाइडर को WiFi ऑथेंटिकेशन तक विस्तारित करना चाहते हैं। इसमें संपूर्ण ऑथेंटिकेशन आर्किटेक्चर, MFA लागू करने के समझौते, RADIUS एट्रिब्यूट मैपिंग के माध्यम से डायनेमिक VLAN असाइनमेंट, और पासवर्ड-आधारित EAP-TTLS और सर्टिफिकेट-आधारित EAP-TLS के बीच महत्वपूर्ण निर्णय को शामिल किया गया है। वेन्यू ऑपरेटरों और एंटरप्राइज IT टीमों को व्यावहारिक डिप्लॉयमेंट गाइडेंस, हॉस्पिटैलिटी और रिटेल के वास्तविक केस स्टडीज, और समर्पित गेस्ट WiFi समाधानों के साथ Okta RADIUS को एकीकृत करने के लिए एक स्पष्ट फ्रेमवर्क मिलेगा।

Iain Jewitt द्वाराप्रकाशित अपडेट किया गया
📖 11 मिनट का पाठ3,121 शब्द2 हल किए गए उदाहरण3 अभ्यास प्रश्न10 मुख्य परिभाषाएं

Video overview

इस गाइड को सुनें

पॉडकास्ट ट्रांसक्रिप्ट देखें
Purple Technical Briefing में आपका स्वागत है। आज हम एक ऐसे विषय पर चर्चा कर रहे हैं जो नेटवर्क आर्किटेक्चर और पहचान प्रबंधन के ठीक बीच में स्थित है: WiFi ऑथेंटिकेशन के लिए Okta और RADIUS। यदि आप एक IT मैनेजर, एक नेटवर्क आर्किटेक्ट, या एक वेन्यू ऑपरेशंस डायरेक्टर हैं, तो आप पहले से ही नेटवर्क एक्सेस के लिए अलग-अलग क्रेडेंशियल प्रबंधित करने के सिरदर्द को जानते हैं। क्लाउड एप्लिकेशन के लिए आपके पास अपनी Okta डायरेक्टरी है, लेकिन शायद आपका WiFi अभी भी एक लेगेसी एक्टिव डायरेक्टरी सर्वर पर निर्भर है, या उससे भी बदतर, ब्रेक रूम की दीवार पर लगा हुआ एक साझा WPA2 पासवर्ड। आज, हम यह देखने जा रहे हैं कि Okta RADIUS एजेंट का उपयोग करके उस अंतर को कैसे पाटा जाए। हम आर्किटेक्चर, WiFi पर मल्टी-फैक्टर ऑथेंटिकेशन को कैसे संभालें, पासवर्ड-आधारित और सर्टिफिकेट-आधारित ऑथेंटिकेशन के बीच महत्वपूर्ण समझौतों, और डायनेमिक VLAN असाइनमेंट के लिए Okta समूहों को RADIUS विशेषताओं से कैसे मैप करें, इन सभी विषयों को कवर करेंगे। आइए इसे विस्तार से समझते हैं। आइए आर्किटेक्चर से शुरुआत करते हैं। Okta RADIUS एजेंट वास्तव में कैसे काम करता है? Okta RADIUS एजेंट एक हल्का एप्लिकेशन है जिसे आप ऑन-प्रिमाइसेस - आमतौर पर एक Windows या Linux सर्वर पर - या क्लाउड वर्चुअल मशीन में तैनात करते हैं। यह एक प्रॉक्सी के रूप में कार्य करता है। यह आपके नेटवर्क इन्फ्रास्ट्रक्चर, जैसे कि आपके वायरलेस एक्सेस पॉइंट या आपके वायरलेस LAN कंट्रोलर, और Okta क्लाउड के बीच बैठता है। जब कोई उपयोगकर्ता आपके 802.1X एंटरप्राइज WiFi से कनेक्ट करने का प्रयास करता है, तो उनका डिवाइस एक्सेस पॉइंट पर क्रेडेंशियल भेजता है। एक्सेस पॉइंट, जो 802.1X मॉडल में ऑथेंटिकेटर के रूप में कार्य करता है, UDP पोर्ट 1812 पर Okta RADIUS एजेंट को RADIUS Access-Request अग्रेषित करता है। एजेंट उस अनुरोध को लेता है और HTTPS API कॉल के माध्यम से इसे Okta क्लाउड पर सुरक्षित रूप से टनल करता है। Okta क्रेडेंशियल की पुष्टि करता है, साइन-ऑन नीतियों की जांच करता है, और निर्णय देता है। इसके बाद एजेंट इसे एक्सेस पॉइंट के लिए RADIUS Access-Accept या Access-Reject संदेश में वापस अनुवादित करता है। यह आपकी डायरेक्टरी को सीधे इंटरनेट पर प्रदर्शित किए बिना स्थानीय नेटवर्क एज तक आपके क्लाउड आइडेंटिटी प्रोवाइडर का विस्तार करने का एक शानदार तरीका है। अब, वह बड़ा सवाल जो हर कोई पूछता है: क्या आप WiFi कनेक्शन पर Okta MFA लागू कर सकते हैं? इसका संक्षिप्त उत्तर हाँ है, लेकिन कुछ महत्वपूर्ण सावधानियों के साथ। Okta RADIUS एजेंट मुख्य रूप से पासवर्ड ऑथेंटिकेशन प्रोटोकॉल, या PAP का समर्थन करता है। क्योंकि PAP पासवर्ड को स्पष्ट रूप से भेजता है, इसलिए यह EAP प्रोटोकॉल (जिसका अर्थ एक्सटेंसिबल ऑथेंटिकेशन प्रोटोकॉल है) के बाहरी TLS टनल द्वारा एन्कैप्सुलेटेड और सुरक्षित होता है। यह व्यवस्था एजेंट को MFA चुनौतियों को संभालने की अनुमति देती है। आप उपयोगकर्ता के फ़ोन पर Okta Verify नोटिफिकेशन भेजने के लिए Okta को कॉन्फ़िगर कर सकते हैं, या उनसे अपने पासवर्ड के साथ एक TOTP कोड - यानी टाइम-बेस्ड वन-टाइम पासवर्ड - जोड़ने के लिए कह सकते हैं। हालांकि, यहीं पर उपयोगकर्ता अनुभव और सुरक्षा के बीच टकराव होता है। कल्पना कीजिए कि जब कोई रिटेल स्टोर सहयोगी दुकान के फर्श पर चलते हुए अपने फोन को स्टाफ WiFi से फिर से कनेक्ट करता है, तो उसे हर बार एक पुश नोटिफिकेशन को अप्रूव करने के लिए कहा जाए। इससे बाधा उत्पन्न होती है। इसके अलावा, यदि MFA चुनौती में बहुत अधिक समय लगता है, तो कई आधुनिक डिवाइस WiFi कनेक्शन को डिस्कनेक्ट कर देंगे। इसलिए, हालांकि WiFi पर MFA तकनीकी रूप से संभव है और Okta द्वारा समर्थित है, हम आम तौर पर इसे सामान्य स्टाफ WiFi के बजाय केवल अत्यधिक विशेषाधिकार प्राप्त एक्सेस, जैसे कि IT एडमिन SSIDs के लिए ही अनुशंसित करते हैं। यह हमें एक महत्वपूर्ण समझौते पर लाता है: Okta के साथ पासवर्ड-आधारित RADIUS बनाम सर्टिफिकेट-आधारित ऑथेंटिकेशन, विशेष रूप से EAP-TLS। जब आप EAP-TTLS या PAP के साथ Okta RADIUS एजेंट का उपयोग करते हैं, तो आप पासवर्ड पर निर्भर होते हैं। पासवर्ड चोरी हो सकते हैं, फ़िशिंग का शिकार हो सकते हैं, या साझा किए जा सकते हैं। इसके अलावा, जैसा कि हमने अभी चर्चा की, WiFi में MFA जोड़ना व्यावहारिक रूप से काफी कठिन है। दूसरी ओर, EAP-TLS उपयोगकर्ता के डिवाइस पर तैनात डिजिटल सर्टिफिकेट का उपयोग करता है। यह म्यूचुअल ऑथेंटिकेशन प्रदान करता है - डिवाइस नेटवर्क के सामने अपनी पहचान साबित करता है, और नेटवर्क डिवाइस के सामने अपनी पहचान साबित करता है। इसमें टाइप करने के लिए कोई पासवर्ड नहीं होता है, और यह फ़िशिंग के प्रति अत्यधिक प्रतिरोधी है। पेच क्या है? Okta RADIUS एजेंट स्वाभाविक रूप से सर्टिफिकेट अथॉरिटी के रूप में कार्य नहीं करता है। यदि आप EAP-TLS चाहते हैं, तो आपको एक पब्लिक की इन्फ्रास्ट्रक्चर, या PKI - जैसे SecureW2, Foxpass, या Microsoft Active Directory Certificate Services - और आपके एंडपॉइंट्स पर सर्टिफिकेट वितरित करने के लिए एक मोबाइल डिवाइस मैनेजमेंट समाधान की आवश्यकता होगी। Okta अभी भी पहचान प्रदाता हो सकता है जो सर्टिफिकेट जारी करने को अधिकृत करता है, लेकिन RADIUS एजेंट स्वयं EAP-TLS के लिए भारी काम नहीं करेगा। BYOD वातावरण के लिए, पासवर्ड-आधारित Okta RADIUS तैनात करना तेज़ और आसान है। प्रबंधित कॉर्पोरेट उपकरणों के लिए, EAP-TLS गोल्ड स्टैंडर्ड है। आइए अब तक के सबसे शक्तिशाली फीचर्स में से एक पर चलते हैं: Dynamic VLAN असाइनमेंट। एक बड़े स्थान - जैसे होटल, स्टेडियम, या कॉन्फ्रेंस सेंटर में - आप नहीं चाहेंगे कि आपका पूरा स्टाफ एक ही नेटवर्क सेगमेंट पर रहे। आप चाहते हैं कि पॉइंट-ऑफ़-सेल टर्मिनल हाउसकीपिंग टैबलेट से बिल्कुल अलग रहें, और IT स्टाफ एक मैनेजमेंट VLAN पर रहे। आप Okta के साथ इसे कैसे हासिल करते हैं? यह सब RADIUS एट्रिब्यूट मैपिंग के बारे में है। Okta एडमिन कंसोल में, RADIUS एप्लिकेशन सेटिंग्स के अंतर्गत, आप एक फीचर को सक्षम कर सकते हैं जिसे Include groups in RADIUS response कहा जाता है। आप यह निर्दिष्ट करते हैं कि ऑथेंटिकेशन रिस्पॉन्स में कौन से Okta ग्रुप वापस भेजे जाने चाहिए। Okta इस ग्रुप की सदस्यता को आपके नेटवर्क कंट्रोलर को स्टैंडर्ड RADIUS एट्रिब्यूट्स का उपयोग करके वापस भेजता है - आमतौर पर Filter-ID के लिए Attribute 11, या Class के लिए Attribute 25। आपका वायरलेस कंट्रोलर या नेटवर्क एक्सेस कंट्रोल सिस्टम, जैसे कि Aruba ClearPass या Cisco ISE, इस ग्रुप का नाम प्राप्त करता है। फिर आप कंट्रोलर पर एक स्थानीय पॉलिसी कॉन्फ़िगर करते हैं जो कहती है, उदाहरण के लिए, यदि RADIUS Attribute 25 Retail-POS के बराबर है, तो क्लाइंट को VLAN 40 पर असाइन करें। कंट्रोलर एक्सेस पॉइंट को स्टैंडर्ड टनल एट्रिब्यूट्स - Tunnel-Type, Tunnel-Medium-Type, और Tunnel-Private-Group-ID - भेजता है, जिससे यूजर डायनेमिक रूप से सही VLAN में पहुंच जाता है। यह पूरी तरह से Okta पहचान के आधार पर नेटवर्क सेगमेंटेशन लागू करने का एक आसान तरीका है, जो PCI-DSS जैसे मानकों के अनुपालन के लिए बेहद शक्तिशाली है, जिसमें कार्डहोल्डर डेटा एनवायरनमेंट के आसपास सख्त नेटवर्क सेगमेंटेशन की आवश्यकता होती है। अब आइए कुछ वास्तविक दुनिया के कार्यान्वयन परिदृश्यों को देखें। यूनाइटेड किंगडम में संपत्तियों वाली एक राष्ट्रीय होटल चेन पर विचार करें। प्रत्येक संपत्ति में फ्रंट डेस्क स्टाफ, हाउसकीपिंग, फूड एंड बेवरेज, और मैनेजमेंट का मिश्रण है। पहले, प्रत्येक संपत्ति स्थानीय Active Directory के साथ अपना स्वयं का NPS सर्वर चलाती थी। IT टीम ने स्थानीय खातों को प्रबंधित करने और RADIUS की विफलताओं को दूर करने में काफी समय बिताया। रिडंडेंट क्लाउड वर्चुअल मशीनों के एक जोड़े में Okta RADIUS एजेंट को तैनात करके, Okta में सभी यूजर खातों को सेंट्रलाइज करके, और ग्रुप-आधारित VLAN असाइनमेंट को कॉन्फ़िगर करके, चेन ने प्रति-संपत्ति अपने IT ओवरहेड को काफी कम कर दिया। फ्रंट डेस्क स्टाफ अपने Okta क्रेडेंशियल्स के साथ ऑथेंटिकेट होते हैं और स्वचालित रूप से गेस्ट-सर्विसेज VLAN पर चले जाते हैं। मैनेजमेंट स्टाफ, जो एक अलग Okta ग्रुप में हैं, संपत्ति प्रबंधन प्रणालियों तक पहुंच के साथ मैनेजमेंट VLAN पर पहुंच जाते हैं। संपूर्ण कॉन्फ़िगरेशन को एक सिंगल Okta एडमिन कंसोल से प्रबंधित किया जाता है, और Okta सिस्टम लॉग सभी संपत्तियों में प्रत्येक ऑथेंटिकेशन इवेंट का एक पूरा ऑडिट ट्रेल प्रदान करता है।दूसरा परिदृश्य: 300 से अधिक स्टोर्स वाली एक बड़ी रिटेल चेन। प्रत्येक स्टोर में एक स्टाफ WiFi नेटवर्क है जिसका उपयोग इन्वेंट्री प्रबंधन, पॉइंट-ऑफ-सेल टर्मिनल्स और बैक-ऑफिस संचालन के लिए किया जाता है। PCI-DSS अनुपालन के लिए कार्डधारक डेटा वातावरण और सामान्य स्टाफ एक्सेस के बीच कड़े नेटवर्क विभाजन (segmentation) की आवश्यकता होती है। Okta RADIUS को अपने मौजूदा वायरलेस इन्फ्रास्ट्रक्चर के साथ एकीकृत करके, रिटेलर Okta समूहों - POS-Staff, Inventory-Staff, और Store-Management - को तीन अलग-अलग VLANs से मैप करता है। जब कोई स्टोर सहयोगी कनेक्ट होता है, तो उनका डिवाइस उनकी Okta समूह सदस्यता के आधार पर स्वचालित रूप से सही VLAN में रख दिया जाता है। यदि कोई कर्मचारी अपनी भूमिका बदलता है, तो उनकी Okta समूह सदस्यता को अपडेट करने से उनके अगले कनेक्शन पर उनके नेटवर्क एक्सेस तुरंत बदल जाते हैं। अपडेट करने के लिए कोई फ़ायरवॉल नियम नहीं, व्यक्तिगत स्टोर्स पर पुश करने के लिए कोई VLAN कॉन्फ़िगरेशन नहीं। अब, आइए कार्यान्वयन अनुशंसाओं और सामान्य समस्याओं के बारे में बात करते हैं। पहली और सबसे आम समस्या टाइमआउट सेटिंग्स को अनदेखा करना है। Okta API कॉल्स में समय लगता है, विशेष रूप से तब जब इसमें एक MFA पुश शामिल हो। यदि आपके वायरलेस कंट्रोलर का RADIUS टाइमआउट डिफ़ॉल्ट तीन या पांच सेकंड पर सेट है, तो उपयोगकर्ता द्वारा अपने फ़ोन पर Approve टैप करने से पहले ही अनुरोध टाइमआउट हो जाएगा। आपको अपने WLC पर RADIUS टाइमआउट को कम से कम तीस से साठ सेकंड तक बढ़ाना होगा। यह नेटवर्क की ओर से किया जाने वाला एक कॉन्फ़िगरेशन परिवर्तन है, Okta में नहीं, और इसे अक्सर अनदेखा कर दिया जाता है। दूसरी अनुशंसा उच्च उपलब्धता (high availability) है। कभी भी केवल एक Okta RADIUS एजेंट तैनात न करें। अलग-अलग सर्वरों पर कम से कम दो एजेंट तैनात करें और अपने वायरलेस कंट्रोलर को उनके बीच लोड-बैलेंस करने के लिए कॉन्फ़िगर करें। यदि एक सर्वर पैचिंग के लिए डाउन हो जाता है, तो आपका WiFi प्रमाणीकरण चालू रहता है। तीसरी समस्या: PEAP के साथ सावधान रहें। Okta RADIUS एजेंट PEAP-MSCHAPv2 का समर्थन नहीं करता है, जो कई पुराने Windows वातावरणों के लिए डिफ़ॉल्ट है। आपको अपने क्लाइंट्स को PAP के साथ EAP-TTLS का उपयोग करने के लिए कॉन्फ़िगर करना होगा। इसके लिए आम तौर पर Group Policy या MDM के माध्यम से एक वायरलेस प्रोफ़ाइल पुश करने की आवश्यकता होती है, क्योंकि Windows आसानी से EAP-TTLS को डिफ़ॉल्ट नहीं करता है। ऐसा करने में विफल होना असफल तैनाती का सबसे बड़ा कारण है। सामान्य क्लाइंट प्रश्नों पर आधारित त्वरित प्रश्न और उत्तर सत्र का समय। पहला प्रश्न: क्या हम गेस्ट WiFi के लिए Okta RADIUS का उपयोग कर सकते हैं? उत्तर: नहीं। Okta की कीमत प्रति उपयोगकर्ता के अनुसार होती है और इसे कार्यबल की पहचान के लिए डिज़ाइन किया गया है। गेस्ट WiFi के लिए, आपको एक विशेष रूप से निर्मित captive portal समाधान का उपयोग करना चाहिए, जो Okta लाइसेंस का उपभोग किए बिना सेवा की शर्तों, सोशल लॉगिन और एनालिटिक्स को संभालता है। दूसरा प्रश्न: क्या Okta RADIUS WiFi प्रमाणीकरण के लिए YubiKeys का समर्थन करता है? उत्तर: आम तौर पर, नहीं। हार्डवेयर टोकन और WebAuthn RADIUS प्रोटोकॉल पर अच्छी तरह से काम नहीं करते हैं। यदि आपको WiFi पर MFA का उपयोग करना ही है, तो Okta Verify पुश या TOTP का ही उपयोग करें। तीसरा प्रश्न: यह Purple परिनियोजन के साथ कैसे काम करता है? उत्तर: बहुत अच्छी तरह से। अपनी पहचान प्रदाता के रूप में Okta का उपयोग करने वाले Purple एंटरप्राइज ग्राहक स्टाफ WiFi को सुरक्षित रूप से प्रमाणित करने के लिए Okta RADIUS का उपयोग कर सकते हैं, जबकि एक अलग SSID पर गेस्ट एक्सेस के लिए Purple के captive portal का उपयोग कर सकते हैं। यह Purple को एक एकीकृत, आधुनिक प्रमाणीकरण स्टैक में Okta के साथ रखता है - एक SSID पर Okta RADIUS के साथ स्टाफ, दूसरे पर Purple के ब्रांडेड पोर्टल के साथ गेस्ट। आज की ब्रीफिंग को संक्षेप में प्रस्तुत करने के लिए: Okta RADIUS एजेंट पुराने ऑन-प्रीमिस डायरेक्टरी को समाप्त करने और अपने WiFi प्रमाणीकरण को अपने क्लाउड पहचान प्रदाता में एकीकृत करने के लिए एक शक्तिशाली उपकरण है। यह मजबूत नेटवर्क विभाजन के लिए डायनेमिक VLAN असाइनमेंट का समर्थन करता है, जो PCI-DSS और अन्य ढांचे के अनुपालन के लिए महत्वपूर्ण है। हालाँकि, यदि आप WiFi पर MFA लागू करते हैं, तो उपयोगकर्ता अनुभव का ध्यान रखें, और याद रखें कि पूरी तरह से प्रबंधित कॉर्पोरेट उपकरणों के लिए, एक समर्पित PKI के साथ प्रमाणपत्र-आधारित EAP-TLS पर माइग्रेट करना अधिक सुरक्षित दीर्घकालिक रणनीति है। Okta RADIUS एजेंट एक उत्कृष्ट ब्रिज समाधान है, विशेष रूप से उन संगठनों के लिए जो Okta-केंद्रित हैं और उस पहचान निवेश को नेटवर्क लेयर तक तेज़ी से विस्तारित करना चाहते हैं। इस ब्रीफिंग के लिए बस इतना ही। विस्तृत कॉन्फ़िगरेशन चरणों, आर्किटेक्चर आरेखों और व्यावहारिक उदाहरणों के लिए संपूर्ण तकनीकी संदर्भ मार्गदर्शिका को देखना न भूलें। अगली बार तक, अपने नेटवर्क को सुरक्षित रखें और अपने उपयोगकर्ताओं को कनेक्टेड रखें।

हमारी मुख्य श्रृंखला का हिस्सा: एंटरप्राइज WiFi सुरक्षा गाइड →

Interactive technical advisor

Okta RADIUS WiFi architecture and sizing advisor

Model your enterprise identity infrastructure, device endpoints, and authentication protocols to generate an 802.1X deployment blueprint, timeout guidelines, and network configuration checklist.

Cloud-hosted RADIUS endpoints with native Okta API and SCIM directory synchronization. Eliminates on-premises servers and provides automated geographic failover.
Fully managed Windows and macOS laptops enrolled in Microsoft Intune, Jamf Pro, or Kandji.
Passwordless cryptographic authentication. Both client and server validate certificates. Resistant to phishing and credential theft.
Recommended deployment blueprint

Cloud RADIUS with Okta Directory Sync and EAP-TLS

Wireless access points forward 802.1X requests to a globally distributed Cloud RADIUS service. Cloud RADIUS verifies client certificates and queries Okta Universal Directory via SCIM APIs in real time, granting network access without exposing internal servers.
Security score
100/100
RADIUS timeout
5s
Compliance level: NIST SP 800-207 Zero Trust and WPA3-Enterprise compliant
Step-by-step implementation checklist
  1. Configure Cloud RADIUS tenant and establish OAuth 2.0 API connection to your Okta organization.
  2. Add wireless controller management IP addresses as authorised network access clients (NAS) in Cloud RADIUS.
  3. Configure 802.1X SSID security settings with Cloud RADIUS primary and secondary IP addresses and shared secrets.
  4. Configure RADIUS Return Attributes: Tunnel-Type (64 = VLAN), Tunnel-Medium-Type (65 = 802), and Tunnel-Private-Group-ID (81 = target VLAN tag) mapped from Okta groups.
  5. Wireless controller RADIUS timeout can remain at standard enterprise default of 5 seconds with 3 retries.
Useful? Link to this tool

Okta और RADIUS: अपने आइडेंटिटी प्रोवाइडर को WiFi ऑथेंटिकेशन तक विस्तारित करना

कार्यकारी सारांश

वितरित स्थानों का प्रबंधन करने वाली एंटरप्राइज IT टीमों के लिए - होटल श्रृंखलाओं से लेकर स्टेडियमों तक - क्लाउड पहचान प्रदाता के साथ नेटवर्क एक्सेस कंट्रोल को एकीकृत करना Zero Trust की दिशा में एक महत्वपूर्ण कदम है। Okta RADIUS एजेंट आधुनिक क्लाउड पहचान और पारंपरिक 802.1X WiFi इन्फ्रास्ट्रक्चर के बीच के अंतर को पाटता है, जिससे संगठनों को नेटवर्क प्रमाणीकरण के लिए विरासत में मिले ऑन-प्रिमाइसेस RADIUS सर्वर और Active Directory इन्फ्रास्ट्रक्चर को हटाने की अनुमति मिलती है।

यह गाइड एंटरप्राइज WiFi प्रमाणीकरण के लिए Okta RADIUS एजेंट को तैनात करने के तरीके का विवरण देती है, जिसमें प्रॉक्सी आर्किटेक्चर, MFA प्रवर्तन तंत्र और पासवर्ड-आधारित EAP-TTLS व प्रमाणपत्र-आधारित EAP-TLS के बीच के समझौतों को कवर किया गया है। यह डायनेमिक VLAN असाइनमेंट के लिए Okta समूह सदस्यता को RADIUS विशेषताओं से मैप करने पर कार्रवाई योग्य मार्गदर्शन भी प्रदान करता है - एक ऐसी क्षमता जो सीधे PCI-DSS नेटवर्क सेगमेंटेशन आवश्यकताओं का समर्थन करती है। कर्मचारियों के प्रमाणीकरण के लिए Okta को Guest WiFi समाधानों के साथ एकीकृत करके, स्थल संचालक बिना पहचान इन्फ्रास्ट्रक्चर की नकल किए एक एकीकृत, सुरक्षित और अनुपालन योग्य एक्सेस लेयर प्राप्त कर सकते हैं।

तकनीकी गहन विश्लेषण

Okta RADIUS एजेंट कैसे काम करता है

Okta RADIUS एजेंट एक लाइटवेट सिस्टम सेवा है जो नेटवर्क एक्सेस सर्वर (NAS) - जैसे कि वायरलेस एक्सेस पॉइंट (WAPs) या वायरलेस LAN कंट्रोलर (WLCs) - और Okta क्लाउड के बीच एक प्रॉक्सी के रूप में कार्य करती है। इसे आमतौर पर ऑन-प्रिमाइसेस या क्लाउड VPC के भीतर Windows या Linux सर्वर पर तैनात किया जाता है, और प्रारंभिक इंस्टॉलेशन के बाद इसे पूरी तरह से Okta एडमिन कंसोल से प्रबंधित किया जाता है।

प्रमाणीकरण प्रवाह एक मानक 802.1X प्रॉक्सी मॉडल का अनुसरण करता है। उपयोगकर्ता का डिवाइस (सप्लीकेंट) एक एंटरप्राइज SSID से कनेक्ट होता है और क्रेडेंशियल प्रस्तुत करता है। WAP या WLC (प्रमाणक) UDP पोर्ट 1812 पर Okta RADIUS एजेंट को एक RADIUS Access-Request अग्रेषित करता है। एजेंट HTTPS API कॉल के माध्यम से इस अनुरोध को Okta क्लाउड पर सुरक्षित रूप से टनल करता है, जहां Okta का पॉलिसी इंजन अपनी उपयोगकर्ता निर्देशिका और किसी भी कॉन्फ़िगर की गई साइन-ऑन नीतियों के विरुद्ध क्रेडेंशियल्स का मूल्यांकन करता है। यदि प्रमाणीकरण सफल होता है, तो एजेंट प्रमाणक को एक RADIUS Access-Accept संदेश लौटाता है, जिसमें वैकल्पिक रूप से VLAN असाइनमेंट जैसी प्राधिकरण के लिए RADIUS विशेषताएं शामिल होती हैं। यदि MFA की आवश्यकता होती है, तो एजेंट क्लाइंट को वापस एक RADIUS Access-Challenge भेजता है, जिससे अंतिम निर्णय वापस आने से पहले दूसरे कारक के लिए संकेत मिलता है।

Okta और RADIUS: अपने आइडेंटिटी प्रोवाइडर को WiFi ऑथेंटिकेशन तक विस्तारित करना - architecture overview

इस प्रॉक्सी मॉडल का अर्थ है कि Okta RADIUS एजेंट को उपयोगकर्ता क्रेडेंशियल स्थानीय रूप से संग्रहीत करने की आवश्यकता नहीं है। सभी प्रमाणीकरण तर्क, नीति मूल्यांकन और ऑडिट लॉगिंग Okta क्लाउड में होते हैं, जिससे प्रशासकों को क्लाउड अनुप्रयोगों और नेटवर्क एक्सेस दोनों में पहचान प्रशासन के लिए एक सिंगल पेन ऑफ ग्लास मिलता है।

समर्थित EAP प्रोटोकॉल और महत्वपूर्ण सीमाएं

Okta RADIUS एजेंट की एक बुनियादी आर्किटेक्चरल सीमा प्राथमिक प्रमाणीकरण के लिए पासवर्ड ऑथेंटिकेशन प्रोटोकॉल (PAP) पर इसकी निर्भरता है। हालांकि PAP आंतरिक परत पर पासवर्ड को प्लेनटेक्स्ट में प्रसारित करता है, लेकिन इसे Extensible Authentication Protocol (EAP) के बाहरी TLS टनल द्वारा इनकैप्सुलेट और सुरक्षित किया जाता है। समर्थित बाहरी प्रोटोकॉल EAP-TTLS (आंतरिक विधि के रूप में PAP के साथ) और EAP-GTC हैं। EAP विधियों की गहन तुलना के लिए, Comparativa de métodos EAP: PEAP, EAP-TLS, EAP-TTLS y EAP-FAST संदर्भ मार्गदर्शिका देखें।

महत्वपूर्ण रूप से, PEAP-MSCHAPv2 समर्थित नहीं है। यह Windows क्लाइंट और कई लीगेसी एंटरप्राइज़ वातावरणों के लिए डिफॉल्ट 802.1X प्रोटोकॉल है। एक पारंपरिक NPS/Active Directory RADIUS सेटअप से माइग्रेट करने वाले संगठनों को PAP के साथ EAP-TTLS का उपयोग करने के लिए अपने क्लाइंट सप्लिकेंट्स को पुनर्गठित करना होगा - एक ऐसा बदलाव जिसके लिए आम तौर पर MDM या समूह नीति के माध्यम से भेजे गए एक वायरलेस प्रोफ़ाइल की आवश्यकता होती है। इसका ध्यान न रखना Okta RADIUS परिनियोजन के विफल होने का सबसे आम कारण है।

EAP-TLS, जो पूरी तरह से आपसी प्रमाणपत्र-आधारित प्रमाणीकरण पर निर्भर करता है, वह भी Okta RADIUS एजेंट द्वारा मूल रूप से समर्थित नहीं है। जिन संगठनों को EAP-TLS की आवश्यकता होती है, उन्हें एक समर्पित PKI या क्लाउड RADIUS समाधान तैनात करना होगा जो सीधे Okta RADIUS एजेंट का उपयोग करने के बजाय SAML या OIDC के माध्यम से IdP के रूप में Okta के साथ एकीकृत होता है।

WiFi कनेक्शन पर MFA लागू करना

Okta RADIUS एजेंट WiFi एक्सेस के लिए MFA का समर्थन करता है, लेकिन यह उपयोगकर्ता अनुभव से जुड़ी चुनौतियाँ पैदा करता है जिन पर परिनियोजन से पहले सावधानीपूर्वक विचार किया जाना चाहिए। जब कोई MFA नीति ट्रिगर होती है, तो एजेंट क्लाइंट को एक RADIUS Access-Challenge भेजता है। Okta RADIUS एप्लिकेशन्स के लिए कई कारकों का समर्थन करता है:

MFA फ़ैक्टर PAP EAP-TTLS नोट्स
Okta Verify Push समर्थित समर्थित आउट-ऑफ-बैंड भेजा गया; उपयोगकर्ता मोबाइल पर 'Approve' टैप करता है
TOTP (Okta Verify / Google Auth) समर्थित समर्थित उपयोगकर्ता पासवर्ड के अंत में OTP जोड़ता है (जैसे, Pass123,456789)
SMS / ईमेल / वॉयस समर्थित समर्थित उपयोगकर्ता पहले ट्रिगर स्ट्रिंग (SMS, EMAIL, CALL) भेजता है
Duo Push / SMS / पासकोड समर्थित समर्थित Duo पासकोड केवल EAP-TTLS के लिए
YubiKey / U2F / Windows Hello समर्थित नहीं समर्थित नहीं हार्डवेयर टोकन RADIUS प्रोटोकॉल के साथ असंगत हैं

व्यावहारिक सीमा रोमिंग है। Hospitality वातावरण में, एक हाउसकीपर का टैबलेट प्रति शिफ्ट दर्जनों बार एक्सेस पॉइंट्स के बीच रोम कर सकता है, जिससे हर बार पुनः प्रमाणीकरण ट्रिगर होता है। प्रत्येक रोम पर एक पुश नोटिफिकेशन स्वीकृति की आवश्यकता होना परिचालन की दृष्टि से अव्यावहारिक है। सामान्य स्टाफ WiFi के लिए, सक्रिय MFA संकेतों के बजाय Okta के डिवाइस ट्रस्ट और नेटवर्क ज़ोन नीतियों के साथ संयुक्त मजबूत पासवर्ड नीतियां आमतौर पर पसंद की जाती हैं। WiFi पर MFA को प्रशासनिक SSIDs या उच्च-अधिकार वाले एक्सेस परिदृश्यों के लिए आरक्षित किया जाना चाहिए।

पासवर्ड-आधारित बनाम प्रमाणपत्र-आधारित प्रमाणीकरण

पासवर्ड-आधारित RADIUS (Okta RADIUS एजेंट के माध्यम से) और सर्टिफिकेट-आधारित EAP-TLS के बीच का चयन एक एंटरप्राइज WiFi परिनियोजन में सबसे महत्वपूर्ण निर्णयों में से एक है। इनके बीच का समझौता केवल सुरक्षा के बारे में नहीं है; इसमें परिनियोजन की जटिलता, डिवाइस प्रबंधन की परिपक्वता और परिचालन ओवरहेड शामिल हैं।

Okta और RADIUS: अपने आइडेंटिटी प्रोवाइडर को WiFi ऑथेंटिकेशन तक विस्तारित करना - comparison chart

Okta RADIUS एजेंट के माध्यम से पासवर्ड-आधारित प्रमाणीकरण एकीकृत पहचान के लिए एक त्वरित मार्ग प्रदान करता है। यदि आपका संगठन पहले से ही Okta में उपयोगकर्ताओं को प्रबंधित करता है, तो परिनियोजन को हफ्तों के बजाय घंटों में पूरा किया जा सकता है। इसमें बनाने के लिए कोई PKI नहीं है, वितरित करने के लिए कोई सर्टिफिकेट नहीं है, और कोई MDM निर्भरता नहीं है। समझौता यह है कि पासवर्ड प्राथमिक क्रेडेंशियल बने रहते हैं, और आपसी प्रमाणीकरण की अनुपस्थिति का मतलब है कि क्लाइंट नेटवर्क की पहचान को क्रिप्टोग्राफिक रूप से सत्यापित नहीं कर सकता है - जो उच्च-जोखिम वाले वातावरण में एविल ट्विन (evil twin) हमलों के लिए एक माध्यम है।

सर्टिफिकेट-आधारित EAP-TLS, WiFi प्रमाणीकरण समीकरण से पासवर्ड को पूरी तरह से समाप्त कर देता है। क्लाइंट एक डिवाइस सर्टिफिकेट प्रस्तुत करता है, और RADIUS सर्वर एक सर्वर सर्टिफिकेट प्रस्तुत करता है, जिससे आपसी प्रमाणीकरण मिलता है। WPA3-Enterprise नेटवर्क पर 802.1X के लिए यह अनुशंसित दृष्टिकोण है, विशेष रूप से PCI-DSS या NCSC Cyber Essentials Plus के अधीन आने वाले वातावरणों में। इसके लिए एक कार्यात्मक PKI - या तो एक ऑन-प्रिमाइसेस Microsoft ADCS परिनियोजन या एक क्लाउड PKI सेवा - और सभी प्रबंधित एंडपॉइंट्स पर सर्टिफिकेट वितरित करने में सक्षम एक MDM प्लेटफॉर्म की पूर्व-आवश्यकता होती है। सैकड़ों प्रबंधित पॉइंट-ऑफ-सेल उपकरणों वाले Retail वातावरण के लिए, यह निवेश पूरी तरह से न्यायसंगत है। BYOD-प्रधान वातावरण या त्वरित परिनियोजन के लिए, EAP-TTLS के साथ Okta RADIUS एक व्यावहारिक विकल्प है।

डायनेमिक VLAN असाइनमेंट के लिए RADIUS एट्रिब्यूट मैपिंग

डायनेमिक VLAN असाइनमेंट वह जगह है जहाँ Okta RADIUS एकीकरण अपना सबसे वास्तविक परिचालन मूल्य प्रदान करता है। Okta समूह सदस्यता को RADIUS एट्रिब्यूट्स से मैप करके, नेटवर्क एडमिनिस्ट्रेटर प्रति डिवाइस या प्रति स्थान अलग-अलग VLAN नीतियां बनाए रखे बिना भूमिका-आधारित नेटवर्क विभाजन लागू कर सकते हैं।

Okta, RADIUS Access-Accept संदेश में समूह सदस्यता डेटा को तीन एट्रिब्यूट्स में से किसी एक का उपयोग करके पास करता है, जो Okta एप्लिकेशन की उन्नत RADIUS सेटिंग्स में कॉन्फ़िगर करने योग्य है:

  • Attribute 11 (Filter-Id): एक स्ट्रिंग एट्रिब्यूट जिसमें समूह का नाम होता है। विभिन्न वेंडर्स में व्यापक रूप से समर्थित।
  • Attribute 25 (Class): प्राधिकरण के लिए उपयोग किया जाने वाला एक अपारदर्शी एट्रिब्यूट। Cisco ISE, Aruba ClearPass, और Fortinet द्वारा समर्थित।
  • Attribute 26 (Vendor-Specific): अधिक बारीक नियंत्रण के लिए वेंडर-विशिष्ट उप-एट्रिब्यूट्स की अनुमति देता है।

नेटवर्क कंट्रोलर (WLC, NAC उपकरण) चुने गए एट्रिब्यूट में Okta समूह का नाम प्राप्त करता है और इसे VLAN असाइनमेंट के लिए आवश्यक मानक RADIUS टनल एट्रिब्यूट्स में मैप करता है:

RADIUS Attribute Value Purpose
64 (Tunnel-Type) 13 (VLAN) VLAN टनलिंग निर्दिष्ट करता है
65 (Tunnel-Medium-Type) 6 (802) IEEE 802 मीडियम को निर्दिष्ट करता है
81 (Tunnel-Private-Group-ID) जैसे, 40 लक्षित VLAN ID

उदाहरण के लिए, Okta ग्रुप Retail-POS-Staff वाले उपयोगकर्ता को Access-Accept में Class: Retail-POS-Staff वापस प्राप्त होगा। WLC पॉलिसी इसे Tunnel-Private-Group-ID: 40 पर मैप करेगी, जिससे डिवाइस VLAN 40 - पृथक POS नेटवर्क पर आ जाएगा। Store-Management वाले उपयोगकर्ता को VLAN 50 पर रखा जाएगा। यह लॉजिक नेटवर्क एज पर लागू किया जाता है, न कि Okta में, लेकिन यह पूरी तरह से Okta ग्रुप की सदस्यता द्वारा संचालित होता है।

अपने विशिष्ट सेटअप को लेकर कोई सवाल हैं?

हमारी टीम 80,000 से अधिक वेन्यू में वेन्यू ऑपरेटरों, IT मैनेजरों और नेटवर्क इंजीनियरों के साथ काम करती है। 20 मिनट का कॉल बुक करें और हम आपको दिखाएंगे कि आपके जैसे अन्य लोगों ने इसे कैसे हल किया।

इम्प्लीमेंटेशन गाइड

चरण 1: Okta RADIUS Agent को डिप्लॉय करें (हाई अवेलेबिलिटी)

हाई अवेलेबिलिटी सुनिश्चित करने के लिए Okta RADIUS agent को कम से कम दो सर्वरों पर - चाहे ऑन-प्रिमाइसेस हो या क्लाउड VPC में - डिप्लॉय करें। सिंगल-एजेंट डिप्लॉयमेंट एक गंभीर जोखिम है: यदि पैचिंग के लिए सर्वर अनुपलब्ध है या कोई खराबी आती है, तो पूरे एस्टेट में सभी 802.1X WiFi ऑथेंटिकेशन विफल हो जाएंगे। दोनों एजेंटों के बीच RADIUS अनुरोधों को लोड बैलेंस करने के लिए अपने WLC या NAC अप्लायंस को कॉन्फ़िगर करें।

इंस्टॉलेशन के दौरान, एजेंट को ऑथराइज करने और उसे Okta टेनेंट से लिंक करने के लिए एजेंट एक Okta एडमिनिस्ट्रेटर लॉगिन का संकेत देगा। एक बार ऑथराइज होने के बाद, एजेंट Okta एडमिन कंसोल में Settings > Downloads > RADIUS Agent Status के अंतर्गत दिखाई देता है, जहाँ इसके स्वास्थ्य और कनेक्टिविटी की निगरानी की जा सकती है।

चरण 2: Okta में RADIUS एप्लिकेशन को कॉन्फ़िगर करें

  1. Okta एडमिन कंसोल में, Applications > Applications पर जाएं और ऐप कैटलॉग में RADIUS Application खोजें।
  2. एप्लिकेशन जोड़ें, इसे एक वर्णनात्मक नाम दें (जैसे, Corporate-WiFi-Staff), और Next पर क्लिक करें।
  3. Sign On टैब के अंतर्गत, RADIUS Port (डिफ़ॉल्ट 1812) को कॉन्फ़िगर करें और कम से कम 32 कैरेक्टर का एक मजबूत, रैंडम रूप से जनरेट किया गया Shared Secret जनरेट करें।
  4. Advanced RADIUS Settings के अंतर्गत, Accept password and security token in the same login request को इनेबल करें यदि आप पासवर्ड के साथ जुड़े TOTP का समर्थन करना चाहते हैं।
  5. सहज पुश-आधारित MFA के लिए वैकल्पिक रूप से Permit Automatic Push for Okta Verify Enrolled Users को इनेबल करें।
  6. अपने कर्मचारियों का प्रतिनिधित्व करने वाले प्रासंगिक Okta ग्रुप्स को एप्लिकेशन असाइन करें।

चरण 3: ग्रुप-आधारित VLAN असाइनमेंट कॉन्फ़िगर करें

  1. RADIUS एप्लिकेशन की Sign On सेटिंग्स में, Advanced RADIUS Settings सेक्शन में Edit पर क्लिक करें।
  2. Include groups in RADIUS response को चेक करें।
  3. RADIUS एट्रिब्यूट चुनें: Aruba और Cisco परिवेशों के लिए 25 Class की सिफारिश की जाती है; Fortinet और अन्य के लिए 11 Filter-Id।
  4. शामिल करने के लिए विशिष्ट Okta ग्रुप के नाम जोड़ें (जैसे, Retail-POS-Staff, Store-Management, IT-Admins)।
  5. अपने WLC या NAC अप्लायंस पर, ऐसी एनफोर्समेंट पॉलिसियां बनाएं जो प्रत्येक ग्रुप नाम को संबंधित VLAN टनल एट्रिब्यूट्स से मैप करती हों।

चरण 4: क्लाइंट सप्लिकेंट्स को कॉन्फ़िगर करें

चूँकि PEAP-MSCHAPv2 असमर्थित है, इसलिए क्लाइंट डिवाइसों को आंतरिक पद्धति के रूप में EAP-TTLS with PAP का उपयोग करने के लिए कॉन्फ़िगर किया जाना चाहिए। अपने MDM प्लेटफॉर्म (जैसे, Microsoft Intune, Jamf Pro) के माध्यम से या Windows डोमेन-जॉइन्ड डिवाइसों के लिए Group Policy Objects (GPO) के माध्यम से एक वायरलेस नेटवर्क प्रोफाइल परिनियोजित करें। प्रोफाइल में निम्नलिखित निर्दिष्ट होना चाहिए:

  • SSID: आपके एंटरप्राइज SSID का नाम
  • सुरक्षा: WPA2-Enterprise या WPA3-Enterprise
  • EAP विधि: EAP-TTLS
  • आंतरिक प्रमाणीकरण: PAP
  • सर्वर प्रमाणपत्र सत्यापन: सक्षम (आपके RADIUS एजेंट के सर्वर प्रमाणपत्र CN से पिन करें)

चरण 5: RADIUS टाइमआउट सेट करें

अपने WLC पर RADIUS टाइमआउट को डिफ़ॉल्ट 3-5 सेकंड से बढ़ाकर 30-60 सेकंड करें। यदि MFA पुश नोटिफिकेशन का उपयोग किया जा रहा है तो यह महत्वपूर्ण है, क्योंकि उपयोगकर्ता के पास WLC द्वारा प्रमाणीकरण प्रयास को छोड़ने से पहले अपने डिवाइस पर नोटिफिकेशन को स्वीकृत करने के लिए पर्याप्त समय होना चाहिए।

सर्वोत्तम प्रथाएँ

WiFi प्रमाणीकरण के लिए Okta RADIUS को परिनियोजित करना सीधा है, लेकिन कई परिचालन संबंधी सर्वोत्तम प्रथाएँ एक लचीले उत्पादन परिनियोजन को एक नाजुक प्रूफ-ऑफ-कांसेप्ट से अलग करती हैं।

SSID स्तर पर अतिथि और कर्मचारी ट्रैफ़िक को विभाजित करें। Okta RADIUS एक कार्यबल पहचान टूल है। विज़िटर और अतिथि एक्सेस के लिए, एक समर्पित Captive Portal समाधान परिनियोजित करें। यह Okta लाइसेंस लागत को अतिथि संख्या के साथ बढ़ने से रोकता है और चिंताओं का स्पष्ट पृथक्करण सुनिश्चित करता है। Purple के एंटरप्राइज ग्राहक उसी भौतिक बुनियादी ढांचे पर कर्मचारियों के प्रमाणीकरण के लिए Okta RADIUS का उपयोग करते हुए एक अलग SSID पर Guest WiFi तैनात कर सकते हैं।

जटिल नीति परिवेशों के लिए NAC उपकरण का उपयोग करें। यदि आपके परिवेश को उपयोगकर्ता पहचान के साथ-साथ डिवाइस की स्थिति, MAC एड्रेस फ़िल्टरिंग, या प्रमाणपत्र स्थिति के आधार पर सशर्त पहुंच की आवश्यकता है, तो Okta RADIUS एजेंट को अनुरोधों को प्रॉक्सी करने के लिए एक मध्यवर्ती NAC उपकरण (Aruba ClearPass, Cisco ISE, या Portnox) तैनात करें। NAC उपकरण RADIUS प्रतिक्रिया को अतिरिक्त टनल विशेषताओं के साथ समृद्ध कर सकता है जिन्हें Okta एजेंट अकेले उत्पन्न नहीं कर सकता है।

Okta सिस्टम लॉग के माध्यम से निगरानी करें। प्रत्येक प्रमाणीकरण इवेंट - सफलता, विफलता, MFA चुनौती, और फ़ैक्टर प्रकार - Okta सिस्टम लॉग में रिकॉर्ड किया जाता है। प्रमाणीकरण विसंगतियों पर रीयल-टाइम अलर्टिंग के लिए अपने SIEM पर लॉग स्ट्रीमिंग कॉन्फ़िगर करें। यह ऑडिट आवश्यकताओं के अधीन Healthcare और सार्वजनिक क्षेत्र के संगठनों के लिए विशेष रूप से मूल्यवान है।

एक शेड्यूल पर साझा रहस्यों (shared secrets) को बदलें। Okta RADIUS एप्लिकेशन और आपके NAS के बीच साझा रहस्य एक महत्वपूर्ण सुरक्षा क्रेडेंशियल है। एक रोटेशन शेड्यूल लागू करें (तिमाही अनुशंसित है) और Okta एप्लिकेशन और WLC/NAC कॉन्फ़िगरेशन दोनों को एक साथ अपडेट करें।

RADIUS सेवा एड्रेस को प्रतिबंधित करें। Okta RADIUS एजेंट कॉन्फ़िगरेशन में, प्रतिबंधित करें कि किन IP एड्रेस को RADIUS अनुरोध भेजने की अनुमति है। यह अनधिकृत NAS डिवाइसों को आपके Okta टेनेंट के खिलाफ प्रमाणीकरण का प्रयास करने से रोकता है। व्यापक नेटवर्क आर्किटेक्चर संदर्भ पर मार्गदर्शन के लिए, The Core SD WAN Benefits for Modern Businesses और Wireless Access Points Definition Your Ultimate 2026 Guide देखें।

ट्रबलशूटिंग और जोखिम शमन

निम्न तालिका Okta RADIUS WiFi परिनियोजन में आने वाली सबसे आम विफलता मोड और उनके अनुशंसित शमन को संक्षेप में प्रस्तुत करती है।

विफलता मोड मूल कारण शमन
प्रमाणीकरण टाइमआउट Okta API या MFA प्रतिक्रिया के लिए WLC RADIUS टाइमआउट बहुत छोटा है WLC RADIUS टाइमआउट को बढ़ाकर 30-60 सेकंड करें
Windows क्लाइंट अस्वीकृत Windows डिफ़ॉल्ट रूप से PEAP-MSCHAPv2 पर सेट होता है, जिसे Okta RADIUS अस्वीकार कर देता है MDM या GPO के माध्यम से EAP-TTLS/PAP वायरलेस प्रोफ़ाइल पुश करें
गलत VLAN में उपयोगकर्ता Okta समूह नाम का बेमेल होना या WLC पर टनल एट्रिब्यूट्स का गायब होना सत्यापित करें कि WLC Tunnel-Private-Group-ID के लिए Class/Filter-Id को मैप करता है; Okta सिस्टम लॉग की जांच करें
एजेंट अनुपलब्ध सर्वर ऑफ़लाइन है, API टोकन समाप्त हो गया है, या फ़ायरवॉल Okta के लिए HTTPS को ब्लॉक कर रहा है अनावश्यक एजेंट तैनात करें; Okta एडमिन कंसोल में एजेंट स्थिति की निगरानी करें; आउटबाउंड HTTPS सत्यापित करें
MFA पुश डिलीवर नहीं हुआ उपयोगकर्ता Okta Verify में नामांकित नहीं है, या मोबाइल डिवाइस ऑफ़लाइन है Okta Verify नामांकन नीति लागू करें; फ़ॉलबैक के रूप में TOTP पर विचार करें
प्रमाणपत्र सत्यापन त्रुटियां क्लाइंट RADIUS सर्वर प्रमाणपत्र को सत्यापित नहीं कर सकता है क्लाइंट वायरलेस प्रोफ़ाइल में सर्वर प्रमाणपत्र CN को पिन करें; सुनिश्चित करें कि CA चेन विश्वसनीय है
VLAN एट्रिब्यूट्स नहीं भेजे गए RADIUS प्रतिक्रिया कॉन्फ़िगरेशन में Okta समूह शामिल नहीं है सत्यापित करें कि समूह Advanced RADIUS Settings में सूचीबद्ध है; पुष्टि करें कि उपयोगकर्ता Okta में समूह का सदस्य है

Transport और सार्वजनिक क्षेत्र के वातावरण के लिए जहां नेटवर्क अपटाइम मिशन-महत्वपूर्ण है, सिंथेटिक निगरानी लागू करें जो समय-समय पर RADIUS प्रमाणीकरण का एंड-टू-एंड परीक्षण करती है और उपयोगकर्ताओं के प्रभावित होने से पहले विफलता पर अलर्ट करती है।

ROI और व्यावसायिक प्रभाव

Okta RADIUS WiFi प्रमाणीकरण का व्यावसायिक मामला तीन स्तंभों पर आधारित है: परिचालन दक्षता, सुरक्षा स्थिति में सुधार, और अनुपालन तैयारी।

परिचालन दक्षता। Okta में WiFi प्रमाणीकरण को समेकित करने से प्रत्येक स्थल या साइट पर अलग से ऑन-प्रिमाइसेस RADIUS इन्फ्रास्ट्रक्चर (NPS सर्वर, स्थानीय AD) को बनाए रखने की आवश्यकता समाप्त हो जाती है। 50 संपत्तियों वाली एक होटल श्रृंखला के लिए, यह प्रति-साइट इन्फ्रास्ट्रक्चर लागत और IT सहायता ओवरहेड में महत्वपूर्ण कमी का प्रतिनिधित्व कर सकता है। उपयोगकर्ता का प्रावधान और वि-प्रावधान परमाणु बन जाते हैं: सही Okta समूह में एक उपयोगकर्ता को जोड़ने से एप्लिकेशन एक्सेस और उपयुक्त WiFi VLAN एक्सेस दोनों एक साथ मिल जाते हैं। जब कोई कर्मचारी छोड़ता है, तो उनके Okta खाते को निष्क्रिय करने से सभी साइटों पर तुरंत WiFi एक्सेस रद्द हो जाता है।सुरक्षा स्थिति (Security Posture)। साझा किए गए PSK WiFi पासवर्ड को प्रति-उपयोगकर्ता 802.1X प्रमाणीकरण से बदलने से क्रेडेंशियल साझाकरण समाप्त हो जाता है, जो आंतरिक खतरे और अनधिकृत पहुंच का एक सामान्य माध्यम है। डायनेमिक VLAN असाइनमेंट के साथ मिलकर, यह नेटवर्क परत पर न्यूनतम विशेषाधिकार के सिद्धांत को लागू करता है। Okta System Log प्रत्येक WiFi प्रमाणीकरण घटना का एक संपूर्ण, छेड़छाड़-मुक्त ऑडिट ट्रेल प्रदान करता है, जो घटना प्रतिक्रिया के लिए आवश्यक है।

अनुपालन तत्परता (Compliance Readiness)। PCI DSS 4.0 की आवश्यकता 8.3 सभी गैर-कंसोल प्रशासनिक पहुंच के लिए MFA को अनिवार्य बनाती है। आवश्यकता 1.3 के तहत कार्डधारक डेटा वातावरण और अन्य नेटवर्क के बीच नेटवर्क विभाजन की आवश्यकता होती है। समूह-आधारित VLAN असाइनमेंट के साथ Okta RADIUS सीधे इन दोनों आवश्यकताओं को पूरा करता है। GDPR अनुपालन के लिए, Okta System Log व्यक्तिगत डेटा प्रोसेसिंग प्रणालियों पर उपयुक्त तकनीकी नियंत्रण प्रदर्शित करने के लिए आवश्यक एक्सेस रिकॉर्ड प्रदान करता है। Modern Hospitality WiFi Solutions को तैनात करने वाले स्थानों के लिए, पहचान और नेटवर्क पहुंच का यह एकीकृत दृष्टिकोण उद्यम खरीद के लिए तेजी से एक अनिवार्य शर्त बनता जा रहा है।

जिन संगठनों ने इस एकीकरण को पूरा कर लिया है, वे आमतौर पर WiFi से संबंधित IT सपोर्ट टिकटों में कमी (कम पासवर्ड रीसेट अनुरोध, कम VLAN गलत कॉन्फ़िगरेशन घटनाएं) और सुरक्षा ऑडिट स्कोर में मापने योग्य सुधार की रिपोर्ट करते हैं। Okta RADIUS एजेंट को तैनात और कॉन्फ़िगर करने में किया गया निवेश - जो आम तौर पर एकल-साइट परिनियोजन के लिए हफ्तों के बजाय दिनों में मापा जाता है - निरंतर परिचालन बचत प्रदान करता है जो पूरे वितरित एस्टेट में जुड़ती जाती है।

मुख्य परिभाषाएं

Okta RADIUS Agent

एक लाइटवेट ऑन-प्रिमाइसेस या क्लाउड-होस्टेड प्रॉक्सी सेवा जो नेटवर्क इन्फ्रास्ट्रक्चर (एक्सेस पॉइंट्स, WLCs) से RADIUS ऑथेंटिकेशन अनुरोधों को Okta API कॉल्स में अनुवादित करती है, जिससे Okta क्लाउड 802.1X WiFi के लिए ऑथेंटिकेशन बैकएंड के रूप में कार्य करने में सक्षम होता है।

IT टीमों को इसका सामना तब करना पड़ता है जब वे Okta द्वारा समर्थित एंटरप्राइज WiFi ऑथेंटिकेशन को तैनात करते हैं। यह पुराने RADIUS-आधारित नेटवर्क इन्फ्रास्ट्रक्चर और आधुनिक क्लाउड पहचान के बीच महत्वपूर्ण ब्रिज घटक है।

802.1X

पोर्ट-आधारित नेटवर्क एक्सेस कंट्रोल (NAC) के लिए एक IEEE मानक जो वायर्ड और वायरलेस नेटवर्क के लिए एक ऑथेंटिकेशन फ्रेमवर्क को परिभाषित करता है। यह सप्लिकेंट (डिवाइस), ऑथेंटिकेटर (AP/स्विच) और ऑथेंटिकेशन सर्वर (RADIUS) के बीच ऑथेंटिकेशन क्रेडेंशियल्स ले जाने के लिए Extensible Authentication Protocol (EAP) का उपयोग करता है।

802.1X एंटरप्राइज WiFi सुरक्षा की नींव है। WPA2-Enterprise या WPA3-Enterprise का उपयोग करने वाला कोई भी परिनियोजन 802.1X का उपयोग कर रहा है। कनेक्टिविटी समस्याओं के निवारण के लिए IT टीमों को तीन-पक्षीय मॉडल (सप्लिकेंट, ऑथेंटिकेटर, ऑथेंटिकेशन सर्वर) को समझना चाहिए।

EAP-TTLS (Extensible Authentication Protocol - Tunnelled Transport Layer Security)

एक EAP विधि जो केवल सर्वर-साइड सर्टिफिकेट का उपयोग करके एक TLS टनल स्थापित करती है, फिर टनल के भीतर एक सरल आंतरिक ऑथेंटिकेशन प्रोटोकॉल (जैसे PAP) ले जाती है। यह आंतरिक क्रेडेंशियल्स को अनधिकृत रूप से देखे जाने से सुरक्षित रखता है, जबकि इसके लिए केवल सर्वर-साइड सर्टिफिकेट इन्फ्रास्ट्रक्चर की आवश्यकता होती है।

PAP के साथ EAP-TTLS, Okta RADIUS WiFi ऑथेंटिकेशन के लिए अनुशंसित प्रोटोकॉल है। यह सामान्य PAP की तुलना में अधिक सुरक्षित है लेकिन इसके लिए क्लाइंट-साइड सर्टिफिकेट की आवश्यकता नहीं होती है, जिससे यह BYOD और मिश्रित-डिवाइस परिवेशों के लिए व्यावहारिक बन जाता है।

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

एक EAP विधि जो पारस्परिक प्रमाणपत्र-आधारित प्रमाणीकरण का उपयोग करती है - क्लाइंट और सर्वर दोनों डिजिटल प्रमाणपत्र प्रस्तुत करते हैं। यह सबसे सुरक्षित 802.1X विधि है, जो फ़िशिंग-प्रतिरोधी, पासवर्ड-मुक्त प्रमाणीकरण प्रदान करती है।

EAP-TLS प्रबंधित कॉर्पोरेट डिवाइस परिवेशों के लिए स्वर्ण मानक है। इसके लिए प्रमाण पत्र वितरण के लिए एक PKI इन्फ्रास्ट्रक्चर और MDM की आवश्यकता होती है। Okta RADIUS एजेंट मूल रूप से EAP-TLS का समर्थन नहीं करता है; एक समर्पित क्लाउड PKI या RADIUS सेवा की आवश्यकता होती है।

PAP (Password Authentication Protocol)

एक सरल प्रमाणीकरण प्रोटोकॉल जो यूजरनेम और पासवर्ड को प्लेनटेक्स्ट में प्रसारित करता है। 802.1X के संदर्भ में, PAP का उपयोग EAP-TTLS टनल के भीतर आंतरिक प्रमाणीकरण विधि के रूप में किया जाता है, जहाँ बाहरी TLS परत एन्क्रिप्शन प्रदान करती है।

PAP मुख्य प्रमाणीकरण तंत्र है जो Okta RADIUS एजेंट द्वारा समर्थित है। IT टीमों को यह समझना चाहिए कि अकेले PAP असुरक्षित है, लेकिन EAP-TTLS के अंदर PAP उद्यम WiFi के लिए स्वीकार्य है जब सर्वर प्रमाणपत्र ठीक से सत्यापित हो।

Dynamic VLAN Assignment

एक नेटवर्क एक्सेस कंट्रोल तकनीक जहां एक RADIUS सर्वर Access-Accept संदेश में VLAN असाइनमेंट विशेषताओं को लौटाता है, जिससे वायरलेस कंट्रोलर या स्विच प्रमाणित क्लाइंट को एक स्थिर प्रति-SSID VLAN के बजाय उनकी पहचान या समूह सदस्यता के आधार पर एक विशिष्ट VLAN पर रखता है।

बहु-भूमिका वाले परिवेशों में नेटवर्क पृथक्करण के लिए Dynamic VLAN Assignment आवश्यक है (जैसे, सामान्य स्टाफ उपकरणों से POS टर्मिनलों को अलग करना)। इसे Access-Accept संदेश में RADIUS विशेषताओं 64, 65, और 81 को वापस करके कॉन्फ़िगर किया जाता है।

RADIUS Attribute 25 (Class)

एक मानक RADIUS विशेषता जिसका उपयोग प्रमाणीकरण सर्वर से NAS को मनमाना प्राधिकरण डेटा पास करने के लिए किया जाता है। Okta इस विशेषता का उपयोग वायरलेस कंट्रोलर को Okta समूह सदस्यता जानकारी वापस करने के लिए करता है, जो तब इसका उपयोग VLAN असाइनमेंट या एक्सेस नीति निर्णयों के लिए कर सकता है।

Okta समूह-आधारित VLAN असाइनमेंट को कॉन्फ़िगर करने वाली IT टीमें WLC को Class विशेषता मान पढ़ने और इसे एक VLAN ID से मैप करने के लिए कॉन्फ़िगर करेंगी। उपयोग की जाने वाली सटीक विशेषता (11, 25, या 26) WLC विक्रेता के दस्तावेज़ीकरण पर निर्भर करती है।

NAS (Network Access Server)

RADIUS शब्दावली में, NAS वह नेटवर्क डिवाइस है जो उपयोगकर्ता के कनेक्शन अनुरोध को प्राप्त करता है और प्रमाणीकरण के लिए इसे RADIUS सर्वर पर अग्रेषित करता है। WiFi परिनियोजन में, NAS आमतौर पर वायरलेस एक्सेस पॉइंट या वायरलेस LAN कंट्रोलर होता है।

NAS 802.1X मॉडल में प्रमाणक है। IT टीमों को RADIUS सर्वर IP पते, पोर्ट और साझा रहस्य के साथ NAS को कॉन्फ़िगर करना होगा। NAS IP पते को Okta RADIUS एजेंट की सेवा पता फ़िल्टरिंग कॉन्फ़िगरेशन में श्वेतसूचीबद्ध किया जाना चाहिए।

Shared Secret

एक पूर्व-साझा पासवर्ड जिसका उपयोग NAS (WLC/AP) और RADIUS सर्वर (Okta RADIUS एजेंट) के बीच RADIUS संदेशों को प्रमाणित करने के लिए किया जाता है। इसका उपयोग एक Message-Authenticator हैश की गणना करने के लिए किया जाता है जो RADIUS पैकेटों की अखंडता को सत्यापित करता है।

Shared secret दोनों Okta RADIUS एप्लिकेशन कॉन्फ़िगरेशन और WLC/NAC RADIUS सर्वर प्रविष्टि पर समान होना चाहिए। यह कम से कम 32 वर्णों का होना चाहिए, बेतरतीब ढंग से उत्पन्न होना चाहिए, और नियमित शेड्यूल पर घुमाया जाना चाहिए। बेमेल होना RADIUS प्रमाणीकरण विफलताओं का एक सामान्य कारण है।

MFA Challenge (RADIUS Access-Challenge)

अतिरिक्त प्रमाणीकरण कारकों की आवश्यकता होने पर प्रमाणीकरण सर्वर द्वारा NAS को भेजा जाने वाला एक RADIUS संदेश प्रकार। NAS क्लाइंट को चैलेंज रीले करता है, जिसे प्रमाणीकरण पूरा होने से पहले उपयुक्त कारक (जैसे, OTP, पुश अनुमोदन) के साथ प्रतिक्रिया देनी होगी।

Access-Challenge तंत्र वह तरीका है जिससे Okta RADIUS पर MFA लागू करता है। IT टीमों को यह सुनिश्चित करना होगा कि WLC चैलेंज-रिस्पॉन्स एक्सचेंज का समर्थन करता है और RADIUS टाइमआउट इतना लंबा है कि उपयोगकर्ता MFA चरण को पूरा कर सके।

हल किए गए उदाहरण

एक 150-प्रॉपर्टी वाली होटल चेन वर्तमान में 802.1X स्टाफ WiFi ऑथेंटिकेशन के लिए प्रत्येक प्रॉपर्टी पर ऑन-प्रिमाइसेस NPS सर्वर का उपयोग करती है। प्रत्येक NPS सर्वर एक स्थानीय Active Directory डोमेन से जुड़ा है। IT टीम Okta में आइडेंटिटी मैनेजमेंट को सेंट्रलाइज करना चाहती है और प्रति-प्रॉपर्टी NPS इंफ्रास्ट्रक्चर को समाप्त करना चाहती है। उन्हें इस माइग्रेशन को कैसे आगे बढ़ाना चाहिए?

अनुशंसित दृष्टिकोण प्रत्येक प्रॉपर्टी के बजाय एक सेंट्रलाइज्ड क्लाउड VPC में डिप्लॉय किए गए Okta RADIUS एजेंट का उपयोग करके चरणबद्ध माइग्रेशन है। चरण 1: अधिकांश प्रॉपर्टी वाले क्षेत्र में एक क्लाउड VPC (जैसे, AWS या Azure) में दो Okta RADIUS एजेंट इंस्टेंस डिप्लॉय करें। एजेंटों को UDP 1812 पर सुनने के लिए कॉन्फ़िगर करें। चरण 2: प्रत्येक प्रॉपर्टी के लिए, WLC पर सेकेंडरी RADIUS सर्वर के रूप में Okta RADIUS एजेंट IP जोड़ें, जबकि मौजूदा NPS को प्राइमरी के रूप में रखें। यह लाइव ऑथेंटिकेशन को बाधित किए बिना समानांतर संचालन और परीक्षण की अनुमति देता है। चरण 3: उपयोगकर्ताओं को स्थानीय AD से Okta में माइग्रेट करें। शुरुआत में मौजूदा खातों को सिंक करने के लिए Okta के AD एजेंट का उपयोग करें, फिर धीरे-धीरे Okta को अथॉरिटेटिव सोर्स के रूप में उपयोग करना शुरू करें। चरण 4: प्रत्येक प्रॉपर्टी के लिए, WLC को EAP-TTLS/PAP का उपयोग करने के लिए कॉन्फ़िगर करें और MDM के माध्यम से स्टाफ डिवाइस पर नया वायरलेस प्रोफाइल पुश करें। चरण 5: एक बार जब सभी डिवाइस EAP-TTLS पर कन्फर्म हो जाएं, तो WLC RADIUS प्रायोरिटी को Okta एजेंटों को प्राइमरी के रूप में स्विच करें और NPS सर्वर को डिकमिशन करें। Okta ग्रुप (Front-Desk, Housekeeping, F&B, Management, IT-Admins) कॉन्फ़िगर करें और एट्रिब्यूट 25 (क्लास) का उपयोग करके ग्रुप-आधारित VLAN असाइनमेंट सक्षम करें। WLC पर प्रत्येक ग्रुप को उचित VLAN से मैप करें। Okta API लेटेंसी को समायोजित करने के लिए WLC RADIUS टाइमआउट को 45 सेकंड तक बढ़ाएं।

परीक्षक की टिप्पणी: यह चरणबद्ध दृष्टिकोण इसलिए बेहतर है क्योंकि यह एक साथ 150 प्रॉपर्टी में हार्ड कटओवर के जोखिम को समाप्त करता है। ट्रांजिशन अवधि के दौरान NPS और Okta RADIUS को समानांतर रूप से चलाने का मतलब है कि किसी भी गलत कॉन्फ़िगरेशन को लाइव उपयोगकर्ताओं को प्रभावित किए बिना पकड़ा और सुधारा जा सकता है। RADIUS एजेंटों का क्लाउड VPC डिप्लॉयमेंट प्रति-प्रॉपर्टी डिप्लॉयमेंट की तुलना में आर्किटेक्चरल रूप से बेहतर है क्योंकि यह मैनेजमेंट को सेंट्रलाइज करता है, इंफ्रास्ट्रक्चर के प्रभाव को कम करता है, और लगातार पॉलिसी लागू करना सुनिश्चित करता है, चाहे कोई उपयोगकर्ता किसी भी प्रॉपर्टी से ऑथेंटिकेट कर रहा हो। कम करने के लिए मुख्य जोखिम प्रॉपर्टी और क्लाउड VPC के बीच WAN लेटेंसी है - अच्छे उपयोगकर्ता अनुभव के लिए RADIUS ऑथेंटिकेशन 2 सेकंड से कम समय में पूरा होना चाहिए, इसलिए VPC क्षेत्र का चयन राउंड-ट्रिप समय को कम करने वाला होना चाहिए।

320 स्टोर वाली एक राष्ट्रीय रिटेल चेन को अपने स्टाफ WiFi के लिए PCI DSS 4.0 अनुपालन प्राप्त करने की आवश्यकता है। स्टोर सहयोगी इन्वेंट्री मैनेजमेंट के लिए हैंडहेल्ड डिवाइस का उपयोग करते हैं, और डिवाइस का एक अलग सेट पॉइंट-ऑफ-सेल ट्रांजैक्शन को संभालता है। यह चेन वर्कफोर्स आइडेंटिटी के लिए Okta का उपयोग करती है। PCI DSS नेटवर्क सेगमेंटेशन आवश्यकताओं को पूरा करने के लिए वे Okta RADIUS का उपयोग करके VLAN सेगमेंटेशन कैसे लागू करते हैं?

तीन Okta ग्रुप बनाएं: POS-Staff (POS टर्मिनल संचालित करने वाले कर्मचारियों के लिए), Inventory-Staff (गोदाम और शॉप फ्लोर सहयोगियों के लिए), और Store-Management। Okta RADIUS एप्लिकेशन में, 'Include groups in RADIUS response' को सक्षम करें और Attribute 25 (Class) चुनें। रिस्पॉन्स कॉन्फ़िगरेशन में तीनों ग्रुप जोड़ें। प्रत्येक स्टोर पर वायरलेस कंट्रोलर पर (या क्लाउड WLC के माध्यम से केंद्रीय रूप से), तीन लागू करने वाली नीतियां बनाएं: (1) यदि Class = POS-Staff, तो Tunnel-Private-Group-ID = 40 असाइन करें (POS VLAN, जो PCI DSS के दायरे में है और जिसमें केवल भुगतान प्रोसेसर तक पहुंच को प्रतिबंधित करने वाले फ़ायरवॉल नियम हैं)। (2) यदि Class = Inventory-Staff, तो Tunnel-Private-Group-ID = 50 असाइन करें (इन्वेंट्री VLAN, PCI दायरे से बाहर)। (3) यदि Class = Store-Management, तो Tunnel-Private-Group-ID = 60 असाइन करें (स्टोर प्रबंधन प्रणालियों तक पहुंच वाला प्रबंधन VLAN)। POS-Staff ग्रुप में किसी उपयोगकर्ता के क्रेडेंशियल्स के साथ कनेक्ट होने वाले डिवाइस स्वचालित रूप से VLAN 40 पर रख दिए जाते हैं। यदि किसी स्टोर सहयोगी की भूमिका बदलती है, तो उनकी Okta ग्रुप सदस्यता को अपडेट करने से अगले कनेक्शन पर उनका VLAN असाइनमेंट तुरंत बदल जाता है - किसी WLC रीकॉन्फ़िगरेशन की आवश्यकता नहीं होती है। PCI DSS QSA ऑडिट के लिए नेटवर्क सेगमेंटेशन आरेख में Okta ग्रुप-टू-VLAN मैपिंग का दस्तावेजीकरण करें।

परीक्षक की टिप्पणी: यह कार्यान्वयन सीधे PCI DSS 4.0 Requirement 1.3 (नेटवर्क सेगमेंटेशन) और Requirement 7 (व्यावसायिक आवश्यकता के आधार पर एक्सेस कंट्रोल) को पूरा करता है। महत्वपूर्ण बात यह है कि VLAN असाइनमेंट पहचान से संचालित होता है, न कि डिवाइस MAC एड्रेस या स्टेटिक VLAN कॉन्फ़िगरेशन से - जिसका अर्थ है कि यह प्रति-स्टोर VLAN नीति रखरखाव के बिना 320 स्टोर्स में आसानी से स्केल हो जाता है। QSA यह देखने के लिए सबूत चाहेगा कि POS VLAN वास्तव में अन्य नेटवर्क सेगमेंट से अलग है, इसलिए WLC और फ़ायरवॉल कॉन्फ़िगरेशन में VLAN सीमाएं दिखाई देनी चाहिए। Okta का System Log वह ऑडिट ट्रेल प्रदान करता है जो PCI DSS Requirement 10 (लॉगिंग और मॉनिटरिंग) द्वारा आवश्यक है। एक महत्वपूर्ण चेतावनी: यदि POS डिवाइस अप्रबंधित या साझा किए गए हैं (यानी, किसी विशिष्ट उपयोगकर्ता को असाइन नहीं किए गए हैं), तो 802.1X के बजाय उन डिवाइसों के लिए MAC Authentication Bypass (MAB) का उपयोग करने पर विचार करें, जिसमें Okta RADIUS का उपयोग केवल उपयोगकर्ता-प्रमाणित डिवाइसों के लिए किया जाता है।

अभ्यास प्रश्न

Q1. एक मध्यम आकार का कॉन्फ्रेंस सेंटर सभी कर्मचारियों के पहचान प्रबंधन के लिए Okta का उपयोग करता है। वे अपने मौजूदा Cisco Meraki एक्सेस पॉइंट्स का उपयोग करके कर्मचारियों के लिए 802.1X WiFi तैनात करना चाहते हैं। उनके Windows लैपटॉप Microsoft Intune के माध्यम से प्रबंधित होते हैं। IT प्रबंधक सभी WiFi कनेक्शनों के लिए Okta Verify पुश MFA लागू करना चाहता है। वे कौन से तीन सबसे महत्वपूर्ण कॉन्फ़िगरेशन चरण हैं जिन्हें उन्हें पूरा करना होगा, और यदि वे उनमें से किसी को भी छोड़ देते हैं तो सबसे संभावित विफलता मोड क्या है?

संकेत: Okta RADIUS और Windows डिफ़ॉल्ट के बीच EAP प्रोटोकॉल संगतता, RADIUS टाइमआउट सेटिंग और क्लाइंट वायरलेस प्रोफाइल कॉन्फ़िगरेशन पर विचार करें।

मॉडल उत्तर देखें

तीन महत्वपूर्ण चरण हैं: (1) Intune के माध्यम से एक वायरलेस प्रोफ़ाइल तैनात करें जो Windows क्लाइंट्स को आंतरिक विधि के रूप में PAP के साथ EAP-TTLS का उपयोग करने के लिए कॉन्फ़िगर करती है - Windows डिफ़ॉल्ट रूप से PEAP-MSCHAPv2 का उपयोग करता है, जिसे Okta RADIUS एजेंट समर्थित नहीं करता है, जिससे सभी प्रमाणीकरण प्रयास अस्वीकार कर दिए जाते हैं। (2) Cisco Meraki RADIUS टाइमआउट को डिफ़ॉल्ट 5 सेकंड से बढ़ाकर कम से कम 45-60 सेकंड करें - इसके बिना, उपयोगकर्ता द्वारा Okta Verify पुश नोटिफिकेशन को स्वीकृत करने से पहले ही प्रमाणीकरण अनुरोध का समय समाप्त (टाइम आउट) हो जाएगा। (3) Okta RADIUS एप्लिकेशन के एडवांस RADIUS सेटिंग्स में 'Permit Automatic Push for Okta Verify Enrolled Users' को सक्षम करें - इसके बिना, उपयोगकर्ताओं को स्वचालित पुश प्राप्त होने के बजाय मैन्युअल रूप से अपने MFA फ़ैक्टर को चुनने के लिए प्रेरित किया जा सकता है। यदि चरण 1 को छोड़ दिया जाता है, तो सबसे संभावित विफलता मोड सभी Windows उपकरणों के लिए पूर्ण प्रमाणीकरण विफलता है। यदि चरण 2 को छोड़ दिया जाता है, तो उन उपयोगकर्ताओं के लिए प्रमाणीकरण रुक-रुक कर विफल होगा जो पुश को स्वीकृत करने में 5 सेकंड से अधिक का समय लेते हैं। यदि चरण 3 को छोड़ दिया जाता है, तो उपयोगकर्ताओं को एक सहज पुश नोटिफिकेशन के बजाय एक भ्रमित करने वाले चुनौती प्रॉम्प्ट का सामना करना पड़ेगा।

Q2. एक बड़ी रिटेल श्रृंखला की सुरक्षा टीम ने संकेत दिया है कि उनका वर्तमान Okta RADIUS WiFi परिनियोजन एक एकल RADIUS एजेंट सर्वर का उपयोग करता है। हाल ही के पैचिंग विंडो के दौरान, सर्वर 45 मिनट के लिए ऑफ़लाइन था, जिससे सभी 80 स्टोरों में WiFi प्रमाणीकरण विफल हो गया। IT टीम को इसे रोकने के लिए कौन से आर्किटेक्चरल बदलाव लागू करने चाहिए, और एजेंटों के लिए दो परिनियोजन विकल्प क्या हैं?

संकेत: एजेंट परिनियोजन टोपोलॉजी और अतिरेक (redundancy) का समर्थन करने के लिए आवश्यक WLC कॉन्फ़िगरेशन दोनों पर विचार करें।

मॉडल उत्तर देखें

IT टीम को कम से कम दो Okta RADIUS एजेंट इंस्टेंस तैनात करने चाहिए और प्रत्येक स्टोर पर WLC को दोनों एजेंटों का उपयोग करने के लिए कॉन्फ़िगर करना चाहिए। दो परिनियोजन विकल्प हैं: विकल्प A (केंद्रीकृत क्लाउड VMs) - एक क्लाउड VPC (जैसे, AWS या Azure) में दोनों एजेंट तैनात करें, आदर्श रूप से विभिन्न उपलब्धता क्षेत्रों (availability zones) में। प्रत्येक स्टोर पर WLC दोनों क्लाउड IPs को इंगित करता है, जिसमें एक प्राथमिक और एक माध्यमिक के रूप में (या लोड बैलेंसिंग सक्षम के साथ) होता है। यह प्रति-साइट बुनियादी ढांचे को कम करता है लेकिन WAN निर्भरता पेश करता है। विकल्प B (ऑन-प्रिमाइसेस रिडंडेंट पेयर) - एक केंद्रीय डेटा सेंटर या को-लोकेशन सुविधा में दो एजेंट सर्वर तैनात करें, जिसमें WLC, RADIUS फ़ेलओवर का उपयोग करता है। WLC पर, प्राथमिक RADIUS सर्वर को एजेंट 1 और माध्यमिक को एजेंट 2 के रूप में कॉन्फ़िगर करें, जिसमें 3-5 सेकंड का फ़ेलओवर टाइमआउट हो। यदि WLC विक्रेता द्वारा समर्थित हो, तो 'Dead Server Detection' सक्षम करें। इसके अतिरिक्त, IT टीम को Okta Admin Console में स्वास्थ्य निगरानी को कॉन्फ़िगर करना चाहिए और एजेंट के ऑफ़लाइन होने पर अलर्ट सेट करना चाहिए। स्थानीय सर्वर वाले स्टोरों के लिए, एक स्थानीय एजेंट WAN आउटेज के खिलाफ लचीलेपन के लिए तीसरे फ़ॉलबैक के रूप में काम कर सकता है।

Q3. एक उद्यम संगठन यह मूल्यांकन कर रहा है कि क्या अपने कॉर्पोरेट WiFi के लिए EAP-TTLS/PAP के साथ Okta RADIUS एजेंट का उपयोग किया जाए या EAP-TLS के लिए क्लाउड PKI समाधान में निवेश किया जाए। उनके पास Microsoft Intune में पंजीकृत 2,000 प्रबंधित Windows और macOS डिवाइस हैं, और वे PCI DSS 4.0 के अधीन हैं। अनुशंसित दृष्टिकोण क्या है और प्राथमिक सुरक्षा औचित्य क्या है?

संकेत: PCI DSS आवश्यकताओं, डिवाइस प्रबंधन परिपक्वता (सभी डिवाइस MDM-पंजीकृत हैं), और प्रत्येक प्रमाणीकरण विधि के सुरक्षा गुणों पर विचार करें।

मॉडल उत्तर देखें

अनुशंसित दृष्टिकोण क्लाउड PKI समाधान के साथ EAP-TLS में निवेश करना है। इसका प्राथमिक सुरक्षा औचित्य पारस्परिक प्रमाणीकरण (mutual authentication) है: EAP-TLS के लिए क्लाइंट और RADIUS सर्वर दोनों को डिजिटल प्रमाणपत्र प्रस्तुत करने की आवश्यकता होती है, जिसका अर्थ है कि डिवाइस नेटवर्क के सामने अपनी पहचान को क्रिप्टोग्राफिक रूप से सिद्ध करता है और नेटवर्क डिवाइस के सामने अपनी पहचान सिद्ध करता है। यह evil twin हमलों (जहाँ एक दुर्भावनापूर्ण AP कॉर्पोरेट SSID का प्रतिरूपण करता है) के जोखिम को समाप्त करता है और WiFi प्रमाणीकरण समीकरण से पासवर्ड को पूरी तरह से हटा देता है, जिससे क्रेडेंशियल चोरी और फ़िशिंग जैसे हमले के रास्ते समाप्त हो जाते हैं। PCI DSS 4.0 के लिए, EAP-TLS प्रमाणपत्र-आधारित प्रमाणीकरण के माध्यम से परोक्ष रूप से आवश्यकता 8.3 (नॉन-कंसोल एडमिन एक्सेस के लिए MFA) को पूरा करता है, और यह WPA3-Enterprise 192-बिट मोड (मजबूत क्रिप्टोग्राफी के लिए आवश्यकता 4.2.1) का समर्थन करता है। पूर्वापेक्षा - Intune में नामांकित सभी 2,000 डिवाइस - पहले से ही पूरी हो चुकी है, जिससे Intune SCEP प्रोफाइल के माध्यम से प्रमाणपत्र वितरण सीधा हो जाता है। PKI निर्माण के दौरान EAP-TTLS/PAP के साथ Okta RADIUS एजेंट एक स्वीकार्य अंतरिम समाधान होगा, लेकिन PCI DSS दायरे और पूरी तरह से प्रबंधित डिवाइस एस्टेट को देखते हुए, EAP-TLS ही सही दीर्घकालिक आर्किटेक्चर है। क्लाउड PKI सेवा में अतिरिक्त निवेश (आमतौर पर $3-8 प्रति डिवाइस प्रति वर्ष) सुरक्षा वृद्धि और क्रेडेंशियल प्रबंधन के कम ओवरहेड द्वारा उचित है।

अक्सर पूछे जाने वाले प्रश्न

Can I connect Okta directly to enterprise WiFi without an intermediate RADIUS server?

No. Enterprise wireless access points and controllers authenticate clients using the 802.1X protocol, which relies on RADIUS (Remote Authentication Dial-In User Service). Because Okta is a cloud identity provider operating over REST APIs and SAML or OIDC, it cannot speak the RADIUS protocol directly over UDP ports 1812 and 1813. You must deploy either the on-premises Okta RADIUS Server Agent or a cloud RADIUS service that translates network authentication requests into Okta API calls.

What is the difference between the on-premises Okta RADIUS agent and Cloud RADIUS?

The Okta RADIUS agent is a service that you host on an internal Windows or Linux virtual machine. It receives RADIUS requests from your wireless controllers and proxies them to the Okta API. Cloud RADIUS is a fully hosted, multi-region cloud service that requires zero on-premises virtual machines, offers native PKI integration for EAP-TLS client certificates, and scales globally with automated failover.

Which EAP authentication protocol should be used with the Okta RADIUS agent?

Okta recommends EAP-TTLS (Tunneled Transport Layer Security) with PAP as the inner authentication method when using the Okta RADIUS agent. EAP-TTLS establishes an encrypted TLS tunnel using a server-side certificate on the RADIUS agent, protecting user credentials in transit while allowing Okta to validate passwords directly against its cloud directory without requiring client-side certificates.

How does dynamic VLAN assignment work between Okta and wireless controllers?

Dynamic VLAN assignment allows your wireless LAN controller to place users onto specific network segments based on their Okta group membership. During 802.1X authentication, the RADIUS server returns standard attributes in the Access-Accept response: Tunnel-Type (Attribute 64 = VLAN), Tunnel-Medium-Type (Attribute 65 = 802), and Tunnel-Private-Group-ID (Attribute 81 = VLAN ID or name). Your controller assigns the client to that VLAN tag upon connection.

What RADIUS timeout settings are required when using Okta Verify push MFA for WiFi?

Standard RADIUS timeouts of 3 to 5 seconds are too short for interactive push notifications, causing the wireless controller to drop connections before the user can approve the prompt on their phone. When enabling Okta Verify push notifications for WiFi access, increase your wireless controller RADIUS retransmission timeout to at least 30 to 60 seconds and set retry attempts to 1 or 2 to avoid duplicate push notifications.

इस श्रृंखला में आगे पढ़ें

Enterprise डिप्लॉयमेंट के लिए IronWiFi के विकल्प

आप अपने नेटवर्क द्वारा किए जाने वाले कार्यों - authentication, identity, सहमति, हार्डवेयर कवरेज और तीन साल की लागत के आधार पर IronWiFi के विकल्प को शॉर्टलिस्ट करने में सक्षम होंगे। आप जानेंगे कि कब Purple, Cloud4Wi, Spotipo या Cloudi-Fi बेहतर बैठता है, कब IronWiFi अभी भी जीतता है, और प्रत्येक वेंडर के दावों को साबित करने वाले वन-वेन्यू पायलट को कैसे चलाया जाए।

गाइड पढ़ें →

Sophos Firewall और अतिथि WiFi: Purple के साथ कैप्टिव पोर्टल सेटअप

कैसे Purple का क्लाउड अतिथि WiFi एक मानक बाहरी कैप्टिव पोर्टल और RADIUS के माध्यम से Sophos Firewall और इसके एक्सेस पॉइंट्स के साथ काम करता है, और सहायता की जांच कहां करें और चरणों को कहां खोजें।

गाइड पढ़ें →

Aruba Central और Purple WiFi: क्लाउड-प्रबंधित एकीकरण

Aruba Central को Purple के क्लाउड-होस्टेड गेस्ट WiFi इंटेलिजेंस प्लेटफ़ॉर्म के साथ एकीकृत करने के लिए एक व्यापक तकनीकी संदर्भ मार्गदर्शिका। यह मार्गदर्शिका उद्यम IT टीमों के लिए आर्किटेक्चर, बाहरी कैप्टिव पोर्टल और RADIUS के चरण-दर-चरण कॉन्फ़िगरेशन, और मल्टी-साइट रोलआउट रणनीतियों को कवर करती है।

गाइड पढ़ें →

अपने विशिष्ट सेटअप को लेकर कोई सवाल हैं?

हमारी टीम 80,000 से अधिक वेन्यू में वेन्यू ऑपरेटरों, IT मैनेजरों और नेटवर्क इंजीनियरों के साथ काम करती है। 20 मिनट का कॉल बुक करें और हम आपको दिखाएंगे कि आपके जैसे अन्य लोगों ने इसे कैसे हल किया।