Okta WiFi ऑथेंटिकेशन: सेटअप पायऱ्या, पर्याय आणि निवारण
Published
Okta Wi-Fi authentication वरील लोकप्रिय सल्ला म्हणजे तुमचे ॲक्सेस पॉइंट्स Okta कडे पॉइंट करणे, MFA सुरू करणे आणि सामायिक केलेला पासवर्ड काढून टाकणे हा आहे. या वाक्यावर तुमचे रोलआउट तयार करू नका. Okta हा तुमच्या ॲक्सेस पॉइंट्सवर वायरलेस ऑथेंटिकेटर नाही, एक मूळ 802.1X सप्लिकंट अनेकदा परस्परसंवादी आव्हान (interactive challenge) स्पष्टपणे दाखवू शकत नाही, आणि पूर्ण साइट डिस्कनेक्ट करणारा भाग सहसा प्रमाणपत्र ट्रस्ट किंवा खराब डिव्हाइस प्रोफाइल असतो, MFA प्रॉम्प्ट नाही.
याचा अर्थ असा नाही की आयडेंटिटी आधारित WiFi ही चुकीची दिशा आहे. Okta सिक्योर साइन इन ट्रेंड्स रिपोर्ट 2024 ने नोंदवले आहे की जानेवारी 2024 पर्यंत 66% Okta वर्कफोर्स आयडेंटिटी वापरकर्त्यांनी मल्टीफॅक्टर ऑथेंटिकेशन सह साइन इन केले, तर प्रशासकांमधील हे प्रमाण 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 पद्धती त्याच प्रकारे कार्य करतील याचा पुरावा नाही.
वेगवेगळ्या समस्या सोडवणारे चार मार्ग
| पर्याय | Okta तपासत असलेली ओळखपत्रे | सर्वोत्तम जुळणी | मुख्य मर्यादा |
|---|---|---|---|
| Okta RADIUS Server Agent | PAP वर युझरनेम आणि पासवर्ड | लॅब-सत्यापित PAP पाथ असलेले लेगसी नियंत्रक | Okta दस्तऐवजीकरणामध्ये सपोर्टेड म्हणून WiFi पायाभूत सुविधांची यादी नाही |
| Cisco Meraki 802.1X वरील Okta ओळखपत्रे | EAP देवाणघेवाणीत Okta युझरनेम आणि पासवर्ड | Okta च्या दस्तऐवजीकृत EAP सुरक्षा सेटिंगचे अनुसरण करणारे Meraki WLANs | Okta दस्तऐवजीकरण करत असलेल्या Meraki कॉन्फिगरेशनशी जोडलेले |
| Captive Portal वर SAML किंवा SSO साइन-इन | ओळख प्रदात्याद्वारे (Identity provider) ब्राउझर साइन-इन | पाहुणे आणि 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 चे अपयश नसतात. ते ट्रस्ट (विश्वासार्हतेचे) अपयश असतात. डिव्हाइस 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 पासवर्ड्स डिझाइनमध्ये ठेवते. ते फिशिंग, पुन्हा वापर, हेल्प डेस्क रीसेट आणि Wi-Fi सप्लिकंटवर अस्ताव्यस्त आव्हान हाताळणीसाठी उघडे असतात. EAP-TLS वायरलेस एक्सचेंजमधून पासवर्ड काढून टाकते आणि परस्पर ऑथेंटिकेशन प्रदान करते, परंतु ते काम तुमच्या certificate authority, SCEP इश्युअन्स, नूतनीकरण आणि रिव्होकेशन पाइपलाइनमध्ये हलवते. दोन्हीपैकी काहीही मोफत नाही. ऑपरेशन्सचा भार कुठे ठेवायचा हे तुम्ही निवडत आहात.
बहुतेक मार्गदर्शक वगळतात ते लाइफसायकल तयार करा
- सर्टिफिकेट अथॉरिटी निवडा: कोणते CA RADIUS सर्व्हर प्रमाणपत्रावर स्वाक्षरी करते आणि कोणते CA क्लायंट प्रमाणपत्रे जारी करते ते ठरवा. प्रोफाइलमध्ये त्यांची सरमिसळ करू नका आणि सार्वजनिक सर्व्हर प्रमाणपत्राच्या समाप्तीने आश्चर्यचकित होऊ नका.
- नूतनीकरणाचे वेळापत्रक आधीच करा: कालबाह्य होण्यापूर्वी सर्व्हर प्रमाणपत्राचे नूतनीकरण करा, जुने कार्य करत असताना नवीन ट्रस्ट अँकर पुश करा आणि उपकरणे अपेक्षित सर्व्हर नाव सत्यापित करतात याची पुष्टी करा.
- MDM द्वारे प्रोफाइल पुश करा: SSID, EAP प्रकार, विश्वासू CA, सर्व्हर नाव आणि SCEP प्रमाणपत्र वितरीत करण्यासाठी Intune, Jamf किंवा तुमचे विद्यमान MDM वापरा. मॅन्युअल इन्स्टॉलेशनचे प्रमाण वाढवता येत नाही आणि त्याचे ऑडिट करता येत नाही.
- अमलबजावणीपूर्वी ऑनबोर्डिंगचा क्रम लावा: उपकरणांना तात्पुरता ऑनबोर्डिंग मार्ग द्या, प्रोफाइल आणि प्रमाणपत्र मिळाले असल्याची पुष्टी करा, त्यानंतर कर्मचार्‍यांच्या SSID ची अमलबजावणी करा. विश्वास नसलेले उपकरण कर्मचार्‍यांचे नेटवर्क वापरून त्याचा विश्वास मिळवू शकत नाही.
- रद्दीकरण आणि पुनर्प्राप्तीचे नियोजन करा: एखादे उपकरण हरवल्यावर, प्रमाणपत्र रद्द केल्यावर, CA बदलल्यावर किंवा MDM प्रोफाइल काढल्यावर काय होते ते परिभाषित करा. सुट्या उपकरणावर पुन्हा जारी करण्याची चाचणी घ्या.
कोणत्याही साइटवर बदल करण्यापूर्वी टेस्ट मॅट्रिक्स चालवा. Windows, macOS, iOS, आणि Android ची मॅनेज्ड आणि अनमॅनेज्ड या दोन्ही प्रकारे, पहिल्या कनेक्टवर, रीकनेक्टवर, ॲक्सेस पॉइंट्स दरम्यान रोमिंग करताना आणि सिम्युलेटेड प्रमाणपत्र नूतनीकरणानंतर चाचणी करा. यामध्ये एक नाव न नोंदवलेला वापरकर्ता आणि प्रोफाइल हटवलेले एक डिव्हाइस समाविष्ट करा.
समजा एका शाखेत शुक्रवारी कोणत्याही इशाराशिवाय प्रोफाइल पुश अयशस्वी झाला. सोमवारी, त्या ठिकाणचे प्रत्येक मॅनेज केलेले डिव्हाइस सर्व्हर प्रमाणपत्र नाकारते, तर प्रोफाइल प्राप्त झालेले मुख्यालय योग्यरित्या कार्य करते. Okta पॉलिसी बदललेली नाही. ट्रस्ट डिलिव्हरी बदलली आहे. ही परिस्थिती अशी आहे ज्यामुळे प्रोफाइल रिपोर्टिंग तुमच्या गो लाईव्ह निकषांमध्ये असावे, घटनेनंतरच्या पुनरावलोकनात नाही.
Okta RADIUS एजंट टप्प्याटप्प्याने कसा सेट करावा
अनुरोध मार्गापासून सुरुवात करा, कारण लॉगइन अयशस्वी झाल्यावर कुठे पाहावे हे ते तुम्हाला सांगते. कंट्रोलर Okta RADIUS Server Agent ला RADIUS अनुरोध पाठवतो, एजंट Okta API ला कॉल करतो, Okta पॉलिसीचे मूल्यांकन करते, नेटवर्क डिव्हाइसद्वारे एक पर्यायी MFA चॅलेंज परत येते, आणि एजंट कंट्रोलरला Access-Accept किंवा Access-Reject परत पाठवतो. इतर घटक न बिघडता देखील प्रत्येक टप्पा अयशस्वी होऊ शकतो.
खालील उपयोजन क्रम Okta च्या नेटवर्क ॲक्सेस सर्व्हर मार्गदर्शकामधील मॉडेलचे अनुसरण करतो, जे एजंटला नेटवर्क ॲक्सेस सर्व्हर आणि UDP port 1812 वरील Okta पॉलिसी मूल्यांकनाच्या दरम्यान ठेवते. हे याच क्रमाने, लॅबमध्ये, पहिल्या चाचणीपासून पॅकेट आणि एजंट लॉगिंग उपलब्ध ठेवून तयार करा.
लॅब मार्ग क्रमाने तयार करा
- सर्व्हिस म्हणून एजंट इन्स्टॉल करा. Okta RADIUS Server Agent अशा Windows किंवा Linux होस्टवर इन्स्टॉल करा जो वायरलेस कंट्रोलर आणि Okta दोन्हीपर्यंत पोहोचू शकेल. त्याला स्लीप मोडवर जाणाऱ्या, अयोग्यरीत्या पॅच होणाऱ्या किंवा दस्तऐवजीकरण नसलेल्या फायरवॉल नियमाच्या मागे असलेल्या वर्कस्टेशनवर ठेवू नका. नेहमीची चूक म्हणजे सर्व्हर कन्सोलवरून Okta ची पोहोच सिद्ध करणे पण कंट्रोलर ते एजंटची पोहोच कधीही सिद्ध न करणे.
- Okta मध्ये RADIUS अॅप्लिकेशन तयार करा. अॅप्लिकेशन तयार करा, एजंटला आवश्यक असलेल्या सेटिंग्जची नोंद घ्या आणि नाव तुम्ही वापरत असलेल्या SSID आणि साइट स्कोपशी जोडलेले ठेवा. अस्पष्ट अॅप नावामुळे नंतरचा लॉग शोध मंद होतो. दोन्ही RADIUS वर कार्य करतात म्हणून वाय-फाय साठी VPN RADIUS अॅपचा पुन्हा वापर करू नका.
- कंट्रोलरला RADIUS क्लायंट म्हणून कॉन्फिगर करा. वायरलेस कंट्रोलर किंवा नेटवर्क ॲक्सेस सर्व्हरला एजंट IP ॲड्रेसकडे पॉइंट करा, UDP 1812 सेट करा आणि दोन्ही टोकांना जुळणारा शेअर केलेला सिक्रेट एंटर करा. सिक्रेट टाइप करा, चॅट संदेशातून पेस्ट करू नका ज्यामुळे शेवटी अतिरिक्त स्पेस येऊ शकते. सिक्रेट जुळत नसल्यास ते सहसा क्लायंटमध्ये चुकीचा पासवर्ड असल्यासारखे दिसते.
- सोर्स मर्यादित करा. क्लायंट सोर्स IP किंवा Okta नेटवर्क झोन फक्त कंट्रोलर ॲड्रेसपुरता मर्यादित करा. हे अनधिकृत अंतर्गत होस्टना एजंटला ऑथेंटिकेशन विनंत्या पाठवण्यापासून थांबवते. चाचणीदरम्यान मॅनेजमेंट सबनेटला अनुमती देणे आणि नंतर ते कधीही मर्यादित न करणे ही सामान्य चूक आहे.
- योग्य Okta गट नियुक्त करा. RADIUS अॅप्लिकेशन फक्त अशा गटांना नियुक्त करा ज्यांना हा SSID मिळायला हवा. गट असाइनमेंट ही तुमची कर्मचारी, कंत्राटदार आणि ॲडमिनिस्ट्रेटरची मुख्य सीमा आहे. संपूर्ण कंपनीला नियुक्त करू नका आणि नंतर कोणीही न लिहिलेल्या फायरवॉल नियमांसह सेगमेंटेशनचे निराकरण करण्याचे वचन देऊ नका.
- स्वीकार आणि नकार यांची चाचणी करा. नियुक्त केलेल्या गटातील चाचणी खात्यासह लॅब क्लायंट कनेक्ट करा, नंतर ते खाते काढून टाकल्यानंतर त्याच खात्याची चाचणी घ्या. तुम्हाला कंट्रोलर लॉग आणि Okta लॉग दोन्हीमध्ये दोन्ही परिणामांची आवश्यकता आहे. फक्त यशाची चाचणी घेतल्याने रिव्होकेशनबद्दल काहीही सिद्ध होत नाही.
- चॅलेंज वर्तनाची खात्री करा. धोरणासाठी MFA आवश्यक असल्यास, विशिष्ट क्लायंट सप्लिकंट आणि कंट्रोलर त्यांच्या टाइमआउटमध्ये चॅलेंज सादर करू शकतात आणि परत करू शकतात याची खात्री करा. अनेक उपकरणे हे सुरळीतपणे करू शकत नाहीत. प्रॉम्प्ट कधीही दिसत नसल्यास, प्रोटोकॉल मर्यादा समजून घेण्यापूर्वी प्रॉडक्शनमध्ये धोरण कमकुवत करून ते सोडवू नका.
इतर कशातही सुधारणा करण्यापूर्वी, एक संपूर्ण लॅब ऑथेंटिकेशन पाहा आणि तुमच्या लॉग्जसह प्रत्येक टप्प्याची तुलना करा.
Meraki प्रकारासाठी, क्लायंट Okta च्या दस्तऐवजीकृत 802.1X EAP कॉन्फिगरेशन अंतर्गत Okta युझरनेम आणि पासवर्ड प्रदान करतो. आपण SSID सेटिंग्ज बदलत राहण्यापूर्वी टेस्ट क्लायंटवर प्रमाणपत्र विश्वासार्हता आणि तैनात केलेल्या प्रोफाईलची पडताळणी करा. अमान्य प्रमाणपत्र किंवा चुकीचे प्रोफाईल योग्य कंट्रोलर कॉन्फिगरेशन निष्फळ करेल, म्हणून प्रोफाईल मॅन्युअली इंस्टॉल करण्याऐवजी MDM द्वारे पुश करा.
तुमच्या डिझाइनला EAP पद्धतींची किंवा प्रमाणाची (scale) गरज असल्यास, जी ऑन-प्रिमाइस एजंट योग्यरित्या हाताळू शकत नाही, तर साइट्सवर एजंट सर्व्हर्स वाढवण्यापूर्वी त्या मर्यादेची तुलना मॅनेज केलेल्या RADIUS as a service लेयरशी करा. तुम्ही काहीही निवडले तरी, एक स्वतंत्र इमर्जन्सी प्रशासक मार्ग ठेवा जो एजंट, Okta APIs किंवा MFA सर्व्हिसवर अवलंबून नसेल. पहिल्या प्रमाणपत्र किंवा WAN घटनेदरम्यान तुम्हाला याची गरज भासेल, ती घडल्यानंतर नाही.
एका लॅपटॉपने एकदा कनेक्ट केले म्हणून कॉन्फिगरेशनचे प्रमोशन करू नका. स्वीकारणे, नाकारणे, ग्रुप हटवणे, टाइमआउट आणि एजंट रीस्टार्ट या सर्वांचे वर्तन तुम्ही दस्तऐवजीकरण केल्याप्रमाणे असेल तेव्हाच त्याचे प्रमोशन करा.
कंडिशनल ॲक्सेस आणि डिव्हाइस पोस्चर नियम सेट करा
प्रत्येक नियंत्रण ते लागू करू शकणाऱ्या लेयरमध्ये ठेवा. Okta वापरकर्ता कोण आहे, ते कोणत्या ग्रुपशी संबंधित आहेत आणि कोणती फॅक्टर पॉलिसी लागू होते हे ठरवते. MDM हे ठरवते की डिव्हाइस एनरोल आणि सुसंगत आहे की नाही आणि त्याचे प्रमाणपत्र आणि Wi-Fi प्रोफाइल वितरीत करते. RADIUS agent or controller या इनपुट्सना Access-Accept किंवा Access-Reject मध्ये रूपांतरित करतो आणि परत मिळालेला VLAN किंवा रोल लागू करतो.
RADIUS ॲप्लिकेशनला ग्रुप असाइनमेंट हे ठरवते की कोण SSID मध्ये सामील होऊ शकते. त्या ॲप्लिकेशनवरील फॅक्टर पॉलिसी MFA आवश्यक आहे की नाही हे ठरवते, परंतु कंट्रोलर आणि सप्लिकंटला तरीही आव्हान पार पाडावे लागते. डिव्हाइस पोस्चर पासवर्डवरून येत नाही. ते MDM एनरोलमेंट आणि वैध प्रमाणपत्राच्या उपस्थितीतून येते, त्यामुळे अनमॅनेज केलेले वैयक्तिक डिव्हाइस केवळ त्याच्या मालकाला वैध क्रेडेंशियल्स माहित आहेत म्हणून स्टाफ नेटवर्कवर येऊ नये.
डिरेक्टरी ग्रुप मेंबरशिप स्वीकृतीनंतर प्लेसमेंट देखील ठरवू शकते. प्रत्येक ग्रुपला एका VLAN किंवा रोलशी मॅप करा, तो ॲट्रिब्यूट Access-Accept वर परत पाठवा आणि मॅपिंग ऑडिट करण्यासाठी पुरेसे लहान ठेवा. स्त्रोत निर्बंध Okta नेटवर्क झोनमध्ये आणि एजंटवर असले पाहिजेत. केवळ कंट्रोलरचे पत्ते हे वैध RADIUS स्त्रोत असले पाहिजेत. ब्रॉडर नेटवर्क ॲक्सेसचे निर्णय तुमच्या व्यापक network access control solutions शी सुसंगत राहिले पाहिजेत, विशिष्ट SSID अपवादांचा संच बनू नयेत.
रोलआउटपूर्वी तीन तपासण्या करा
- रिव्होकेशन चाचणी: नियुक्त केलेल्या ग्रुपमधून एक वास्तविक चाचणी खाते हटवा आणि पुढील कनेक्शन नाकारले गेले आहे याची खात्री करा. नंतर ते खाते डिझॅबल करा आणि पुन्हा चाचणी करा.
- पॉश्चर चाचणी: एनरोल केलेले सुसंगत डिव्हाइस, एनरोल केलेले असुसंगत डिव्हाइस आणि एनरोल न केलेले डिव्हाइस वापरून पहा. केवळ पहिले डिव्हाइस स्टाफ VLAN पर्यंत पोहोचत असल्याची खात्री करा.
- ऑडिट दस्तऐवज: प्रत्येक ग्रुप ते VLAN मॅपिंग, प्रत्येक ग्रुपचा मालक आणि स्वतंत्र गेस्ट नियम संच तुमच्या हेल्प डेस्कला वाचता येईल अशा एका दस्तऐवजात नोंदवा.
आयडेंटिटी, एंडपॉइंट्स आणि नेटवर्क डिव्हाइसेसमधील या मर्यादा कडक करणाऱ्या टीम्सना IT protection from Wisely देखील विस्तृत पार्श्वभूमी म्हणून उपयुक्त वाटू शकते. या रोलआउटसाठी, चाचणी मर्यादित ठेवा. जर लॅबमध्ये स्वीकारणे, नाकारणे किंवा VLAN बदलताना एखादे नियंत्रण दाखवले जाऊ शकत नसेल, तर ते अद्याप कॉन्फिगर केलेले नाही.
अयशस्वी Okta Wi-Fi लॉगिनचे ट्रबलशूटिंग
वापरकर्ते ज्या लक्षणाची सर्वाधिक तक्रार करतात त्यापासून सुरुवात करा. क्रेडेंशियल प्रॉम्प्ट कधीही न दाखवणारा क्लायंट सहसा Okta ची वाट पाहत नसतो. त्याचे 802.1X प्रोफाइल गहाळ आहे, ते चुकीची EAP पद्धत देत आहे किंवा क्रेडेंशियल पाठवण्यापूर्वी ते सर्व्हर प्रमाणपत्र नाकारत आहे. कोणाचाही पासवर्ड रिसेट करण्यापूर्वी डिव्हाइस प्रोफाइल आणि कंट्रोलर EAP सेटिंग्ज तपासा.
एका वेळी एका लेयरवर काम करा. एजंट सर्व्हिस चालू असल्याची पुष्टी करा, कंट्रोलर नाकारण्याचे कारण वाचा, नंतर एक सेटिंग बदला आणि त्याच डिव्हाइस आणि खात्यासह पुन्हा चाचणी करा. जर तुम्ही सिक्रेट, प्रोफाइल, ग्रुप आणि सर्टिफिकिट एकत्र एडिट केले, तर पुढील साइटवर कोणता दोष परत येईल हे न शिकता तुम्ही लॉगिन निश्चित कराल.
पहिल्या उपायाशी लक्षणाचा मेळ घाला
| लक्षण | संभाव्य कारण | पहिली सुधारणा (फिक्स) |
|---|---|---|
| क्लायंट कधीही क्रेडेन्शियल प्रॉम्प्ट दाखवत नाही | 802.1X प्रोफाईल गहाळ आहे किंवा EAP प्रकार जुळत नाही | प्रोफाईल पुन्हा रीडिप्लॉय करा आणि EAP पद्धत कंट्रोलरशी जुळवा |
| ऑथेंटिकेशन टाईम आऊट होते | UDP 1812 ब्लॉक केले आहे किंवा एजंट सर्व्हिस बंद आहे | कंट्रोलर नेटवर्कवरून फायरवॉल पाथ आणि एजंट सर्व्हिसची स्थिती तपासा |
| योग्य पासवर्ड असूनही Access-Reject येते | शेअर केलेले सिक्रेट जुळत नाही किंवा युझर असाइन केलेल्या ग्रुपच्या बाहेर आहे | दोन्ही टोकांना सिक्रेट पुन्हा प्रविष्ट करा आणि ग्रुप असाइनमेंटची पुष्टी करा |
| फक्त एकाच कंट्रोलरकडून Rejects येतात | सोर्स IP किंवा नेटवर्क झोन त्या कंट्रोलरला वगळतो | कंट्रोलर अॅड्रेसची मंजूर केलेल्या झोनशी तुलना करा |
| MFA प्रॉम्प्ट कधीही दिसत नाही | क्लायंट किंवा कंट्रोलर चॅलेंज प्रदर्शित करू शकत नाही | दुसऱ्या क्लायंटची चाचणी घ्या आणि लॅबमध्ये चॅलेंज पाथची पुष्टी करा |
| Windows वर कार्य करते, परंतु iOS वर अयशस्वी होते | प्रमाणपत्र ट्रस्ट किंवा प्रोफाईल जुळत नाही | अयशस्वी होणाऱ्या OS वर सर्व्हर प्रमाणपत्र साखळी आणि प्रोफाईल ट्रस्ट सेटिंग्ज तपासा |
| कार्यरत असलेली साईट एका विशिष्ट तारखेनंतर अयशस्वी होते | सर्व्हर प्रमाणपत्राची मुदत संपली आहे | प्रमाणपत्राचे नूतनीकरण करा आणि अद्यतनित ट्रस्ट प्रोफाईल पुश करा |
काही मिनिटांतील दुरुस्त्या आणि मोठ्या प्रमाणातील (fleet) दुरुस्त्या वेगळ्या ठेवा. शेअर्ड सिक्रेट पुन्हा प्रविष्ट करणे, ग्रुप दुरुस्त करणे, कंट्रोलर सोर्स ॲड्रेस जोडणे, किंवा एजंट रीस्टार्ट करणे यामुळे लॅबमधील त्रुटी त्वरित दूर होऊ शकते. सर्व्हर प्रमाणपत्राचे नूतनीकरण करणे, ट्रस्ट प्रोफाईलची पुनर्रचना करणे आणि हजारो डिव्हाइसेसनी MDM कडे चेक इन करण्याची वाट पाहणे यासाठी काही दिवस लागू शकतात. ट्रस्ट साखळीच्या समस्येसाठी एकाच दिवसात साईट पूर्ववत करण्याचे वचन देऊ नका.
समजा Windows लॅपटॉप प्रमाणपत्र बदलल्यानंतर पुन्हा कनेक्ट होतात परंतु एका इमारतीमध्ये iPhones अयशस्वी ठरतात. तो पॅटर्न Okta पॉलिसीपासून दूर निर्देश करतो, कारण तेच खाते इतरत्र यशस्वी होतात. वर्किंग Windows डिव्हाइसविरुद्ध iOS प्रोफाइलचे विश्वासू CA, अपेक्षित सर्व्हर नाव आणि प्रमाणपत्र साखळी यांची तुलना करा. एका OS ने नवीन ट्रस्ट कॅश किंवा प्राप्त केले असावे तर दुसऱ्याने नाही.
पुराव्यासह एस्केलेट करा. जर एका टेस्ट सायकलने रिजेक्ट करण्याचे कारण बदलले नाही, तर प्रोडक्शन सेटिंग्ज एडिट करणे थांबवा, अयशस्वी डिव्हाइसला परत लॅब SSID वर आणा आणि त्याच्या असोसिएशन, EAP एक्सचेंज, RADIUS निकाल आणि असाइन केलेल्या VLAN ची वर्किंग डिव्हाइसशी तुलना करा. तुमच्यासोबत टाइमस्टॅम्प आणा. चार सिस्टीममधील अंदाज बांधल्याने चेंज विंडो वाया जाते.
तुम्ही साईट्सचा विस्तार करण्यापूर्वी पायलटची पुष्टी करा
यशस्वी Okta लॉगिन म्हणजे कार्यरत WiFi सत्र नाही. पायलटला असोसिएशनपासून ते वापरण्यायोग्य नेटवर्क ॲक्सेसपर्यंत संपूर्ण व्यवहाराचे मोजमाप करावे लागेल, कारण वापरकर्त्यांना याने काही फरक पडत नाही की कोणत्या हॉपने एरर परत केली. Okta RADIUS बेस्ट प्रॅक्टिस फ्लो मध्ये अकरा लॉजिकल स्टेप्सपर्यंत समाविष्ट असलेल्या चॅलेंज फ्लोचे वर्णन केले आहे, ज्यामध्ये क्रेडेन्शियल फॉरवर्डिंग, API व्हॅलिडेशन, MFA चॅलेंज प्रेझेंटेशन, चॅलेंज रिस्पॉन्स, सेकंद व्हॅलिडेशन आणि अंतिम RADIUS निर्णय समाविष्ट आहे. त्यानुसार साखळीची रचना करा.
प्रत्येक पायलट डिव्हाइससाठी चार चेकपॉइंट्स वापरा. पहिले, ॲक्सेस पॉइंटवर असोसिएशन आणि 802.1X/EAP निगोशिएशन. दुसरे, एजंटवर RADIUS विनंतीची पावती. तिसरे, Okta पॉलिसी आणि फॅक्टर प्रतिसाद. चौथे, कंट्रोलरवर अंतिम Access-Accept किंवा Access-Reject, आणि त्यानंतर योग्य VLAN. प्रथम प्रयत्न यश, median आणि 95th percentile ऑथेंटिकेशन लॅटन्सी, टाइमआउट दर, वारंवार येणारे प्रॉम्प्ट्स आणि रिजेक्शनची कारणे डिव्हाइस OS, साइट, SSID, कंट्रोलर मॉडेल आणि फॅक्टर प्रकारानुसार विभाजित करा.
Okta कोणताही युनिव्हर्सल WiFi ऑथेंटिकेशन यश बेंचमार्क प्रकाशित करत नाही, म्हणून एक स्थानिक स्वीकृती नियम सेट करा आणि त्याचे रक्षण करा. उदाहरणार्थ, नियंत्रित पायलटमध्ये किमान 99% प्रथम-प्रयत्न पूर्णता, शून्य अस्पष्ट रिजेक्ट्स आणि तुमच्या रोमिंग बजेटपेक्षा जास्त कोणताही ऑथेंटिकेशन टाइमआउट नसावा. यांना तुमचे स्वतःचे पायलट थ्रेशोल्ड मानून, पीक कॉन्करन्सी आणि WAN अपयश चाचणी अंतर्गत त्यांचे व्हॅलिडेशन करा. दुपारी पाच लॅब युझर्ससाठी कार्य करणारे लॉगिन जेव्हा शिफ्ट सुरू होते आणि शेकडो डिव्हाइसेस एकत्र रीकनेक्ट होतात तेव्हा अयशस्वी होऊ शकते.
तुमचा पुरावा संपूर्ण इस्टेटमध्ये क्वेरी करण्यायोग्य असणे आवश्यक आहे. Purple Access एक ऑथेंटिकेशन लॉग प्रदान करते जे प्रत्येक स्वीकार आणि नकार दर्शवते, ज्यामध्ये आयडेंटिटी, डिव्हाइस, MDM एनरोलमेंट स्टेट, पद्धत, ॲक्सेस पॉइंट, SSID, साइट, VLAN, भूमिका, कारण आणि टाइमस्टॅम्प, एकाच इस्टेटव्यापी क्वेरीमध्ये समाविष्ट असतात. तो तपशील सेगमेंटेशन पुराव्यासाठी देखील महत्त्वाचा आहे, विशेषत: कारण PCI DSS v4.0.1 Req 2.3.2 ला ते माहित असलेल्या कोणीही सोडल्यास वायरलेस की बदलणे आवश्यक आहे, जे शेअर केलेली की असल्यास अशक्य होते. मूलभूत WiFi नेटवर्क डिझाइन नजरेसमोर ठेवा, कारण ऑथेंटिकेशन कमकुवत VLAN सीमांचे रक्षण करू शकत नाही.
केवळ स्पष्ट निर्णय झाल्यानंतरच विस्तार करा. स्कोपमधील प्रत्येक OS आणि घटकाचा प्रकार तिन्ही स्वीकृती अटी पूर्ण करतो, नकार दिलेल्यांची कारणे नोंदवली गेली आहेत, आणि एजंट थांबवून आणीबाणीच्या प्रशासक मार्गाची चाचणी केली गेली आहे. कोणतीही अट अयशस्वी झाल्यास, पायलट मोडमध्येच राहा आणि तो स्तर दुरुस्त करा. अधिक साइट्स जोडल्यास न सोडवलेली त्रुटी वाढू शकते.
तुमच्या Okta Wi-Fi authentication डिझाइनने सामायिक पासवर्ड, नाजूक एजंट सर्व्हर्स किंवा मॅन्युअल प्रमाणपत्राच्या कामापेक्षा मोठे रूप घेतले असल्यास, Purple Access तुमच्याकडे आधीपासून असलेल्या ॲक्सेस पॉइंट्सचा वापर करून पाहुणे, कर्मचारी आणि डिव्हाइसेसना स्वतंत्र ओळख-आधारित नेटवर्कवर आणू शकते. तुमचे कंट्रोलर मॉडेल, MDM आणि ग्रुप ते VLAN प्लॅन आणा, आणि ते प्रोडक्शन साइटवर पोहोचण्यापूर्वी आम्ही तुम्हाला लॅब-फर्स्ट रोलआउट व्हॅलिडेट करण्यात मदत करू.
