- Purple
- Enterprise WiFi security and authentication: a complete guide
- Okta और RADIUS: अपने आइडेंटिटी प्रोवाइडर को WiFi ऑथेंटिकेशन तक विस्तारित करना
Okta और RADIUS: अपने आइडेंटिटी प्रोवाइडर को WiFi ऑथेंटिकेशन तक विस्तारित करना
यह गाइड उन Okta-केंद्रित संगठनों के IT एडमिनिस्ट्रेटर के लिए एक व्यापक तकनीकी संदर्भ प्रदान करती है जो Okta RADIUS एजेंट का उपयोग करके अपने क्लाउड आइडेंटिटी प्रोवाइडर को WiFi ऑथेंटिकेशन तक विस्तारित करना चाहते हैं। इसमें संपूर्ण ऑथेंटिकेशन आर्किटेक्चर, MFA लागू करने के समझौते, RADIUS एट्रिब्यूट मैपिंग के माध्यम से डायनेमिक VLAN असाइनमेंट, और पासवर्ड-आधारित EAP-TTLS और सर्टिफिकेट-आधारित EAP-TLS के बीच महत्वपूर्ण निर्णय को शामिल किया गया है। वेन्यू ऑपरेटरों और एंटरप्राइज IT टीमों को व्यावहारिक डिप्लॉयमेंट गाइडेंस, हॉस्पिटैलिटी और रिटेल के वास्तविक केस स्टडीज, और समर्पित गेस्ट WiFi समाधानों के साथ Okta RADIUS को एकीकृत करने के लिए एक स्पष्ट फ्रेमवर्क मिलेगा।
Video overview
इस गाइड को सुनें
पॉडकास्ट ट्रांसक्रिप्ट देखें
हमारी मुख्य श्रृंखला का हिस्सा: एंटरप्राइज WiFi सुरक्षा गाइड →
- कार्यकारी सारांश
- तकनीकी गहन विश्लेषण
- Okta RADIUS एजेंट कैसे काम करता है
- समर्थित EAP प्रोटोकॉल और महत्वपूर्ण सीमाएं
- WiFi कनेक्शन पर MFA लागू करना
- पासवर्ड-आधारित बनाम प्रमाणपत्र-आधारित प्रमाणीकरण
- डायनेमिक VLAN असाइनमेंट के लिए RADIUS एट्रिब्यूट मैपिंग
- इम्प्लीमेंटेशन गाइड
- चरण 1: Okta RADIUS Agent को डिप्लॉय करें (हाई अवेलेबिलिटी)
- चरण 2: Okta में RADIUS एप्लिकेशन को कॉन्फ़िगर करें
- चरण 3: ग्रुप-आधारित VLAN असाइनमेंट कॉन्फ़िगर करें
- चरण 4: क्लाइंट सप्लिकेंट्स को कॉन्फ़िगर करें
- चरण 5: RADIUS टाइमआउट सेट करें
- सर्वोत्तम प्रथाएँ
- ट्रबलशूटिंग और जोखिम शमन
- ROI और व्यावसायिक प्रभाव
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 RADIUS with Okta Directory Sync and EAP-TLS
- Configure Cloud RADIUS tenant and establish OAuth 2.0 API connection to your Okta organization.
- Add wireless controller management IP addresses as authorised network access clients (NAS) in Cloud RADIUS.
- Configure 802.1X SSID security settings with Cloud RADIUS primary and secondary IP addresses and shared secrets.
- 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.
- Wireless controller RADIUS timeout can remain at standard enterprise default of 5 seconds with 3 retries.

कार्यकारी सारांश
वितरित स्थानों का प्रबंधन करने वाली एंटरप्राइज 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 एजेंट को उपयोगकर्ता क्रेडेंशियल स्थानीय रूप से संग्रहीत करने की आवश्यकता नहीं है। सभी प्रमाणीकरण तर्क, नीति मूल्यांकन और ऑडिट लॉगिंग 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 एजेंट के माध्यम से पासवर्ड-आधारित प्रमाणीकरण एकीकृत पहचान के लिए एक त्वरित मार्ग प्रदान करता है। यदि आपका संगठन पहले से ही 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 एप्लिकेशन को कॉन्फ़िगर करें
- Okta एडमिन कंसोल में, Applications > Applications पर जाएं और ऐप कैटलॉग में RADIUS Application खोजें।
- एप्लिकेशन जोड़ें, इसे एक वर्णनात्मक नाम दें (जैसे,
Corporate-WiFi-Staff), और Next पर क्लिक करें। - Sign On टैब के अंतर्गत, RADIUS Port (डिफ़ॉल्ट 1812) को कॉन्फ़िगर करें और कम से कम 32 कैरेक्टर का एक मजबूत, रैंडम रूप से जनरेट किया गया Shared Secret जनरेट करें।
- Advanced RADIUS Settings के अंतर्गत, Accept password and security token in the same login request को इनेबल करें यदि आप पासवर्ड के साथ जुड़े TOTP का समर्थन करना चाहते हैं।
- सहज पुश-आधारित MFA के लिए वैकल्पिक रूप से Permit Automatic Push for Okta Verify Enrolled Users को इनेबल करें।
- अपने कर्मचारियों का प्रतिनिधित्व करने वाले प्रासंगिक Okta ग्रुप्स को एप्लिकेशन असाइन करें।
चरण 3: ग्रुप-आधारित VLAN असाइनमेंट कॉन्फ़िगर करें
- RADIUS एप्लिकेशन की Sign On सेटिंग्स में, Advanced RADIUS Settings सेक्शन में Edit पर क्लिक करें।
- Include groups in RADIUS response को चेक करें।
- RADIUS एट्रिब्यूट चुनें: Aruba और Cisco परिवेशों के लिए 25 Class की सिफारिश की जाती है; Fortinet और अन्य के लिए 11 Filter-Id।
- शामिल करने के लिए विशिष्ट Okta ग्रुप के नाम जोड़ें (जैसे,
Retail-POS-Staff,Store-Management,IT-Admins)। - अपने 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 सेकंड तक बढ़ाएं।
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 मैपिंग का दस्तावेजीकरण करें।
अभ्यास प्रश्न
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 मिनट का कॉल बुक करें और हम आपको दिखाएंगे कि आपके जैसे अन्य लोगों ने इसे कैसे हल किया।