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

उपकरणांवर WIFI प्रमाणपत्रे पाठवण्यासाठी MICROSOFT INTUNE चा वापर कसा करावा Purple Enterprise WiFi इंटेलिजन्स ब्रीफिंग [परिचय आणि संदर्भ - अंदाजे १ मिनिट] पुन्हा स्वागत आहे. मी आज Purple, एंटरप्राइझ WiFi इंटेलिजन्स प्लॅटफॉर्मच्या वतीने बोलत आहे, आणि हा एपिसोड Microsoft Intune टूलकिटमधील सर्वात व्यावहारिक - आणि खरं सांगायचं तर, सर्वात दुर्लक्षित - क्षमतांपैकी एकावर केंद्रित ब्रीफिंग आहे: 802.1X WiFi प्रमाणीकरणासाठी स्वयंचलित प्रमाणपत्र वितरण (deployment). जर तुम्ही हॉटेल इस्टेट, रिटेल साखळी, स्टेडियम किंवा सार्वजनिक क्षेत्रातील मालमत्तेमधील WiFi व्यवस्थापित करत असाल, तर मी आता जे वर्णन करणार आहे ते वेदनादायक ठिकाण तुम्हाला नक्कीच माहिती असेल. तुमच्याकडे शेकडो किंवा हजारो व्यवस्थापित उपकरणे आहेत. युजर्सनी पासवर्ड टाईप न करता, आयटी टीमने प्रत्येक उपकरणाला स्पर्श न करता, त्यांनी तुमच्या कॉर्पोरेट WiFi शी स्वयंचलितपणे, सुरक्षितपणे कनेक्ट व्हावे अशी तुमची इच्छा आहे. आणि तुम्हाला ते कनेक्शन क्रिप्टोग्राफिकदृष्ट्या मजबूत हवे आहे - केवळ एक सामायिक केलेला पासवर्ड नको जो आधीच कोणीतरी अर्ध्या संस्थेला ईमेल केला आहे. Intune प्रमाणपत्र वितरण नेमकी हीच समस्या सोडवते. आणि पुढील नऊ मिनिटांत, मी तुम्हाला हे कसे कार्य करते, ते कसे तैनात करायचे आणि पहिल्याच प्रयत्नात बहुतांश टीम्स ज्या अडचणींमध्ये अडकतात, त्या कशा टाळायच्या याबद्दल सविस्तर माहिती देणार आहे. [तांत्रिक सखोल विश्लेषण - अंदाजे ५ मिनिटे] चला आर्किटेक्चरपासून सुरुवात करूया. याचा पाया IEEE 802.1X आहे - पोर्ट-आधारित नेटवर्क ऍक्सेस कंट्रोल मानक जे दोन दशकांहून अधिक काळ एंटरप्राइझ WiFi सुरक्षेचा कणा राहिले आहे. जेव्हा एखादे उपकरण तुमच्या WiFi शी कनेक्ट होते, तेव्हा 802.1X ला नेटवर्क ऍक्सेस मिळण्यापूर्वी त्याचे प्रमाणीकरण करणे आवश्यक असते. प्रमाणीकरणाचे संभाषण तीन पक्षांमध्ये होते: उपकरण - ज्याला सप्लिकंट (supplicant) म्हटले जाते - तुमचे WiFi ऍक्सेस पॉईंट, जे ऑथेंटिकेटर म्हणून काम करते, आणि तुमचे RADIUS सर्व्हर, जे अंतिम निर्णय घेणारे ऑथेंटिकेशन सर्व्हर आहे. आता, 802.1X एकाधिक प्रमाणीकरण पद्धतींना सपोर्ट करते. सर्वात सुरक्षित पद्धत EAP-TLS आहे - ट्रान्सपोर्ट लेयर सिक्युरिटीसह एक्स्टेंसिबल ऑथेंटिकेशन प्रोटोकॉल. EAP-TLS परस्पर प्रमाणपत्र प्रमाणीकरण वापरते: उपकरण त्याची ओळख सिद्ध करण्यासाठी प्रमाणपत्र सादर करते आणि RADIUS सर्व्हर त्याची ओळख सिद्ध करण्यासाठी प्रमाणपत्र सादर करते. यामध्ये कोणतेही पासवर्ड समाविष्ट नसतात. फिशिंग केले जाऊ शकेल असे कोणतेही क्रेडेंशियल्स नसतात. हेच आपले उद्दिष्ट आहे. मोठ्या प्रमाणावर ही प्रमाणपत्रे उपकरणांवर मिळवणे हे नेहमीच एक आव्हान राहिले आहे. तिथेच Microsoft Intune उपयोगात येते. Intune दोन प्रमाणपत्र वितरण यंत्रणांना सपोर्ट करते: SCEP - सिंपल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल - आणि PKCS, ज्याचा अर्थ पब्लिक की क्रिप्टोग्राफी स्टँडर्ड्स असा आहे. यातील फरक समजून घेणे महत्त्वाचे आहे. SCEP सह, प्रायव्हेट की उपकरणावरच तयार केली जाते. उपकरण एक प्रमाणपत्र स्वाक्षरी विनंती (Certificate Signing Request) तयार करते, ती NDES - नेटवर्क डिव्हाइस एनरोलमेंट सर्व्हिस नावाच्या मध्यस्थ सर्व्हरद्वारे तुमच्या सर्टिफिकेट ऑथॉरिटीकडे पाठवते आणि 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 अनिवार्य आहे. किमान की साईझ २०४८ बिट्स सेट करा, किंवा तुमच्या संस्थेच्या सुरक्षा धोरणानुसार आवश्यक असल्यास ४०९६ सेट करा. दुसरी पायरी: ट्रस्टेड रूट प्रमाणपत्र डिप्लॉय करा. कोणतेही डिव्हाइस RADIUS सर्वरच्या प्रमाणपत्राची पडताळणी करण्यापूर्वी, ज्या CA ने ते जारी केले आहे त्यावर त्याचा विश्वास असणे आवश्यक आहे. तुम्ही Intune मध्ये Trusted Certificate कॉन्फिगरेशन प्रोफाइल तयार करता, रूट CA प्रमाणपत्र अपलोड करता आणि ते तुमच्या डिव्हाइस ग्रुप्सना नियुक्त करता. हे कोणत्याही WiFi प्रोफाइल किंवा क्लायंट प्रमाणपत्र प्रोफाइलच्या आधी डिव्हाइसेसवर पोहोचले पाहिजे. जर तुमचा क्रम चुकला, तर डिव्हाइसेस RADIUS सर्वर नाकारतील आणि तुम्ही Windows इव्हेंट लॉगमध्ये Event ID २०२७१ पाहत दुपार घालवाल. तिसरी पायरी: क्लायंट प्रमाणपत्र प्रोफाइल डिप्लॉय करा. हे एकतर तुमचे SCEP प्रोफाइल आहे - जे तुमच्या NDES सर्वर URL कडे निर्देश करते - किंवा तुमचे PKCS प्रोफाइल आहे, जे तुमच्या Certificate Authority कडे निर्देश करते. Subject Alternative Name मध्ये युझर प्रमाणपत्रांसाठी User Principal Name, किंवा डिव्हाइस प्रमाणपत्रांसाठी AAD Device ID समाविष्ट असावा. हा फरक महत्त्वाचा आहे: युझर प्रमाणपत्रे लॉग-इन केलेल्या युझरची पडताळणी करतात, डिव्हाइस प्रमाणपत्रे मशीनची स्वतःची पडताळणी करतात, ज्याचा अर्थ असा की युझरने लॉग इन करण्यापूर्वी डिव्हाइस WiFi शी कनेक्ट होऊ शकते - डोमेन जॉइन परिस्थिती आणि किओस्क डिप्लॉयमेंटसाठी हे उपयुक्त आहे. चौथी पायरी: WiFi कॉन्फिगरेशन प्रोफाइल तयार करा. Intune मध्ये, हे Devices, Configuration Profiles, Templates, Wi-Fi अंतर्गत आहे. WiFi प्रकार Enterprise वर सेट करा, तुमचा SSID प्रविष्ट करा, EAP प्रकार EAP-TLS वर सेट करा, सर्वर ट्रस्ट सेटिंग्ज कॉन्फिगर करा - येथे तुम्ही RADIUS सर्वर प्रमाणपत्राच्या नावाचा संदर्भ देता - आणि क्लायंट पडताळणीसाठी, तुम्ही तिसऱ्या पायरीत तयार केलेल्या प्रमाणपत्र प्रोफाइलचा संदर्भ द्या. पाचवी पायरी: सर्व गोष्टी योग्य ग्रुप्सना नियुक्त करा आणि पडताळणी करा. तुमचे रूट प्रमाणपत्र, क्लायंट प्रमाणपत्र आणि WiFi प्रोफाइल एकाच डिव्हाइस किंवा युझर ग्रुप्सना नियुक्त करा. प्रोफाइल डिप्लॉयमेंट स्थितीचे निरीक्षण करण्यासाठी Intune चे अंगभूत रिपोर्टिंग वापरा. यशस्वी डिप्लॉयमेंट डिव्हाइसच्या कॉन्फिगरेशन प्रोफाइल सूचीमध्ये हे तिन्ही प्रोफाइल्स Succeeded म्हणून दाखवते. Windows Server वातावरणासाठी NPS कॉन्फिगरेशनवर एक अत्यंत महत्त्वाचा मुद्दा: २०२४ च्या सुरुवातीपासून, Microsoft ने सर्टिफिकेट मॅपिंगच्या आवश्यकता अधिक कडक केल्या आहेत. जर तुम्ही Azure AD-joined उपकरणांसह डिव्हाइस सर्टिफिकेट वापरत असाल जे ऑन-प्रिमाइसेस NPS विरुद्ध ऑथेंटिकेट करत आहेत, तर तुम्हाला हे सुनिश्चित करणे आवश्यक आहे की Active Directory मधील कॉम्प्युटर ऑब्जेक्टवरील altSecurityIdentities ॲट्रिब्यूट सर्टिफिकेटच्या थम्बप्रिंटसह पॉप्युलेट केलेले असावे. हे आपोआप घडत नाही - तुम्हाला हे हाताळण्यासाठी एक स्क्रिप्ट किंवा वर्कफ्लो आवश्यक आहे, जे सहसा CA नवीन सर्टिफिकेट जारी करते तेव्हा ट्रिगर होते. [अमलबजावणीच्या शिफारसी आणि त्रुटी - अंदाजे २ मिनिटे] मी तुम्हाला एंटरप्राइझ डिप्लॉयमेंटमध्ये वारंवार दिसणाऱ्या तीन त्रुटी सांगतो. पहिली त्रुटी: सर्टिफिकेट चेन गॅप्स. उपकरणाने रूट CA पासून ते RADIUS सर्व्हरच्या सर्टिफिकेटपर्यंतच्या चेन मधील प्रत्येक सर्टिफिकेटवर विश्वास ठेवणे आवश्यक आहे. जर तुमचे RADIUS सर्व्हर सर्टिफिकेट एखाद्या इंटरमीजिएट CA द्वारे जारी केले गेले असेल, तर तुम्हाला रूट आणि इंटरमीजिएट दोन्ही उपकरणांवर डिप्लॉय करावे लागेल. एखाद्याने रूट डिप्लॉय केले परंतु इंटरमीजिएट नाही, यामुळे अनेक आठवडे डिप्लॉयमेंट अयशस्वी झालेली मी पाहिली आहे. दुसरी त्रुटी: प्रोफाइल असाइनमेंट टायमिंग. Intune प्रोफाइल उपकरणांवर त्वरित पोहोचत नाहीत. मोठ्या इस्टेटमध्ये, असाइनमेंटनंतर प्रोफाइल्सचा प्रसार होण्यासाठी १५ ते ३० मिनिटे लागू शकतात. प्रोफाइल्स तयार केल्यावर लगेच चाचणी करू नका. चेक-इन सक्तीने करण्यासाठी Intune पोर्टलवरील Sync बटण वापरा, नंतर प्रतीक्षा करा. तसेच, WiFi प्रोफाइल लागू करण्यापूर्वी क्लायंट सर्टिफिकेट प्रोफाइल डिप्लॉय आणि कन्फर्म केले पाहिजेत - जर WiFi प्रोफाइल अशा सर्टिफिकेटचा संदर्भ देत असेल जे अद्याप अस्तित्वात नाही, तर काही प्लॅटफॉर्म्सवर प्रोफाइल शांतपणे अयशस्वी होईल. तिसरी त्रुटी: BYOD सर्टिफिकेट रिव्होकेशन. जेव्हा एखादे उपकरण Intune मधून अनएनरोल केले जाते - कर्मचारी सोडून गेल्यामुळे किंवा उपकरण हरवल्यामुळे - तेव्हा तुम्हाला सर्टिफिकेट रद्द करण्याची प्रक्रिया आवश्यक असते. जर तुम्ही ADCS सह SCEP वापरत असाल, तर सर्टिफिकेट रिव्होकेशन लिस्ट डिस्ट्रिब्युशन पॉईंट योग्यरित्या कॉन्फिगर करा आणि तुमचा RADIUS सर्व्हर प्रत्येक ऑथेंटिकेशनवर CRL किंवा OCSP तपासत असल्याची खात्री करा. PCI-DSS सारख्या फ्रेमवर्क अंतर्गत ही एक अनुपालन आवश्यकता आहे, जी यापुढे गरज नसताना ॲक्सेस कंट्रोल मेकॅनिझम त्वरित रद्द करणे बंधनकारक करते. अनुपालनाच्या विषयावर: जर तुम्ही PCI-DSS च्या कक्षेमध्ये काम करत असाल - उदाहरणार्थ, रिटेल पेमेंट वातावरण - तर वायरलेस नेटवर्क ॲक्सेससाठी सर्टिफिकेट-आधारित 802.1X ऑथेंटिकेशन हे तुमचे सर्वात मजबूत नियंत्रण आहे. हे नेटवर्क ॲक्सेस कंट्रोल्सच्या संदर्भातील PCI-DSS ची आवश्यकता १.३ आणि ऑथेंटिकेशन फॅक्टर्सच्या संदर्भातील आवश्यकता ८.६ चे समाधान करते. तुमच्या अनुपालनाच्या पुराव्याचा भाग म्हणून तुमच्या सर्टिफिकेट लाइफसायकल मॅनेजमेंट प्रक्रियेचे दस्तऐवजीकरण करा. GDPR द्वारे नियंत्रित वातावरणासाठी, विशेषत: हॉस्पिटॅलिटी आणि सार्वजनिक क्षेत्रात, तुमच्या कॉर्पोरेट 802.1X नेटवर्क आणि तुमच्या अतिथी WiFi नेटवर्कमधील वेगळेपण अत्यंत महत्त्वाचे आहे. तुमचे कॉर्पोरेट Intune द्वारे व्यवस्थापित केलेले नेटवर्क कोणत्याही अतिथी किंवा अभ्यागत नेटवर्कपेक्षा पूर्णपणे वेगळ्या VLAN आणि SSID वर असावे. Purple चे अतिथी WiFi प्लॅटफॉर्म अभ्यागतांच्या बाजूचे काम हाताळते - captive portal, संमती कॅप्चर, ॲनालिटिक्स - तर तुमचे Intune द्वारे व्यवस्थापित कॉर्पोरेट नेटवर्क कर्मचारी आणि ऑपरेशनल डिव्हाइसेस हाताळते. या दोन नेटवर्कनी कधीही ऑथेंटिकेशन इन्फ्रास्ट्रक्चर शेअर करू नये. [रॅपिड-फायर प्रश्न आणि उत्तरे - अंदाजे १ मिनिट] नियमितपणे समोर येणाऱ्या काही प्रश्नांचा आढावा घेऊया. मी ऑन-प्रिमायसेस ADCS ऐवजी Intune Cloud PKI वापरू शकतो का? होय. २०२४ मध्ये रिलीज झालेले Microsoft चे Intune Cloud PKI, Azure मध्ये पूर्णपणे व्यवस्थापित CA प्रदान करते. हे SCEP साठी NDES सर्व्हरची आवश्यकता काढून टाकते आणि कनेक्टर सेटअप लक्षणीयरीत्या सुलभ करते. ग्रीनफिल्ड उपयोजन किंवा सध्याचे ADCS इन्फ्रास्ट्रक्चर नसलेल्या संस्थांसाठी, हा शिफारस केलेला मार्ग आहे. हे macOS आणि iOS डिव्हाइसेससाठी कार्य करते का? होय. Intune हे Windows, iOS, iPadOS, Android आणि macOS साठी प्रमाणपत्र प्रोफाइलचे समर्थन करते. प्रोफाइल प्रकार आणि कॉन्फिगरेशन पर्याय प्लॅटफॉर्मनुसार थोडे वेगळे असतात, परंतु मुख्य आर्किटेक्चर - trusted root, क्लायंट प्रमाणपत्र, WiFi प्रोफाइल - सुसंगत असते. BYOD प्रोग्राममधील वैयक्तिक डिव्हाइसेसचे काय? SCEP येथे तुमचा मित्र आहे. Intune च्या डिव्हाइस अनुपालन धोरणांसह, प्रमाणपत्र जारी करण्यापूर्वी डिव्हाइसने किमान सुरक्षा मानके पूर्ण करणे तुम्ही आवश्यक करू शकता. डिव्हाइस अनुपालनातून बाहेर पडल्यास - स्क्रीन लॉक नसणे, जुनी OS - प्रमाणपत्र रद्द केले जाऊ शकते आणि नेटवर्क प्रवेश स्वयंचलितपणे काढून टाकला जाऊ शकतो. Purple या आर्किटेक्चरसह समाकलित होऊ शकते का? नक्कीच. Purple चे प्लॅटफॉर्म अतिथी नेटवर्कच्या बाजूला असते, जे captive portal ऑथेंटिकेशन, संमती व्यवस्थापन आणि ॲनालिटिक्स हाताळते. कॉर्पोरेट 802.1X नेटवर्क आणि Purple चे अतिथी WiFi समांतर चालतात - समान भौतिक पायाभूत सुविधा, भिन्न SSIDs आणि VLANs - जे तुम्हाला कर्मचारी कनेक्टिव्हिटी आणि अभ्यागत सहभाग यामध्ये पूर्ण वेगळेपण देते. [सारांश आणि पुढील पावले - अंदाजे १ मिनिट] थोडक्यात सांगायचे तर: Intune द्वारे WiFi प्रमाणपत्रे उपयोजित करणे ही पाच-चरण प्रक्रिया आहे - CA कॉन्फिगरेशन, trusted root उपयोजन, क्लायंट प्रमाणपत्र प्रोफाइल, WiFi प्रोफाइल आणि गट असाइनमेंट. BYOD आणि उच्च-सुरक्षा वातावरणासाठी SCEP निवडा; सोप्या कॉर्पोरेट मालकीच्या ताफ्यांसाठी PKCS निवडा. क्रम योग्य ठेवा, NPS प्रमाणपत्र मॅपिंगची आवश्यकता हाताळा आणि पहिल्या दिवसापासून प्रमाणपत्र रद्द करण्याचे वर्कफ्लो तयार करा. व्यवसायाचे उद्दिष्ट अगदी स्पष्ट आहे: तुम्ही सामायिक केलेले WiFi पासवर्ड काढून टाकता, तुम्हाला प्रति-डिव्हाइस आणि प्रति-वापरकर्ता ऑथेंटिकेशन लॉग मिळतात, तुम्ही PCI-DSS आणि ISO 27001 वायरलेस सुरक्षा आवश्यकता पूर्ण करता आणि तुम्ही मोठ्या मालमत्तेमध्ये WiFi क्रेडेन्शियल्स व्यवस्थापित करण्याचा IT ओव्हरहेड कमी करता.तुम्ही उपयोजनाचे (deployment) नियोजन करत असल्यास आणि Purple चे गेस्ट WiFi आणि ॲनालिटिक्स प्लॅटफॉर्म तुमच्या कॉर्पोरेट नेटवर्क आर्किटेक्चरसह कसे सुसंगत बसते हे समजून घ्यायचे असल्यास, purple.ai ला भेट द्या. आमच्याकडे Azure Entra ID इंटिग्रेशन, 802.1X आर्किटेक्चर आणि हॉस्पिटॅलिटी, रिटेल आणि सार्वजनिक-क्षेत्रातील वातावरणासाठी गेस्ट नेटवर्क डिझाइनबद्दल तपशीलवार मार्गदर्शक आहेत. ऐकल्याबद्दल धन्यवाद. पुढील वेळेपर्यंत.