WiFi के लिए Microsoft Cloud PKI: Intune और Entra ID के साथ EAP-TLS प्रमाण पत्र परिनियोजन

हाँ। Microsoft Cloud PKI, जो Intune Suite में होस्ट किया गया सर्टिफ़िकेट अथॉरिटी है, Intune - प्रबंधित डिवाइसों को EAP-TLS WiFi सर्टिफ़िकेट जारी करता है। एक SCEP सर्टिफ़िकेट प्रोफाइल सीधे अनुरोध करता है, इसलिए आपको NDES सर्वर, सर्टिफ़िकेट कनेक्टर या ऑन-प्रिमाइसेस CA की आवश्यकता नहीं होती है। आपका RADIUS सर्वर इम्पोर्ट किए गए Cloud PKI रूट पर भरोसा करता है और सर्विस द्वारा पब्लिश की गई CRL के खिलाफ प्रत्येक सर्टिफ़िकेट की जांच करता है।

WiFi ऑथेंटिकेशन के लिए Microsoft Cloud PKI क्या करता है?

EAP-TLS (एक्सटेंसिबल ऑथेंटिकेशन प्रोटोकॉल - ट्रांसपोर्ट लेयर सिक्योरिटी) 802.1X विधि है जिसमें दोनों पक्ष सर्टिफ़िकेट के साथ अपनी पहचान साबित करते हैं। IEEE 802.1X, WPA2 - Enterprise और WPA3 - Enterprise के पीछे पोर्ट-आधारित एक्सेस कंट्रोल मानक है। एक्सेस प्वाइंट प्रत्येक कनेक्शन प्रयास को RADIUS सर्वर पर भेजता है, जो ऑथेंटिकेशन सर्वर है और डिवाइस को स्वीकार या अस्वीकार करता है। EAP-TLS के साथ फ़िशिंग के लिए कोई पासवर्ड नहीं है और लीक होने के लिए कोई साझा कुंजी नहीं है। प्रत्येक डिवाइस अपनी निजी कुंजी और सर्टिफ़िकेट रखता है।

सबसे कठिन भाग हमेशा इसके पीछे का PKI (पब्लिक की इंफ्रास्ट्रक्चर) रहा है। Intune - प्रबंधित डिवाइसों पर सर्टिफ़िकेट प्राप्त करने के लिए पारंपरिक रूप से चार चीजों की आवश्यकता होती थी:

• एक Active Directory Certificate Services (AD CS) इश्यूइंग CA
• एक NDES (नेटवर्क डिवाइस एनरोलमेंट सर्विस) सर्वर
• Intune सर्टिफ़िकेट कनेक्टर
• NDES को इंटरनेट पर पब्लिश करने के लिए एक रिवर्स प्रॉक्सी या Microsoft Entra एप्लिकेशन प्रॉक्सी

प्रत्येक को पैचिंग, बैकअप और मॉनिटरिंग की आवश्यकता होती है।

Microsoft Cloud PKI उस स्टैक को आपके Intune टेनेंट में होस्ट किए गए सर्टिफ़िकेट अथॉरिटी से बदल देता है। डिवाइस SCEP (सिंपल सर्टिफ़िकेट एनरोलमेंट प्रोटोकॉल) के माध्यम से सर्टिफ़िकेट का अनुरोध करते हैं, और Cloud PKI स्वयं उन अनुरोधों का उत्तर देता है। यह Intune के खिलाफ प्रत्येक अनुरोध को मान्य करता है, सर्टिफ़िकेट पर हस्ताक्षर करता है और इसे वापस लौटाता है। डिवाइस अपनी निजी कुंजी स्थानीय रूप से जनरेट करता है, और कुंजी कभी भी इसे नहीं छोड़ती है।

Entra ID - जुड़े फ़्लीट के लिए, यह सर्टिफ़िकेट श्रृंखला में अंतिम ऑन-प्रिमाइसेस निर्भरता को हटा देता है। जिन डिवाइसों ने कभी डोमेन कंट्रोलर नहीं देखा है, वे भी WiFi सर्टिफ़िकेट प्राप्त कर सकते हैं।

Cloud PKI CA पदानुक्रम कैसे काम करता है

Cloud PKI दो-स्तरीय पदानुक्रम का उपयोग करता है। एक रूट CA एक या अधिक इश्यूइंग CA पर हस्ताक्षर करता है, और इश्यूइंग CA डिवाइस सर्टिफ़िकेट पर हस्ताक्षर करता है। Microsoft हार्डवेयर सुरक्षा मॉड्यूल (HSM) में CA हस्ताक्षर कुंजियों को रखता है, इसलिए आपको कभी भी कुंजी सामग्री का प्रबंधन नहीं करना पड़ता है।

