Okta WiFi प्रमाणीकरण: सेटअप चरण, विकल्प और समाधान
Published
Okta WiFi प्रमाणीकरण पर लोकप्रिय सलाह यह है कि अपने एक्सेस पॉइंट्स को Okta पर पॉइंट करें, MFA चालू करें, और साझा पासवर्ड को हटा दें। अपनी रोलआउट योजना केवल इस वाक्य के आधार पर न बनाएं। Okta आपके एक्सेस पॉइंट्स पर एक वायरलेस प्रमाणक नहीं है, एक नेटिव 802.1X सप्लीकेंट अक्सर एक इंटरैक्टिव चैलेंज को स्पष्ट रूप से प्रदर्शित नहीं कर पाता है, और जो हिस्सा पूरी साइट को डिस्कनेक्ट करता है वह आमतौर पर प्रमाणपत्र ट्रस्ट या एक खराब डिवाइस प्रोफ़ाइल होती है, न कि MFA प्रॉम्प्ट।
इसका मतलब यह नहीं है कि पहचान-आधारित WiFi गलत दिशा है। Okta Secure Sign-In Trends Report 2024 में बताया गया है कि जनवरी 2024 तक Okta Workforce Identity के 66% उपयोगकर्ताओं ने मल्टीफैक्टर प्रमाणीकरण के साथ साइन इन किया, जबकि प्रशासकों के बीच यह अपनाव 91% तक पहुँच गया। वे आंकड़े एप्लिकेशन साइन-इन का वर्णन करते हैं, WiFi सत्रों का नहीं, लेकिन वे दिखाते हैं कि पहचान आश्वासन उसी डायरेक्टरी में अकेले पासवर्ड की जगह ले रहा है जिसे आप नेटवर्क नीति के लिए उपयोग करेंगे।
मैं एक कठिन प्रश्न से शुरुआत करूंगा। कौन सा घटक EAP एक्सचेंज को समाप्त करता है, कौन सा सिस्टम डिवाइस पर ट्रस्ट जारी और नवीनीकृत करता है, और जब दोनों में से कोई भी बदलता है तो क्या होता है? एक लैब में इन तीनों का उत्तर दें और Okta WiFi प्रमाणीकरण प्रबंधनीय हो जाता है। इन्हें छोड़ दें और आप एक समय में एक ऑपरेटिंग सिस्टम के उत्पादन SSID को डिबग करेंगे।
विषय-सूची
- वह Okta एकीकरण पाथ चुनें जो आपका नेटवर्क सपोर्ट करता है
- कनेक्ट करने से पहले प्रमाणपत्र ट्रस्ट और डिवाइस ऑनबोर्डिंग
- Okta RADIUS एजेंट को चरण-दर-चरण कैसे सेट करें
- सशर्त पहुंच (कंडीशनल एक्सेस) और डिवाइस स्थिति नियम सेट करें
- विफल Okta WiFi लॉगिन का निवारण (ट्रबलशूटिंग)
- साइटों का विस्तार करने से पहले पायलट की पुष्टि करें
वह Okta एकीकरण पथ चुनें जिसका आपका नेटवर्क समर्थन करता है
Okta अकेले आपके एक्सेस पॉइंट्स पर 802.1X नहीं चलाता है। एक वायरलेस कंट्रोलर, एक्सेस पॉइंट, या अलग RADIUS सेवा को ऑथेंटिकेटर के रूप में कार्य करना होगा, प्रत्येक अनुरोध को फॉरवर्ड करना होगा, और वापस आने वाले Access-Accept, Access-Reject, VLAN, या भूमिका को लागू करना होगा। Okta पहचान का निर्णय प्रदान करता है। यह WLAN का सामना करने वाले प्रोटोकॉल कार्य को नहीं हटाता है।
इसीलिए पहला विकल्प कोई Okta सेटिंग नहीं है। यह वह आर्किटेक्चर है जिसे आपका कंट्रोलर और क्लाइंट वास्तव में पूरा कर सकते हैं। Okta Cisco Meraki RADIUS इंटीग्रेशन दस्तावेज़ एक 802.1X EAP सुरक्षा कॉन्फ़िगरेशन का वर्णन करता है जहां वायरलेस क्लाइंट नेटवर्क प्रमाणीकरण के दौरान एक Okta उपयोगकर्ता नाम और पासवर्ड प्रदान करता है। यह एक विशिष्ट दस्तावेज़ीकृत Meraki मार्ग है, न कि इस बात का प्रमाण कि प्रत्येक कंट्रोलर और EAP विधि समान रूप से काम करेगी।
विभिन्न समस्याओं को हल करने वाले चार मार्ग
| विकल्प | Credential Okta जांच करता है | सबसे उपयुक्त | मुख्य सीमा |
|---|---|---|---|
| Okta RADIUS Server Agent | PAP पर उपयोगकर्ता नाम और पासवर्ड | लैब-सत्यापित PAP पाथ के साथ लेगेसी कंट्रोलर्स | Okta दस्तावेज़ीकरण समर्थित के रूप में Wi-Fi इंफ्रास्ट्रक्चर को सूचीबद्ध नहीं करता है |
| Cisco Meraki 802.1X पर Okta क्रेडेंशियल्स | EAP एक्सचेंज में Okta उपयोगकर्ता नाम और पासवर्ड | Meraki WLANs जो Okta के दस्तावेज़ित EAP सुरक्षा सेटअप का पालन करते हैं | Okta दस्तावेज़ों के Meraki कॉन्फ़िगरेशन से बंधा हुआ है |
| Captive Portal पर SAML या SSO साइन-इन | आइडेंटिटी प्रदाता के माध्यम से ब्राउज़र साइन-इन | गेस्ट और BYOD ऑनबोर्डिंग | 802.1X पर स्टाफ डिवाइसों को प्रमाणित नहीं करता है |
| डायरेक्टरी ग्रुप मेंबरशिप के साथ MDM-जारी किए गए सर्टिफिकेट्स | MDM द्वारा जारी किया गया EAP-TLS क्लाइंट सर्टिफिकेट | कई साइटों पर प्रबंधित स्टाफ डिवाइस | एक सर्टिफिकेट अथॉरिटी, MDM प्रोफ़ाइल डिलीवरी और एक नवीनीकरण योजना की आवश्यकता है |
RADIUS एजेंट पंक्ति को ध्यान से पढ़ें। इसे एक लेगेसी नेटवर्क एक्सेस ब्रिज के रूप में मानें, न कि एक मूल WiFi पहचान प्लेन के रूप में। प्रमाणपत्र आधारित EAP-TLS के आसपास निर्मित एक पारंपरिक WPA2 या WPA3-Enterprise डिज़ाइन को सीधे एक ऐसे एजेंट के साथ काम करने के लिए नहीं माना जा सकता है जिसका दस्तावेजीकृत प्रोटोकॉल PAP है, जिसमें केवल विशेष RADIUS एप्लिकेशन परिदृश्यों के लिए EAP-TTLS और EAP-GTC सूचीबद्ध हैं।
Captive portal SSO एक अलग काम पूरा करता है। यह मेहमानों और अनमैनेज्ड BYOD को इंटरनेट एक्सेस से पहले एक ब्राउज़र यात्रा देता है, और यह रिकॉर्ड कर सकता है कि कौन कनेक्टेड है। यह कर्मचारियों के लैपटॉप को पहले पैकेट से एन्क्रिप्टेड 802.1X एक्सेस नहीं देता है, और हेडलैस डिवाइस इसे पूरा नहीं कर सकते हैं। कर्मचारियों के नेटवर्क प्रमाणीकरण के स्थान पर किसी साफ सुथरे पोर्टल डेमो को स्वीकार न करें।
निर्णय लेने के लिए तीन मानदंडों का उपयोग करें
- कंट्रोलर और EAP सपोर्ट: सटीक कंट्रोलर मॉडल, फर्मवेयर, सप्लिकेंट और EAP विधि की एक साथ पुष्टि करें। 802.1X के लिए एक डेटाशीट दावा आपके PAP, EAP-TTLS, या EAP-TLS पथ को साबित नहीं करता है।
- डिवाइस मैनेजमेंट: मैनेज्ड लैपटॉप और फोन ऑटोमैटिक रूप से सर्टिफ़िकेट और ट्रस्ट प्रोफ़ाइल प्राप्त कर सकते हैं। अनमैनेज्ड डिवाइस को पासवर्ड आधारित ऑनबोर्डिंग या एक पोर्टल लेन की आवश्यकता होती है।
- प्रभाव का दायरा: उन साइटों, SSIDs और कंट्रोलर प्रकारों की गणना करें जो एक साथ बदलते हैं। अधिक साइटें मैन्युअल सेटअप के बजाय केंद्रीकृत प्रोफ़ाइल और प्रमाण पत्र वितरण का समर्थन करती हैं।
निर्णय नियम: RADIUS एजेंट का उपयोग केवल तब करें जब लैब सटीक कंट्रोलर और क्लाइंट संयोजन को साबित कर दे। मैनेज्ड स्टाफ डिवाइसों के लिए, पहले प्रमाणपत्र पथ की योजना बनाएं और पासवर्ड को फ़ॉलबैक के रूप में लें।
कनेक्ट करने से पहले प्रमाणपत्र ट्रस्ट और डिवाइस ऑनबोर्डिंग
हेल्प डेस्क तक पहुँचने वाली अधिकांश Okta WiFi विफलताएँ MFA विफलताएँ नहीं होती हैं। वे ट्रस्ट (trust) विफलताएँ होती हैं। डिवाइस RADIUS सर्वर प्रमाणपत्र पर भरोसा नहीं करता है, 802.1X प्रोफ़ाइल गलत EAP विधि या सर्वर का नाम देती है, क्लाइंट प्रमाणपत्र नहीं पहुँचा है, या उपयोगकर्ता ने उस फैक्टर को नामांकित नहीं किया है जिसकी नीति को आवश्यकता है। Okta पहचान का सही मूल्यांकन कर सकता है, जबकि डिवाइस कभी भी पूछने के लिए पर्याप्त आगे नहीं बढ़ता है।
नामांकन बिंदु दस्तावेज़ित है, सैद्धांतिक नहीं। Okta RADIUS एप्लिकेशन दस्तावेज़ीकरण बताता है कि EAP-TTLS पासवर्ड और पासकोड प्रमाणीकरण का समर्थन करता है जबकि EAP-TTLS नामांकन का समर्थन नहीं करता है, इसलिए जब उपयोगकर्ता आवश्यक फ़ैक्टर में पहले से नामांकित नहीं होते हैं तो प्रमाणीकरण विफल हो सकता है। Okta का Meraki ट्रबलशूटिंग भी एक अमान्य या अविश्वसनीय सर्टिफिकेट और गलत तरीके से तैनात 802.1X प्रोफ़ाइल को विफल कनेक्शन के कारणों के रूप में पहचानता है। पहले एनरोल करें। बाद में कनेक्ट करें।
दो EAP विकल्पों की ईमानदारी से तुलना करें
| तरीका | भेजा गया क्रेडेंशियल | पहले कनेक्ट से पूर्व एनरोलमेंट | यह कहाँ उपयुक्त है | योजना न बनाने पर विफलता |
|---|---|---|---|---|
| पासवर्ड या पासकोड के साथ EAP-TTLS | TLS टनल के भीतर Okta पासवर्ड या पासकोड | आवश्यक, क्योंकि EAP-TTLS एनरोलमेंट का समर्थन नहीं करता है | एनरोल किए गए उपयोगकर्ताओं के साथ मिश्रित या अनमैनेज्ड डिवाइस | जो उपयोगकर्ता अभी तक फैक्टर में एनरोल नहीं हैं, वे कनेक्ट नहीं कर सकते |
| MDM जारी प्रमाणपत्र के साथ EAP-TLS | SCEP पर जारी क्लाइंट प्रमाणपत्र | आवश्यक, MDM द्वारा पुश किए गए प्रमाणपत्र के साथ | बड़े पैमाने पर मैनेज्ड कॉर्पोरेट डिवाइस | एक समाप्त हो चुका सर्वर या क्लाइंट प्रमाणपत्र पूरी साइट पर एक्सेस हटा देता है |
EAP-TTLS पासवर्ड को डिज़ाइन में रखता है। वे फ़िशिंग, पुनरुपयोग, हेल्प डेस्क रीसेट, और WiFi सप्लीकेंट पर कठिन चैलेंज हैंडलिंग के संपर्क में आते हैं। EAP-TLS वायरलेस एक्सचेंज से पासवर्ड को हटा देता है और म्यूचुअल प्रमाणीकरण प्रदान करता है, लेकिन यह कार्य को आपके सर्टिफिकेट अथॉरिटी, SCEP जारी करने, नवीनीकरण, और निरसन पाइपलाइन में स्थानांतरित कर देता है। दोनों में से कोई भी मुफ़्त नहीं है। आप यह चुन रहे हैं कि परिचालन बोझ कहाँ रहेगा।
वह जीवनचक्र बनाएं जिसे अधिकांश गाइड छोड़ देते हैं
- सर्टिफिकेट अथॉरिटी चुनें: तय करें कि कौन सा CA RADIUS सर्वर सर्टिफिकेट पर हस्ताक्षर करता है और कौन सा CA क्लाइंट सर्टिफिकेट जारी करता है। प्रोफ़ाइल में उन्हें मिश्रित न करें, और सार्वजनिक सर्वर सर्टिफिकेट की समाप्ति से आश्चर्यचकित न हों।
- नवीनीकरण पहले से निर्धारित करें: समाप्त होने से बहुत पहले सर्वर सर्टिफिकेट का नवीनीकरण करें, पुराना काम करते समय नया ट्रस्ट एंकर पुश करें, और पुष्टि करें कि डिवाइस अपेक्षित सर्वर नाम को सत्यापित करते हैं।
- MDM के माध्यम से प्रोफ़ाइल पुश करें: SSID, EAP प्रकार, विश्वसनीय CA, सर्वर नाम और SCEP सर्टिफिकेट देने के लिए Intune, Jamf या अपने मौजूदा MDM का उपयोग करें। मैनुअल इंस्टॉलेशन स्केलेबल नहीं है और इसका ऑडिट नहीं किया जा सकता है।
- लागू करने से पहले ऑनबोर्डिंग का क्रम तय करें: डिवाइसों को एक अस्थायी ऑनबोर्डिंग पाथ दें, पुष्टि करें कि प्रोफ़ाइल और सर्टिफिकेट आ गए हैं, फिर स्टाफ SSID लागू करें। बिना ट्रस्ट वाला डिवाइस अपने ट्रस्ट को प्राप्त करने के लिए स्टाफ नेटवर्क का उपयोग नहीं कर सकता है।
- रद्दीकरण और रिकवरी की योजना बनाएं: परिभाषित करें कि डिवाइस खो जाने, सर्टिफिकेट रद्द होने, CA बदलने या MDM प्रोफ़ाइल हटा दिए जाने पर क्या होगा। स्पेयर डिवाइस पर पुनः जारी करने का परीक्षण करें।
किसी भी साइट परिवर्तन से पहले एक परीक्षण मैट्रिक्स चलाएं। Windows, macOS, iOS, और Android का परीक्षण करें, प्रत्येक को प्रबंधित और गैर-प्रबंधित के रूप में, पहली बार कनेक्ट करने, फिर से कनेक्ट करने, एक्सेस पॉइंट्स के बीच रोमिंग करने और सिम्युलेटेड प्रमाणपत्र नवीनीकरण के बाद परखें। इसमें एक अन-एनरोल उपयोगकर्ता और प्रोफ़ाइल हटाए गए एक डिवाइस को शामिल करें।
मान लीजिए कि शुक्रवार को एक शाखा में बिना किसी चेतावनी के प्रोफ़ाइल पुश विफल हो जाता है। सोमवार को, उस स्थान पर प्रत्येक मैनेज्ड डिवाइस सर्वर सर्टिफिकेट को अस्वीकार कर देता है, जबकि प्रोफ़ाइल प्राप्त करने वाला मुख्यालय ठीक से काम करता है। Okta नीति नहीं बदली है। ट्रस्ट की डिलीवरी बदली है। यही कारण है कि प्रोफ़ाइल रिपोर्टिंग आपके गो लाइव मानदंडों में शामिल होनी चाहिए, न कि किसी घटना के बाद की समीक्षा में।
Okta RADIUS एजेंट को चरण दर चरण कैसे सेट करें
अनुरोध पथ (request path) से शुरुआत करें, क्योंकि जब लॉगिन विफल होता है तो यह आपको बताता है कि कहाँ देखना है। कंट्रोलर Okta RADIUS Server Agent को एक RADIUS अनुरोध भेजता है, एजेंट Okta APIs को कॉल करता है, Okta नीति का मूल्यांकन करता है, एक वैकल्पिक MFA चुनौती नेटवर्क डिवाइस के माध्यम से वापस आती है, और एजेंट कंट्रोलर को वापस Access-Accept या Access-Reject भेजता है। अन्य के टूटे बिना भी प्रत्येक होप (hop) विफल हो सकता है।
नीचे दिया गया परिनियोजन अनुक्रम Okta के नेटवर्क एक्सेस सर्वर गाइड में दिए गए मॉडल का अनुसरण करता है, जो एजेंट को UDP port 1812 पर नेटवर्क एक्सेस सर्वर और Okta नीति मूल्यांकन के बीच रखता है। इसे एक लैब में, इसी क्रम में बनाएं, जिसमें पहले परीक्षण से ही पैकेट और एजेंट लॉगिंग उपलब्ध हो।
क्रम में लैब पाथ का निर्माण करें
- एजेंट को एक सर्विस के रूप में इंस्टॉल करें। Okta RADIUS Server Agent को ऐसे Windows या Linux होस्ट पर इंस्टॉल करें जो वायरलेस कंट्रोलर और Okta दोनों तक पहुंच सके। इसे ऐसे वर्कस्टेशन में न छिपाएं जो स्लीप मोड में चला जाता है, अनपेक्षित रूप से पैच होता है, या किसी अनडॉक्यूमेंटेड फ़ायरवॉल नियम के पीछे है। सामान्य गलती सर्वर कंसोल से Okta पहुंच क्षमता को साबित करना है, लेकिन कंट्रोलर से एजेंट की पहुंच क्षमता को कभी साबित न करना है।
- Okta में RADIUS एप्लिकेशन बनाएं। एप्लिकेशन बनाएं, एजेंट के लिए आवश्यक सेटिंग्स को नोट करें, और नाम को उसके द्वारा दिए जाने वाले SSID और साइट स्कोप से जोड़कर रखें। अस्पष्ट ऐप नाम बाद में लॉग खोज को धीमा कर देते हैं। केवल इसलिए Wi-Fi के लिए VPN RADIUS ऐप का पुनः उपयोग न करें क्योंकि दोनों RADIUS का उपयोग करते हैं।
- कंट्रोलर को RADIUS क्लाइंट के रूप में कॉन्फ़िगर करें। वायरलेस कंट्रोलर या नेटवर्क एक्सेस सर्वर को एजेंट IP एड्रेस पर पॉइंट करें, UDP 1812 सेट करें, और दोनों सिरों पर एक मिलान गुप्त साझा कुंजी दर्ज करें। गुप्त कुंजी को टाइप करें, इसे किसी ऐसे चैट संदेश से पेस्ट न करें जो अंत में स्पेस जोड़ सकता है। एक गुप्त कुंजी का बेमेल होना अक्सर क्लाइंट पर गलत पासवर्ड जैसा दिखता है।
- सोर्स को सीमित करें। क्लाइंट सोर्स IP या Okta नेटवर्क ज़ोन को केवल कंट्रोलर एड्रेस तक सीमित करें। यह मनमाने आंतरिक होस्ट को एजेंट को प्रमाणीकरण अनुरोध भेजने से रोकता है। सामान्य त्रुटि टेस्टिंग के दौरान प्रबंधन सबनेट की अनुमति देना और इसे कभी सीमित न करना है।
- सही Okta ग्रुप असाइन करें। RADIUS एप्लिकेशन केवल उन ग्रुप्स को असाइन करें जिन्हें यह SSID मिलना चाहिए। ग्रुप असाइनमेंट आपकी मोटी स्टाफ, ठेकेदार और प्रशासक सीमा है। पूरी कंपनी को असाइन न करें और बाद में ऐसे फ़ायरवॉल नियमों के साथ विभाजन को ठीक करने का वादा न करें जिन्हें किसी ने नहीं लिखा है।
- स्वीकार और अस्वीकार का परीक्षण करें। असाइन किए गए ग्रुप के भीतर एक परीक्षण खाते के साथ एक लैब क्लाइंट को कनेक्ट करें, फिर इसे हटाने के बाद उसी खाते का परीक्षण करें। आपको कंट्रोलर लॉग और Okta लॉग दोनों में दोनों परिणामों की आवश्यकता है। केवल सफलता का परीक्षण करने से निरसन के बारे में कुछ भी साबित नहीं होता है।
- चैलेंज व्यवहार साबित करें। यदि नीति के लिए MFA की आवश्यकता है, तो पुष्टि करें कि विशिष्ट क्लाइंट सप्लिकेंट और कंट्रोलर अपने टाइमआउट के भीतर चैलेंज प्रस्तुत और वापस कर सकते हैं। कई लोग इसे स्पष्ट रूप से नहीं कर सकते। यदि प्रॉम्प्ट कभी दिखाई नहीं देता है, तो प्रोटोकॉल सीमा को समझने से पहले प्रोडक्शन में नीति को कमजोर करके इसे हल न करें।
किसी भी अन्य चीज़ को ट्यून करने से पहले, एक पूर्ण लैब प्रमाणीकरण देखें और अपने लॉग के साथ प्रत्येक होप की तुलना करें।
Meraki संस्करण के लिए, क्लाइंट Okta के दस्तावेजीकृत 802.1X EAP कॉन्फ़िगरेशन के तहत एक Okta उपयोगकर्ता नाम और पासवर्ड प्रदान करता है। SSID सेटिंग्स को बदलना जारी रखने से पहले परीक्षण क्लाइंट पर प्रमाणपत्र ट्रस्ट और तैनात प्रोफ़ाइल की पुष्टि करें। एक अमान्य प्रमाणपत्र या गलत प्रोफ़ाइल एक सही कंट्रोलर कॉन्फ़िगरेशन को विफल कर देगी, इसलिए इसे हाथ से इंस्टॉल करने के बजाय MDM के माध्यम से प्रोफ़ाइल को पुश करें।
यदि आपकी डिज़ाइन को EAP विधियों या ऐसे स्केलिंग की आवश्यकता है जिसे एक ऑन प्रेमाइसेस एजेंट ठीक से संभालने में असमर्थ है, तो साइटों पर एजेंट सर्वर बढ़ाने से पहले उस बाधा की तुलना एक प्रबंधित RADIUS as a service लेयर से करें। आप जो भी विकल्प चुनें, एक अलग आपातकालीन प्रशासक पथ रखें जो एजेंट, Okta API, या MFA सेवा पर निर्भर न हो। आपको इसकी आवश्यकता पहले प्रमाणपत्र या WAN घटना के दौरान होगी, न कि उसके बाद।
किसी कॉन्फ़िगरेशन को केवल इसलिए आगे न बढ़ाएं क्योंकि एक लैपटॉप एक बार कनेक्ट हुआ था। इसे तब आगे बढ़ाएं जब स्वीकार करना, अस्वीकार करना, ग्रुप हटाना, टाइमआउट होना और एजेंट पुनः आरंभ होना - ये सभी उसी तरह व्यवहार करें जैसा आपने दस्तावेज़ में दर्ज किया है।
सशर्त एक्सेस और डिवाइस स्थिति नियम सेट करें
प्रत्येक नियंत्रण को उस लेयर में रखें जो इसे लागू कर सकती है। Okta यह तय करता है कि उपयोगकर्ता कौन है, वे किन समूहों से संबंधित हैं, और कौन सी फैक्टर पॉलिसी लागू होती है। MDM यह तय करता है कि डिवाइस एनरोल और अनुपालन में है या नहीं और इसका प्रमाणपत्र और WiFi प्रोफ़ाइल प्रदान करता है। RADIUS एजेंट या कंट्रोलर उन इनपुट को Access-Accept या Access-Reject में बदलता है और लौटाए गए VLAN या रोल को लागू करता है।
RADIUS एप्लिकेशन में ग्रुप असाइनमेंट यह तय करता है कि कौन SSID से जुड़ सकता है। उस एप्लिकेशन पर फैक्टर पॉलिसी तय करती है कि MFA आवश्यक है या नहीं, लेकिन कंट्रोलर और सप्लीकेंट को अभी भी उस चैलेंज को ले जाना पड़ता है। डिवाइस पोस्चर पासवर्ड से नहीं आता है। यह MDM एनरोलमेंट और एक मान्य प्रमाणपत्र की उपस्थिति से आता है, इसलिए एक अनप्रबंधित व्यक्तिगत डिवाइस केवल इसलिए स्टाफ नेटवर्क पर नहीं आना चाहिए क्योंकि उसके मालिक को मान्य क्रेडेंशियल पता हैं।
डायरेक्टरी ग्रुप की सदस्यता स्वीकृति के बाद प्लेसमेंट भी संचालित कर सकती है। प्रत्येक ग्रुप को एक VLAN या भूमिका से मैप करें, Access-Accept पर उस विशेषता (attribute) को वापस लौटाएं, और मैपिंग को ऑडिट करने योग्य छोटा रखें। स्रोत प्रतिबंध Okta नेटवर्क ज़ोन और एजेंट पर होना चाहिए। केवल कंट्रोलर पते ही मान्य RADIUS स्रोत होने चाहिए। व्यापक नेटवर्क एक्सेस निर्णय आपके व्यापक नेटवर्क एक्सेस कंट्रोल समाधानों के अनुरूप होने चाहिए, न कि SSID विशिष्ट अपवादों का एक सेट बनना चाहिए।
रोलआउट से पहले तीन जांच चलाएं
- निरसन (Revocation) परीक्षण: अपने असाइन किए गए ग्रुप से एक वास्तविक परीक्षण खाते को हटाएं और पुष्टि करें कि अगला कनेक्शन अस्वीकृत कर दिया गया है। फिर खाता अक्षम करें और इसे दोहराएं।
- पोस्चर परीक्षण: एक नामांकित अनुपालन वाले डिवाइस, एक नामांकित गैर-अनुपालन वाले डिवाइस और एक गैर-नामांकित डिवाइस का प्रयास करें। पुष्टि करें कि केवल पहला ही स्टाफ VLAN तक पहुंचता है।
- ऑडिट दस्तावेज़: प्रत्येक ग्रुप की VLAN मैपिंग, प्रत्येक ग्रुप के स्वामी, और अलग से अतिथि नियम सेट को एक दस्तावेज़ में दर्ज करें जिसे आपका हेल्प डेस्क पढ़ सके।
आइडेंटिटी, एंडपॉइंट्स और नेटवर्क डिवाइसों के बीच इन सीमाओं को कड़ा करने वाली टीमों को व्यापक पृष्ठभूमि के रूप में Wisely से IT सुरक्षा भी उपयोगी लग सकती है। इस रोलआउट के लिए, परीक्षण को सीमित रखें। यदि किसी नियंत्रण को लैब में स्वीकार, अस्वीकार या VLAN बदलते हुए नहीं दिखाया जा सकता है, तो वह अभी तक कॉन्फ़िगर नहीं किया गया है।
विफल Okta WiFi लॉगिन को ठीक करना
उपयोगकर्ता द्वारा बताई गई सबसे प्रमुख समस्या से शुरुआत करें। एक क्लाइंट जो कभी क्रेडेंशियल प्रॉम्प्ट नहीं दिखाता है, वह आमतौर पर Okta का इंतजार नहीं कर रहा होता है। इसमें इसका 802.1X प्रोफ़ाइल गायब है, यह गलत EAP विधि की पेशकश कर रहा है, या यह क्रेडेंशियल भेजने से पहले सर्वर सर्टिफिकेट को अस्वीकार कर रहा है। किसी का भी पासवर्ड रीसेट करने से पहले डिवाइस प्रोफ़ाइल और कंट्रोलर EAP सेटिंग्स की जांच करें।
एक बार में एक स्तर पर काम करें। पुष्टि करें कि एजेंट सेवा चल रही है, कंट्रोलर अस्वीकृति का कारण पढ़ें, फिर एक सेटिंग बदलें और उसी डिवाइस और अकाउंट के साथ फिर से परीक्षण करें। यदि आप सीक्रेट, प्रोफ़ाइल, समूह और सर्टिफिकेट को एक साथ संपादित करते हैं, तो आप यह जाने बिना लॉगिन को ठीक कर देंगे कि अगली साइट पर कौन सी खराबी वापस आएगी।
लक्षण को पहले सुधार से मिलाएं
| लक्षण | संभावित कारण | पहला समाधान |
|---|---|---|
| क्लाइंट कभी क्रेडेंशियल प्रॉम्प्ट नहीं दिखाता है | 802.1X प्रोफ़ाइल गायब है या EAP प्रकार मेल नहीं खा रहा है | प्रोफ़ाइल को फिर से कस्टमाइज़ करें और कंट्रोलर से EAP विधि का मिलान करें |
| प्रामाणिकरण समय समाप्त (ऑथेंटिकेशन टाइमआउट) हो गया | UDP 1812 ब्लॉक है या एजेंट सेवा बंद है | कंट्रोलर नेटवर्क से फ़ायरवॉल पाथ और एजेंट सेवा स्थिति की जांच करें |
| सही पासवर्ड के साथ Access-Reject | शेयर किया गया सीक्रेट मेल नहीं खाता या उपयोगकर्ता असाइन किए गए समूह से बाहर है | दोनों सिरों पर सीक्रेट फिर से दर्ज करें और समूह असाइनमेंट की पुष्टि करें |
| केवल एक कंट्रोलर से अस्वीकृति | स्रोत IP या नेटवर्क ज़ोन उस कंट्रोलर को बाहर करता है | स्वीकृत ज़ोन के साथ कंट्रोलर पते की तुलना करें |
| MFA प्रॉम्प्ट कभी दिखाई नहीं देता | क्लाइंट या कंट्रोलर चुनौती प्रदर्शित करने में असमर्थ है | दूसरे क्लाइंट का परीक्षण करें और लैब में चुनौती पाथ की पुष्टि करें |
| Windows पर काम करता है, iOS पर विफल रहता है | प्रमाणपत्र ट्रस्ट या प्रोफ़ाइल बेमेल | विफल हो रहे OS पर सर्वर प्रमाणपत्र शृंखला और प्रोफ़ाइल ट्रस्ट सेटिंग्स की जांच करें |
| एक निश्चित तिथि के बाद काम कर रही साइट विफल हो जाती है | सर्वर प्रमाणपत्र की समयावधि समाप्त (एक्सपायर) हो गई है | प्रमाणपत्र का नवीनीकरण करें और अपडेट की गई ट्रस्ट प्रोफ़ाइल को पुश करें |
मिनटों में होने वाले सुधारों को फ़्लीट सुधारों से अलग रखें। साझा रहस्य को फिर से दर्ज करना, किसी समूह को सही करना, कंट्रोलर स्रोत पता जोड़ना, या एजेंट को पुनारंभ करना लैब दोष को जल्दी से बंद कर सकता है। सर्वर प्रमाणपत्र का नवीनीकरण करना, ट्रस्ट फ़ाइल को फिर से बनाना, और हजारों डिवाइसों द्वारा MDM के साथ चेक इन करने का इंतज़ार करने में दिनों लग सकते हैं। ट्रस्ट चेन की समस्या के लिए उसी दिन साइट रिकवरी का वादा न करें।
मान लीजिए कि सर्टिफिकेट बदलने के बाद Windows लैपटॉप फिर से कनेक्ट हो जाते हैं लेकिन एक इमारत में iPhones विफल हो जाते हैं। यह पैटर्न Okta नीति से अलग इशारा करता है, क्योंकि वही अकाउंट कहीं और सफल होते हैं। कार्यशील Windows डिवाइस के साथ iOS प्रोफ़ाइल के विश्वसनीय CA, अपेक्षित सर्वर नाम और सर्टिफिकेट चेन की तुलना करें। हो सकता है कि एक OS ने नया ट्रस्ट कैश्ड या प्राप्त कर लिया हो, जबकि दूसरे ने नहीं किया हो।
प्रमाण के साथ आगे बढ़ें। यदि एक परीक्षण चक्र अस्वीकृति का कारण नहीं बदलता है, तो प्रोडक्शन सेटिंग्स को संपादित करना बंद करें, विफल डिवाइस को वापस लैब SSID पर ले जाएं, और कार्यशील डिवाइस के खिलाफ इसके एसोसिएशन, EAP एक्सचेंज, RADIUS परिणाम और असाइन किए गए VLAN की तुलना करें। अपने साथ टाइमस्टैम्प लाएं। चार प्रणालियों में अनुमान लगाने से चेंज विंडो बर्बाद होती है।
साइटों का विस्तार करने से पहले पायलट की पुष्टि करें
एक सफल Okta लॉगिन एक कार्यशील WiFi सत्र नहीं है। पायलट को एसोसिएशन से लेकर प्रयोग करने योग्य नेटवर्क एक्सेस तक, संपूर्ण ट्रांजैक्शन को मापना होगा, क्योंकि उपयोगकर्ताओं को इससे फर्क नहीं पड़ता कि किस होप ने एरर दिया है। Okta RADIUS बेस्ट प्रैक्टिस फ्लो ग्यारह तार्किक चरणों तक वाले एक चैलेंज फ्लो का वर्णन करता है, जिसमें क्रेडेंशियल फ़ॉरवर्डिंग, API वैलिडेसन, MFA चैलेंज प्रेजेंटेशन, चैलेंज रिस्पॉन्स, दूसरा वैलिडेसन और अंतिम RADIUS निर्णय शामिल हैं। तदनुसार इस श्रृंखला को व्यवस्थित करें।
प्रत्येक पायलट डिवाइस के लिए चार चेकपॉइंट का उपयोग करें। पहला, एक्सेस पॉइंट पर एसोसिएशन और 802.1X/EAP बातचीत (negotiation)। दूसरा, एजेंट पर RADIUS अनुरोध की प्राप्ति। तीसरा, Okta नीति और कारक प्रतिक्रिया। चौथा, कंट्रोलर पर अंतिम Access-Accept या Access-Reject, इसके बाद सही VLAN। पहली कोशिश की सफलता, मध्यिका (median) और 95वें प्रतिशतक (percentile) प्रमाणीकरण विलंबता (latency), टाइमआउट दर, दोहराए गए संकेत, और अस्वीकृति के कारणों को डिवाइस OS, साइट, SSID, कंट्रोलर मॉडल और कारक प्रकार के आधार पर विभाजित करें।
Okta कोई सार्वभौमिक WiFi प्रमाणीकरण सफलता बेंचमार्क प्रकाशित नहीं करता है, इसलिए एक स्थानीय स्वीकृति नियम सेट करें और उसका बचाव करें। उदाहरण के लिए, नियंत्रित पायलट में कम से कम 99% पहली-कोशिश पूर्णता, शून्य अस्पष्टीकृत अस्वीकृति, और आपके रोमिंग बजट से परे कोई प्रमाणीकरण टाइमआउट न होने की आवश्यकता रखें। इन्हें अपने स्वयं के पायलट थ्रेसहोल्ड के रूप में मानें, फिर चरम समवर्ती (peak concurrency) और WAN विफलता परीक्षण के तहत उन्हें मान्य करें। एक लॉगिन जो दोपहर में पांच लैब उपयोगकर्ताओं के लिए काम करता है, वह तब विफल हो सकता है जब एक शिफ्ट शुरू होती है और सैकड़ों डिवाइस एक साथ फिर से कनेक्ट होते हैं।
आपके प्रमाण पूरी संपदा में क्वेरी करने योग्य होने चाहिए। Purple Access एक प्रमाणीकरण लॉग प्रदान करता है जो एक ही संपदा-व्यापी क्वेरी में पहचान, डिवाइस, MDM एनरोलमेंट स्थिति, तरीका, एक्सेस पॉइंट, SSID, साइट, VLAN, भूमिका, कारण और टाइमस्टैम्प के साथ प्रत्येक स्वीकार और अस्वीकार को दिखाता है। विवरण का वह स्तर सेगमेंटेशन प्रमाण के लिए भी महत्वपूर्ण है, विशेष रूप से क्योंकि PCI-DSS v4.0.1 Req 2.3.2 के लिए आवश्यक है कि वायरलेस कुंजियों को जानने वाले किसी भी व्यक्ति के जाने पर उन्हें बदल दिया जाए, जो एक साझा कुंजी के कारण अव्यावहारिक हो जाता है। अंतर्निहित WiFi नेटवर्क डिज़ाइन को ध्यान में रखें, क्योंकि प्रमाणीकरण कमजोर VLAN सीमाओं को ठीक नहीं कर सकता है।
केवल स्पष्ट निर्णय होने पर ही विस्तार करें। दायरा में प्रत्येक OS और कारक प्रकार सभी तीन स्वीकृति शर्तों को पूरा करता है, अस्वीकरण के कारण दर्ज हैं, और एजेंट के बंद होने पर आपातकालीन प्रशासक पथ का परीक्षण किया गया है। यदि कोई भी शर्त विफल होती है, तो पायलट में ही रहें और उस परत को ठीक करें। अधिक साइटों को जोड़ने से अनसुलझी खराबी बढ़ जाती है।
यदि आपका Okta WiFi प्रमाणीकरण डिज़ाइन साझा पासवर्ड, नाजुक एजेंट सर्वर, या मैन्युअल प्रमाणपत्र कार्य से आगे बढ़ चुका है, तो Purple Access आपके पास पहले से मौजूद एक्सेस पॉइंट्स का उपयोग करके मेहमानों, कर्मचारियों और डिवाइसों को अलग-अलग पहचान संचालित नेटवर्क पर रख सकता है। अपने कंट्रोलर मॉडल, MDM, और ग्रुप से VLAN योजना लाएं, और हम प्रोडक्शन साइट पर पहुंचने से पहले लैब फ़र्स्ट रोलआउट को मान्य करने में आपकी मदद करेंगे।
