WiFi साठी Microsoft Cloud PKI: Intune आणि Microsoft Entra ID सोबत EAP-TLS सर्टिफिकेट उपयोजन

होय. Microsoft Cloud PKI, Intune Suite मधील होस्ट केलेले प्रमाणपत्र प्राधिकृत संस्था (certificate authority), Intune द्वारे व्यवस्थापित उपकरणांना EAP-TLS WiFi प्रमाणपत्रे जारी करते. SCEP प्रमाणपत्र प्रोफाइल थेट त्यांची विनंती करते, ज्यामुळे तुम्हाला कोणत्याही NDES सर्व्हर, प्रमाणपत्र कनेक्टर किंवा ऑन-प्रिमाइसेस CA ची आवश्यकता नसते. तुमचा RADIUS सर्व्हर इंपोर्ट केलेल्या Cloud PKI रूटवर विश्वास ठेवतो आणि सेवा प्रकाशित करत असलेल्या CRL विरुद्ध प्रत्येक प्रमाणपत्राची तपासणी करतो.

Microsoft Cloud PKI WiFi ऑथेंटिकेशनसाठी काय करते?

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) ही 802.1X पद्धत आहे ज्यामध्ये दोन्ही बाजू प्रमाnature प्रमाणपत्रांसह त्यांची ओळख सिद्ध करतात. IEEE 802.1X हे WPA2-Enterprise आणि WPA3-Enterprise मागे असलेले पोर्ट-आधारित ॲक्सेस कंट्रोल मानक आहे. ॲक्सेस पॉइंट प्रत्येक कनेक्शन प्रकरणाची विनंती RADIUS सर्व्हरकडे पाठवतो, जो ऑथेंटिकेशन सर्व्हर डिव्हाइस स्वीकारतो किंवा नाकारतो. EAP-TLS सह फिशिंग करण्यासाठी कोणताही पासवर्ड नसतो आणि लीक होण्यासाठी कोणतीही शेअर केलेली की नसते. प्रत्येक डिव्हाइसची स्वतःची खाजगी की आणि प्रमाणपत्र असते.

यामागील सर्वात कठीण भाग नेहमीच PKI (पब्लिक की इन्फ्रास्ट्रक्चर) राहिला आहे. Intune द्वारे व्यवस्थापित डिव्हाइसेसवर प्रमाणपत्रे मिळवण्यासाठी पारंपारिकपणे चार गोष्टींची आवश्यकता होती:

• एक Active Directory Certificate Services (AD CS) जारी करणारी CA
• एक NDES (Network Device Enrollment Service) सर्व्हर
• Intune प्रमाणपत्र कनेक्टर
• इंटरनेटवर NDES प्रकाशित करण्यासाठी रिव्हर्स प्रॉक्सी किंवा Microsoft Entra ॲप्लिकेशन प्रॉक्सी

यातील प्रत्येकाला पॅचिंग, बॅकअप आणि मॉनिटरिंगची गरज असते.

Microsoft Cloud PKI तुमच्या Intune टेनंटमध्ये होस्ट केलेल्या प्रमाणपत्र प्राधिकृत संस्थेने हा स्टॅक बदलतो. डिव्हाइसेस SCEP (Simple Certificate Enrollment Protocol) द्वारे प्रमाणपत्रांची विनंती करतात आणि Cloud PKI स्वतः त्या विनंत्यांना प्रतिसाद देते. हे Intune विरुद्ध प्रत्येक विनंतीचे व्हॅलिडेशन करते, प्रमाणपत्रावर सही करते आणि ते परत करते. डिव्हाइस स्थानिक पातळीवर त्याची खाजगी की तयार करते आणि की कधीही ते सोडून जात नाही.

Entra ID शी जोडलेल्या डिव्हाइसेससाठी, हे प्रमाणपत्र साखळीतील शेवटचे ऑन-प्रिमाइसेस अवलंबित्व काढून टाकते. ज्या डिव्हाइसेसनी कधीही डोमेन कंट्रोलर पाहिला नाही, ते देखील WiFi प्रमाणपत्र मिळवू शकतात.

Cloud PKI CA हायराकी कशी कार्य करते

Cloud PKI दोन-स्तरीय हायराकी वापरते. एक रूट CA एक किंवा अधिक जारी करणाऱ्या CA वर सही करतो आणि जारी करणारी CA डिव्हाइस प्रमाणपत्रांवर सही करते. Microsoft CA स्वाक्षरी की हार्डवेअर सिक्युरिटी मॉड्युल्स (HSMs) मध्ये ठेवते, त्यामुळे तुम्हाला कधीही की मटेरियल व्यवस्थापित करावे लागत नाही.

तुम्ही दोन अँकरपैकी एक निवडू शकता:

• Cloud PKI रूट. Microsoft तुमच्या टेनंटमध्ये रूट आणि जारी करणारी CA दोन्ही होस्ट करते. ग्रीनफील्ड Entra ID इस्टेटसाठी हा सर्वात सोपा पर्याय आहे.
• Bring your own CA (BYOCA). तुम्ही Cloud PKI जारी करणारी CA तयार करता, तिची प्रमाणपत्र स्वाक्षरी विनंती डाउनलोड करता आणि त्यावर तुमच्या विद्यमान खाजगी रूटसह सही करता, जसे की AD CS रूट. त्या रूटवर आधीपासून विश्वास ठेवणारी कोणतीही गोष्ट नवीन जारी करणाऱ्या CA च्या साखळीवर विश्वास ठेवते.