आप दो एंकर में से एक चुनते हैं:

• Cloud PKI रूट। Microsoft आपके टेनेंट में रूट और इश्यूइंग CA दोनों को होस्ट करता है। यह ग्रीनफील्ड Entra ID एस्टेट के लिए सबसे सरल विकल्प है।
• अपना स्वयं का CA लाएं (BYOCA)। आप एक Cloud PKI इश्यूइंग CA बनाते हैं, इसका सर्टिफ़िकेट साइनिंग रिक्वेस्ट डाउनलोड करते हैं और अपने मौजूदा प्राइवेट रूट, जैसे AD CS रूट के साथ उस पर हस्ताक्षर करते हैं। कोई भी चीज जो पहले से ही उस रूट पर भरोसा करती है, वह नए इश्यूइंग CA की श्रृंखला पर भरोसा करती है।

जब आप प्रत्येक CA बनाते हैं, तो आप एक्सटेंडेड की यूसेज (EKUs) सेट करते हैं। WiFi क्लाइंट प्रमाण पत्रों को क्लाइंट प्रमाणीकरण EKU की आवश्यकता होती है, इसलिए इसे दोनों स्तरों पर शामिल करें। इसकी सावधानीपूर्वक योजना बनाएं, क्योंकि CA बनने पर EKUs फिक्स हो जाते हैं।

डिजाइन के लिए एक सीमा महत्वपूर्ण है। Cloud PKI SCEP के माध्यम से Intune-प्रबंधित उपकरणों को प्रमाण पत्र जारी करता है। इसे आपके RADIUS सर्वर का अपना प्रमाण पत्र जारी करने के लिए नहीं बनाया गया है, इसलिए वह प्रमाण पत्र आमतौर पर किसी सार्वजनिक CA या आपके मौजूदा PKI से आता है।

NDES और PKCS के साथ Cloud PKI की SCEP से तुलना

	Cloud PKI (SCEP)	NDES के साथ SCEP	PKCS
CA होस्टिंग	आपके Intune किरायेदार में Microsoft-होस्टेड	आपका AD CS या थर्ड-पार्टी CA	आपका AD CS या थर्ड-पार्टी CA
ऑन-प्रीमिस सर्वर	कोई नहीं	जारीकर्ता CA, NDES सर्वर, कनेक्टर होस्ट	जारीकर्ता CA, कनेक्टर होस्ट
इंटरनेट-प्रकाशित घटक	कोई नहीं	NDES, रिवर्स प्रॉक्सी या एप्लिकेशन प्रॉक्सी के माध्यम से	कोई नहीं
प्राइवेट की कहाँ उत्पन्न होती है	डिवाइस पर	डिवाइस पर	CA की तरफ, डिवाइस को PFX के रूप में वितरित की जाती है
केवल Microsoft Entra ID बेड़े के लिए उपयुक्त	नेटिव	काम करता है, लेकिन ऑन-प्रीमिस निर्भरता बनाए रखता है	काम करता है, लेकिन ऑन-प्रीमिस निर्भरता बनाए रखता है
निरसन (Revocation)	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 प्लान 1 सदस्यता के साथ Microsoft Intune Suite या स्टैंडअलोन Cloud PKI ऐड-ऑन।
• अनुमतियां। Intune व्यवस्थापक भूमिका, या 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 प्रसारित करना होगा।एक्सेस पॉइंट की ओर, हर प्रमुख प्लेटफॉर्म 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 दस्तावेज़ उपयोग करें, क्योंकि एडमिन सेंटर का लेआउट रिलीज़ के बीच बदलता रहता है।

चरण 1: रूट CA बनाएं, या अपना स्वयं का लाएं

Intune एडमिन सेंटर में, टैनेंट एडमिनिस्ट्रेशन के तहत एक रूट CA बनाएं। Client Authentication सहित कुंजी का आकार, वैधता अवधि और EKU चुनें।

BYOCA के लिए, रूट को छोड़ दें। जारी करने वाले CA को BYOCA प्रकार के रूप में बनाएं और इसके प्रमाणपत्र हस्ताक्षर अनुरोध को एक्सपोर्ट करें। Client Authentication शामिल करने वाले टेम्प्लेट का उपयोग करके अपने प्राइवेट CA पर अनुरोध को साइन करें, फिर हस्ताक्षरित प्रमाणपत्र और उसकी श्रृंखला को अपलोड करें।

