802.1X Supplicant क्या है? क्लाइंट प्रकार और डिवाइस कॉन्फ़िगरेशन

ब्रिटिश अंग्रेजी में एक आश्वस्त, आधिकारिक और संवादात्मक टोन में बोलें - जैसे कि एक वरिष्ठ नेटवर्क सुरक्षा सलाहकार किसी क्लाइंट को जानकारी दे रहा हो। मापी गई गति, स्पष्ट उच्चारण, पेशेवर लेकिन कड़ा नहीं। जोर देने के लिए बीच-बीच में स्वाभाविक विराम: Purple तकनीकी ब्रीफिंग श्रृंखला में आपका स्वागत है। आज हम उस विषय को कवर कर रहे हैं जो सीधे तौर पर एंटरप्राइज WiFi सुरक्षा के केंद्र में स्थित है - 802.1X सप्लीकेंट (supplicant)। यदि आपने कभी सोचा है कि कुछ डिवाइस बिना पासवर्ड पूछे आपके कॉर्पोरेट नेटवर्क से क्यों कनेक्ट हो जाते हैं, जबकि अन्य डिवाइस सर्टिफिकेट त्रुटियां और हेल्पडेस्क टिकट दिखाते हैं, तो यह एपिसोड आपके लिए है। [मध्यम विराम] आइए बुनियादी बातों से शुरू करते हैं। 802.1X सप्लीकेंट एक क्लाइंट डिवाइस - जैसे लैपटॉप, स्मार्टफोन या टैबलेट - पर एक सॉफ्टवेयर घटक होता है, जो तब प्रमाणीकरण हैंडशेक (authentication handshake) को संभालता है जब वह डिवाइस IEEE 802.1X द्वारा सुरक्षित नेटवर्क से जुड़ने का प्रयास करता है। इसे डिवाइस के आईडी कार्ड प्रस्तुतकर्ता के रूप में सोचें। नेटवर्क सिर्फ किसी को भी प्रवेश नहीं देता। यह क्रेडेंशियल मांगता है। सप्लीकेंट वह है जो आगे कदम बढ़ाता है और कहता है: यह मेरी पहचान है, यह मेरा सर्टिफिकेट है, मुझे अंदर आने दें। यह मानक - IEEE 802.1X - पोर्ट-आधारित नेटवर्क एक्सेस कंट्रोल को परिभाषित करता है। प्रमाणीकरण सफल होने से पहले, एक्सेस पॉइंट या स्विच केवल बहुत ही सीमित प्रकार के ट्रैफ़िक को जाने देता है: EAPOL फ्रेम, जिसका अर्थ है लैन पर एक्स्टेंसिबल ऑथेंटिकेशन प्रोटोकॉल (Extensible Authentication Protocol over LAN)। बाकी सब कुछ ब्लॉक कर दिया जाता है। एक बार जब सप्लीकेंट ऑथेंटिकेटर के माध्यम से RADIUS सर्वर को अपनी पहचान साबित कर देता है, तो पोर्ट खुल जाता है और सामान्य ट्रैफ़िक प्रवाहित होने लगता है। [मध्यम विराम] अब, इस खेल में तीन अभिनेता हैं। पहला, सप्लीकेंट - क्लाइंट डिवाइस। दूसरा, ऑथेंटिकेटर - आपका एक्सेस पॉइंट या स्विच, जैसे Cisco Meraki, HPE Aruba, Ruckus, या Juniper Mist जैसे हार्डवेयर। तीसरा, ऑथेंटिकेशन सर्वर - जो लगभग हमेशा एक RADIUS सर्वर होता है, जो Microsoft Entra ID या Okta जैसी डायरेक्टरी के साथ क्रेडेंशियल को सत्यापित करता है। सप्लीकेंट EAPOL-Start संदेश भेजकर प्रक्रिया शुरू करता है। ऑथेंटिकेटर पहचान के लिए EAP-Request के साथ जवाब देता है। सप्लीकेंट अपनी पहचान के साथ उत्तर देता है। वह पहचान RADIUS सर्वर को फॉरवर्ड कर दी जाती है, जो फिर सहमत EAP विधि के साथ सप्लीकेंट को चुनौती देता है। यदि सब कुछ सही रहता है, तो RADIUS सर्वर एक Access-Accept भेजता है, पोर्ट खुल जाता है, और डिवाइस को सही VLAN पर रख दिया जाता है। [मध्यम विराम] आइए EAP विधियों के बारे में बात करें, क्योंकि यहीं पर अधिकांश परिनियोजन (deployment) निर्णय लिए जाते हैं। EAP-TLS - यानी Transport Layer Security के साथ Extensible Authentication Protocol - गोल्ड स्टैंडर्ड है। इसके लिए क्लाइंट और सर्वर दोनों को सर्टिफिकेट प्रस्तुत करने की आवश्यकता होती है। पारस्परिक प्रमाणीकरण। कोई पासवर्ड नहीं। क्लाइंट सर्टिफिकेट डिवाइस की पहचान साबित करता है; सर्वर सर्टिफिकेट साबित करता है कि नेटवर्क वैध है, जो evil twin हमलों से बचाता है जहां एक दुष्ट एक्सेस पॉइंट क्रेडेंशियल्स चुराने की कोशिश करता है। EAP-TLS बारह चरणों में पूरा होता है और इसमें शुरू से अंत तक पब्लिक-प्राइवेट की (key) क्रिप्टोग्राफी का उपयोग किया जाता है। यह इसके उच्चतम सुरक्षा मोड में WPA3-Enterprise के लिए आवश्यक तरीका है, और यह डिवाइस पहचान सत्यापन के लिए NIST SP 800-171 आवश्यकताओं के अनुरूप है। PEAP - Protected EAP - उन संगठनों के लिए अधिक सामान्य प्रारंभिक बिंदु है जिनके पास अभी तक पूर्ण PKI नहीं है। PEAP एक पासवर्ड-आधारित आंतरिक विधि, आमतौर पर MSCHAPv2, को एक TLS टनल के भीतर रैप करता है। सर्वर एक सर्टिफिकेट प्रस्तुत करता है; क्लाइंट नहीं करता। इसका मतलब है कि परिनियोजन (deployment) सरल है - आपको क्लाइंट सर्टिफिकेट प्रदान करने की आवश्यकता नहीं है - लेकिन यह कम सुरक्षित है। MSCHAPv2, MD4 हैशिंग का उपयोग करता है, जिसे 1995 से ही समझौता किया हुआ (compromised) माना गया है। यदि कोई उपयोगकर्ता किसी ऐसे दुष्ट एक्सेस पॉइंट से जुड़ता है जो विश्वसनीय दिखने वाला सर्टिफिकेट प्रस्तुत करता है, तो उनके क्रेडेंशियल्स कैप्चर किए जा सकते हैं। इसलिए PEAP चलाते समय क्लाइंट साइड पर सर्वर सर्टिफिकेट सत्यापन गैर-परक्राम्य (non-negotiable) है। [medium pause] आइए अब सप्लीकेंट पर चर्चा करें - विशेष रूप से नेटिव OS सप्लीकेंट्स और थर्ड-पार्टी क्लाइंट सॉफ़्टवेयर के बीच चयन पर। प्रत्येक प्रमुख ऑपरेटिंग सिस्टम इन-बिल्ट 802.1X सप्लीकेंट के साथ आता है। Windows ने XP के बाद से Wireless AutoConfig और Wired AutoConfig सेवाओं के माध्यम से मूल रूप से इसका समर्थन किया है। macOS और iOS अपने नेटवर्क कॉन्फ़िगरेशन प्रोफाइल के माध्यम से 802.1X को संभालते हैं। Android इसका समर्थन WiFi सेटिंग्स पैनल के माध्यम से करता है। ये नेटिव सप्लीकेंट्स सभी वर्तमान प्लेटफॉर्म पर EAP-TLS और PEAP-MSCHAPv2 को कवर करते हैं। नेटिव सप्लीकेंट्स का लाभ स्पष्ट है: परिनियोजित करने के लिए कोई अतिरिक्त सॉफ़्टवेयर नहीं, कोई लाइसेंसिंग लागत नहीं, स्वचालित OS सुरक्षा अपडेट, और ऑपरेटिंग सिस्टम के सर्टिफिकेट स्टोर के साथ कड़ा एकीकरण। प्रबंधित डिवाइस बेड़े के लिए - जैसे Microsoft Intune में नामांकित Windows मशीनें, Jamf के माध्यम से प्रबंधित Macs - आप MDM के माध्यम से चुपचाप 802.1X कॉन्फ़िगरेशन प्रोफाइल पुश कर सकते हैं, और उपयोगकर्ताओं को कभी कोई संकेत (prompt) नहीं दिखाई देता है। जब भी डिवाइस रेंज में आता है, वह हर बार स्वचालित रूप से प्रमाणित होता है। विशिष्ट परिदृश्यों में थर्ड-पार्टी सप्लीकेंट्स (supplicants) की भूमिका होती है। यदि आप Cisco इन्फ्रास्ट्रक्चर चला रहे हैं और EAP-FAST - Cisco की प्रोप्राइटरी EAP विधि - का उपयोग करना चाहते हैं, तो आपको Cisco के क्लाइंट सॉफ़्टवेयर की आवश्यकता होगी, जो ऐतिहासिक रूप से Secure Services Client या AnyConnect Network Access Manager रहा है। यदि आपको मिश्रित-OS एस्टेट में लगातार कॉन्फ़िगरेशन प्रबंधन की आवश्यकता है और आप सप्लीकेंट सेटिंग्स को लॉक करना चाहते हैं ताकि उपयोगकर्ता गलती से उन्हें गलत तरीके से कॉन्फ़िगर न कर सकें, तो थर्ड-पार्टी क्लाइंट आपको वह नियंत्रण देता है। SecureW2 के JoinNow सुइट जैसे टूल ऑनबोर्डिंग एजेंट के रूप में भी कार्य करते हैं - वे इसे बदलने के बजाय मूल सप्लीकेंट को कॉन्फ़िगर करते हैं, उपयोगकर्ताओं को सर्टिफिकेट नामांकन और प्रोफ़ाइल इंस्टॉलेशन के माध्यम से मार्गदर्शन करते हैं। [medium pause] इसे ठोस रूप देने के लिए मैं आपको दो वास्तविक दुनिया के परिदृश्यों के माध्यम से समझाता हूँ। पहला, एक 400 कमरों वाला होटल। यह प्रॉपर्टी आज PEAP-MSCHAPv2 के साथ WPA2-Enterprise पर एक स्टाफ नेटवर्क चलाती है। IT टीम पासवर्ड-आधारित ऑथेंटिकेशन को समाप्त करने और क्रेडेंशियल चोरी के जोखिम को कम करने के लिए EAP-TLS पर माइग्रेट करना चाहती है। चुनौती: स्टाफ डिवाइस Intune के माध्यम से प्रबंधित Windows लैपटॉप, व्यक्तिगत Android फोन जो प्रॉपर्टी मैनेजमेंट सॉफ़्टवेयर के लिए उपयोग किए जाते हैं, और बैक-ऑफ-हाउस में कुछ पुराने Windows 7 मशीनों का मिश्रण हैं। यहाँ दृष्टिकोण चरणबद्ध है। प्रबंधित Windows बेड़े (fleet) से शुरुआत करें। एक Intune कॉन्फ़िगरेशन प्रोफ़ाइल पुश करें जो RADIUS सर्वर का रूट CA सर्टिफिकेट इंस्टॉल करती है, WiFi प्रोफ़ाइल को EAP-TLS के लिए कॉन्फ़िगर करती है, और आंतरिक PKI से SCEP-आधारित सर्टिफिकेट नामांकन को ट्रिगर करती है। वे डिवाइस पहले दिन से स्वचालित रूप से ऑथेंटिकेट होते हैं। Android BYOD डिवाइसों के लिए, एक सेल्फ-सर्विस ऑनबोर्डिंग पोर्टल तैनात करें - उपयोगकर्ता एक URL पर जाते हैं, एक कॉन्फ़िगरेशन प्रोफ़ाइल डाउनलोड करते हैं, और सप्लीकेंट उनके लिए कॉन्फ़िगर हो जाता है। पुराने Windows 7 मशीनें सख्त सर्वर सर्टिफिकेट सत्यापन के साथ PEAP पर बनी रहती हैं, जिन्हें सीमित पहुंच के साथ एक अलग VLAN में तब तक अलग रखा जाता है, जब तक कि वे सेवामुक्त (decommissioned) न हो जाएं। [medium pause] दूसरा परिदृश्य: 200 स्टोर वाली एक बड़ी रिटेल चेन। प्रत्येक स्टोर में पॉइंट-ऑफ-सेल (POS) टर्मिनल, स्टाफ टैबलेट और एक गेस्ट WiFi नेटवर्क का मिश्रण है। PCI DSS की आवश्यकता है कि कार्डधारक डेटा वातावरण अन्य नेटवर्क सेगमेंट से अलग हों। रिटेलर स्टाफ और POS नेटवर्क पर 802.1X का उपयोग करता है, जिसमें VLAN असाइनमेंट सर्टिफिकेट विशेषताओं द्वारा संचालित होता है। एक POS टर्मिनल "POS" के संगठनात्मक विंग के साथ एक डिवाइस सर्टिफिकेट प्रस्तुत करता है - RADIUS नीति इसे PCI VLAN को सौंपती है। एक स्टाफ टैबलेट "Staff" के साथ एक सर्टिफिकेट प्रस्तुत करता है - यह स्टाफ VLAN पर समाप्त होता है। गेस्ट डिवाइस पूरी तरह से एक अलग SSID से कनेक्ट होते हैं, जिसे एक Captive Portal समाधान द्वारा संभाला जाता है। POS टर्मिनलों पर सप्लीकेंट कॉन्फ़िगरेशन MDM के माध्यम से लॉक किया गया है। किसी उपयोगकर्ता सहभागिता की आवश्यकता नहीं है। टर्मिनल बूट होने पर चुपचाप ऑथेंटिकेट होते हैं। सर्टिफिकेट रिन्यूअल SCEP के माध्यम से स्वचालित होता है, इसलिए सर्टिफिकेट समाप्त होने पर किसी मैन्युअल हस्तक्षेप की आवश्यकता नहीं होती है। [medium pause] अब, कार्यान्वयन की कमियां। मैं आपको चार सबसे सामान्य कमियां बताता हूँ। नंबर एक: PEAP डिप्लॉयमेंट पर सर्वर सर्टिफिकेट वैलिडेशन का न होना। यदि आप सप्लीकेंट को RADIUS सर्वर के सर्टिफिकेट को वैलिडेट करने और सर्वर नाम की जांच करने के लिए कॉन्फ़िगर नहीं करते हैं, तो उपयोगकर्ता किसी रोग (rogue) एक्सेस पॉइंट से कनेक्ट होने के प्रति संवेदनशील हो जाते हैं। हमेशा सप्लीकेंट प्रोफाइल में ट्रस्टेड रूट CA और सर्वर नाम निर्दिष्ट करें। नंबर दो: सर्टिफिकेट की समय-सीमा समाप्त (expiry) होने से बड़े पैमाने पर ऑथेंटिकेशन फेल होना। क्लाइंट सर्टिफिकेट की एक वैधता अवधि होती है। यदि आपके पास SCEP या NDES के माध्यम से स्वचालित रिन्यूअल की व्यवस्था नहीं है, तो आपको ऐसी गंभीर स्थिति का सामना करना पड़ेगा जहां सैकड़ों डिवाइस एक साथ ऑथेंटिकेट होना बंद कर देंगे। लाइव होने से पहले रिन्यूअल ऑटोमेशन तैयार करें। नंबर तीन: असंगत सप्लीकेंट व्यवहार वाले BYOD डिवाइस। Android में विशेष रूप से विभिन्न निर्माताओं के बीच खंडित (fragmented) 802.1X सपोर्ट है। कुछ वर्शन्स में उपयोगकर्ता को WiFi प्रोफाइल द्वारा इसे स्वीकार करने से पहले मैन्युअल रूप से CA सर्टिफिकेट इंस्टॉल करने की आवश्यकता होती है। एक ऑनबोर्डिंग पोर्टल जो इस चरण को संभालता है, हेल्पडेस्क वॉल्यूम को काफी कम कर देता है। नंबर चार: Windows 11 के फीचर अपडेट्स द्वारा सप्लीकेंट कॉन्फ़िगरेशन को बाधित करना। Microsoft ने कई Windows 11 अपडेट्स में 802.1X के व्यवहार को बदल दिया है। विशेष रूप से, 24H2 अपडेट ने इस बात में बदलाव किए हैं कि नेटिव सप्लीकेंट EAP-TLS फॉलबैक को कैसे संभालता है। प्रोडक्शन में रोल आउट करने से पहले नए OS वर्शन्स के साथ अपने सप्लीकेंट प्रोफाइल का परीक्षण करें। [medium pause] अब कुछ त्वरित प्रश्न। क्या IoT डिवाइस 802.1X का समर्थन कर सकते हैं? अधिकांश नहीं कर सकते। IoT डिवाइसों में आमतौर पर पूरी तरह से सप्लीकेंट की कमी होती है। इसका फॉलबैक MAC Authentication Bypass - MAB - है, जहां RADIUS सर्वर डिवाइस को उसके MAC एड्रेस के आधार पर ऑथेंटिकेट करता है। MAC एड्रेस को स्पूफ़ (spoof) किया जा सकता है, इसलिए MAB डिवाइसों को हमेशा सख्त फ़ायरवॉल नियमों के साथ एक अलग IoT VLAN पर रखा जाना चाहिए। क्या मुझे 802.1X चलाने के लिए PKI की आवश्यकता है? PEAP के लिए, नहीं - आपको केवल RADIUS सर्वर पर एक सर्वर सर्टिफिकेट की आवश्यकता होती है। EAP-TLS के लिए, हाँ - आपको क्लाइंट सर्टिफिकेट जारी करने के लिए PKI की आवश्यकता होती है। क्लाउड-आधारित PKI सेवाएं इंफ्रास्ट्रक्चर ओवरहेड को काफी कम करती हैं। 802.1X Purple के नेटवर्क एक्सेस प्लेटफॉर्म के साथ कैसे इंटरैक्ट करता है? Purple आपके मौजूदा हार्डवेयर - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist और अन्य के शीर्ष पर एक क्लाउड ओवरले के रूप में कार्य करता है। स्टाफ WiFi नेटवर्क पर, Purple का SecurePass ऐड-ऑन आपके आइडेंटिटी प्रोवाइडर - Microsoft Entra ID, Okta, या Google Workspace - के साथ एकीकृत होता है ताकि बिना ऑन-प्रिमाइसेस RADIUS इंफ्रास्ट्रक्चर की आवश्यकता के 802.1X ऑथेंटिकेशन को लागू किया जा सके और प्रति-उपयोगकर्ता VLAN नीतियां लागू की जा सकें। [medium pause] निष्कर्ष के तौर पर: 802.1X सप्लीकेंट डिवाइस-साइड एजेंट है जो पोर्ट-आधारित नेटवर्क एक्सेस कंट्रोल को काम करने योग्य बनाता है। EAP पद्धति का आपका चयन - अधिकतम सुरक्षा के लिए EAP-TLS, एक संक्रमणकालीन विकल्प के रूप में PEAP - आपकी PKI आवश्यकताओं और आपके सप्लीकेंट कॉन्फ़िगरेशन दृष्टिकोण को निर्धारित करता है। MDM के माध्यम से डिप्लॉय किए जाने पर नेटिव OS सप्लीकेंट अधिकांश प्रबंधित डिवाइस परिदृश्यों को कवर करते हैं। थर्ड-पार्टी क्लाइंट विशिष्ट मामलों में मूल्य जोड़ते हैं: मालिकाना (proprietary) EAP पद्धतियां, सुसंगत कॉन्फ़िगरेशन की आवश्यकता वाले मिश्रित-OS एस्टेट, या सेल्फ-सर्विस BYOD ऑनबोर्डिंग। याद रखने वाली तीन मुख्य बातें: हर supplicant profile पर अपने RADIUS सर्वर सर्टिफिकेट को वैलिडेट करें, बड़े पैमाने पर EAP-TLS को लागू करने से पहले सर्टिफिकेट रिन्यूअल को ऑटोमेट करें, और ऐसे डिवाइसेज को अलग करें जो 802.1X - IoT, लीगेसी हार्डवेयर - को सपोर्ट नहीं कर सकते हैं, उन्हें फॉलबैक के रूप में MAC Authentication Bypass के साथ डेडिकेटेड VLANs पर रखें। Purple आपके नेटवर्क एक्सेस आर्किटेक्चर के साथ कैसे इंटीग्रेट होता है, इस बारे में अधिक जानने के लिए, purple dot ai पर जाएं। सुनने के लिए धन्यवाद।