तुम्ही जेव्हा प्रत्येक CA तयार करता तेव्हा विस्तारित की वापरा (EKUs) सेट करता. WiFi क्लायंट प्रमाणपत्रांना Client Authentication EKU ची आवश्यकता असते, त्यामुळे ते दोन्ही टप्प्यांवर समाविष्ट करा. हे काळजीपूर्वक प्लॅन करा, कारण CA तयार केल्यावर EKUs स्थिर असतात.

रचनेसाठी एक सीमा महत्त्वाची आहे. Cloud PKI SCEP द्वारे Intune-व्यवस्थापित उपकरणांना प्रमाणपत्रे जारी करते. हे तुमच्या RADIUS सर्व्हरचे स्वतःचे प्रमाणपत्र जारी करण्यासाठी तयार केलेले नाही, त्यामुळे ते प्रमाणपत्र सामान्यतः सार्वजनिक CA किंवा तुमच्या विद्यमान PKI कडून येते.

Cloud PKI ची NDES आणि PKCS सह SCEP शी तुलना कशी होते

	Cloud PKI (SCEP)	NDES सह SCEP	PKCS
CA होस्टिंग	तुमच्या Intune भाडेकरूमध्ये Microsoft-होस्ट केलेले	तुमचे AD CS किंवा तृतीय-पक्ष CA	तुमचे AD CS किंवा तृतीय-पक्ष CA
ऑन-प्रिमाइसेस सर्व्हर्स	काहीही नाही	Issuing CA, NDES सर्व्हर, कनेक्टर होस्ट	Issuing CA, कनेक्टर होस्ट
इंटरनेट-प्रकाशित घटक	काहीही नाही	NDES, रिव्हर्स प्रॉक्सी किंवा ॲप्लिकेशन प्रॉक्सीद्वारे	काहीही नाही
खाजगी की कुठे जनरेट केली जाते	डिव्हाइसवर	डिव्हाइसवर	CA बाजूला, डिव्हाइसला PFX म्हणून वितरित केली जाते
केवळ Entra ID साठी उपयुक्त	नेटिव्ह	कार्य करते, परंतु ऑन-प्रिमाइसेस अवलंबित्व ठेवते	कार्य करते, परंतु ऑन-प्रिमाइसेस अवलंबित्व ठेवते
रद्द करणे	Intune ॲडमिन सेंटरमध्ये रद्द करा, CRL द्वारे प्रकाशित केले	कनेक्टर आणि तुमच्या CA च्या CRL द्वारे	कनेक्टर आणि तुमच्या CA च्या CRL द्वारे
परवाना मॉडेल	Intune Suite किंवा Cloud PKI ॲड-ऑन, प्रति सीट	Windows Server परवाने अधिक Intune	Windows Server परवाने अधिक Intune
हे कोणासाठी योग्य आहे	क्लाउड-फर्स्ट इस्टेट जे ऑन-प्रिमाइसेस PKI निवृत्त करत आहेत	परिपक्व AD CS टीम आणि लांब CA रोडमॅप असलेल्या इस्टेट्स	S/MIME सारख्या एकापेक्षा जास्त प्लॅटफॉर्मवर समान की आवश्यक असलेल्या केसेस

SCEP आणि PKCS सह Intune प्रमाणपत्र उपयोजनाची आमची स्वतंत्र मार्गदर्शिका दोन ऑन-प्रिमाइसेस मार्गांना सखोलपणे कव्हर करते.

EAP-TLS साठी Cloud PKI उपयोगात आणण्यापूर्वी तुम्हाला कशाची गरज आहे?

तुम्ही काहीही तयार करण्यापूर्वी या सहा गोष्टी तपासा. प्रत्येक गोष्ट खालील ट्रबलशूटिंग विभागातील अपयशाशी जोडलेली आहे.

• परवाना. Intune Plan 1 सबस्क्रिप्शन अधिक Microsoft Intune Suite किंवा स्वतंत्र Cloud PKI ॲड-ऑन.
• परवानग्या. Intune Administrator भूमिका, किंवा Cloud PKI परवानग्यांसह कस्टम भूमिका.
• नोंदणीकृत साधने. Intune मध्ये नोंदणीकृत Windows, macOS, iOS/iPadOS किंवा Android साधने, जी Microsoft Entra ID सुरक्षा गटांमध्ये गटबद्ध आहेत.
• EAP-TLS-सक्षम RADIUS सर्व्हर. हे तुम्हाला CA प्रमाणपत्रे आयात करण्यास, HTTP वर Cloud PKI CRL पर्यंत पोहोचण्यास आणि Entra ID वस्तूंवर प्रमाणपत्र ओळख मॅप करण्यास अनुमती देणारे असणे आवश्यक आहे. Microsoft NPS (नेटवर्क पॉलिसी सर्व्हर) ऑन-प्रिमाइसेस Active Directory मध्ये खाती शोधते, त्यामुळे केवळ-क्लाउड साधने तिथे अयशस्वी होतात.
• RADIUS सर्व्हर प्रमाणपत्र. तुम्हाला रूट आणि ते जारी करणारी कोणतीही मध्यम प्रमाणपत्रे देखील आवश्यक आहेत, कारण उपकरणांनी सर्व्हर प्रमाणित केला पाहिजे.
• 802.1X-सक्षम ॲक्सेस पॉइंट्स. यांनी तुमच्या RADIUS सर्व्हरकडे निर्देश केलेला WPA2-Enterprise किंवा WPA3-Enterprise SSID ब्रॉडकास्ट केला पाहिजे.॥- ँक्सेस पुंईट (Access Point) च्या बाजूने, प्रत्येक मुख्य प्लूटफॉर्भ 802.1X ला सपोर्ट करतो. त्यात Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणी Fortinet यांचा समावेश आहे. वेंडर-विशिष्ट मार्गदर्शनासाठी, Configuring 802.1X on Juniper Mist with cloud RADIUS पाहा.

