EAP-TLS विरुद्ध EAP-TTLS: आपण कोणते सर्टिफिकेट-बेस्ड WiFi प्रोटोकॉल निवडावे?
हे मार्गदर्शक IEEE 802.1X अंतर्गत एंटरप्राइझ WiFi ऑथेंटिकेशनसाठी EAP-TLS आणि EAP-TTLS ची एक निश्चित समोरासमोर तुलना प्रदान करते. हे म्युचुअल सर्टिफिकेट ऑथेंटिकेशन आणि सर्व्हर-ओन्ली सर्टिफिकेट टनेलिंगमधील आर्किटेक्चरल फरक स्पष्ट करते, आणि आयटी मॅनेजर्स, नेटवर्क आर्किटेक्ट्स आणि CISOs ना डिव्हाइस मॅनेजमेंट क्षमता आणि अनुपालन आवश्यकतांवर आधारित एक स्पष्ट निर्णय फ्रेमवर्क देते. Purple हे Staff WiFi साठी EAP-TLS आणि EAP-TTLS दोन्ही ऑथेंटिकेशन पाथ्सना सपोर्ट करते, आणि हे मार्गदर्शक संस्थांना कोणत्याही एका दृष्टिकोनाचा अवलंब करण्यापूर्वी इन्फ्रास्ट्रक्चरच्या तडजोडी समजून घेण्यास मदत करते.
Video overview
हे मार्गदर्शक ऐका
पॉडकास्ट ट्रान्सक्रिप्ट पहा
आमच्या मुख्य मालिकेचा भाग: एंटरप्राइझ WiFi सुरक्षा मार्गदर्शक →
EAP-TLS vs EAP-TTLS decision and PKI sizing tool
Evaluate mutual certificate requirements, tunneled credential protocols, OS supplicant compatibility, and RADIUS directory integration for enterprise 802.1X WiFi.
EAP-TLS (Mutual Certificate-Based 802.1X)
Deploy mutual EAP-TLS with automated SCEP or ACME certificate enrolment via MDM.
Recommended implementation milestones
- Deploy trusted root and intermediate CA certificates via MDM profile
- Configure SCEP/NDES profile to issue client certificates into hardware TPM or Secure Enclave
- Configure Cloud RADIUS server certificate validation with Subject Alternative Name (SAN) mapping
Plan your enterprise 802.1X & Cloud RADIUS deployment with Purple
Whether migrating from legacy credentials to EAP-TTLS or rolling out passwordless EAP-TLS with Cloud PKI, Purple provides secure 802.1X Staff WiFi, dynamic VLAN segmentation, and enterprise access control across multi-vendor networks.
कार्यकारी सारांश (Executive Summary)
तुमच्या 802.1X उपयोजनासाठी योग्य EAP पद्धत निवडणे हे तुमचे कॉर्पोरेट WiFi खरोखर सुरक्षित आहे की केवळ कागदावरच सुसंगत आहे हे ठरवते. RFC 5216 मध्ये परिभाषित केलेल्या EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) साठी परस्पर प्रमाणपत्र प्रमाणीकरण आवश्यक आहे: नेटवर्क प्रवेश मंजूर होण्यापूर्वी क्लायंट डिव्हाइस आणि RADIUS सर्व्हर दोन्ही वैध X.509 प्रमाणपत्रे सादर करतात. यामध्ये कोणत्याही क्षणी पासवर्डची देवाणघेवाण केली जात नाही. RFC 5281 मध्ये परिभाषित केलेल्या EAP-TTLS (Tunneled Transport Layer Security) साठी केवळ एनक्रिप्टेड TLS टनेल स्थापित करण्यासाठी सर्व्हर-साइड प्रमाणपत्राची आवश्यकता असते, ज्याच्या आत क्लायंट सध्याच्या डिरेक्टरी क्रेडेंशियलचा वापर करून प्रमाणीकरण करतो.
रिटेल चेन्स, हॉस्पिटॅलिटीचे ठिकाण आणि सार्वजनिक क्षेत्रातील संस्थांमधील पायाभूत सुविधा व्यवस्थापित करणाऱ्या CTOs आणि नेटवर्क आर्किटेक्ट्ससाठी हा निर्णय एका प्रश्नावर येऊन थांबतो: तुम्ही डिव्हाइसेस व्यवस्थापित करता का? जर तुम्ही MDM द्वारे डिव्हाइसच्या ताफ्यावर नियंत्रण ठेवत असाल, तर EAP-TLS हा सर्वोत्तम पर्याय आहे. जर तुम्ही वैविध्यपूर्ण BYOD वातावरणाचे समर्थन करत असाल किंवा तुमच्याकडे मजबूत पब्लिक की इन्फ्रास्ट्रक्चर (PKI) नसेल, तर EAP-TTLS एक व्यावहारिक आणि अत्यंत सुरक्षित पर्याय प्रदान करतो. Purple ८०,००० हून अधिक थेट ठिकाणांवर Staff WiFi साठी या दोन्ही प्रमाणीकरण मार्गांना समर्थन देते.
तांत्रिक सखोल विश्लेषण (Technical Deep-Dive)
EAP-TLS ची रचना (Architecture of EAP-TLS)
EAP-TLS हे IEEE 802.1X पोर्ट-आधारित प्रवेश नियंत्रण फ्रेमवर्कमध्ये परस्पर प्रमाणीकरण मॉडेलवर कार्य करते. प्रत्येक प्रमाणीकरण देवाणघेवाणीमध्ये तीन मुख्य घटकांचा समावेश असतो: सप्लिकंट (क्लायंट डिव्हाइस), प्रमाणकर्ता (वायरलेस ॲक्सेस पॉइंट), आणि प्रमाणीकरण सर्व्हर (RADIUS सर्व्हर). ॲक्सेस पॉइंट प्रमाणीकरणाचा निर्णय स्वतः घेत नाही. हे एक ट्रान्सपरंट रिले म्हणून काम करते, EAP संदेशांना RADIUS पॅकेट्समध्ये समाविष्ट करते आणि त्यांना प्रमाणीकरण सर्व्हरकडे पाठवते.EAP-TLS हँडशेक खालीलप्रमाणे कार्य करतो. ऍक्सेस पॉईंट कनेक्ट होणाऱ्या डिव्हाइसला EAP-Request/Identity पाठवतो. डिव्हाइस त्याच्या ओळखीसह प्रतिसाद देते. RADIUS सर्व्हर EAP-TLS/Start मेसेजसह TLS हँडशेक सुरू करतो. क्लायंट ClientHello पाठवतो, ज्यामध्ये त्याच्या समर्थित TLS सायफर सूटची जाहिरात असते. RADIUS सर्व्हर ServerHello, त्याचे X.509 सर्व्हर सर्टिफिकेट आणि सर्टिफिकेट विनंतीसह प्रतिसाद देतो. क्लायंट त्याच्या विश्वसनीय रूट CA स्टोअरच्या तुलनेत सर्व्हर सर्टिफिकेट प्रमाणित करतो. व्हॅलिडेशन अयशस्वी झाल्यास, हँडशेक समाप्त होतो - ज्यामुळे फसव्या ऍक्सेस पॉईंट्सपासून संरक्षण मिळते. क्लायंट नंतर स्वतःचे X.509 सर्टिफिकेट सादर करतो. RADIUS सर्व्हर क्लायंट सर्टिफिकेट प्रमाणित करतो, विश्वसनीय रूट CA पर्यंतची स्वाक्षरी साखळी तपासतो, सर्टिफिकेट कालबाह्य झाले नसल्याची पडताळणी करतो आणि सर्टिफिकेट रिव्होकेशन लिस्ट (CRL) तपासतो किंवा OCSP ला क्वेरी करतो. जेव्हा दोन्ही पक्षांचे समाधान होते, तेव्हाच TLS टनेल स्थापित केले जाते आणि नेटवर्क ऍक्सेस मंजूर केला जातो.
कोणतेही पासवर्ड देवाणघेवाण केले जात नसल्यामुळे, EAP-TLS ऑफलाइन डिक्शनरी हल्ले, क्रेडेंशियल स्टफिंग आणि फिशिंगपासून सुरक्षित आहे. WPA3-Enterprise १९२-बिट (Suite B) आवश्यकता पूर्ण करणारी ही एकमेव EAP पद्धत आहे, आणि कार्डधारक डेटा वातावरणासाठी PCI-DSS 4.0 द्वारे आणि उच्च सुरक्षिततेच्या वायरलेस उपयोजनांसाठी NIST SP 800-120 द्वारे हे अनिवार्य किंवा अत्यंत शिफारसीय आहे.
EAP-TLS साठी PKI आवश्यक आहे. तुम्हाला किमान एक ऑफलाइन रूट CA आणि एक ऑनलाइन जारी करणारे CA आवश्यक आहे. रूट CA एअर-गॅप असले पाहिजे, कारण त्याची प्रायव्हेट की तुमच्या संपूर्ण सर्टिफिकेट पदानुक्रमासाठी मास्टर ट्रस्ट अँकर असते. जारी करणारे CA दररोज सर्टिफिकेट जारी करण्याचे काम सांभाळते आणि CRLs प्रकाशित करते. क्लायंट सर्टिफिकेट वैयक्तिक डिव्हाइसेसना जारी केली जातात, वापरकर्त्यांना नाही - हे एक डिव्हाइस-आयडेंटिटी मॉडेल आहे. IoT डिव्हाइसेस, सामायिक टर्मिनल्स आणि हेडलेस सिस्टम्ससाठी हा फरक अत्यंत महत्त्वाचा आहे.
EAP-TTLS ची रचना
EAP-TTLS ची रचना प्रत्येक क्लायंट डिव्हाइसवर सर्टिफिकेट्स तैनात करण्याच्या ऑपरेशनल ओझ्याशिवाय मजबूत 802.1X सुरक्षा प्रदान करण्यासाठी केली गेली आहे. हे दोन टप्प्यांत कार्य करते. पहिल्या टप्प्यात, RADIUS सर्व्हर आपले सर्टिफिकेट सादर करतो आणि एक सुरक्षित TLS टनेल स्थापित करतो. केवळ सर्व्हरला सर्टिफिकेटची आवश्यकता असते. दुसऱ्या टप्प्यात, क्लायंटला त्या कूटबद्ध टनेलमध्ये अंतर्गत ऑथेंटिकेशन पद्धतीचा वापर करून अधिकृत केले जाते. सामान्य अंतर्गत पद्धतींमध्ये PAP (Password Authentication Protocol), CHAP आणि MS-CHAPv2 चा समावेश होतो. क्लायंट त्याचा युझरनेम आणि पासवर्ड पाठवतो, परंतु ही देवाणघेवाण TLS टनेलच्या आत होत असल्याने, क्रेडेंशियल्स ट्रान्झिटमध्ये कूटबद्ध (encrypted) केली जातात आणि हवेत कधीही उघड होत नाहीत.
EAP-TTLS हे macOS, Linux, Android, आणि iOS वर उत्कृष्ट क्रॉस-प्लॅटफॉर्म समर्थन प्रदान करते. Windows च्या बाबतीत एक अडचण आहे: अंगभूत Windows सप्लिकंट वायरलेस 802.1X साठी मूळतः EAP-TTLS ला थेट समर्थन देत नाही. मोठ्या प्रमाणात Windows डिव्हाइसेस असलेल्या वातावरणात थर्ड-पार्टी सप्लिकंटची आवश्यकता असू शकते, ज्यामुळे ऑपरेशनल गुंतागुंत वाढते. Windows-केंद्रित वातावरणासाठी, MS-CHAPv2 सह PEAP हा बहुधा अधिक व्यावहारिक पर्याय ठरतो.
EAP-TTLS ची सर्वात मोठी मर्यादा ही आहे की ते पासवर्डच्या अंगभूत जोखमींना दूर करत नाही. जर वापरकर्त्याने कमकुवत पासवर्ड निवडला, तर तो ऑफलाइन ब्रूट-फोर्स हल्ल्यांसाठी असुरक्षित राहतो. जर अंतर्गत प्रमाणीकरणामध्ये PAP वापरले जात असेल, तर पासवर्ड टनेलमध्ये प्लेनटेक्स्ट स्वरूपात पाठवला जातो - जे तुम्ही तुमच्या RADIUS इन्फ्रास्ट्रक्चरवर विश्वास ठेवत असल्यास स्वीकार्य आहे, परंतु हे समजून घेणे एक आवश्यक ट्रस्ट मॉडेल आहे.
समोरासमोर तुलना
| वैशिष्ट्य | EAP-TLS | EAP-TTLS |
|---|---|---|
| RFC मानक | RFC 5216 | RFC 5281 |
| क्लायंट प्रमाणपत्र आवश्यक आहे | होय | नाही |
| सर्व्हर प्रमाणपत्र आवश्यक आहे | होय | होय |
| प्रमाणीकरण मॉडेल | परस्पर (दोन्ही बाजू) | केवळ-सर्व्हर |
| पासवर्डची जोखीम | काहीही नाही - पासवर्डलेस | एन्क्रिप्टेड टनेलमध्ये पासवर्ड |
| PKI आवश्यकता | पूर्ण PKI (Root CA + Issuing CA + MDM) | केवळ सर्व्हर प्रमाणपत्र |
| WPA3-Enterprise 192-bit | आवश्यक पद्धत | समर्थित नाही |
| PCI-DSS 4.0 सुसंगतता | अत्यंत शिफारसीय | मजबूत अंतर्गत प्रमाणीकरणासह स्वीकार्य |
| BYOD साठी सुसंगतता | कमी (क्लायंट प्रमाणपत्राची आवश्यकता आहे) | जास्त (केवळ क्रेडेंशियल्स) |
| IoT डिव्हाइस सुसंगतता | जास्त (स्टेजिंगवर प्रमाणपत्र प्रोव्हिजन केलेले असते) | कमी (क्रेडेंशियल इनपुटसाठी कोणतेही UI नसते) |
| Windows मूळ सपोर्ट | होय | आंशिक (बऱ्याचदा थर्ड-पार्टी सप्लिकंटची आवश्यकता असते) |
| macOS/Linux/Android सपोर्ट | होय | होय |
| उपयोजन जटिलता | जास्त | मध्यम |
अंमलबजावणी मार्गदर्शक
व्यवस्थापित फ्लीट्ससाठी EAP-TLS उपयोजित करणे
EAP-TLS उपयोजित करण्यासाठी कार्यरत PKI आणि MDM प्लॅटफॉर्म आवश्यक आहे. एंटरप्राइझ स्तरावर मॅन्युअल प्रमाणपत्र स्थापना व्यावहारिक नाही. तुम्ही SCEP (सिंपल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल) किंवा EST (एनरोलमेंट ओव्हर सिक्युर ट्रान्सपोर्ट) वापरून तुमच्या PKI ला तुमच्या MDM सोबत एकत्रित केले पाहिजे. जेव्हा एखादे कॉर्पोरेट डिव्हाइस नोंदणीकृत केले जाते, तेव्हा ते वापरकर्त्याच्या हस्तक्षेपाशिवाय स्वयंचलितपणे त्याच्या प्रमाणपत्राची विनंती करते आणि ते प्राप्त करते.
ओळख व्यवस्थापनासाठी, Purple Connect परवान्यांतर्गत OpenRoaming सारख्या सेवांसाठी एक विनामूल्य ओळख प्रदाता म्हणून काम करते, जे अंतर्निहित प्रमाणपत्र आणि ओळख फ्रेमवर्क वापरून विविध ठिकाणी सुरक्षित रोमिंग सुलभ करते.
RADIUS च्या बाजूने, तुमच्या अंतर्गत CA च्या विरूद्ध क्लायंट प्रमाणपत्रांचे प्रमाणीकरण करण्यासाठी आणि CRL तपासण्यासाठी किंवा रिअल-टाइम रिव्होकेशन तपासणीसाठी OCSP वापरण्यासाठी तुमचा सर्व्हर कॉन्फिगर करा. समर्थित RADIUS प्लॅटफॉर्ममध्ये FreeRADIUS, Microsoft NPS आणि Cisco ISE समाविष्ट आहेत. Purple चे क्लाउड ओव्हरले Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet हार्डवेअरसह एकत्रित होते.
मिश्र वातावरणासाठी EAP-TTLS उपयोजित करणे
अव्यवस्थित डिव्हाइसेस असलेल्या वातावरणासाठी EAP-TTLS हा सर्वोत्तम पर्याय आहे. तुम्हाला तुमच्या RADIUS सर्व्हरवर फक्त एका विश्वसनीय प्रमाणपत्राची आवश्यकता आहे. अंतर्गत प्रमाणीकरण क्रेडेंशियल्स सत्यापित करण्यासाठी तुमचा RADIUS सर्व्हर थेट तुमच्या डिरेक्टरी सेवेशी - Microsoft Entra ID, Okta किंवा Google Workspace - एकत्रित असल्याची खात्री करा. तुमच्या विशिष्ट विश्वसनीय CA च्या विरूद्ध सर्व्हर प्रमाणपत्र प्रमाणीकरण लागू करण्यासाठी तुमचे MDM-उपयोजित WiFi प्रोफाइल कॉन्फिगर करा. या चरणाशिवाय, TLS टनेल रॉग ॲक्सेस पॉईंट्सपासून कोणतेही संरक्षण प्रदान करत नाही.
तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?
आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.
सर्वोत्कृष्ट पद्धती
प्रत्येक क्लायंटवर सर्व्हर प्रमाणपत्र प्रमाणीकरण लागू करा
EAP-TLS आणि EAP-TTLS या दोन्हीसाठी सर्वात महत्त्वाचे कॉन्फिगरेशन पाऊल म्हणजे क्लायंट डिव्हाइसवर सर्व्हर प्रमाणपत्र प्रमाणीकरण लागू करणे. जर एखादे डिव्हाइस विशिष्ट विश्वसनीय CA च्या विरूद्ध RADIUS सर्व्हरचे प्रमाणपत्र प्रमाणित करत नसेल, तर ते कोणत्याही प्रमाणपत्रासह सादर होणाऱ्या कोणत्याही सर्व्हरशी कनेक्ट होईल - ज्यामध्ये फसव्या ॲक्सेस पॉइंटचाही समावेश आहे. तुमच्या MDM-नियोजित WiFi प्रोफाइलमध्ये नेहमी विश्वसनीय CA आणि अपेक्षित सर्व्हरचे नाव निर्दिष्ट करा. ही एकच कॉन्फिगरेशन तपासणी आज तुम्ही अंमलात आणू शकत असलेली सर्वात प्रभावी सुरक्षा सुधारणा आहे.
प्रमाणपत्र लाइफसायकल व्यवस्थापन स्वयंचलित करा
प्रमाणपत्रांची मुदत संपते. जर तुमच्याकडे स्वयंचलित नूतनीकरण प्रक्रिया नसेल, तर एकाच वेळी प्रमाणपत्रांची मुदत संपल्यावर तुम्हाला मोठ्या प्रमाणावर प्रमाणीकरण अपयशाचा सामना करावा लागेल. नूतनीकरण स्वयंचलित करण्यासाठी SCEP किंवा EST वापरा आणि मुदत संपण्याच्या तारखेच्या खूप आधी देखरेख सतर्कता (मॉनिटरिंग अलर्ट) कॉन्फिगर करा. एखादे डिव्हाइस हरवल्यास किंवा कर्मचाऱ्याने नोकरी सोडल्यास, प्रमाणपत्र त्वरित रद्द करा. रिअल-टाइम प्रमाणीकरणासाठी CRLs तपासण्यासाठी किंवा OCSP वापरण्यासाठी तुमचा RADIUS सर्व्हर कॉन्फिगर करा.
प्रमाणीकरण पद्धतीनुसार तुमच्या नेटवर्कचे विभाजन करा
मोठ्या किंवा वितरित वातावरणात, स्वतंत्र SSIDs वर दोन्ही प्रोटोकॉल चालवण्याचा विचार करा. कॉर्पोरेट व्यवस्थापित डिव्हाइसेस समर्पित स्टाफ WiFi SSID वर EAP-TLS द्वारे प्रमाणित होतात. कंत्राटदार आणि BYOD डिव्हाइसेस योग्य VLAN विभाजनासह स्वतंत्र SSID वर EAP-TTLS द्वारे प्रमाणित होतात. हा पॅटर्न प्रिमियर इन आणि व्हिटब्रेड सारख्या आदरातिथ्य समूहांमध्ये सामान्य आहे, जेथे कर्मचाऱ्यांच्या डिव्हाइसेसचे व्यवस्थापन केले जाते आणि प्रमाणपत्रे दिली जातात, तर अतिथी पायाभूत सुविधा स्वतंत्र प्रमाणीकरण मार्ग वापरतात. SSID आर्किटेक्चरवरील अधिक तपशीलांसाठी, आमचे मार्गदर्शक पहा थ्री SSIDs टू रूल देम ऑल: द WiFi डिझाइन फॉर गेस्ट, स्टाफ अँड IoT.
सर्व पायाभूत सुविधांमध्ये वेळ समक्रमित करा
प्रमाणपत्र प्रमाणीकरण अचूक सिस्टम वेळेवर अवलंबून असते. क्लायंट डिव्हाइसेस किंवा RADIUS सर्व्हरवरील घड्याळाच्या वेळेतील फरकामुळे 'अद्याप वैध नाही' किंवा 'मुदत संपली आहे' अशा प्रमाणपत्राच्या त्रुटी उद्भवतात ज्यांचे निदान करणे कठीण असते. सर्व पायाभूत सुविधांचे घटक विश्वसनीय NTP सर्व्हरसह समक्रमित असल्याचे सुनिश्चित करा.
समस्यानिवारण आणि जोखीम कमी करणे
अज्ञात CA त्रुटी
जर RADIUS लॉग्ज 'unknown CA' दर्शवत असतील, तर क्लायंट डिव्हाइस RADIUS सर्व्हरचे प्रमाणपत्र जारी करणाऱ्या CA वर विश्वास ठेवत नाही. तुमच्या MDM प्रोफाइलमध्ये रूट CA प्रमाणपत्र समाविष्ट असल्याचे आणि अर्जदार त्यावर विश्वास ठेवण्यासाठी कॉन्फिगर केलेला असल्याचे सत्यापित करा. CA रोटेशन किंवा प्रमाणपत्र नूतनीकरणानंतर, अपडेट केलेले CA बंडल सर्व डिव्हाइसेसवर पुन्हा पुश करा.
EAP पद्धतीचा बेबनाव
जर डिव्हाइसेस ॲक्सेस पॉइंटशी कनेक्ट होत असतील परंतु प्रमाणीकरण अयशस्वी होत असेल, तर क्लायंटवर कॉन्फिगर केलेली EAP पद्धत RADIUS सर्व्हरद्वारे स्वीकारलेल्या पद्धतीशी जुळत असल्याची तपासणी करा. केवळ PEAP साठी कॉन्फिगर केलेल्या RADIUS सर्व्हरवर EAP-TLS साठी सेट केलेले डिव्हाइस प्रोफाइल अयशस्वी होईल.
कालबाह्य झालेल्या प्रमाणपत्रांमुळे मोठ्या प्रमाणावर होणारे अपयश
जर मोठ्या संख्येने उपकरणे एकाच वेळी ऑथेंटिकेट होण्यास अपयशी ठरली, तर सर्वात आधी प्रमाणपत्र संपण्याची तारीख (certificate expiry dates) तपासा. EAP-TLS उपयोजनांमध्ये मोठ्या प्रमाणावर 802.1X अयशस्वी होण्याचे हे सर्वात सामान्य कारण आहे. अशी मॉनिटरिंग सिस्टम लागू करा जी प्रमाणपत्र संपण्याच्या ६० दिवस, ३० दिवस आणि सात दिवस आधी अलर्ट पाठवेल.
RADIUS क्लायंटची चुकीची कॉन्फिगरेशन
प्रत्येक ॲक्सेस पॉइंट किंवा वायरलेस कंट्रोलर योग्य IP ॲड्रेस आणि शेअर्ड सीक्रेटसह RADIUS क्लायंट म्हणून परिभाषित केलेला असणे आवश्यक आहे. यामधील विसंगतीमुळे ऑथेंटिकेशन टाईमआउट्स होतात, जे सहसा चुकीच्या पद्धतीने EAP पद्धतीमुळे झाल्याचे समजले जाते. पहिल्या दिवसापासूनच तपशीलवार RADIUS लॉगिंग सक्षम करा. अधिक WiFi ट्रबलशूटिंग मार्गदर्शनासाठी, आमचे Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures हे मार्गदर्शन पहा.
अनुपालन आणि नियामक संरेखन (Compliance and Regulatory Alignment)
CISO आणि नेटवर्क आर्किटेक्ट्ससाठी, EAP-TLS आणि EAP-TTLS मधील निवड करताना नियामक लँडस्केप समजून घेणे आवश्यक आहे. EAP पद्धतीची निवड थेट तुमच्या अनेक प्रमुख फ्रेमवर्कमधील अनुपालन स्थितीवर परिणाम करते.
PCI DSS 4.0 (पेमेंट कार्ड इंडस्ट्री डेटा सिक्युरिटी स्टँडर्ड) ला कार्डधारक डेटा वातावरणातील वायरलेस नेटवर्कसाठी मजबूत क्रिप्टोग्राफिक ऑथेंटिकेशन आवश्यक आहे. आवश्यकता ८.३ CDE च्या सर्व प्रवेशासाठी मल्टी-फॅक्टर ऑथेंटिकेशन अनिवार्य करते, आणि व्याप्तीमधील वायरलेस नेटवर्कने मजबूत ऑथेंटिकेशन यंत्रणा वापरली पाहिजे. EAP-TLS, प्रमाणपत्र-आधारित परस्पर ऑथेंटिकेशनसह, ही आवश्यकता निश्चितपणे पूर्ण करते. जर अंतर्गत ऑथेंटिकेशन योग्यरित्या सुरक्षित केले असेल आणि सर्व्हर प्रमाणपत्र प्रमाणीकरण लागू केले असेल तर MS-CHAPv2 सह EAP-TTLS स्वीकार्य आहे, परंतु EAP-TLS हा अधिक मजबूत आणि ऑडिटरसाठी सोयीस्कर पर्याय आहे. HIPAA (हेल्थ इन्शुरन्स पोर्टेबिलिटी अँड अकाउंटेबिलिटी ॲक्ट) ला कव्हर केलेल्या संस्थांनी तांत्रिक सुरक्षा उपाय लागू करणे आवश्यक आहे जे इलेक्ट्रॉनिक कम्युनिकेशन नेटवर्कवर प्रसारित होणाऱ्या इलेक्ट्रॉनिक संरक्षित आरोग्य माहितीचे (ePHI) संरक्षण करतात. HIPAA सुरक्षा नियम विशिष्ट प्रोटोकॉल अनिवार्य करत नाही, परंतु ePHI वाहून नेणाऱ्या वायरलेस नेटवर्कसाठी एन्क्रिप्शन आणि ॲक्सेस कंट्रोलची अपेक्षा व्यवस्थापित वैद्यकीय उपकरणांच्या ताफ्यासाठी EAP-TLS च्या आणि कर्मचारी उपकरणांसाठी लागू केलेल्या सर्व्हर प्रमाणपत्र प्रमाणीकरणासह EAP-TTLS च्या बाजूने मोठ्या प्रमाणावर झुकते.
WPA3-Enterprise 192-bit (ज्याला Suite B किंवा CNSA मोड देखील म्हणतात) हा Wi-Fi Alliance च्या WPA3 प्रमाणपत्राचा सर्वोच्च सुरक्षा स्तर आहे. हे EAP-TLS ला एकमेव अनुमत ऑथेंटिकेशन पद्धत म्हणून अनिवार्य करते, विशिष्ट सायफर सूटसह (ECDHE with P-384, AES-256-GCM) TLS १.२ किंवा त्याहून अधिक आवश्यक आहे, आणि ECDSA किंवा RSA-3072 प्रमाणपत्रांची आवश्यकता असते. सरकारी, संरक्षण किंवा गंभीर पायाभूत सुविधांच्या ॲप्लिकेशनसाठी WPA3-Enterprise 192-bit तैनात करणाऱ्या संस्थांनी EAP-TLS वापरणे आवश्यक आहे.ISO/IEC 27001 विशिष्ट प्रोटोकॉल्स अनिवार्य करत नाही, परंतु नेटवर्क संसाधनांसाठी संस्थांनी योग्य प्रवेश नियंत्रणे लागू करणे आवश्यक आहे. EAP-TLS किंवा EAP-TTLS (सक्तीच्या सर्व्हर प्रमाणपत्र प्रमाणीकरणासह) यांपैकी एकासह 802.1X उपयोजन, Annex A.9.1 आणि A.13.1 च्या नेटवर्क प्रवेश नियंत्रण आवश्यकता पूर्ण करते.
ROI आणि व्यावसायिक प्रभाव
EAP-TLS वर स्थलांतरित होण्यासाठी PKI आणि MDM एकत्रीकरणामध्ये सुरुवातीची गुंतवणूक आवश्यक आहे, परंतु यामुळे पासवर्ड रीसेटचा कार्यात्मक खर्च आणि तडजोड केलेल्या क्रेडेंशियल्समुळे नेटवर्क उल्लंघनाचा आर्थिक धोका दूर होतो. ४०० स्टोअर्स असलेल्या रिटेल साखळीसाठी, सामायिक केलेल्या PSK नेटवर्कवरील एका तडजोड केलेल्या पासवर्डमुळे संपूर्ण मालमत्ता धोक्यात येऊ शकते. EAP-TLS हा हल्ला करण्याचा मार्ग पूर्णपणे काढून टाकतो.
बहु-भाडेकरू (multi-tenant) पर्यावरण आणि प्रवासी हबसाठी, सुरक्षित प्रमाणीकरण केवळ अधिकृत वापरकर्तेच नेटवर्क बँडविड्थचा वापर करत असल्याची खात्री करते, ज्यामुळे पायाभूत सुविधांचा वापर इष्टतम होतो. RADIUS प्रमाणपत्र गुणधर्मांद्वारे डायनॅमिक VLAN असाइनमेंट क्रिप्टोग्राफिक पद्धतीने लागू केलेल्या नेटवर्क विभाजनास सक्षम करते, ज्यामुळे डिव्हाइसेस केवळ SSID निवडीवर किंवा MAC पत्ता फिल्टरिंगवर अवलंबून न राहता प्रमाणपत्र गुणधर्मांवर आधारित योग्य नेटवर्क विभागावर ठेवले जातील याची खात्री होते.
Purple चे WiFi Analytics प्लॅटफॉर्म दोन्ही प्रमाणीकरण मार्गांशी समाकलित होते, जे तुमच्या संपूर्ण मालमत्तेवर डिव्हाइस संख्या, सत्र कालावधी आणि नेटवर्क वापराविषयी दृश्यमानता प्रदान करते. क्षेत्र-विशिष्ट उपयोजन मार्गदर्शनासाठी, आमच्या Hospitality, Retail, Healthcare आणि Transport च्या संसाधनांचा शोध घ्या.
महत्वाच्या व्याख्या
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
RFC 5216 मध्ये परिभाषित केलेली एक 802.1X प्रमाणीकरण पद्धत ज्यासाठी क्लायंट डिव्हाइस आणि RADIUS सर्व्हर या दोन्हीने वैध X.509 प्रमाणपत्रे सादर करणे आवश्यक आहे. कोणतेही पासवर्ड बदलले जात नाहीत. प्रमाणीकरण परस्पर आणि क्रिप्टोग्राफिक पद्धतीने बांधील असते.
एंटरप्राइझ वायरलेस सुरक्षेसाठी सुवर्ण मानक. WPA3-Enterprise 192-bit साठी आवश्यक आणि PCI-DSS 4.0 कार्डधारक डेटा वातावरणासाठी अत्यंत शिफारसीय.
EAP-TTLS (Extensible Authentication Protocol - Tunneled Transport Layer Security)
RFC 5281 मध्ये परिभाषित केलेली एक 802.1X प्रमाणीकरण पद्धत ज्यासाठी एनक्रिप्टेड TLS टनेल स्थापित करण्यासाठी केवळ सर्व्हर-साइड प्रमाणपत्राची आवश्यकता असते. क्लायंट दुय्यम अंतर्गत प्रमाणीकरण पद्धतीचा, सामान्यतः युझरनेम आणि पासवर्डचा वापर करून टनेलच्या आत प्रमाणीकरण करतो.
BYOD वातावरण आणि मिश्र-OS नेटवर्क्स जेथे क्लायंट प्रमाणपत्रे तैनात करणे कार्यात्मकदृष्ट्या अव्यवहार्य आहे अशा ठिकाणांसाठी पसंतीचा पर्याय.
802.1X
पोर्ट-आधारित नेटवर्क ऍक्सेस नियंत्रणासाठी एक IEEE मानक जे LAN किंवा WLAN ला कनेक्ट होणाऱ्या उपकरणांसाठी प्रमाणीकरण यंत्रणा प्रदान करते. हे सप्लिकंट, ऑथेंटिकेटर आणि ऑथेंटिकेशन सर्व्हरच्या भूमिका परिभाषित करते.
एक पायाभूत फ्रेमवर्क जे एंटरप्राइझ नेटवर्क्सना एका सामायिक पासवर्डवर अवलंबून राहण्याऐवजी वैयक्तिक उपकरणांचे प्रमाणीकरण करण्यास सक्षम करते. EAP-TLS आणि EAP-TTLS दोन्ही या फ्रेमवर्कमध्ये कार्य करतात.
RADIUS (Remote Authentication Dial-In User Service)
एक नेटवर्किंग प्रोटोकॉल जो नेटवर्क सेवेशी कनेक्ट होणाऱ्या युझर्ससाठी केंद्रीकृत प्रमाणीकरण, अधिकृतता आणि अकाउंटिंग व्यवस्थापन प्रदान करतो. 802.1X उपयोजनांमध्ये, RADIUS सर्व्हर हा ऑथेंटिकेशन सर्व्हर असतो जो प्रमाणपत्रे किंवा क्रेडेंशियल्स सत्यापित करतो.
सर्व्हर घटक जो प्रमाणपत्रे किंवा पासवर्ड सत्यापित करतो आणि ऍक्सेस पॉईंटला नेटवर्क ऍक्सेस मंजूर किंवा नाकारण्याचे निर्देश देतो. सपोर्टेड प्लॅटफॉर्म्समध्ये FreeRADIUS, Microsoft NPS, आणि Cisco ISE समाविष्ट आहेत.
PKI (Public Key Infrastructure)
डिजिटल प्रमाणपत्रे तयार करण्यासाठी, व्यवस्थापित करण्यासाठी, वितरित करण्यासाठी, वापरण्यासाठी, संग्रहित करण्यासाठी आणि रद्द करण्यासाठी आवश्यक असलेल्या भूमिका, धोरणे, हार्डवेअर, सॉफ्टवेअर आणि प्रक्रियांचा संच. एका सामान्य एंटरप्राइझ PKI मध्ये ऑफलाइन रूट CA आणि ऑनलाइन इश्यूइंग CA समाविष्ट असते.
EAP-TLS प्रमाणीकरणामध्ये वापरले जाणारे क्लायंट आणि सर्व्हर प्रमाणपत्रे जारी करण्यासाठी आवश्यक असणारी बॅकएंड पायाभूत सुविधा. PKI शिवाय, EAP-TLS उपयोजित केले जाऊ शकत नाही.
MDM (Mobile Device Management)
कर्मचाऱ्यांच्या मोबाईल उपकरणांचे आणि लॅपटॉप्सचे निरीक्षण, व्यवस्थापन आणि सुरक्षितता राखण्यासाठी IT विभागांद्वारे वापरले जाणारे सॉफ्टवेअर. Microsoft Intune आणि Jamf सारखे MDM प्लॅटफॉर्म्स नोंदणीकृत उपकरणांवर प्रमाणपत्रे आणि WiFi प्रोफाइल्सचे उपयोजन स्वयंचलित करू शकतात.
मोठ्या प्रमाणावर EAP-TLS साठी क्लायंट प्रमाणपत्रांचे उपयोजन स्वयंचलित करण्यासाठी आवश्यक. MDM इंटिग्रेशनशिवाय, हजारो उपकरणांवर मॅन्युअली प्रमाणपत्रे स्थापित करणे कार्यात्मकदृष्ट्या अशक्य आहे.
SCEP (Simple Certificate Enrollment Protocol)
नेटवर्क उपकरणांना डिजिटल प्रमाणपत्रे जारी करणे स्वयंचलित करण्यासाठी वापरला जाणारा एक प्रोटोकॉल. MDM प्लॅटफॉर्म्स युझरच्या हस्तक्षेपाशिवाय नोंदणीकृत कॉर्पोरेट उपकरणांवर प्रमाणपत्रे मागवण्यासाठी आणि स्थापित करण्यासाठी SCEP चा वापर करतात.
EAP-TLS उपयोजनांमध्ये झिरो-टच प्रमाणपत्र प्रोव्हिजनिंगसाठी मानक यंत्रणा. Microsoft Intune, Jamf, आणि बहुतेक एंटरप्राइझ MDM प्लॅटफॉर्म्सद्वारे समर्थित.
CRL (Certificate Revocation List)
डिजिटल प्रमाणपत्रांची एक सूची जी जारी करणार्‍या Certificate Authority द्वारे त्यांच्या नियोजित समाप्ती तारखेपूर्वी रद्द केली गेली आहे. Connecting डिव्हाइसचे प्रमाणपत्र अद्याप वैध आहे की नाही हे सत्यापित करण्यासाठी RADIUS सर्व्हर CRL तपासतात.
अशी यंत्रणा जी तुम्हाला चोरीला गेलेल्या किंवा तडजोड केलेल्या उपकरणाचे प्रमाणपत्र रद्द करून त्याला नेटवर्कवरून ताबडतोब ब्लॉक करण्याची परवानगी देते. RADIUS सर्व्हर वारंवार CRL तपासण्यासाठी कॉन्फिगर केलेले असावेत, किंवा रिअल-टाइम व्हॅलिडेशनसाठी OCSP चा वापर करावा.
X.509
सार्वजनिक की प्रमाणपत्रांचे स्वरूप परिभाषित करणारा एक ITU-T मानक. EAP-TLS आणि EAP-TTLS दोन्ही सर्व्हर प्रमाणीकरणासाठी X.509 प्रमाणपत्रे वापरतात. EAP-TLS ला क्लायंट डिव्हाइसवर देखील X.509 प्रमाणपत्रांची आवश्यकता असते.
सर्व एंटरप्राइझ PKI उपयोजनांमध्ये वापरले जाणारे प्रमाणपत्र स्वरूप. जेव्हा IT टीम 802.1X च्या संदर्भात 'डिजिटल प्रमाणपत्रे' चा संदर्भ घेतात, तेव्हा त्यांचा अर्थ X.509 प्रमाणपत्रे असा असतो.
Inner authentication method
EAP-TTLS द्वारे स्थापित केलेल्या कूटबद्ध TLS बोगद्याच्या आत वापरला जाणारा दुय्यम प्रमाणीकरण प्रोटोकॉल. सामान्य अंतर्गत पद्धतींमध्ये PAP (Password Authentication Protocol), CHAP, आणि MS-CHAPv2 यांचा समावेश होतो.
अंतर्गत प्रमाणीकरण पद्धतीची निवड EAP-TTLS उपयोजनाच्या सुरक्षा गुणधर्मांवर परिणाम करते. PAP बोगद्याच्या आत प्लेनटेक्स्टमध्ये पासवर्ड पाठवते; MS-CHAPv2 चॅलेंज - रिस्पॉन्स मेकॅनिझम वापरते. बोगदा सर्व अंतर्गत प्रमाणीकरण ट्रॅफिक कूटबद्ध (encrypt) करतो.
सोडवलेली उदाहरणे
४०० स्टोअर्स असलेल्या एका राष्ट्रीय रिटेल साखळीला त्यांचे पॉइंट-ऑफ-सेल (POS) टर्मिनल्स आणि कर्मचार्‍यांचे हँडहेल्ड स्कॅनर्स सुरक्षित करायचे आहेत. हे वातावरण PCI-DSS 4.0 च्या कक्षेमध्ये येते. सर्व डिव्हाइसेस Microsoft Intune मध्ये एनरोल आहेत. त्यांनी कोणता प्रोटोकॉल तैनात करावा आणि मुख्य कॉन्फिगरेशन पायऱ्या कोणत्या आहेत?
EAP-TLS तैनात करा. पायरी १: एअर-गॅप असलेल्या ऑफलाइन रूट CA आणि ऑनलाइन इश्युइंग CA सह टू-टियर PKI स्थापित करा. पायरी २: सर्व POS आणि स्कॅनर डिव्हाइसेसना लक्ष्य करणारे SCEP सर्टिफिकेट प्रोफाइलसह Microsoft Intune कॉन्फिगर करा. पायरी ३: RADIUS सर्व्हर (Microsoft NPS किंवा क्लाउड RADIUS) तैनात करा आणि अंतर्गत CA विरुद्ध क्लायंट सर्टिफिकेट्स व्हॅलिडेट करण्यासाठी ते कॉन्फिगर करा. पायरी ४: RADIUS सर्व्हरवर CRL चेकिंग किंवा OCSP सक्षम करा. पायरी ५: SSID, ऑथेंटिकेशन पद्धत म्हणून EAP-TLS, ट्रस्टेड रूट CA आणि अपेक्षित RADIUS सर्व्हरचे नाव निर्दिष्ट करणारे WiFi प्रोफाइल Intune द्वारे पुश करा. पायरी ६: सर्व ४०० साइट्सवर रोल आउट करण्यापूर्वी १० डिव्हाइसेसच्या पायलट ग्रुपसह चाचणी करा. पायरी ७: एक्स्पायरीच्या ६०, ३० आणि ७ दिवस आधी अलर्टसह सर्टिफिकेट एक्स्पायरी मॉनिटरिंग प्रक्रिया स्थापित करा.
एका मोठ्या युनिव्हर्सिटी कॅम्पसला वैयक्तिक लॅपटॉप, स्मार्टफोन आणि टॅब्लेट (BYOD) चे मिश्रण वापरून २०,००० विद्यार्थ्यांसाठी सुरक्षित WiFi प्रदान करायचे आहे. आयटी टीम वैयक्तिक डिव्हाइसेसवर सर्टिफिकेट्स इन्स्टॉल करू शकत नाही. युनिव्हर्सिटी आयडेंटिटी मॅनेजमेंटसाठी Microsoft Entra ID वापरते. त्यांनी कोणता प्रोटोकॉल तैनात करावा?
RADIUS द्वारे Microsoft Entra ID सह एकत्रित करून, इनर ऑथेंटिकेशन पद्धत म्हणून MS-CHAPv2 सह EAP-TTLS तैनात करा. पायरी १: सर्व प्रमुख ऑपरेटिंग सिस्टम्सद्वारे ट्रस्टेड असलेल्या पब्लिक CA कडून सर्व्हर सर्टिफिकेट मिळवा, किंवा अंतर्गत CA तैनात करा आणि मॅनेज केलेल्या डिव्हाइसेससाठी युनिव्हर्सिटीच्या डिव्हाइस मॅनेजमेंट टूल्सद्वारे रूट सर्टिफिकेट वितरित करा. पायरी २: LDAP किंवा RADIUS प्रॉक्सी वापरून Microsoft Entra ID विरुद्ध ऑथेंटिकेट करण्यासाठी RADIUS सर्व्हर कॉन्फिगर करा. पायरी ३: विद्यार्थ्यांसाठी SSID, EAP-TTLS, MS-CHAPv2 आणि ट्रस्टेड CA निर्दिष्ट करणारे WiFi ऑनबोर्डिंग मार्गदर्शक तयार करा. पायरी ४: Entra ID स्तरावर मजबूत पासवर्ड पॉलिसी लागू करा आणि सुरुवातीच्या एनरोलमेंटसाठी मल्टी-फॅक्टर ऑथेंटिकेशन सक्षम करण्याचा विचार करा. पायरी ५: सर्व्हर सर्टिफिकेट व्हॅलिडेशन सक्तीचे करण्यासाठी आणि ट्रस्टेड CA आणि RADIUS सर्व्हरचे नाव निर्दिष्ट करण्यासाठी WiFi प्रोफाइल कॉन्फिगर करा.
सराव प्रश्न
Q1. तुम्ही ५० ऑफिस लोकेशन्सवरील ५,००० कॉर्पोरेट लॅपटॉप्सच्या ताफ्यासाठी EAP-TLS उपयोजित करत आहात. Microsoft Intune द्वारे WiFi प्रोफाईल पुश केल्यानंतर, डिव्हाइसेस कनेक्ट होण्यास अपयशी ठरत आहेत. RADIUS सर्व्हर लॉग प्रत्येक अयशस्वी प्रमाणीकरण प्रयत्नासाठी 'Unknown CA' दाखवतात. याचे सर्वात संभाव्य कारण काय आहे, आणि तुम्ही त्याचे निवारण कसे कराल?
टीप: क्लायंट बाजूने प्रमाणपत्र वैधता साखळीचा (validation chain) विचार करा, आणि MDM प्रोफाईलमध्ये केवळ EAP पद्धत सेटिंगव्यतिरिक्त कशाचा समावेश असणे आवश्यक आहे ते पहा.
नमुना उत्तर पहा
क्लायंट डिव्हाइसेसना RADIUS सर्व्हरचे प्रमाणपत्र जारी करणार्‍या अंतर्गत Certificate Authority वर विश्वास ठेवण्यासाठी कॉन्फिगर केलेले नाही. MDM WiFi प्रोफाईलमध्ये रूट CA प्रमाणपत्र (आणि कोणतेही इंटरमीडिएट CA प्रमाणपत्रे) समाविष्ट असले पाहिजे आणि सर्व्हर वैधतेसाठी त्यांच्यावर विश्वास ठेवण्यासाठी सप्लिकंटला कॉन्फिगर केले पाहिजे. याशिवाय, क्लायंट RADIUS सर्व्हरचे प्रमाणपत्र नाकारतो आणि हँडशेक संपुष्टात आणतो. उपाय: 'Root certificate for server validation' सेटिंग अंतर्गत विश्वसनीय रूट CA प्रमाणपत्र समाविष्ट करण्यासाठी Intune WiFi प्रोफाईल अपडेट करा, आणि सर्व डिव्हाइसेसवर प्रोफाईल पुन्हा पुश करा.
Q2. तुमच्या संस्थेने मिश्र BYOD वातावरणासाठी EAP-TTLS उपयोजित केले आहे. सुरक्षा पुनरावलोकनादरम्यान, तुमच्या पेनेट्रेशन टेस्टिंग टीमने हे दाखवून दिले की ते सेल्फ-साईन केलेल्या प्रमाणपत्रासह रॉग ॲक्सेस पॉइंट सेट करून वापरकर्त्यांचे क्रेडेंशियल कॅप्चर करू शकतात. EAP-TLS वर स्थलांतर न करता तुम्ही या असुरक्षिततेचे निवारण कसे कराल?
टीप: अंतर्गत प्रमाणीकरणापूर्वी काय घडते आणि क्लायंट बाजूने कोणते कॉन्फिगरेशन अविश्वसनीय सर्व्हरसह TLS बोगदा स्थापित होण्यापासून रोखते याचा विचार करा.
नमुना उत्तर पहा
ही असुरक्षितता अस्तित्वात आहे कारण क्लायंट डिव्हाइसेस RADIUS सर्व्हरच्या प्रमाणपत्राचे प्रमाणीकरण करण्यासाठी कॉन्फिगर केलेले नाहीत. निवारण: सर्व WiFi प्रोफाईल्स अपडेट करा (मॅनेज्ड डिव्हाइसेससाठी MDM द्वारे, आणि BYOD साठी नवीन ऑनबोर्डिंग मार्गदर्शकाद्वारे) जेणेकरून सर्व्हर प्रमाणपत्र प्रमाणीकरण सक्तीचे होईल. प्रोफाईलमध्ये विश्वसनीय CA आणि अपेक्षित RADIUS सर्व्हरचे नाव निर्दिष्ट करा. अशा प्रकारे कॉन्फिगर केलेले क्लायंट निर्दिष्ट विश्वसनीय CA द्वारे स्वाक्षरी केलेले प्रमाणपत्र सादर न करू शकणाऱ्या कोणत्याही सर्व्हरसह TLS बोगदा स्थापित करण्यास नकार देतील, ज्यामुळे रॉग ॲक्सेस पॉइंटचा हल्ला करण्याचा मार्ग नष्ट होईल.
Q3. एका हॉस्पिटलचे IT संचालक त्यांच्या वैद्यकीय IoT डिव्हाइसेससाठी (इन्फ्युजन पंप, पेशंट मॉनिटर्स, पर्यावरणीय सेन्सर) 802.1X उपयोजित करू इच्छितात. ते EAP-TTLS चा विचार करत आहेत कारण त्यांना वाटते की प्रमाणपत्र व्यवस्थापन अत्यंत गुंतागुंतीचे आहे. हा युक्तिवाद का चुकीचा आहे, आणि योग्य दृष्टीकोन कोणता आहे?
टीप: हेडलेस IoT डिव्हाइसेस प्रमाणीकरण प्रॉम्प्ट कशा प्रकारे हाताळतात आणि जेव्हा एखादे डिव्हाइस क्रेडेंशियल इनपुट करू शकत नाही तेव्हा काय होते याचा विचार करा.
नमुना उत्तर पहा
हा युक्तिवाद दोन कारणांमुळे चुकीचा आहे. पहिले, बहुतेक हेडलेस वैद्यकीय IoT उपकरणांमध्ये क्रेडेंशियल प्रविष्ट करण्यासाठी यूजर इंटरफेस नसतो, ज्यामुळे युझरनेम/पासवर्ड इनर ऑथेंटिकेशनसह EAP-TTLS वापरणे व्यावहारिकदृष्ट्या अशक्य बनते. दुसरे, प्रत्यक्ष व्यवहारात IoT साठी EAP-TLS खरोखर सोपे आहे: उपयोजनापूर्वी डिव्हाइस स्टेजिंग दरम्यान प्रमाणपत्रे प्रदान केली जाऊ शकतात आणि कोणतेही युझर इंटरअॅक्शन न करता डिव्हाइस स्वयंचलितपणे ऑथेंटिकेट होते. स्टेजिंग दरम्यान वापरल्या जाणाऱ्या डिव्हाइस मॅनेजमेंट सिस्टमद्वारे प्रदान केलेल्या प्रमाणपत्रांसह EAP-TLS चा वापर करणे हा योग्य दृष्टिकोन आहे. हे आरोग्य सेवा वातावरणात मजबूत वायरलेस ऑथेंटिकेशनसाठी HIPAA आवश्यकता देखील पूर्ण करते.
Q4. तुम्ही २०० प्रॉपर्टीज असलेल्या हॉटेल ग्रुपसाठी नेटवर्क आर्किटेक्ट आहात. तुम्हाला ३,००० व्यवस्थापित स्टाफ डिव्हाइसेससाठी (Intune मध्ये नोंदणीकृत) Staff WiFi सुरक्षित करणे आवश्यक आहे आणि स्वतःचे लॅपटॉप आणणाऱ्या कंत्राटदारांना आणि थर्ड-पार्टी व्हेंडरना सुरक्षित WiFi प्रदान करणे आवश्यक आहे. ऑथेंटिकेशन आर्किटेक्चर डिझाइन करा.
टीप: एकाच SSID सह एकच EAP पद्धत या दोन्ही लोकसंख्येसाठी काम करू शकते का, आणि या दोन प्रकारच्या युझर्समुळे नेटवर्क सेगमेंटेशनवर काय परिणाम होतील याचा विचार करा.
नमुना उत्तर पहा
वेगवेगळ्या ऑथेंटिकेशन पद्धती आणि VLAN असाइनमेंटसह दोन स्वतंत्र SSID तैनात करा. SSID 1 (Staff WiFi): EAP-TLS, Intune SCEP द्वारे पुश केलेली प्रमाणपत्रे, हॉटेल मॅनेजमेंट सिस्टममध्ये पूर्ण प्रवेशासह स्टाफ नेटवर्क सेगमेंटला असाइन केलेले VLAN. SSID 2 (Contractor WiFi): MS-CHAPv2 सह EAP-TTLS, वेगळ्या डिरेक्टरी किंवा Microsoft Entra ID मधील मर्यादित कालावधीच्या कंत्राटदार खात्याद्वारे क्रेडेंशियल सत्यापित केले जातात, अंतर्गत सिस्टममध्ये कोणताही प्रवेश नसलेल्या आयसोलेटेड इंटरनेट-ओन्ली सेगमेंटला असाइन केलेले VLAN. दोन्ही SSID ने सर्व्हर प्रमाणपत्र प्रमाणीकरण अनिवार्य केले पाहिजे. हे आर्किटेक्चर कर्मचाऱ्यांना सर्वोच्च सुरक्षा प्रदान करते तर कंत्राटदारांना एक व्यावहारिक ऑथेंटिकेशन पद्धत देते, आणि नेटवर्क सेगमेंटेशन हे सुनिश्चित करते की तडजोड केलेले कंत्राटदार क्रेडेंशियल अंतर्गत हॉटेल मॅनेजमेंट सिस्टमपर्यंत पोहोचू शकत नाही.
वारंवार विचारले जाणारे प्रश्न
What is the primary technical difference between EAP-TLS and EAP-TTLS?
EAP-TLS (RFC 5216) requires mutual authentication where both the RADIUS server and client device validate each other using X.509 digital certificates. EAP-TTLS (RFC 5281) requires a digital certificate only on the RADIUS server to build an encrypted TLS tunnel, through which the client authenticates using inner credentials such as PAP, CHAP, or MSCHAPv2.
Does EAP-TTLS require client certificates?
No. EAP-TTLS eliminates the need to issue or manage client-side certificates, requiring only a trusted server certificate on the RADIUS server. This simplifies onboarding for unmanaged BYOD devices while securing credentials inside the encrypted outer TLS tunnel.
Which protocol is more secure against rogue access points and evil twin attacks?
EAP-TLS is cryptographically immune to evil twin attacks because authentication relies on mutual private key verification. EAP-TTLS protects credentials inside the TLS tunnel, but requires client devices to strictly validate the RADIUS server root CA certificate and domain name to prevent rogue access points from intercepting inner credentials.
Why do organizations choose EAP-TTLS over EAP-TLS?
Organizations choose EAP-TTLS when they do not operate a mobile device management (MDM) or public key infrastructure (PKI) capable of enrolling client certificates on every device, or when authenticating against directory services and multi-factor authentication tokens using inner PAP without SCEP or EST overhead.
Do Windows, macOS, iOS, and Android support EAP-TTLS natively?
Apple macOS, iOS, and Android provide native out-of-the-box supplicant support for EAP-TTLS with inner PAP and MSCHAPv2. Windows 10 and 11 also support EAP-TTLS natively, though configuring inner PAP typically requires an XML network profile or automated onboarding tool.
या मालिकेमध्ये पुढे वाचा
iOS आणि macOS 802.1X ट्रबलशूटिंग: Intune, Jamf आणि Microsoft Entra ID साठी एक डिप्लोयमेंट चेकलिस्ट
iPhones, iPads आणि Macs वर Intune किंवा Jamf Pro च्या माध्यमातून 802.1X का अयशस्वी होत आहे याचे निदान करण्यासाठी ही चेकलिस्ट वापरा. प्रत्येक बिघाड चारपैकी एका कारणामुळे होतो: सर्व्हर ट्रस्ट, आयडेंटिटी सर्टिफिकेट, macOS मोड किंवा Microsoft Entra ID ग्रुप स्कोपिंग. तुम्ही eapolclient आणि RADIUS लॉग्समधून कारणाची खात्री कराल, त्यावर उपाय लागू कराल आणि भविष्यातील सर्टिफिकेट रोटेशनचे टप्पे ठरवाल.
Intune WiFi प्रोफाइल सर्व्हर ट्रस्ट: Entra ID साठी सर्टिफिकेट सर्व्हर नावे आणि रूट CA चेकलिस्ट
तुम्ही Intune WiFi प्रोफाईलचे सर्व्हर व्हॅलिडेशन कॉन्फिगर करू शकाल जेणेकरून EAP-TLS आणि PEAP हे Windows, Apple आणि Android वर कनेक्ट होतील. तुम्ही सर्टिफिकेट सर्व्हरच्या नावांना RADIUS सर्टिफिकेटशी जुळवून घ्याल, योग्य root CA डिप्लोय कराल, Microsoft Entra ID ग्रुप असाइनमेंट्स अलाइन कराल आणि सर्टिफिकेट रिन्यूअल्स कनेक्शन खंडित करण्यापूर्वी ते आधीच स्टेज करून ठेवाल.
Android 802.1X आणि EAP-TLS ट्रबलशूटिंग: Intune आणि Microsoft Entra ID साठी एक डिप्लॉयमेंट चेकलिस्ट
तुम्ही हे शोधून काढू शकाल की व्यवस्थापित Android फोन्स तुमच्या स्टाफ SSID वर EAP-TLS मध्ये का अपयशी ठरतात आणि ते Intune मध्ये दुरुस्त करू शकाल. प्रत्येक समस्येला चार सामान्य कारणांशी जुळवून घ्या - गहाळ CA किंवा डोमेन, चुकीच्या प्रोफाइलमधील क्लायंट प्रमाणपत्र, न जुळणारे RADIUS सर्व्हरचे नाव व्हॅल्यू, किंवा न पोहोचवलेले ट्रस्टेड रूट. त्यानंतर एक रोलआउट चेकलिस्ट लागू करा जी पुन्हा होणारे आउटेज थांबवते.
तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?
आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.