डिव्हाइसेसवर WiFi सर्टिफिकेट्स पुश करण्यासाठी Microsoft Intune चा वापर कसा करावा

डिव्हाइसेसवर WiFi सर्टिफिकेट्स पुश करण्यासाठी Microsoft Intune चा वापर कसा करावा एक Purple एंटरप्राइझ WiFi इंटेलिजन्स ब्रीफिंग [परिचय आणि संदर्भ — अंदाजे 1 मिनिट] पुन्हा स्वागत आहे. मी आज Purple, एंटरप्राइझ WiFi इंटेलिजन्स प्लॅटफॉर्मच्या वतीने बोलत आहे, आणि हा एपिसोड Microsoft Intune टूलकिटमधील सर्वात व्यावहारिक — आणि प्रामाणिकपणे, सर्वात अंडररेटेड — क्षमतेवर एक केंद्रित ब्रीफिंग आहे: 802.1X WiFi ऑथेंटिकेशनसाठी ऑटोमेटेड सर्टिफिकेट डिप्लॉयमेंट. जर तुम्ही हॉटेल इस्टेट, रिटेल चेन, स्टेडियम किंवा सार्वजनिक क्षेत्रातील इस्टेटमध्ये WiFi चे व्यवस्थापन करत असाल, तर मी वर्णन करणार असलेला पेन पॉईंट तुम्हाला माहीत असेल. तुमच्याकडे शेकडो किंवा हजारो मॅनेज्ड डिव्हाइसेस आहेत. तुम्हाला ती तुमच्या कॉर्पोरेट WiFi शी आपोआप, सुरक्षितपणे, युझर्सनी पासवर्ड टाईप न करता, IT ने प्रत्येक डिव्हाइसला स्पर्श न करता कनेक्ट व्हावीत असे वाटते. आणि ते कनेक्शन क्रिप्टोग्राफिकदृष्ट्या मजबूत असावे असे तुम्हाला वाटते — केवळ एक शेअर केलेला पासवर्ड नाही जो आधीच अर्ध्या संस्थेला ईमेल केला गेला आहे. Intune सर्टिफिकेट डिप्लॉयमेंट नेमके हेच सोडवते. आणि पुढच्या नऊ मिनिटांत, मी तुम्हाला ते कसे कार्य करते, ते कसे डिप्लॉय करायचे आणि पहिल्या प्रयत्नात बहुतेक टीम्सना अडकवणारे धोके याबद्दल मार्गदर्शन करणार आहे. [तांत्रिक सखोल माहिती — अंदाजे 5 मिनिटे] आपण आर्किटेक्चरपासून सुरुवात करूया. याचा पाया IEEE 802.1X आहे — पोर्ट-आधारित नेटवर्क अ‍ॅक्सेस कंट्रोल स्टँडर्ड जे दोन दशकांहून अधिक काळ एंटरप्राइझ WiFi सुरक्षेचा कणा आहे. जेव्हा एखादे डिव्हाइस तुमच्या WiFi शी कनेक्ट होते, तेव्हा 802.1X ला कोणताही नेटवर्क अ‍ॅक्सेस मिळण्यापूर्वी त्याने ऑथेंटिकेट करणे आवश्यक असते. ऑथेंटिकेशन संभाषण तीन पक्षांमध्ये होते: डिव्हाइस — ज्याला सप्लिकंट म्हणतात — तुमचा WiFi अ‍ॅक्सेस पॉईंट, जो ऑथेंटिकेटर म्हणून काम करतो, आणि तुमचा RADIUS सर्व्हर, जो ऑथेंटिकेशन सर्व्हर आहे जो अंतिम निर्णय घेतो. आता, 802.1X एकाधिक ऑथेंटिकेशन पद्धतींना सपोर्ट करते. सर्वात सुरक्षित EAP-TLS आहे — Extensible Authentication Protocol with Transport Layer Security. EAP-TLS म्युच्युअल सर्टिफिकेट ऑथेंटिकेशन वापरते: डिव्हाइस आपली ओळख सिद्ध करण्यासाठी सर्टिफिकेट सादर करते आणि RADIUS सर्व्हर आपली ओळख सिद्ध करण्यासाठी सर्टिफिकेट सादर करतो. यात कोणतेही पासवर्ड्स समाविष्ट नाहीत. फिश केले जाऊ शकतील असे कोणतेही क्रेडेंशियल्स नाहीत. हेच आपले ध्येय आहे. मोठ्या प्रमाणावर डिव्हाइसेसवर ती सर्टिफिकेट्स मिळवणे हे नेहमीच आव्हान राहिले आहे. तिथेच Microsoft Intune येते. Intune दोन सर्टिफिकेट डिप्लॉयमेंट यंत्रणांना सपोर्ट करते: SCEP — Simple Certificate Enrollment Protocol — आणि PKCS, ज्याचा अर्थ Public Key Cryptography Standards असा होतो. यातील फरक समजून घेणे महत्त्वाचे आहे. SCEP सह, प्रायव्हेट की डिव्हाइसवरच जनरेट केली जाते. डिव्हाइस Certificate Signing Request तयार करते, ती NDES — Network Device Enrollment Service — नावाच्या मध्यस्थ सर्व्हरद्वारे तुमच्या Certificate Authority ला पाठवते आणि CA सर्टिफिकेट परत जारी करते. प्रायव्हेट की कधीही डिव्हाइस सोडत नाही. हा अधिक सुरक्षित दृष्टिकोन आहे आणि BYOD वातावरणासाठी आणि उच्च-सुरक्षा डिप्लॉयमेंट्ससाठी याची शिफारस केली जाते. PKCS सह, Certificate Authority की पेअर जनरेट करते आणि Intune Certificate Connector प्रायव्हेट की आणि सर्टिफिकेट डिव्हाइसला वितरित करतो. हे सेट अप करणे सोपे आहे — कोणत्याही NDES सर्व्हरची आवश्यकता नाही — परंतु प्रायव्हेट की कनेक्टरमधून ट्रान्झिट होते, जो तुमच्या सुरक्षा पोश्चरसाठी एक विचार करण्याजोगा मुद्दा आहे. बहुतेक एंटरप्राइझ डिप्लॉयमेंट्ससाठी मी BYOD आणि मिश्र-डिव्हाइस वातावरणासाठी SCEP ची शिफारस करेन, आणि जिथे तुमच्याकडे कॉर्पोरेट-मालकीच्या Windows डिव्हाइसेसचा एकसंध फ्लीट आहे आणि तुम्हाला इन्फ्रास्ट्रक्चरची गुंतागुंत कमी करायची आहे तिथे PKCS ची शिफारस करेन. आता, आपण डिप्लॉयमेंट सिक्वेन्सबद्दल बोलूया — कारण क्रम महत्त्वाचा आहे आणि तो चुकीचा असणे हे अयशस्वी रोलआउट्सचे सर्वात सामान्य कारण आहे. पायरी एक: तुमची Certificate Authority कॉन्फिगर करा. तुम्हाला तुमच्या Active Directory Certificate Services इन्स्टन्सवर सर्टिफिकेट टेम्प्लेटची आवश्यकता आहे — किंवा जर तुम्ही पूर्णपणे क्लाउड-नेटिव्ह असाल, तर Microsoft चे Intune Cloud PKI आता सर्वसाधारणपणे उपलब्ध आहे आणि ते ऑन-प्रिमाइसेस CA ची आवश्यकता पूर्णपणे दूर करते. टेम्प्लेटला योग्य की युसेज एक्स्टेंशन्सची आवश्यकता आहे: Client Authentication अनिवार्य आहे. किमान की साईझ 2048 बिट्सवर सेट करा, किंवा तुमच्या संस्थेच्या सुरक्षा धोरणानुसार आवश्यक असल्यास 4096 वर सेट करा. पायरी दोन: Trusted Root Certificate डिप्लॉय करा. कोणत्याही डिव्हाइसने RADIUS सर्व्हरचे सर्टिफिकेट प्रमाणित करण्यापूर्वी, त्याने ते जारी केलेल्या CA वर विश्वास ठेवला पाहिजे. तुम्ही Intune मध्ये Trusted Certificate कॉन्फिगरेशन प्रोफाइल तयार करता, Root CA सर्टिफिकेट अपलोड करता आणि ते तुमच्या डिव्हाइस ग्रुप्सना असाइन करता. हे कोणत्याही WiFi प्रोफाइल किंवा क्लायंट सर्टिफिकेट प्रोफाइलच्या आधी डिव्हाइसेसवर पोहोचले पाहिजे. जर तुम्ही सिक्वेन्सिंग चुकीचे केले, तर डिव्हाइसेस RADIUS सर्व्हर नाकारतील आणि तुम्ही Windows इव्हेंट लॉगमध्ये Event ID 20271 कडे पाहत दुपार घालवाल. पायरी तीन: Client Certificate Profile डिप्लॉय करा. हे एकतर तुमचे SCEP प्रोफाइल आहे — जे तुमच्या NDES सर्व्हर URL कडे निर्देशित करते — किंवा तुमचे PKCS प्रोफाइल, जे तुमच्या Certificate Authority कडे निर्देशित करते. Subject Alternative Name मध्ये युझर सर्टिफिकेट्ससाठी User Principal Name किंवा डिव्हाइस सर्टिफिकेट्ससाठी AAD Device ID समाविष्ट असावा. हा फरक महत्त्वाचा आहे: युझर सर्टिफिकेट्स लॉग-इन केलेल्या युझरला ऑथेंटिकेट करतात, डिव्हाइस सर्टिफिकेट्स मशीनलाच ऑथेंटिकेट करतात, ज्याचा अर्थ युझरने लॉग इन करण्यापूर्वी डिव्हाइस WiFi शी कनेक्ट होऊ शकते — डोमेन जॉईन परिस्थिती आणि किओस्क डिप्लॉयमेंट्ससाठी उपयुक्त. पायरी चार: WiFi Configuration Profile तयार करा. Intune मध्ये, हे Devices, Configuration Profiles, Templates, Wi-Fi अंतर्गत आहे. WiFi प्रकार Enterprise वर सेट करा, तुमचा SSID एंटर करा, EAP प्रकार EAP-TLS वर सेट करा, सर्व्हर ट्रस्ट सेटिंग्ज कॉन्फिगर करा — येथे तुम्ही RADIUS सर्व्हर सर्टिफिकेटचे नाव संदर्भित करता — आणि क्लायंट ऑथेंटिकेशनसाठी, तुम्ही पायरी तीन मध्ये तयार केलेले सर्टिफिकेट प्रोफाइल संदर्भित करा. पायरी पाच: सर्वकाही योग्य ग्रुप्सना असाइन करा आणि प्रमाणित करा. तुमचे Root Certificate, Client Certificate आणि WiFi प्रोफाइल्स समान डिव्हाइस किंवा युझर ग्रुप्सना असाइन करा. प्रोफाइल डिप्लॉयमेंट स्थितीचे निरीक्षण करण्यासाठी Intune च्या अंगभूत रिपोर्टिंगचा वापर करा. यशस्वी डिप्लॉयमेंट डिव्हाइसच्या कॉन्फिगरेशन प्रोफाइल सूचीमध्ये तिन्ही प्रोफाइल्स Succeeded म्हणून दर्शवते. Windows Server वातावरणासाठी NPS कॉन्फिगरेशनवरील एक महत्त्वाचा मुद्दा: 2024 च्या सुरुवातीपासून, Microsoft ने सर्टिफिकेट मॅपिंग आवश्यकता कठोर केल्या आहेत. जर तुम्ही ऑन-प्रिमाइसेस NPS विरुद्ध ऑथेंटिकेट करणाऱ्या Azure AD-जॉईन्ड डिव्हाइसेससह डिव्हाइस सर्टिफिकेट्स वापरत असाल, तर तुम्हाला Active Directory मधील कॉम्प्युटर ऑब्जेक्टवरील altSecurityIdentities अ‍ॅट्रिब्युट सर्टिफिकेटच्या थंबप्रिंटसह पॉप्युलेट केलेले असल्याची खात्री करणे आवश्यक आहे. हे आपोआप होत नाही — हे हाताळण्यासाठी तुम्हाला स्क्रिप्ट किंवा वर्कफ्लोची आवश्यकता आहे, जे सामान्यतः CA नवीन सर्टिफिकेट जारी करते तेव्हा ट्रिगर होते. [अंमलबजावणी शिफारसी आणि धोके — अंदाजे 2 मिनिटे] मी तुम्हाला एंटरप्राइझ डिप्लॉयमेंट्समध्ये वारंवार दिसणारे तीन धोके सांगतो. धोका एक: सर्टिफिकेट चेन गॅप्स. डिव्हाइसने Root CA पासून RADIUS सर्व्हरच्या सर्टिफिकेटपर्यंतच्या चेनमधील प्रत्येक सर्टिफिकेटवर विश्वास ठेवला पाहिजे. जर तुमचे RADIUS सर्व्हर सर्टिफिकेट Intermediate CA द्वारे जारी केले गेले असेल, तर तुम्हाला Root आणि Intermediate दोन्ही डिव्हाइसेसवर डिप्लॉय करणे आवश्यक आहे. मी डिप्लॉयमेंट्स आठवडे अयशस्वी होताना पाहिले आहेत कारण कोणीतरी Root डिप्लॉय केले पण Intermediate नाही. धोका दोन: प्रोफाइल असाइनमेंट टायमिंग. Intune प्रोफाइल्स डिव्हाइसेसवर त्वरित पोहोचत नाहीत. मोठ्या इस्टेटमध्ये, असाइनमेंटनंतर प्रोफाइल्स प्रोपोगेट होण्यासाठी 15 ते 30 मिनिटे लागू शकतात. प्रोफाइल्स तयार केल्यानंतर लगेच चाचणी करू नका. चेक-इन फोर्स करण्यासाठी Intune पोर्टल मधील Sync बटण वापरा, नंतर प्रतीक्षा करा. तसेच, WiFi प्रोफाइल लागू होण्यापूर्वी क्लायंट सर्टिफिकेट प्रोफाइल्स डिप्लॉय आणि कन्फर्म केले जाणे आवश्यक आहे — जर WiFi प्रोफाइल अद्याप अस्तित्वात नसलेल्या सर्टिफिकेटचा संदर्भ देत असेल, तर प्रोफाइल काही प्लॅटफॉर्म्सवर सायलेंटली अयशस्वी होईल. धोका तीन: BYOD सर्टिफिकेट रिव्होकेशन. जेव्हा एखादे डिव्हाइस Intune मधून अनएनरोल केले जाते — कारण कर्मचारी सोडून जातो, किंवा डिव्हाइस हरवते — तेव्हा तुम्हाला सर्टिफिकेट रद्द करण्यासाठी प्रक्रियेची आवश्यकता असते. जर तुम्ही ADCS सह SCEP वापरत असाल, तर Certificate Revocation List डिस्ट्रिब्युशन पॉईंट योग्यरित्या कॉन्फिगर करा आणि तुमचा RADIUS सर्व्हर प्रत्येक ऑथेंटिकेशनवर CRL किंवा OCSP तपासत असल्याची खात्री करा. PCI DSS सारख्या फ्रेमवर्क्स अंतर्गत ही एक कंप्लायन्स आवश्यकता आहे, जी अनिवार्य करते की अ‍ॅक्सेस कंट्रोल यंत्रणांची आवश्यकता नसताना ती त्वरित रद्द केली जावी. कंप्लायन्सच्या विषयावर: जर तुम्ही PCI DSS स्कोपमध्ये काम करत असाल — उदाहरणार्थ रिटेल पेमेंट वातावरण — तर सर्टिफिकेट-आधारित 802.1X ऑथेंटिकेशन हे वायरलेस नेटवर्क अ‍ॅक्सेससाठी तुमचे सर्वात मजबूत कंट्रोल आहे. हे नेटवर्क अ‍ॅक्सेस कंट्रोल्सच्या आसपासची PCI DSS Requirement 1.3 आणि ऑथेंटिकेशन फॅक्टर्सच्या आसपासची Requirement 8.6 पूर्ण करते. तुमच्या कंप्लायन्स पुराव्याचा भाग म्हणून तुमच्या सर्टिफिकेट लाइफसायकल मॅनेजमेंट प्रक्रियेचे डॉक्युमेंटेशन करा. GDPR-रेग्युलेटेड वातावरणासाठी, विशेषतः हॉस्पिटॅलिटी आणि सार्वजनिक-क्षेत्रात, तुमचे कॉर्पोरेट 802.1X नेटवर्क आणि तुमचे गेस्ट WiFi नेटवर्क यांच्यातील वेगळेपण महत्त्वपूर्ण आहे. तुमचे कॉर्पोरेट Intune-मॅनेज्ड नेटवर्क कोणत्याही गेस्ट किंवा अभ्यागत नेटवर्कपासून पूर्णपणे वेगळ्या VLAN आणि SSID वर असावे. Purple चे गेस्ट WiFi प्लॅटफॉर्म अभ्यागतांच्या बाजूची हाताळणी करते — Captive Portal, संमती कॅप्चर, अ‍ॅनालिटिक्स — तर तुमचे Intune-मॅनेज्ड कॉर्पोरेट नेटवर्क कर्मचारी आणि ऑपरेशनल डिव्हाइसेस हाताळते. या दोन नेटवर्क्सनी कधीही ऑथेंटिकेशन इन्फ्रास्ट्रक्चर शेअर करू नये. [रॅपिड-फायर प्रश्नोत्तरे — अंदाजे 1 मिनिट] मी नियमितपणे येणाऱ्या काही प्रश्नांची उत्तरे देतो. मी ऑन-प्रिमाइसेस ADCS ऐवजी Intune Cloud PKI वापरू शकतो का? होय. 2024 मध्ये रिलीज झालेले Microsoft चे Intune Cloud PKI, Azure मध्ये पूर्णपणे मॅनेज्ड CA प्रदान करते. हे SCEP साठी NDES सर्व्हरची आवश्यकता दूर करते आणि कनेक्टर सेटअप लक्षणीयरीत्या सुलभ करते. ग्रीनफिल्ड डिप्लॉयमेंट्ससाठी किंवा विद्यमान ADCS इन्फ्रास्ट्रक्चर नसलेल्या संस्थांसाठी, हा शिफारस केलेला मार्ग आहे. हे macOS आणि iOS डिव्हाइसेससाठी काम करते का? होय. Intune Windows, iOS, iPadOS, Android आणि macOS साठी सर्टिफिकेट प्रोफाइल्सना सपोर्ट करते. प्रोफाइल प्रकार आणि कॉन्फिगरेशन पर्याय प्लॅटफॉर्मनुसार थोडे बदलतात, परंतु मूळ आर्किटेक्चर — Trusted Root, Client Certificate, WiFi Profile — सुसंगत आहे. BYOD प्रोग्राममधील वैयक्तिक डिव्हाइसेसचे काय? SCEP येथे तुमचा मित्र आहे. Intune च्या डिव्हाइस कंप्लायन्स पॉलिसीजसह, तुम्ही सर्टिफिकेट जारी करण्यापूर्वी डिव्हाइसने किमान सुरक्षा मानके पूर्ण करणे आवश्यक करू शकता. जर डिव्हाइस कंप्लायन्सच्या बाहेर गेले — स्क्रीन लॉक नाही, जुनी OS — तर सर्टिफिकेट रद्द केले जाऊ शकते आणि नेटवर्क अ‍ॅक्सेस आपोआप काढून घेतला जाऊ शकतो. Purple या आर्किटेक्चरशी इंटिग्रेट होऊ शकते का? नक्कीच. Purple चे प्लॅटफॉर्म गेस्ट नेटवर्कच्या बाजूला बसते, Captive Portal ऑथेंटिकेशन, संमती व्यवस्थापन आणि अ‍ॅनालिटिक्स हाताळते. कॉर्पोरेट 802.1X नेटवर्क आणि Purple चे गेस्ट WiFi समांतर चालतात — समान फिजिकल इन्फ्रास्ट्रक्चर, भिन्न SSIDs आणि VLANs — तुम्हाला कर्मचारी कनेक्टिव्हिटी आणि अभ्यागत एंगेजमेंट यांच्यात पूर्ण वेगळेपण देते. [सारांश आणि पुढील टप्पे — अंदाजे 1 मिनिट] थोडक्यात सांगायचे तर: Intune द्वारे WiFi सर्टिफिकेट्स डिप्लॉय करणे ही पाच-टप्प्यांची प्रक्रिया आहे — CA कॉन्फिगरेशन, Trusted Root डिप्लॉयमेंट, Client Certificate प्रोफाइल, WiFi प्रोफाइल आणि ग्रुप असाइनमेंट. BYOD आणि उच्च-सुरक्षा वातावरणासाठी SCEP निवडा; सोप्या कॉर्पोरेट-मालकीच्या फ्लीट्ससाठी PKCS. सिक्वेन्सिंग योग्य करा, NPS सर्टिफिकेट मॅपिंग आवश्यकता हाताळा आणि पहिल्या दिवसापासून सर्टिफिकेट रिव्होकेशन वर्कफ्लो तयार करा. बिझनेस केस सरळ आहे: तुम्ही शेअर केलेले WiFi पासवर्ड्स दूर करता, तुम्हाला प्रति-डिव्हाइस आणि प्रति-युझर ऑथेंटिकेशन लॉग्स मिळतात, तुम्ही PCI DSS आणि ISO 27001 वायरलेस सुरक्षा आवश्यकता पूर्ण करता आणि मोठ्या इस्टेटमध्ये WiFi क्रेडेंशियल्स व्यवस्थापित करण्याचा IT ओव्हरहेड कमी करता. जर तुम्ही डिप्लॉयमेंटची योजना आखत असाल आणि Purple चे गेस्ट WiFi आणि अ‍ॅनालिटिक्स प्लॅटफॉर्म तुमच्या कॉर्पोरेट नेटवर्क आर्किटेक्चरसोबत कसे बसते हे समजून घ्यायचे असेल, तर purple.ai ला भेट द्या. आमच्याकडे Azure Entra ID इंटिग्रेशन, 802.1X आर्किटेक्चर आणि हॉस्पिटॅलिटी, रिटेल आणि सार्वजनिक-क्षेत्रातील वातावरणासाठी गेस्ट नेटवर्क डिझाइनवर तपशीलवार मार्गदर्शक आहेत. ऐकल्याबद्दल धन्यवाद. पुढच्या वेळेपर्यंत.