WiFi साठी Cloud PKI प्रमाणपत्रे कसी सेटअप करावीत?

खालील क्रम सेटअपचा सारांश देतो. सद्याच्या स्क्रीन्स आणी फील्ड-बाय-फील्ड पाल्यांसाठी Microsoft Learn वरील Microsoft च्या Cloud PKI दस्तैवजीकरणाचा वापर करा, कारंण प्रत्येक रिलीजमध्ये अडमिन सेंटरचा लेआऊट बदलतो.

ठीक १: Root CA तयार करा किंवा आपले स्वतःचे आणा

Intune admin सेंटरमध्ये, tenant administration अंतर्गत root CA तयार करा. Key size, validity period आणी Client Authentication सह EKUs निवडा.

BYOCA साठी, root स्किप करा. BYOCA प्रकार म्हणून issuing CA तयार करा आणी त्याची certificate signing request इक्सपोर्ट करा. Client Authentication समाविष्ट असलेल्या टेम्प्लेटचा वापर करून आपल्या मालकीच्या CA वर या request वर साइन करा, नंतर साइन केलेले प्रमाणपत्र आणी त्याची chain अपलोड करा.

ठीक २: Issuing CA तयार करा

पहिल्या प्रक्रियेतील root ला ँंकर केलेले issuing CA तयार करा. त्याच्या EKUs मध्ये Client Authentication समाविष्ट असणे आवश्यक आहे. एकदा तयार झाल्यावर, त्याचे properties पेज तुम्हाला नंतर लागणार्या तीन गोष्टी दाखवते:

• SCEP URI
• CA प्रमाणपत्र डाउनलोड
• CRL distribution point

ठीक ॡ: Trusted Certificate Profiles डिप्लॉय करा

Root आणी issuing CA प्रमाणपत्रे डाउनलोड करा. प्रत्येक प्लूटफॉर्मनुसार, प्रत्येकासाठी एक trusted certificate profile तयार करा. त्यांना SCEP आणी WiFi Profiles प्राप्त करणार्या त्याच ग्रुप्सना असाइन करा.

SCEP profile यशस्वी होण्यापूर्वी ड्रिव्हाइसेसना या chain ची गरज असते. जर ड्रिव्हाइसेसंनी आठीच त्याच्यावर विश्वास ठेवला नसेल, तर तुमच्या RADIUS सर्वल प्रमाणपत्र जारी करणार्या CA साठी आणखी एक trusted certificate profile तयार करा.

ठीक ४: SCEP Certificate Profile तयार करा

प्रत्येक प्लूटफॉर्मनुसार SCEP certificate profile तयार करा आणी त्याला Cloud PKI कडे पॉइंट करा. येथे मुख्य निर्णय दिले आहेत:

• SCEP server URL. Issuing CA मधून SCEP URI अगदी दाखवल्याप्रमाणे पेस्ट करा. त्याचा placeholder text अनएडिटेड ठेवा, कारंण Intune इष्यूअन्सनुसार त्याला resolve करते.
• Root certificate. Issuing CA नव्हे, तर Cloud PKI root साठी trusted certificate profile निवडा.
• Certificate type. फ्रंट-डेस्क टॅबलेट्स किंवा स्टोंर हँन्डहेल्ड्स यांच्यासारख्या शेअर्ड ड्रिव्हाइसेससाठी Device Certificates निवडा. जेथे स्टाफ स्वतःचा लॅपटॉप वापरतात आणी तुम्हाला व्यक्तीशी जोडलेली policy हवी असेल, तेथे Per-person Certificates निवडा.
• Subject आणी subject alternative name (SAN). तुमचा RADIUS सर्वर Microsoft Entra ID ला map करू शकेल असा identifier समाविष्ट करा. उदाहरणार्थ Entra device ID variable {{AAD_Device_ID}} किंवा UPN variable {{UserPrincipalName}}.
• Key usage आणी EKU. Client Authentication सह Digital signature आणी Key encipherment सेट करा.
• Windows वरील Key storage. TPM (Trusted Platform Module) key storage provider मध्ये enrol करा, ज्यामुले private key ही hardware-bound आणी non-exportable राहील.
• नूतनीकरण मर्यादा. आयुष्यमान शिल्लक राहण्याची टक्केवारी सेट करा ज्यावर Intune नूतनीकरण करेल, जेणेकरून प्रमाणपत्रे कधीही लक्ष न देता संपणार नाहीत.

पायरी 5: RADIUS सर्व्हरला Cloud PKI वर विश्वास ठेवण्यास सक्षम करा

Cloud PKI रूट आणि इश्यूइंग CA प्रमाणपत्रे दोन्ही तुमच्या RADIUS सर्व्हरच्या विश्वासू CA स्टोअरमध्ये इंपोर्ट करा. फक्त रूट इंपोर्ट करणे हे "अज्ञात CA" नाकारण्याचे सर्वात सामान्य कारण आहे.

