EAP-TLS बनाम EAP-TTLS: आपको कौन सा प्रमाणपत्र-आधारित WiFi प्रोटोकॉल चुनना चाहिए?
यह गाइड IEEE 802.1X के तहत एंटरप्राइज WiFi ऑथेंटिकेशन के लिए EAP-TLS और EAP-TTLS की एक स्पष्ट तुलना प्रदान करती है। यह म्यूचुअल सर्टिफिकेट ऑथेंटिकेशन और सर्वर-ओनली सर्टिफिकेट टनेलिंग के बीच के आर्किटेक्चरल अंतर को समझाती है, और IT प्रबंधकों, नेटवर्क आर्किटेक्ट्स और CISOs को डिवाइस मैनेजमेंट क्षमताओं और अनुपालन आवश्यकताओं के आधार पर एक स्पष्ट निर्णय ढांचा देती है। Purple स्टाफ 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.
कार्यकारी सारांश
अपने 802.1X परिनियोजन के लिए सही EAP विधि चुनना यह निर्धारित करता है कि आपका एंटरप्राइज़ WiFi वास्तव में सुरक्षित है या केवल कागज़ पर अनुपालन कर रहा है। RFC 5216 में परिभाषित EAP-TLS (एक्स्टेंसिबल ऑथेंटिकेशन प्रोटोकॉल - ट्रांसपोर्ट लेयर सिक्योरिटी), के लिए पारस्परिक प्रमाणपत्र प्रमाणीकरण की आवश्यकता होती है: नेटवर्क एक्सेस दिए जाने से पहले क्लाइंट डिवाइस और RADIUS सर्वर दोनों मान्य X.509 प्रमाणपत्र प्रस्तुत करते हैं। किसी भी समय पासवर्ड का आदान-प्रदान नहीं किया जाता है। RFC 5281 में परिभाषित EAP-TTLS (टनेल्ड ट्रांसपोर्ट लेयर सिक्योरिटी), को एक एन्क्रिप्टेड TLS टनल स्थापित करने के लिए केवल एक सर्वर-साइड प्रमाणपत्र की आवश्यकता होती है, जिसके अंदर क्लाइंट मौजूदा निर्देशिका क्रेडेंशियल्स का उपयोग करके प्रमाणित होता है।
रिटेल चेन, आतिथ्य स्थलों और सार्वजनिक क्षेत्र के संगठनों में बुनियादी ढांचे का प्रबंधन करने वाले CTO और नेटवर्क आर्किटेक्ट के लिए, यह निर्णय एक सवाल पर निर्भर करता है: क्या आप उपकरणों का प्रबंधन करते हैं? यदि आप MDM के माध्यम से डिवाइस बेड़े को नियंत्रित करते हैं, तो EAP-TLS निश्चित विकल्प है। यदि आप एक विविध BYOD वातावरण का समर्थन करते हैं या एक मजबूत पब्लिक की इन्फ्रास्ट्रक्चर (PKI) की कमी है, तो EAP-TTLS एक व्यावहारिक, अत्यधिक सुरक्षित विकल्प प्रदान करता है। Purple 80,000+ लाइव स्थानों पर स्टाफ WiFi के लिए दोनों प्रमाणीकरण पथों का समर्थन करता है।
तकनीकी गहन विश्लेषण
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 ऑफलाइन डिक्शनरी हमलों, क्रेडेंशियल स्टफिंग और फ़िशिंग से सुरक्षित है। यह एकमात्र EAP तरीका है जो WPA3-Enterprise 192-bit (Suite B) आवश्यकताओं को पूरा करता है, और इसे कार्डधारक डेटा वातावरण के लिए 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 (पासवर्ड ऑथेंटिकेशन प्रोटोकॉल), CHAP और MS-CHAPv2 शामिल हैं। क्लाइंट अपना यूजरनेम और पासवर्ड भेजता है, लेकिन चूंकि यह एक्सचेंज TLS टनल के भीतर होता है, इसलिए क्रेडेंशियल ट्रांज़िट में एन्क्रिप्ट किए जाते हैं और कभी भी हवा में उजागर नहीं होते हैं।
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 के खिलाफ क्लाइंट प्रमाणपत्रों को मान्य करने और CRLs की जांच करने या रीयल-टाइम निरसन जांच के लिए 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 टनल दुष्ट एक्सेस पॉइंट्स के खिलाफ कोई सुरक्षा प्रदान नहीं करती है।
अपने विशिष्ट सेटअप को लेकर कोई सवाल हैं?
हमारी टीम 80,000 से अधिक वेन्यू में वेन्यू ऑपरेटरों, IT मैनेजरों और नेटवर्क इंजीनियरों के साथ काम करती है। 20 मिनट का कॉल बुक करें और हम आपको दिखाएंगे कि आपके जैसे अन्य लोगों ने इसे कैसे हल किया।
सर्वश्रेष्ठ अभ्यास (Best Practices)
प्रत्येक क्लाइंट पर सर्वर सर्टिफिकेट वैलिडेशन लागू करें
EAP-TLS और EAP-TTLS दोनों के लिए सबसे महत्वपूर्ण कॉन्फ़िगरेशन चरण क्लाइंट डिवाइस पर सर्वर सर्टिफिकेट वैलिडेशन लागू करना है। यदि कोई डिवाइस किसी विशिष्ट विश्वसनीय CA के विरुद्ध RADIUS सर्वर के सर्टिफिकेट को सत्यापित नहीं करता है, तो वह किसी भी सर्टिफिकेट को प्रस्तुत करने वाले किसी भी सर्वर से जुड़ जाएगा - जिसमें एक धोखेबाज एक्सेस पॉइंट भी शामिल है। अपने MDM-तैनात WiFi प्रोफाइल में हमेशा विश्वसनीय CA और अपेक्षित सर्वर नाम निर्दिष्ट करें। यह एकल कॉन्फ़िगरेशन जांच सबसे प्रभावी सुरक्षा सुधार है जिसे आप आज लागू कर सकते हैं।
सर्टिफिकेट लाइफसाइकल मैनेजमेंट को स्वचालित करें
सर्टिफिकेट की समय-सीमा समाप्त हो जाती है। यदि आपके पास कोई स्वचालित नवीनीकरण प्रक्रिया नहीं है, तो सर्टिफिकेट समाप्त होने पर आपको एक साथ बड़े पैमाने पर ऑथेंटिकेशन विफलताओं का सामना करना पड़ेगा। नवीनीकरण को स्वचालित करने के लिए SCEP या EST का उपयोग करें, और समाप्ति तिथियों से काफी पहले मॉनिटरिंग अलर्ट कॉन्फ़िगर करें। यदि कोई डिवाइस खो जाता है या कोई कर्मचारी छोड़ देता है, तो सर्टिफिकेट को तुरंत निरस्त करें। रीयल-टाइम वैलिडेशन के लिए CRLs की जांच करने या OCSP का उपयोग करने के लिए अपने RADIUS सर्वर को कॉन्फ़िगर करें।
ऑथेंटिकेशन विधि द्वारा अपने नेटवर्क को विभाजित करें
बड़े या वितरित वातावरण में, अलग-अलग SSID पर दोनों प्रोटोकॉल चलाने पर विचार करें। कॉर्पोरेट प्रबंधित डिवाइस एक समर्पित स्टाफ WiFi SSID पर EAP-TLS के माध्यम से ऑथेंटिकेट होते हैं। ठेकेदार और BYOD डिवाइस उपयुक्त VLAN सेगमेंटेशन के साथ एक अलग SSID पर EAP-TTLS के माध्यम से ऑथेंटिकेट होते हैं। यह पैटर्न प्रीमियर इन और व्हिटब्रेड जैसे आतिथ्य समूहों में आम है, जहां स्टाफ उपकरणों को प्रबंधित किया जाता है और सर्टिफिकेट जारी किए जाते हैं, जबकि गेस्ट इन्फ्रास्ट्रक्चर एक अलग ऑथेंटिकेशन पथ का उपयोग करता है। SSID आर्किटेक्चर पर अधिक विवरण के लिए, हमारी गाइड Three SSIDs to rule them all: the WiFi design for guest, staff and IoT देखें।
सभी इन्फ्रास्ट्रक्चर में समय को सिंक्रोनाइज़ करें
सर्टिफिकेट वैलिडेशन सटीक सिस्टम समय पर निर्भर करता है। क्लाइंट डिवाइस या RADIUS सर्वर पर घड़ी का समय बहकना (Clock drift) 'अभी तक मान्य नहीं' या 'समय-सीमा समाप्त' सर्टिफिकेट त्रुटियां उत्पन्न करता है जिनका निदान करना कठिन है। सुनिश्चित करें कि सभी इन्फ्रास्ट्रक्चर घटक विश्वसनीय NTP सर्वर के साथ सिंक्रोनाइज़्ड हैं।
समस्या निवारण और जोखिम न्यूनीकरण
अज्ञात CA त्रुटियां
यदि RADIUS लॉग 'अज्ञात CA' दिखाते हैं, तो क्लाइंट डिवाइस उस CA पर भरोसा नहीं करता है जिसने RADIUS सर्वर का सर्टिफिकेट जारी किया है। सत्यापित करें कि आपके MDM प्रोफाइल में रूट CA सर्टिफिकेट शामिल है और सप्लीकेंट को उस पर भरोसा करने के लिए कॉन्फ़िगर किया गया है। CA रोटेशन या सर्टिफिकेट नवीनीकरण के बाद, सभी डिवाइसों पर अपडेट किए गए CA बंडल को फिर से पुश करें।
EAP विधि बेमेल
यदि डिवाइस एक्सेस पॉइंट से जुड़ते हैं लेकिन ऑथेंटिकेशन विफल हो जाता है, तो जांचें कि क्लाइंट पर कॉन्फ़िगर की गई EAP विधि RADIUS सर्वर द्वारा स्वीकृत विधि से मेल खाती है या नहीं। EAP-TLS के लिए सेट किया गया डिवाइस प्रोफाइल केवल PEAP के लिए कॉन्फ़िगर किए गए RADIUS सर्वर पर विफल हो जाएगा।
समाप्त हो चुके सर्टिफिकेट के कारण बड़े पैमाने पर विफलताएं
यदि बड़ी संख्या में डिवाइस एक साथ प्रमाणित होने में विफल होते हैं, तो सबसे पहले सर्टिफिकेट की समाप्ति तिथियों की जांच करें। EAP-TLS डिप्लॉयमेंट में बड़े पैमाने पर 802.1X विफलताओं का यह सबसे आम कारण है। एक ऐसी मॉनिटरिंग सिस्टम लागू करें जो समाप्ति से 60 दिन, 30 दिन और सात दिन पहले अलर्ट भेजे।
RADIUS क्लाइंट मिसकॉन्फ़िगरेशन
प्रत्येक एक्सेस पॉइंट या वायरलेस कंट्रोलर को सही IP एड्रेस और शेयर्ड सीक्रेट के साथ एक RADIUS क्लाइंट के रूप में परिभाषित किया जाना चाहिए। बेमेल होने के कारण ऑथेंटिकेशन टाइमआउट होता है जिसे अक्सर गलत तरीके से EAP विधि के कारण मान लिया जाता है। पहले दिन से ही विस्तृत RADIUS लॉगिंग सक्षम करें। आगे की WiFi ट्रबलशूटिंग गाइडेंस के लिए, हमारी गाइड Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures देखें।
अनुपालन और नियामक संरेखण
CISOs और नेटवर्क आर्किटेक्ट्स के लिए, EAP-TLS और EAP-TTLS के बीच निर्णय लेते समय नियामक परिदृश्य को समझना आवश्यक है। EAP विधि का विकल्प सीधे कई प्रमुख फ्रेमवर्क में आपके अनुपालन की स्थिति को प्रभावित करता है।
PCI-DSS 4.0 (पेमेंट कार्ड इंडस्ट्री डेटा सिक्योरिटी स्टैंडर्ड) को कार्डधारक डेटा वातावरण में वायरलेस नेटवर्क के लिए मजबूत क्रिप्टोग्राफिक ऑथेंटिकेशन की आवश्यकता होती है। आवश्यकता 8.3 CDE तक सभी एक्सेस के लिए मल्टी-फैक्टर ऑथेंटिकेशन को अनिवार्य बनाती है, और इन-स्कोप वायरलेस नेटवर्क को मजबूत ऑथेंटिकेशन मैकेनिज्म का उपयोग करना चाहिए। EAP-TLS, सर्टिफिकेट-आधारित म्यूचुअल ऑथेंटिकेशन के साथ, निश्चित रूप से इस आवश्यकता को पूरा करता है। MS-CHAPv2 के साथ EAP-TTLS स्वीकार्य है यदि आंतरिक ऑथेंटिकेशन ठीक से सुरक्षित है और सर्वर सर्टिफिकेट वैलिडेशन लागू है, लेकिन EAP-TLS अधिक मजबूत और ऑडिटर-अनुकूल विकल्प है। HIPAA (हेल्थ इंश्योरेंस पोर्टेबिलिटी एंड अकाउंटेबिलिटी एक्ट) के तहत कवर की गई संस्थाओं को तकनीकी सुरक्षा उपाय लागू करने की आवश्यकता होती है जो इलेक्ट्रॉनिक संचार नेटवर्क पर प्रसारित होने वाली इलेक्ट्रॉनिक संरक्षित स्वास्थ्य जानकारी (ePHI) की रक्षा करते हैं। HIPAA सुरक्षा नियम विशिष्ट प्रोटोकॉल को अनिवार्य नहीं करता है, लेकिन ePHI ले जाने वाले वायरलेस नेटवर्क के लिए एन्क्रिप्शन और एक्सेस कंट्रोल की अपेक्षा प्रबंधित चिकित्सा उपकरण बेड़े के लिए EAP-TLS और स्टाफ उपकरणों के लिए लागू सर्वर सर्टिफिकेट वैलिडेशन के साथ EAP-TTLS के पक्ष में भारी रूप से झुकती है।
WPA3-Enterprise 192-bit (जिसे सुइट B या CNSA मोड भी कहा जाता है) Wi-Fi Alliance के WPA3 सर्टिफिकेशन का उच्चतम सुरक्षा स्तर है। यह EAP-TLS को एकमात्र अनुमत ऑथेंटिकेशन विधि के रूप में अनिवार्य करता है, विशिष्ट सिफर सुइट्स (P-384 के साथ ECDHE, AES-256-GCM) के साथ TLS 1.2 या उच्चतर की आवश्यकता होती है, और ECDSA या RSA-3072 सर्टिफिकेट की आवश्यकता होती है। सरकारी, रक्षा, या महत्वपूर्ण बुनियादी ढांचा अनुप्रयोगों के लिए WPA3-Enterprise 192-bit को तैनात करने वाले संगठनों को EAP-TLS का उपयोग करना चाहिए।ISO/IEC 27001 विशिष्ट प्रोटोकॉल को अनिवार्य नहीं करता है, लेकिन इसके लिए संगठनों को नेटवर्क संसाधनों के लिए उपयुक्त एक्सेस कंट्रोल लागू करने की आवश्यकता होती है। EAP-TLS या EAP-TTLS (लागू सर्वर प्रमाणपत्र सत्यापन के साथ) दोनों में से किसी एक के साथ 802.1X परिनियोजन (deployment) Annex A.9.1 और A.13.1 की नेटवर्क एक्सेस कंट्रोल आवश्यकताओं को पूरा करता है।
-
ROI और व्यावसायिक प्रभाव
EAP-TLS पर माइग्रेट करने के लिए PKI और MDM एकीकरण में शुरुआती निवेश की आवश्यकता होती है, लेकिन यह पासवर्ड रीसेट के परिचालन ओवरहेड और क्रेडेंशियल से समझौता होने के कारण नेटवर्क उल्लंघनों के वित्तीय जोखिम को समाप्त करता है। 400 स्टोरों वाली एक रिटेल चेन के लिए, साझा PSK नेटवर्क पर एक भी समझौता किया गया पासवर्ड पूरे एस्टेट को खतरे में डाल सकता है। EAP-TLS उस हमले के रास्ते को पूरी तरह से समाप्त कर देता है।
मल्टी-टेनेंट वातावरण और ट्रैवल हब के लिए, सुरक्षित प्रमाणीकरण यह सुनिश्चित करता है कि केवल अधिकृत उपयोगकर्ता ही नेटवर्क बैंडविड्थ तक पहुंचें, जिससे बुनियादी ढांचे के उपयोग को अनुकूलित किया जा सके। RADIUS प्रमाणपत्र विशेषताओं के माध्यम से डायनेमिक VLAN असाइनमेंट क्रिप्टोग्राफिक रूप से लागू नेटवर्क सेगमेंटेशन को सक्षम बनाता है, जिससे यह सुनिश्चित होता है कि उपकरणों को SSID चयन या MAC एड्रेस फ़िल्टरिंग पर भरोसा करने के बजाय प्रमाणपत्र गुणों के आधार पर सही नेटवर्क सेगमेंट पर रखा गया है।
Purple का WiFi Analytics प्लेटफ़ॉर्म दोनों प्रमाणीकरण पथों के साथ एकीकृत होता है, जो आपके पूरे एस्टेट में डिवाइस की संख्या, सत्र की अवधि और नेटवर्क उपयोग की दृश्यता प्रदान करता है। क्षेत्र-विशिष्ट परिनियोजन मार्गदर्शन के लिए, Hospitality, Retail, Healthcare, और Transport के लिए हमारे संसाधनों को देखें।
मुख्य परिभाषाएं
EAP-TLS (एक्स्टेंसिबल ऑथेंटिकेशन प्रोटोकॉल - ट्रांसपोर्ट लेयर सिक्योरिटी)
RFC 5216 में परिभाषित एक 802.1X प्रमाणीकरण विधि जिसमें क्लाइंट डिवाइस और RADIUS सर्वर दोनों को वैध X.509 प्रमाणपत्र प्रस्तुत करने की आवश्यकता होती है। कोई पासवर्ड साझा नहीं किया जाता है। प्रमाणीकरण पारस्परिक और क्रिप्टोग्राफिक रूप से बाध्य होता है।
एंटरप्राइज वायरलेस सुरक्षा के लिए स्वर्ण मानक। WPA3-Enterprise 192-बिट के लिए आवश्यक और PCI-DSS 4.0 कार्डधारक डेटा वातावरण के लिए दृढ़ता से अनुशंसित।
EAP-TTLS (एक्स्टेंसिबल ऑथेंटिकेशन प्रोटोकॉल - टनल्ड ट्रांसपोर्ट लेयर सिक्योरिटी)
RFC 5281 में परिभाषित एक 802.1X प्रमाणीकरण विधि जिसमें एक एन्क्रिप्टेड TLS टनल स्थापित करने के लिए केवल सर्वर-साइड प्रमाणपत्र की आवश्यकता होती है। क्लाइंट टनल के अंदर एक द्वितीयक आंतरिक प्रमाणीकरण विधि, आमतौर पर उपयोगकर्ता नाम और पासवर्ड का उपयोग करके प्रमाणित करता है।
BYOD वातावरण और मिश्रित-OS नेटवर्क के लिए पसंदीदा विकल्प जहां क्लाइंट प्रमाणपत्रों को तैनात करना परिचालन के दृष्टिकोण से व्यावहारिक नहीं है।
802.1X
पोर्ट-आधारित नेटवर्क एक्सेस कंट्रोल के लिए एक IEEE मानक जो LAN या WLAN से जुड़ने वाले डिवाइसों के लिए एक प्रमाणीकरण तंत्र प्रदान करता है। यह सप्लिकेंट, ऑथेंटिकेटर, और ऑथेंटिकेशन सर्वर की भूमिकाओं को परिभाषित करता है।
वह बुनियादी ढांचा जो एंटरप्राइज नेटवर्क को किसी एक साझा पासवर्ड पर निर्भर रहने के बजाय व्यक्तिगत डिवाइसों को प्रमाणित करने में सक्षम बनाता है। EAP-TLS और EAP-TTLS दोनों इसी ढांचे के भीतर काम करते हैं।
RADIUS (रिमोट ऑथेंटिकेशन डायल-इन यूजर सर्विस)
एक नेटवर्किंग प्रोटोकॉल जो नेटवर्क सेवा से जुड़ने वाले उपयोगकर्ताओं के लिए केंद्रीकृत प्रमाणीकरण, प्राधिकरण, और लेखांकन प्रबंधन प्रदान करता है। 802.1X परिनियोजन में, RADIUS सर्वर ही वह प्रमाणीकरण सर्वर होता है जो प्रमाणपत्रों या क्रेडेंशियल्स को सत्यापित करता है।
सर्वर घटक जो प्रमाणपत्रों या पासवर्डों को सत्यापित करता है और एक्सेस पॉइंट को निर्देश देता है कि नेटवर्क एक्सेस देना है या अस्वीकार करना है। समर्थित प्लेटफॉर्मों में FreeRADIUS, Microsoft NPS, और Cisco ISE शामिल हैं।
PKI (पब्लिक की इन्फ्रास्ट्रक्चर)
डिजिटल प्रमाणपत्र बनाने, प्रबंधित करने, वितरित करने, उपयोग करने, संग्रहीत करने, और निरस्त करने के लिए आवश्यक भूमिकाओं, नीतियों, हार्डवेयर, सॉफ्टवेयर, और प्रक्रियाओं का एक समूह। एक सामान्य एंटरप्राइज PKI में एक ऑफलाइन रूट CA और एक ऑनलाइन इश्यूइंग CA शामिल होता है।
EAP-TLS प्रमाणीकरण में उपयोग किए जाने वाले क्लाइंट और सर्वर प्रमाणपत्र जारी करने के लिए आवश्यक बैकएंड इन्फ्रास्ट्रक्चर। PKI के बिना, EAP-TLS को तैनात नहीं किया जा सकता है।
MDM (मोबाइल डिवाइस मैनेजमेंट)
आईटी विभागों द्वारा कर्मचारियों के मोबाइल डिवाइसों और लैपटॉपों की निगरानी, प्रबंधन, और उन्हें सुरक्षित करने के लिए उपयोग किया जाने वाला सॉफ्टवेयर। Microsoft Intune और Jamf जैसे MDM प्लेटफॉर्म नामांकित डिवाइसों पर प्रमाणपत्रों और WiFi प्रोफाइल के परिनियोजन को स्वचालित कर सकते हैं।
पैमाने पर EAP-TLS के लिए क्लाइंट प्रमाणपत्रों के परिनियोजन को स्वचालित करने के लिए आवश्यक। MDM एकीकरण के बिना, हजारों डिवाइसों पर मैन्युअल रूप से प्रमाणपत्र इंस्टॉल करना परिचालन के दृष्टिकोण से असंभव है।
SCEP (सिंपल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल)
एक प्रोटोकॉल जिसका उपयोग नेटवर्क डिवाइसों को डिजिटल प्रमाणपत्र जारी करने को स्वचालित करने के लिए किया जाता है। MDM प्लेटफॉर्म उपयोगकर्ता के हस्तक्षेप के बिना नामांकित कॉर्पोरेट डिवाइसों पर चुपचाप प्रमाणपत्रों का अनुरोध और इंस्टॉल करने के लिए SCEP का उपयोग करते हैं।
EAP-TLS परिनियोजन में जीरो-टच सर्टिफिकेट प्रोविज़निंग के लिए मानक तंत्र। Microsoft Intune, Jamf, और अधिकांश एंटरप्राइज MDM प्लेटफॉर्मों द्वारा समर्थित।
CRL (सर्टिफिकेट रिवोकैशन लिस्ट)
डिजिटल प्रमाणपत्रों की एक सूची जिन्हें जारी करने वाले प्रमाणपत्र प्राधिकरण द्वारा उनकी निर्धारित समाप्ति तिथि से पहले रद्द कर दिया गया है। 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 (पासवर्ड ऑथेंटिकेशन प्रोटोकॉल), CHAP और MS-CHAPv2 शामिल हैं।
आंतरिक प्रमाणीकरण विधि का चयन EAP-TTLS डिप्लॉयमेंट के सुरक्षा गुणों को प्रभावित करता है। PAP टनल के अंदर प्लेनटेक्स्ट में पासवर्ड भेजता है; MS-CHAPv2 एक चैलेंज-रिस्पॉन्स तंत्र का उपयोग करता है। टनल सभी आंतरिक प्रमाणीकरण ट्रैफ़िक को एन्क्रिप्ट करती है।
हल किए गए उदाहरण
400 स्टोर वाली एक राष्ट्रीय रिटेल चेन को अपने पॉइंट-ऑफ-सेल (POS) टर्मिनलों और स्टाफ हैंडहेल्ड स्कैनर्स को सुरक्षित करने की आवश्यकता है। यह वातावरण PCI-DSS 4.0 के दायरे में है। सभी डिवाइस Microsoft Intune में नामांकित हैं। उन्हें कौन सा प्रोटोकॉल तैनात करना चाहिए, और मुख्य कॉन्फ़िगरेशन चरण क्या हैं?
EAP-TLS तैनात करें। चरण 1: एक एयर-गैप्ड ऑफलाइन रूट CA और एक ऑनलाइन इश्यूइंग CA के साथ दो-स्तरीय PKI स्थापित करें। चरण 2: सभी POS और स्कैनर डिवाइसों को लक्षित करते हुए एक SCEP प्रमाणपत्र प्रोफ़ाइल के साथ Microsoft Intune को कॉन्फ़िगर करें। चरण 3: एक RADIUS सर्वर (Microsoft NPS या क्लाउड RADIUS) तैनात करें और इसे आंतरिक CA के खिलाफ क्लाइंट प्रमाणपत्रों को मान्य करने के लिए कॉन्फ़िगर करें। चरण 4: RADIUS सर्वर पर CRL चेकिंग या OCSP सक्षम करें। चरण 5: Intune के माध्यम से SSID, ऑथेंटिकेशन विधि के रूप में EAP-TLS, विश्वसनीय रूट CA और अपेक्षित RADIUS सर्वर नाम निर्दिष्ट करते हुए एक WiFi प्रोफ़ाइल पुश करें। चरण 6: सभी 400 साइटों पर रोल आउट करने से पहले 10 डिवाइसों के पायलट समूह के साथ परीक्षण करें। चरण 7: समाप्ति से 60, 30 और सात दिन पहले अलर्ट के साथ प्रमाणपत्र समाप्ति निगरानी प्रक्रिया स्थापित करें।
एक बड़े विश्वविद्यालय परिसर को व्यक्तिगत लैपटॉप, स्मार्टफोन और टैबलेट (BYOD) के मिश्रण का उपयोग करने वाले 20,000 छात्रों के लिए सुरक्षित WiFi प्रदान करने की आवश्यकता है। IT टीम व्यक्तिगत उपकरणों पर प्रमाणपत्र स्थापित नहीं कर सकती है। विश्वविद्यालय पहचान प्रबंधन के लिए Microsoft Entra ID का उपयोग करता है। उन्हें कौन सा प्रोटोकॉल तैनात करना चाहिए?
आंतरिक ऑथेंटिकेशन विधि के रूप में MS-CHAPv2 के साथ EAP-TTLS तैनात करें, जो RADIUS के माध्यम से Microsoft Entra ID के साथ एकीकृत हो। चरण 1: सभी प्रमुख ऑपरेटिंग सिस्टमों द्वारा विश्वसनीय सार्वजनिक CA से सर्वर प्रमाणपत्र प्राप्त करें, या एक आंतरिक CA तैनात करें और प्रबंधित उपकरणों के लिए विश्वविद्यालय के डिवाइस प्रबंधन टूल के माध्यम से रूट प्रमाणपत्र वितरित करें। चरण 2: LDAP या RADIUS प्रॉक्सी का उपयोग करके Microsoft Entra ID के खिलाफ ऑथेंटिकेट करने के लिए RADIUS सर्वर को कॉन्फ़िगर करें। चरण 3: छात्रों के लिए SSID, EAP-TTLS, MS-CHAPv2 और विश्वसनीय CA को निर्दिष्ट करते हुए एक WiFi ऑनबोर्डिंग गाइड बनाएं। चरण 4: Entra ID स्तर पर मजबूत पासवर्ड नीतियां लागू करें और प्रारंभिक नामांकन के लिए मल्टी-फैक्टर ऑथेंटिकेशन सक्षम करने पर विचार करें। चरण 5: सर्वर प्रमाणपत्र सत्यापन को लागू करने और विश्वसनीय CA और RADIUS सर्वर नाम निर्दिष्ट करने के लिए WiFi प्रोफ़ाइल कॉन्फ़िगर करें।
अभ्यास प्रश्न
Q1. आप 50 कार्यालय स्थानों में 5,000 कॉर्पोरेट लैपटॉप के बेड़े के लिए EAP-TLS को डिप्लॉय कर रहे हैं। Microsoft Intune के माध्यम से WiFi प्रोफ़ाइल पुश करने के बाद, डिवाइस कनेक्ट होने में विफल हो रहे हैं। RADIUS सर्वर लॉग प्रत्येक विफल प्रमाणीकरण प्रयास के लिए 'Unknown CA' दिखाते हैं। इसका सबसे संभावित कारण क्या है, और आप इसे कैसे हल करेंगे?
संकेत: क्लाइंट साइड पर प्रमाणपत्र सत्यापन श्रृंखला पर विचार करें, और EAP विधि सेटिंग के अलावा MDM प्रोफ़ाइल में क्या शामिल होना चाहिए, इस पर ध्यान दें।
मॉडल उत्तर देखें
क्लाइंट डिवाइसेस को उस आंतरिक प्रमाणपत्र प्राधिकरण (CA) पर भरोसा करने के लिए कॉन्फ़िगर नहीं किया गया है जिसने RADIUS सर्वर का प्रमाणपत्र जारी किया था। MDM WiFi प्रोफ़ाइल में रूट CA प्रमाणपत्र (और कोई भी मध्यवर्ती CA प्रमाणपत्र) शामिल होना चाहिए और सप्लिकेंट को सर्वर सत्यापन के लिए उन पर भरोसा करने के लिए कॉन्फ़िगर करना चाहिए। इसके बिना, क्लाइंट RADIUS सर्वर के प्रमाणपत्र को अस्वीकार कर देता है और हैंडशेक को समाप्त कर देता है। समाधान: 'Root certificate for server validation' सेटिंग के तहत विश्वसनीय रूट CA प्रमाणपत्र को शामिल करने के लिए Intune WiFi प्रोफ़ाइल को अपडेट करें, और प्रोफ़ाइल को सभी डिवाइस पर फिर से पुश करें।
Q2. आपके संगठन ने एक मिश्रित BYOD वातावरण के लिए EAP-TTLS को डिप्लॉय किया है। एक सुरक्षा समीक्षा के दौरान, आपकी पेनेट्रेशन टेस्टिंग टीम ने प्रदर्शित किया कि वे एक स्व-हस्ताक्षरित (self-signed) प्रमाणपत्र के साथ एक अनधिकृत एक्सेस पॉइंट (rogue access point) स्थापित करके उपयोगकर्ता क्रेडेंशियल्स को कैप्चर कर सकते हैं। EAP-TLS पर माइग्रेट किए बिना आप इस भेद्यता (vulnerability) को कैसे ठीक करेंगे?
संकेत: इस बारे में सोचें कि आंतरिक प्रमाणीकरण से पहले क्या होता है और क्लाइंट साइड पर कौन सा कॉन्फ़िगरेशन किसी अविश्वसनीय सर्वर के साथ TLS टनल स्थापित करने से रोकता है।
मॉडल उत्तर देखें
यह भेद्यता इसलिए मौजूद है क्योंकि क्लाइंट डिवाइसेस को RADIUS सर्वर के प्रमाणपत्र को सत्यापित करने के लिए कॉन्फ़िगर नहीं किया गया है। समाधान: सर्वर प्रमाणपत्र सत्यापन को लागू करने के लिए सभी WiFi प्रोफ़ाइलों को (प्रबंधित उपकरणों के लिए MDM के माध्यम से, और BYOD के लिए एक नए ऑनबोर्डिंग गाइड के माध्यम से) अपडेट करें। प्रोफ़ाइल में विश्वसनीय CA और अपेक्षित RADIUS सर्वर नाम निर्दिष्ट करें। इस तरह से कॉन्फ़िगर किए गए क्लाइंट किसी भी ऐसे सर्वर के साथ TLS टनल स्थापित करने से इनकार कर देंगे जो निर्दिष्ट विश्वसनीय CA द्वारा हस्ताक्षरित प्रमाणपत्र प्रस्तुत नहीं कर सकता, जिससे अनधिकृत एक्सेस पॉइंट का खतरा समाप्त हो जाता है।
Q3. एक अस्पताल के IT निदेशक अपने मेडिकल IoT उपकरणों (इन्फ्यूजन पंप, रोगी मॉनिटर, पर्यावरण सेंसर) के लिए 802.1X डिप्लॉय करना चाहते हैं। वे EAP-TTLS पर विचार कर रहे हैं क्योंकि उनका मानना है कि प्रमाणपत्र प्रबंधन बहुत जटिल है। यह तर्क त्रुटिपूर्ण क्यों है, और सही दृष्टिकोण क्या है?
संकेत: विचार करें कि बिना डिस्प्ले वाले (headless) IoT डिवाइस प्रमाणीकरण संकेतों को कैसे संभालते हैं और क्या होता है जब कोई डिवाइस क्रेडेंशियल्स इनपुट नहीं कर पाता है।
मॉडल उत्तर देखें
यह तर्क दो कारणों से त्रुटिपूर्ण है। पहला, अधिकांश हेडलेस मेडिकल IoT उपकरणों में क्रेडेंशियल इनपुट करने के लिए कोई यूजर इंटरफेस नहीं होता है, जिससे यूजरनेम/पासवर्ड इनर ऑथेंटिकेशन के साथ EAP-TTLS को लागू करना व्यावहारिक रूप से असंभव हो जाता है। दूसरा, EAP-TLS वास्तव में IoT के लिए व्यवहार में अधिक सरल है: परिनियोजन से पहले डिवाइस स्टेजिंग के दौरान सर्टिफिकेट प्रदान किए जा सकते हैं, और डिवाइस बिना किसी यूजर इंटरैक्शन के स्वचालित रूप से ऑथेंटिकेट हो जाता है। सही दृष्टिकोण EAP-TLS है जिसमें स्टेजिंग के दौरान उपयोग किए जाने वाले डिवाइस मैनेजमेंट सिस्टम के माध्यम से सर्टिफिकेट प्रदान किए जाते हैं। यह हेल्थकेयर वातावरण में मजबूत वायरलेस ऑथेंटिकेशन के लिए HIPAA आवश्यकताओं को भी पूरा करता है।
Q4. आप 200 प्रॉपर्टीज वाले एक होटल ग्रुप के नेटवर्क आर्किटेक्ट हैं। आपको 3,000 प्रबंधित स्टाफ उपकरणों (Intune में नामांकित) के लिए Staff WiFi को सुरक्षित करने की आवश्यकता है और उन कॉन्ट्रैक्टर्स और थर्ड-पार्टी वेंडर्स को भी सुरक्षित WiFi प्रदान करना है जो अपने स्वयं के लैपटॉप लाते हैं। ऑथेंटिकेशन आर्किटेक्चर को डिजाइन करें।
संकेत: विचार करें कि क्या एक ही EAP विधि वाला सिंगल SSID दोनों आबादी की सेवा कर सकता है, और दो यूजर प्रकारों से नेटवर्क सेगमेंटेशन के क्या निहितार्थ उत्पन्न होते हैं।
मॉडल उत्तर देखें
अलग-अलग ऑथेंटिकेशन विधियों और 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 और Entra ID के लिए एक डिप्लॉयमेंट चेकलिस्ट
यह जांचने के लिए इस चेकलिस्ट का उपयोग करें कि iPhones, iPads और Macs Intune या Jamf Pro पर 802.1X में विफल क्यों होते हैं। प्रत्येक विफलता चार कारणों में से एक से जुड़ी होती है: सर्वर ट्रस्ट, आइडेंटिटी सर्टिफिकेट, macOS मोड या Entra ID ग्रुप स्कोपिंग। आप eapolclient और RADIUS लॉग से कारण की पुष्टि करेंगे, समाधान लागू करेंगे और भविष्य के सर्टिफिकेट रोटेशन को व्यवस्थित करेंगे।
Intune WiFi प्रोफाइल सर्वर ट्रस्ट: Microsoft Entra ID के लिए सर्टिफिकेट सर्वर नाम और रूट CA चेकलिस्ट
आप एक Intune WiFi प्रोफाइल के सर्वर वैलिडेशन वाले हिस्से को कॉन्फ़िगर करने में सक्षम होंगे ताकि Windows, Apple और Android पर EAP-TLS और PEAP कनेक्ट हो सकें। आप सर्टिफिकेट सर्वर नामों को RADIUS सर्टिफिकेट से मिलाएंगे, सही रूट CA को डिप्लॉय करेंगे, Microsoft Entra ID ग्रुप असाइनमेंट को संरेखित करेंगे, और सर्टिफिकेट रिन्यूअल को उनके द्वारा कनेक्शन को चुपचाप तोड़ने से पहले प्रबंधित करेंगे।
Android 802.1X और EAP-TLS ट्रबलशूटिंग: Intune और Microsoft Entra ID के लिए एक डिप्लॉयमेंट चेकलिस्ट
आप यह सटीक रूप से पता लगाने में सक्षम होंगे कि आपके स्टाफ SSID पर प्रबंधित Android फोन EAP-TLS में क्यों विफल हो जाते हैं और Intune में इसे कैसे ठीक किया जाए। प्रत्येक लक्षण को चार सामान्य कारणों से मिलाएं - अनुपलब्ध CA या डोमेन, गलत प्रोफ़ाइल में क्लाइंट प्रमाणपत्र, बेमेल RADIUS सर्वर नाम मान, या बिना डिलीवर किया गया ट्रस्टेड रूट। फिर एक रोलआउट चेकलिस्ट लागू करें जो बार-बार होने वाले आउटेज को रोकती है।
अपने विशिष्ट सेटअप को लेकर कोई सवाल हैं?
हमारी टीम 80,000 से अधिक वेन्यू में वेन्यू ऑपरेटरों, IT मैनेजरों और नेटवर्क इंजीनियरों के साथ काम करती है। 20 मिनट का कॉल बुक करें और हम आपको दिखाएंगे कि आपके जैसे अन्य लोगों ने इसे कैसे हल किया।