चरण 2: जारी करने वाला CA बनाएं

चरण 1 से रूट से जुड़ा हुआ एक जारी करने वाला CA बनाएं। इसके EKU में Client Authentication शामिल होना चाहिए। एक बार बन जाने पर, इसका गुण पृष्ठ तीन चीज़ें दिखाता है जिनकी आपको बाद में आवश्यकता होगी:

• SCEP URI
• CA प्रमाणपत्र डाउनलोड
• CRL वितरण बिंदु

चरण 3: विश्वसनीय प्रमाणपत्र प्रोफ़ाइल तैनात करें

रूट और जारी करने वाले CA प्रमाणपत्रों को डाउनलोड करें। प्रत्येक प्लेटफॉर्म के लिए प्रत्येक का एक विश्वसनीय प्रमाणपत्र प्रोफ़ाइल बनाएं। उन्हें उन्हीं समूहों को सौंपें जो SCEP और WiFi प्रोफ़ाइल प्राप्त करेंगे।

SCEP प्रोफ़ाइल के सफल होने से पहले डिवाइसों को इस श्रृंखला की आवश्यकता होती है। यदि डिवाइस उस CA पर पहले से भरोसा नहीं करते हैं जिसने आपका RADIUS सर्वर प्रमाणपत्र जारी किया है, तो उसके लिए एक और विश्वसनीय प्रमाणपत्र प्रोफ़ाइल बनाएं।

चरण 4: SCEP प्रमाणपत्र प्रोफ़ाइल बनाएं

प्रति प्लेटफॉर्म एक SCEP प्रमाणपत्र प्रोफ़ाइल बनाएं और इसे Cloud PKI पर निर्देशित करें। ये मुख्य निर्णय हैं:

• SCEP सर्वर URL। जारी करने वाले CA से SCEP URI को ठीक वैसे ही पेस्ट करें जैसा दिखाया गया है। इसके प्लेसहोल्डर टेक्स्ट को बिना संपादित किए छोड़ दें, क्योंकि Intune जारी करने के समय इसे रिज़ॉल्व करता है।
• रूट प्रमाणपत्र। Cloud PKI रूट के लिए विश्वसनीय प्रमाणपत्र प्रोफ़ाइल चुनें, न कि जारी करने वाले CA के लिए।
• प्रमाणपत्र का प्रकार। फ्रंट डेस्क टैबलेट या स्टोर हैंडहेल्ड जैसे साझा डिवाइसों के लिए डिवाइस प्रमाणपत्र चुनें। जहां कर्मचारी अपना स्वयं का लैपटॉप ले जाते हैं और आप नीति को व्यक्ति से जोड़ना चाहते हैं, वहां प्रति व्यक्ति प्रमाणपत्र चुनें।
• विषय और विषय का वैकल्पिक नाम (SAN)। एक पहचानकर्ता शामिल करें जिसे आपका RADIUS सर्वर Microsoft Entra ID में मैप कर सके। उदाहरण के लिए Entra डिवाइस ID वेरिएबल {{AAD_Device_ID}} या UPN वेरिएबल {{UserPrincipalName}} हैं।
• कुंजी का उपयोग और EKU। Client Authentication के साथ डिजिटल हस्ताक्षर और कुंजी एन्क्रिप्शन सेट करें।
• Windows पर कुंजी का भंडारण। TPM (Trusted Platform Module) कुंजी भंडारण प्रदाता में नामांकित करें, ताकि निजी कुंजी हार्डवेयर से बंधी हो और एक्सपोर्ट न की जा सके।
• नवीनीकरण सीमा। शेष जीवनकाल का वह प्रतिशत सेट करें जिस पर Intune नवीनीकरण करता है, ताकि प्रमाण पत्र कभी भी अनजाने में समाप्त न हों।

चरण 5: RADIUS सर्वर को Cloud PKI पर भरोसा करने के लिए सेट करें

अपने RADIUS सर्वर के विश्वसनीय CA स्टोर में Cloud PKI रूट और जारीकर्ता CA दोनों प्रमाणपत्रों को इंपोर्ट करें। केवल रूट को इंपोर्ट करना "अज्ञात CA" अस्वीकृति का सबसे सामान्य कारण है।