CRL तपासणी सक्षम करा आणि RADIUS सर्व्हरला प्रत्येक प्रमाणपत्रामध्ये सूचीबद्ध केलेल्या CRL वितरण बिंदूवर आऊटबाउंड HTTP प्रवेशास अनुमती द्या. BYOCA सह, RADIUS सर्व्हर आधीच तुमच्या रूटवर विश्वास ठेवू शकतो, त्यामुळे तुम्ही फक्त नवीन इश्यूइंग CA प्रमाणपत्र जोडता.

जर Purple चे क्लाउड RADIUS तुमच्या कर्मचारी WiFi चे ऑथेंटिकेशन करत असेल, तर तुमच्या भाडेकरूसाठी (tenant) Cloud PKI साखळी कशी लोड केली जाते याची पुष्टी तुमची Purple खाते टीम करेल.

पायरी 6: WiFi प्रोफाईल तयार करा

एंटरप्राइज सुरक्षा आणि EAP प्रकार म्हणून EAP-TLS सह Intune WiFi प्रोफाईल तयार करा. तीन फील्ड सेट करा:

• क्लायंट ऑथेंटिकेशन प्रमाणपत्र. पायरी 4 मधील SCEP प्रोफाईल निवडा.
• सर्व्हर व्हॅलिडेशनसाठी रूट प्रमाणपत्रे. तुमच्या RADIUS सर्व्हरच्या इश्यूइंग रूटसाठी विश्वासू प्रमाणपत्र प्रोफाईल निवडा.
• प्रमाणपत्र सर्व्हर नावे. RADIUS सर्व्हर प्रमाणपत्राशी तंतोतंत जुळणारी नावे प्रविष्ट करा.

SCEP आणि विश्वासू प्रमाणपत्र प्रोफाईलप्रमाणेच हे प्रोफाईल त्याच गटांना नियुक्त करा.

Cloud PKI सह रिव्होकेशन (रद्दीकरण) कसे कार्य करते?

तुम्ही Intune ॲडमिन सेंटरमधील इश्यूइंग CA कडून Cloud PKI प्रमाणपत्रे रद्द करता. जारी केलेल्या प्रमाणपत्रांची सूची उघडा, डिव्हाइसचे प्रमाणपत्र निवडा आणि ते रद्द करा. Cloud PKI नंतर हा बदल त्याच्या CRL (प्रमाणपत्र रद्दीकरण सूची) वर प्रकाशित करते, जे त्याने जारी केलेल्या प्रत्येक प्रमाणपत्रात एम्बेड केलेल्या HTTP वितरण बिंदूवर असते.

तुमचा RADIUS सर्व्हर रिव्होकेशन लागू करतो, Intune नाही. ते CRL डाउनलोड करते आणि ज्याचा अनुक्रमांक त्यावर दिसतो ते कोणतेही प्रमाणपत्र नाकारते.

बहुतेक RADIUS सर्व्हर पुढील-अपडेट वेळेपर्यंत CRL कॅशे करतात. त्यामुळे रद्द केलेले डिव्हाइस RADIUS सर्व्हरने नवीन सूची मिळेपर्यंत कनेक्ट होत राहू शकते. तो वेळ तीन प्रकारे कमी करा:

1. स्पष्टपणे रद्द करा. प्रोफाईल असाइनमेंट काढून टाकण्यावर किंवा डिव्हाइस रेकॉर्ड हटवण्यावर अवलंबून राहू नका. तुमच्या जॉइनर्स, मुव्हर्स, लीव्हर्स (JML) प्रक्रियेचा भाग म्हणून प्रमाणपत्र स्वतःच रद्द करा.
2. आयडेंटिटी तपासणीसह रिव्होकेशन जोडा. जर तुमची RADIUS सेवा प्रत्येक ऑथेंटिकेशनवर Microsoft Entra ID खाते किंवा डिव्हाइस स्थिती तपासत असेल, तर खाते अक्षम केल्याने CRL रिफ्रेश होण्यापूर्वी प्रवेश ब्लॉक होतो.
3. CRL पुनर्प्राप्तीवर लक्ष ठेवा. अयशस्वी CRL डाउनलोडवर अलर्ट मिळवा. जुने CRL धरून ठेवणारा RADIUS सर्व्हर त्याच्या अपयश धोरणावर अवलंबून एकतर रद्द केलेली डिव्हाइस समाविष्ट करत राहतो किंवा प्रत्येक डिव्हाइस नाकारतो.

तुम्ही Cloud PKI WiFi ऑथेंटिकेशन कसे कार्य करते ते कसे तपासाल?

तुम्ही सपोर्ट करत असलेल्या प्रत्येक प्लॅटफॉर्मवर पाच ते 10 डिव्हाइसेसच्या चाचणी गटासह पायलट रन करा. पाच गोष्टींची पुष्टी करा:

1. प्रोफाईल स्थिती. विश्वासू प्रमाणपत्र, SCEP आणि WiFi प्रोफाईल हे सर्व Intune डिव्हाइस कॉन्फिगरेशन रिपोर्टिंगमध्ये यश नोंदवतात.
2. डिव्हाइसवरील सर्टिफिकेट. Windows वर, सर्टिफिकेट अपेक्षित विषयासह, SAN आणि Client Authentication EKU सोबत वैयक्तिक स्टोअरमध्ये दिसते. त्याची साखळी Cloud PKI रूटपर्यंत तयार झाली पाहिजे.
3. इश्युअन्स रेकॉर्ड. Intune ॲडमिन सेंटरमध्ये जारी करणाऱ्या CA च्या जारी केलेल्या सर्टिफिकेट्सच्या सूचीमध्ये सर्टिफिकेट दिसते.
4. RADIUS लॉग्स. ऑथेंटिकेशन लॉग EAP-TLS यश, अपेक्षित ओळख आणि वैध साखळी दर्शवतो.
5. रिव्होकेशन टेस्ट. एक चाचणी सर्टिफिकेट रद्द करा. एकदा RADIUS सर्व्हर नवीन CRL उचलून घेतल्यानंतर, डिव्हाइस नाकारले गेल्याची पुष्टी करा.

तुम्ही लाइव्ह जाण्यापूर्वी रिव्होकेशन टेस्ट चालवा. ही एकमेव अशी तपासणी आहे जी सिद्ध करते की तुमचा RADIUS सर्व्हर CRL पर्यंत पोहोचू शकतो.

Cloud PKI EAP-TLS मध्ये काय चुकीचे घडते, आणि तुम्ही ते कसे दुरुस्त करता?

लक्षण	संभाव्य कारण	उपाय
SCEP प्रोफाईल त्रुटीमध्ये किंवा प्रलंबित स्थितीत अडकली आहे	ट्रस्टेड सर्टिफिकेट प्रोफाईल एकाच ग्रुपला नियुक्त केलेल्या नाहीत, किंवा SCEP प्रोफाईल रूट ऐवजी जारी करणाऱ्या CA चा संदर्भ देते	रूट आणि इश्युइंग ट्रस्टेड प्रोफाईल्स एकाच ग्रुप्सना नियुक्त करा, आणि SCEP प्रोफाईलमध्ये रूट निवडा
सर्टिफिकेट जारी केले, RADIUS "unknown CA" सह नाकारते	RADIUS मध्ये फक्त रूट इंपोर्ट केले आहे	इश्युइंग CA सर्टिफिकेट देखील इंपोर्ट करा
लाइव्ह झाल्यानंतर प्रत्येक डिव्हाइस नाकारले जाते	RADIUS CRL वितरण बिंदूपर्यंत पोहोचू शकत नाही आणि क्लोज्ड अयशस्वी होते	RADIUS कडून CRL होस्टला आउटबाउंड HTTP अनुमती द्या
Android डिव्हाइसेस कनेक्ट होण्यास नकार देतात	कोणताही सर्व्हर व्हॅलिडेशन सेट केलेला नाही; Android 11 आणि नंतरच्या आवृत्त्यांना त्याची आवश्यकता असते	RADIUS सर्व्हरचे रूट ट्रस्टेड प्रोफाईल म्हणून तैनात करा आणि सर्टिफिकेट सर्व्हरची नावे सेट करा
Windows कर्मचाऱ्यांना सर्व्हरवर विश्वास ठेवण्यास सांगते	WiFi प्रोफाईलमधील सर्व्हरची नावे RADIUS सर्टिफिकेटशी जुळत नाहीत	सर्टिफिकेटशी तंतोतंत जुळण्यासाठी सर्व्हरची नावे दुरुस्त करा
NPS Entra ID-joined डिव्हाइसेस नाकारते	NPS ऑन-प्रीमिसस Active Directory अकाउंट शोधते जे अस्तित्वात नाही	RADIUS सेवा वापरा जी सर्टिफिकेट्स Entra ID ऑब्जेक्ट्सशी मॅप करते
रद्द केलेले डिव्हाइस तरीही कनेक्ट होते	RADIUS कॅश केलेले CRL धारण करत आहे	Entra ID अकाउंट किंवा डिव्हाइस डिसेबलसह रिव्होकेशन जोडा, आणि CRL कॅशिंगचे पुनरावलोकन करा
सर्टिफिकेटमध्ये Client Authentication नाही	इश्युइंग CA त्या EKU शिवाय तयार केले गेले	Client Authentication सह नवीन इश्युइंग CA तयार करा आणि SCEP प्रोफाईल पुन्हा पॉइंट करा

जर तेच डिव्हाइसेस इतरत्र ऑथेंटिकेट होत असताना विशिष्ट खोल्यांमध्ये किंवा मजल्यांवर अपयश येत असेल, तर दोष रेडिओ कव्हरेजचा आहे, PKI चा नाही. EAP-TLS प्री-शेअर केलेल्या की हँडशेकपेक्षा जास्त पॅकेट्सची देवाणघेवाण करते, त्यामुळे सीमांत सिग्नल टाइमआउट्स म्हणून दिसतो. WiFi Site Surveys: A Practical Planning Guide त्या दऱ्या कशा शोधायच्या ते कव्हर करते.

Cloud PKI किंवा NDES सह SCEP: तुम्ही कोणते निवडले पाहिजे?

तुम्ही आधीच काय चालवत आहात आणि काय बंद करण्याचा तुमचा विचार आहे यावर निर्णय आधारित ठेवा.