CRL जाँच सक्षम करें, और RADIUS सर्वर को प्रत्येक प्रमाणपत्र में सूचीबद्ध CRL वितरण बिंदु तक आउटबाउंड HTTP पहुँच की अनुमति दें। BYOCA के साथ, RADIUS सर्वर पहले से ही आपके रूट पर भरोसा कर सकता है, इसलिए आप केवल नया जारीकर्ता CA प्रमाणपत्र जोड़ते हैं।

यदि Purple का क्लाउड RADIUS आपके Staff WiFi को प्रमाणित करता है, तो आपकी Purple खाता टीम यह पुष्टि करेगी कि आपके टेनेंट के लिए Cloud PKI श्रृंखला कैसे लोड की जाती है।

चरण 6: WiFi प्रोफ़ाइल बनाएं

एंटरप्राइज़ सुरक्षा और EAP प्रकार के रूप में EAP-TLS के साथ एक Intune WiFi प्रोफ़ाइल बनाएं। तीन फ़ील्ड सेट करें:

• क्लाइंट प्रमाणीकरण प्रमाणपत्र। चरण 4 से SCEP प्रोफ़ाइल चुनें।
• सर्वर सत्यापन के लिए रूट प्रमाणपत्र। अपने RADIUS सर्वर के जारीकर्ता रूट के लिए विश्वसनीय प्रमाणपत्र प्रोफ़ाइल चुनें।
• प्रमाणपत्र सर्वर नाम। ऐसे नाम दर्ज करें जो RADIUS सर्वर प्रमाणपत्र से बिल्कुल मेल खाते हों।

प्रोफ़ाइल को उन्हीं समूहों में असाइन करें जिनमें SCEP और विश्वसनीय प्रमाणपत्र प्रोफ़ाइल हैं।

Cloud PKI के साथ निरसन (revocation) कैसे काम करता है?

आप Intune एडमिन सेंटर में जारीकर्ता CA से Cloud PKI प्रमाणपत्रों को रद्द करते हैं। जारी किए गए प्रमाणपत्रों की सूची खोलें, डिवाइस के प्रमाणपत्र को चुनें और इसे रद्द करें। Cloud PKI फिर परिवर्तन को अपने CRL (प्रमाणपत्र निरसन सूची) में प्रकाशित करता है, जो इसके द्वारा जारी किए गए प्रत्येक प्रमाणपत्र में एम्बेडेड HTTP वितरण बिंदु पर स्थित होता है।

आपका RADIUS सर्वर निरसन को लागू करता है, Intune नहीं। यह CRL डाउनलोड करता है और किसी भी ऐसे प्रमाणपत्र को अस्वीकार कर देता है जिसका सीरियल नंबर उस पर दिखाई देता है।

अधिकांश RADIUS सर्वर अगले अपडेट समय तक CRL को कैश करते हैं। इसलिए एक रद्द किया गया डिवाइस तब तक कनेक्ट होना जारी रख सकता है जब तक कि RADIUS सर्वर नई सूची प्राप्त नहीं कर लेता। उस समय के अंतर को तीन तरीकों से बंद करें:

1. स्पष्ट रूप से रद्द करें। प्रोफ़ाइल असाइनमेंट हटाने या डिवाइस रिकॉर्ड हटाने पर भरोसा न करें। अपने जॉइनर्स, मूवर्स, लीवर्स (JML) प्रक्रिया के हिस्से के रूप में प्रमाणपत्र को स्वयं रद्द करें।
2. पहचान जांच के साथ निरसन को जोड़ें। यदि आपकी RADIUS सेवा प्रत्येक प्रमाणीकरण पर 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 की कमी है	उस EKU के बिना बनाया गया इश्यूइंग CA	Client Authentication के साथ एक नया इश्यूइंग CA बनाएं और SCEP प्रोफ़ाइल को फिर से पॉइंट करें

यदि विफलताएं विशेष कमरों या मंजिलों में केंद्रित होती हैं जबकि वही डिवाइस अन्यत्र ऑथेंटिकेट होते हैं, तो दोष रेडियो कवरेज का है, PKI का नहीं। EAP-TLS प्री-शेयर्ड की हैंडशेक की तुलना में अधिक पैकेट का आदान-प्रदान करता है, इसलिए सीमांत सिग्नल टाइमआउट के रूप में दिखाई देता है। WiFi Site Surveys: A Practical Planning Guide में उन अंतरालों को खोजने का तरीका शामिल है।