तुमची परिस्थिती	शिफारस	का
Entra ID-joined ताफा, AD CS नाही	Cloud PKI रूटसह Cloud PKI	तयार करण्यासाठी किंवा चालवण्यासाठी कोणताही ऑन-प्रीमिसस PKI नाही
AD CS जागेवर आहे, NDES सर्व्हर्सचे OS रिफ्रेश बाकी आहे	BYOCA सह Cloud PKI	तुमचा विद्यमान रूट ट्रस्ट राखून ठेवते आणि NDES व कनेक्टर निवृत्त करते
दीर्घकालीन CA रोडमॅप आणि इतर प्रमाणपत्र टेम्पलेट्स असलेली AD CS टीम	NDES सह SCEP, पुढील सर्व्हर रिफ्रेश वेळी पुनरावलोकन करा	विद्यमान गुंतवणूक आधीच बिगर-WiFi वापर प्रकरणांचा अंतर्भाव करते
S/MIME सारख्या अनेक उपकरणांवर समान की जोड आवश्यक आहे	त्या वापर प्रकरणासाठी PKCS, WiFi साठी Cloud PKI	PKCS एक्सपोर्ट करण्यायोग्य की वितरित करते; WiFi प्रमाणपत्रे डिव्हाइस-बाउंड राहिली पाहिजेत
NPS वर आज हायब्रिड-जॉईन असलेली उपकरणे, Entra ID जॉईनकडे हलवली जात आहेत	Cloud PKI अधिक क्लाउड RADIUS सेवा	उपकरणे Active Directory सोडल्यानंतर NPS लुकअप्स बंद पडतात

Healthcare मधील नियमन केलेल्या मालमत्ता इतर वर्कलोड्ससाठी अनेकदा AD CS ठेवतात. त्यांच्यासाठी, BYOCA हे सहसा योग्य ठरते, कारण ते संपूर्ण संस्थेत एकच रूट ऑफ ट्रस्ट ठेवते. Trains वर ऑनबोर्ड कर्मचाऱ्यांच्या टॅब्लेटवर प्रमाणपत्रे जारी करणारे रेल्वे ऑपरेटर Cloud PKI रूट मार्गाचा वापर करतात. ती उपकरणे पहिल्या दिवसापासून क्लाउड-व्यवस्थापित असतात.

Cloud PKI चा खर्च किती आहे आणि तुम्हाला त्यातून काय परत मिळते?

Microsoft Cloud PKI चा परवाना प्रति सीट, प्रति महिना दरानुसार देते. हे एकतर Intune Suite मध्ये किंवा Intune Plan 1 च्या वर एक स्वतंत्र ॲड-ऑन म्हणून येते. बंडलिंग बदलत असल्यामुळे Microsoft ची सध्याची किंमत सूची तपासा.

ऑन-प्रीमिसिस मार्गासाठी तुम्हाला येणाऱ्या खर्चाशी याची तुलना करा:

• इश्यूइंग CA, NDES आणि कनेक्टर होस्टसाठी Windows Server परवाने आणि व्हर्च्युअल मशिन्स
• NDES प्रकाशित करणारा रिव्हर्स प्रॉक्सी किंवा ॲप्लिकेशन प्रॉक्सी
• CA डेटाबेस बॅकअप्स
• पॅचिंग आणि सर्टिफिकेट टेम्पलेट प्रशासन

याचा परतावा म्हणजे कमी सर्व्हर्स, इंटरनेटवर प्रकाशित नसलेला NDES एंडपॉइंट आणि तुम्ही व्यवस्थापित करत असलेल्या प्रत्येक प्लॅटफॉर्मवर डिव्हाइस-बाउंड कीज.

वर्क केलेले उदाहरण: 30-प्रॉपर्टी असलेले हॉटेल ग्रुप

परिस्थिती. 30 hotels च्या एका समुहाने एका सामायिक प्री-शेअर की सह सुरक्षित केलेल्या स्टाफ SSID वर 900 Entra ID-जॉईन केलेले लॅपटॉप आणि फ्रंट-डेस्क टॅब्लेट चालवले. प्रत्येक तिमाहीत ती की फिरवणे म्हणजे प्रत्येक प्रॉपर्टीमधील प्रत्येक उपकरणाला स्पर्श करणे होते. हरवलेला टॅब्लेट पुढील रोटेशनपर्यंत की उघडी पाडत असे.

काय केले गेले. IT ने Cloud PKI रूट आणि इश्यूइंग CA तयार केले, त्यानंतर SCEP द्वारे TPM-बॅक्ड डिव्हाइस प्रमाणपत्रे जारी केली. क्लाउड RADIUS सेवेने साखळी प्रमाणित केली आणि CRL तपासले. या समूहाने पायलटसाठी जुन्या सोबत EAP-TLS SSID चालवले, प्रॉपर्टीज टप्प्याटप्प्याने हलवल्या आणि नंतर प्री-शेअर की नेटवर्क बंद केले.

निकाल. या परिस्थितीचे गणित स्पष्ट आहे:

• कर्मचाऱ्यांच्या नेटवर्कवरील सामायिक रहस्ये एकवरून शून्यावर येतात.
• 30 प्रॉपर्टीजमधील त्रैमासिक की रोटेशन पूर्णपणे थांबते.
• हरवलेला टॅब्लेट म्हणजे 900 उपकरणांच्या रि-की ऐवजी एक प्रमाणपत्र रद्द करणे बनते.
• कोणत्याही ऑन-प्रीमिसिस CA, NDES सर्व्हर किंवा कनेक्टरची आवश्यकता नाही.

वर्क केलेले उदाहरण: 250-स्टोअर रिटेल साखळी