NDES के साथ Cloud PKI या 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 पर आज हाइब्रिड-जुड़े डिवाइस, Microsoft 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 Microsoft Entra ID-जुड़े लैपटॉप और फ्रंट-डेस्क टैबलेट चलाए। प्रत्येक तिमाही में उस कुंजी को घुमाने (रोटेट) का अर्थ प्रत्येक संपत्ति में हर डिवाइस को छूना था। एक खोया हुआ टैबलेट अगली रोटेशन तक कुंजी को उजागर छोड़ देता था।

क्या किया गया। IT ने एक Cloud PKI रूट और जारीकर्ता CA बनाया, फिर SCEP के माध्यम से TPM-समर्थित डिवाइस प्रमाणपत्र जारी किए। एक क्लाउड RADIUS सेवा ने श्रृंखला को मान्य किया और CRL की जाँच की। समूह ने पायलट के लिए पुराने SSID के साथ EAP-TLS SSID चलाया, संपत्तियों को चरणों में स्थानांतरित किया, फिर प्री-शेयर्ड कुंजी नेटवर्क को बंद कर दिया।

परिणाम। परिदृश्य का गणित सीधा है:

• कर्मचारी नेटवर्क पर साझा रहस्य (शेयर सीक्रेट्स) एक से घटकर शून्य हो जाते हैं।
• 30 संपत्तियों में त्रैमासिक कुंजी रोटेशन पूरी तरह से बंद हो जाता है।
• एक खोया हुआ टैबलेट 900 डिवाइसों की पुन: कुंजी (री-कीing) के बजाय एक प्रमाणपत्र निरस्तीकरण (रिवोकेशन) बन जाता है।
• किसी ऑन-प्रीमिसिस CA, NDES सर्वर या कनेक्टर की आवश्यकता नहीं होती है।

व्यावहारिक परिदृश्य: एक 250-स्टोर रिटेल चेन

स्थिति. एक खुदरा श्रृंखला ने AD CS और दो NDES सर्वरों के माध्यम से 4,000 स्टोर हैंडहेल्ड और लैपटॉप को WiFi प्रमाणपत्र जारी किए। Intune प्रमाणपत्र कनेक्टर तीसरे सर्वर पर चल रहा था। तीनों सर्वर ऑपरेटिंग सिस्टम प्रतिस्थापन के लिए देय थे, और 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 99.999% अपटाइम के साथ 80,000+ लाइव स्थानों (Purple डेटा) पर चलता है, और 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 प्रमाणपत्र कनेक्टर और इंटरनेट पर 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 पहुंच की भी आवश्यकता होती है, ताकि वह निरसन (revocation) की जांच कर सके। Microsoft Entra ID से जुड़े उपकरणों के लिए, इसे ऑन-प्रेमिसिस Active Directory के बजाय Microsoft Entra ID में प्रमाणपत्र पहचानों को मैप करना होगा।

Cloud PKI के साथ निरसन (revocation) कैसे काम करता है?

आप Intune एडमिन सेंटर में जारीकर्ता CA से एक प्रमाणपत्र को निरस्त करते हैं, और Cloud PKI इस बदलाव को अपने CRL में प्रकाशित करता है। आपका RADIUS सर्वर उस CRL को डाउनलोड करता है और निरस्त किए गए प्रमाणपत्रों को अस्वीकार कर देता है। चूंकि RADIUS सर्वर CRL को कैश करते हैं, इसलिए एक निरस्त किया गया उपकरण अगले रिफ्रेश तक कनेक्ट हो सकता है। यदि आपकी RADIUS सेवा प्रत्येक प्रमाणीकरण पर पहचान स्थिति की जांच करती है, तो Microsoft Entra ID खाते या उपकरण को अक्षम करके उस अंतर को समाप्त करें।

क्या मुझे Cloud PKI या NDES के साथ SCEP चुनना चाहिए?

यदि आप Microsoft Entra ID से जुड़ा बेड़ा चलाते हैं या ऑन-प्रेमिसिस 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 या WPA3 के साथ 802.1X का समर्थन करते हैं। Cloud PKI केवल उपकरणों पर प्रमाणपत्रों और आपके RADIUS सर्वर पर विश्वास को प्रभावित करता है। एक्सेस पॉइंट केवल RADIUS को प्रमाणीकरण अग्रेषित करते हैं। Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks और Fortinet सभी इसका समर्थन करते हैं। Purple की Staff WiFi इन सभी आठों में हार्डवेयर-अज्ञेयवादी क्लाउड ओवरले के रूप में चलती है।