परिस्थिती. एका रिटेल साखळीने AD CS आणि दोन NDES सर्व्हर्सद्वारे 4,000 स्टोअर हँडहेल्ड्स आणि लॅपटॉप्सना WiFi प्रमाणपत्रे जारी केली होती. Intune Certificate Connector तिसऱ्या सर्व्हरवर चालत होता. तिन्ही सर्व्हर्सच्या ऑपरेटिंग सिस्टम बदलण्याची वेळ आली होती, आणि NDES हे ॲप्लिकेशन प्रॉक्सीद्वारे प्रकाशित केले गेले होते.

काय केले गेले. टीमने BYOCA म्हणून Cloud PKI इश्यूइंग CA तयार केले आणि त्यावर विद्यमान AD CS रूटने स्वाक्षरी केली. RADIUS सर्व्हर आधीच त्या रूटवर विश्वास ठेवत होता, त्यामुळे फक्त नवीन इश्यूइंग CA प्रमाणपत्र इंपोर्ट केले गेले. SCEP प्रोफाईल्स एका वेळी एका स्टोअर ग्रुपमध्ये Cloud PKI कडे हलवले गेले. नूतनीकरणापर्यंत विद्यमान प्रमाणपत्रे वैध राहिली, ज्यामुळे रोलबॅक सुरक्षित राहिला.

निकाल. साखळीने तीन सर्व्हर्स बंद केले: दोन NDES आणि एक कनेक्टर होस्ट. इंटरनेट-प्रकाशित NDES एंडपॉइंट देखील काढून टाकला. RADIUS वर किंवा कोणत्याही डिव्हाइसवर रूट पुन्हा-ट्रस्ट करण्याची गरज पडली नाही. इतर वर्कलोड्ससाठी AD CS रूट तसाच राहिला.

Purple कुठे बसते

Purple Staff WiFi हे Microsoft Entra ID, Okta किंवा Google Workspace शी कनेक्ट केलेल्या क्लाउड RADIUS सह आयडेंटिटी-बेस्ड नेटवर्कचा वापर करते. Purple हे Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet या सर्वांवर हार्डवेअर-अग्नोस्टिक आहे. तुमच्या पुढील WiFi अपग्रेडला नवीन हार्डवेअरची गरज का नाही यामध्ये हे स्पष्ट केले आहे की प्रमाणपत्र-आधारित स्टाफ ॲक्सेसवर शिफ्ट होणे म्हणजे ॲक्सेस पॉइंट्स बदलणे असे का नसते.

Purple 80,000+ लाईव्ह व्हेन्यूंवर (Purple डेटा) 99.999% अपटाईमसह चालते, आणि ISO 27001 प्रमाणित आहे. कर्मचारी आणि अभ्यागत यांना वेगवेगळ्या नेटवर्कवर ठेवा: तुम्ही व्यवस्थापित करता त्या डिव्हाइसेससाठी प्रमाणपत्र-आधारित Staff WiFi, आणि इतर सर्वांसाठी Guest WiFi.

वारंवार विचारले जाणारे प्रश्न

Microsoft Cloud PKI WiFi प्रमाणपत्रे जारी करू शकते का?

होय. Cloud PKI हे SCEP सर्टिफिकेट प्रोफाईलद्वारे Intune-व्यवस्थापित Windows, macOS, iOS/iPadOS आणि Android डिव्हाइसेसना क्लायंट ऑथेंटिकेशन प्रमाणपत्रे जारी करते. ती प्रमाणपत्रे EAP-TLS चा वापर करून WPA2-Enterprise किंवा WPA3-Enterprise नेटवर्क्सवर डिव्हाइसेसचे प्रमाणीकरण करतात. तुमच्या इश्यूइंग CA मध्ये क्लायंट ऑथेंटिकेशन EKU समाविष्ट असणे आवश्यक आहे, आणि तुमच्या RADIUS सर्व्हरने Cloud PKI रूट आणि इश्यूइंग CA वर विश्वास ठेवला पाहिजे. Cloud PKI सहसा RADIUS सर्व्हरचे स्वतःचे प्रमाणपत्र जारी करत नाही. ते प्रमाणपत्र पब्लिक्स CA किंवा तुमच्या विद्यमान PKI कडून येते.

मला अजूनही Cloud PKI सह NDES ची गरज आहे का?

नाही. Cloud PKI स्वतः SCEP विनंत्यांना उत्तरे देते, त्यामुळे तुम्हाला NDES सर्व्हर, Intune Certificate Connector आणि इंटरनेटवर NDES प्रकाशित करणाऱ्या रिव्हर्स प्रॉक्सीची गरज उरत नाही. Intune मधील SCEP प्रोफाईल थेट तुमच्या Cloud PKI इश्यूइंग CA वर दाखवलेल्या SCEP URI कडे निर्देशित करते. तुम्ही ब्रिंग-युअर-ओन-CA पर्याय वापरल्यास, तुमचे प्रायव्हेट रूट Cloud PKI इश्यूइंग CA वर एकदा स्वाक्षरी करते. त्यानंतर, डिव्हाइस एनरोलमेंट कधीही तुमच्या ऑन-प्रीमिसस सर्व्हर्सना स्पर्श करत नाही.

RADIUS सर्व्हर Cloud PKI प्रमाणपत्रांवर कसा विश्वास ठेवतो?

तुम्ही Cloud PKI रूट आणि इश्यूइंग CA प्रमाणपत्रे RADIUS सर्व्हरच्या ट्रस्टेड CA स्टोअरमध्ये इंपोर्ट करता. Intune अॅडमिन सेंटरवरून दोन्ही डाउनलोड करा. दोन्ही इंपोर्ट करा, कारण केवळ रूट इंपोर्ट केल्यास "unknown CA" अस्विकार होऊ शकतो. RADIUS सर्व्हरला प्रत्येक प्रमाणपत्रातील CRL वितरण बिंदूवर आउटबाउंड HTTP ऍक्सेस देखील आवश्यक आहे, जेणेकरून ते रिव्होकेशन तपासू शकेल. Entra ID-joined उपकरणांसाठी, त्याने ऑन-प्रीमिसस Active Directory ऐवजी Entra ID शी प्रमाणपत्र ओळख मॅप केली पाहिजे.

Cloud PKI सह रिव्होकेशन कसे कार्य करते?

तुम्ही Intune अॅडमिन सेंटरमधील इश्यूइंग CA कडून प्रमाणपत्र रिव्होक करता, आणि Cloud PKI हा बदल त्याच्या CRL वर प्रकाशित करतो. तुमचा RADIUS सर्व्हर ते CRL डाउनलोड करतो आणि रिव्होक केलेली प्रमाणपत्रे नाकारतो. RADIUS सर्व्हर CRLs कॅशे करत असल्याने, रिव्होक केलेले उपकरण पुढील रिफ्रेश होईपर्यंत कनेक्ट होऊ शकते. तुमच्या RADIUS सेवेद्वारे प्रत्येक ऑथेंटिकेशनवर ओळख स्थिती तपासली जात असल्यास, Entra ID खाते किंवा उपकरण देखील डीफॉल्टनुसार निष्क्रिय करून ते अंतर भरून काढा.

मी NDES सह Cloud PKI की SCEP निवडावे?

तुम्ही Entra ID-joined ताफा चालवत असल्यास किंवा ऑन-प्रीमिसस PKI सर्व्हर निवृत्त करण्याची योजना आखत असल्यास Cloud PKI निवडा. हे इश्यूइंग CA, NDES आणि कनेक्टर होस्ट्स काढून टाकते. तुमच्याकडे परिपक्व AD CS टीम, दीर्घकालीन CA रोडमॅप आणि इतर प्रमाणपत्र टेम्पलेट्स असल्यास NDES सह SCEP ठेवा. तुमचे NDES सर्व्हर रिफ्रेशसाठी बाकी असल्यास, BYOCA सह Cloud PKI तुमचे सध्याचे रूट ट्रस्ट ठेवते आणि तरीही NDES निवृत्त करते.

Microsoft Cloud PKI चे परवाना कसे दिले जाते?

Cloud PKI ला Intune Plan 1 वर प्रति सीट, प्रति महिना परवाना दिला जातो. हे Microsoft Intune Suite चा भाग म्हणून किंवा स्वतंत्र Cloud PKI ॲड-ऑन म्हणून येते. बजेट बनवण्यापूर्वी Microsoft ची सध्याची किंमत सूची तपासा, कारण बंडल बदलतात. Windows Server परवाने, व्हर्च्युअल मशीन्स, प्रोक्सी पब्लिशिंग आणि AD CS, NDES आणि कनेक्टर स्टॅकसाठी आवश्यक असणाऱ्या पॅचिंग प्रयत्नांच्या तुलनेत परवाना खर्चाचे मूल्यमापन करा.

मी Cloud PKI सह माझा सध्याचा ऑन-प्रीमिसस रूट CA ठेवू शकतो का?

होय, ब्रिंग-युअर-ओन-CA पर्यायाद्वारे. तुम्ही Cloud PKI इश्यूइंग CA तयार करता, त्याची प्रमाणपत्र स्वाक्षरी विनंती एक्सपोर्ट करता आणि तुमच्या सध्याच्या खाजगी रूटसह, जसे की AD CS सह त्यावर स्वाक्षरी करता. तुमच्या RADIUS सर्व्हर आणि उपकरणांसह त्या रूटवर आधीपासून विश्वास ठेवणारी कोणतीही गोष्ट नवीन साखळीवर विश्वास ठेवते. तुम्ही फक्त इश्यूइंग CA प्रमाणपत्र जोडता. सध्याची प्रमाणपत्रे नूतनीकरणापर्यंत वैध राहतात आणि तुम्ही SCEP प्रोफाइलचे गटानुसार स्थलांतर करू शकता.

Cloud PKI माझ्या सध्याच्या ऍक्सेस पॉइंट्ससह कार्य करते का?

होय, जोपर्यंत तुमचे ऍक्सेस पॉइंट्स WPA2-Enterprise किंवा WPA3-Enterprise सह 802.1X ला सपोर्ट करतात. Cloud PKI चा केवळ उपकरणांवरील प्रमाणपत्रांवर आणि तुमच्या RADIUS सर्व्हरवरील विश्वासावर परिणाम होतो. ऍक्सेस पॉइंट्स फक्त RADIUS कडे ऑथेंटिकेशन फॉरवर्ड करतात. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet हे सर्व याला सपोर्ट करतात. Purple चे Staff WiFi हे हार्डवेअर-अग्नोस्टिक क्लाउड ओव्हरले म्हणून या आठही प्लॅटफॉर्मवर चालते.