SCEP आणि PKCS द्वारे Microsoft Intune WiFi प्रमाणपत्र उपयोजन
हे मार्गदर्शक SCEP आणि PKCS वापरून Microsoft Intune द्वारे WiFi ऑथेंटिकेशन प्रमाणपत्रे उपयोजित करण्यासाठी चरण-दर-चरण तांत्रिक संदर्भ प्रदान करते. हे IT व्यवस्थापक आणि नेटवर्क आर्किटेक्ट्ससाठी डिझाइन केलेले आहे जे एंटरप्राइझ वातावरणात अखंड, सुरक्षित कनेक्टिव्हिटी सुनिश्चित करण्यासाठी पासवर्डलेस 802.1X WiFi लागू करत आहेत.
- कार्यकारी सारांश
- तांत्रिक सखोल माहिती: SCEP विरुद्ध PKCS
- SCEP (Simple Certificate Enrollment Protocol)
- PKCS (Public Key Cryptography Standards)
- अंमलबजावणी मार्गदर्शक: उपयोजन क्रम
- पायरी १: ट्रस्टेड रूट प्रमाणपत्र प्रोफाइल उपयोजित करा
- पायरी २: SCEP प्रमाणपत्र प्रोफाइल कॉन्फिगर करा
- पायरी ३: 802.1X WiFi प्रोफाइल उपयोजित करा
- सर्वोत्तम पद्धती आणि उद्योग मानके
- NDES सर्व्हर प्लेसमेंट आणि सुरक्षा
- RADIUS आणि CRL चेकिंग
- ट्रबलशूटिंग आणि जोखीम कमी करणे
- समस्या: WiFi प्रोफाइल लागू होण्यास अपयशी ठरते
- समस्या: NDES 403 Forbidden एरर्स
- ROI आणि व्यवसायावर होणारा परिणाम

कार्यकारी सारांश
एंटरप्राइझ ठिकाणांसाठी—मग ते गजबजलेले Hospitality वातावरण असो, मल्टी-साइट Retail ऑपरेशन असो किंवा आधुनिक कॉर्पोरेट कॅम्पस असो—कर्मचारी WiFi साठी प्री-शेअर्ड की किंवा मूलभूत Captive Portal वर अवलंबून राहणे ही सुरक्षिततेची असुरक्षितता आणि ऑपरेशनल अडथळा आहे. आधुनिक नेटवर्क आर्किटेक्चर EAP-TLS वापरून 802.1X ऑथेंटिकेशनची मागणी करते, ज्यामुळे नेटवर्कमध्ये प्रवेश करण्यापूर्वी प्रत्येक डिव्हाइसचे क्रिप्टोग्राफिकरित्या सत्यापन केले जाते.
तथापि, आव्हान वितरणात आहे: हजारो Windows, iOS, आणि Android डिव्हाइसेसवर युनिक क्लायंट प्रमाणपत्रे कशी उपयोजित करायची, तेही तुमच्या हेल्पडेस्कला सपोर्ट तिकिटांमध्ये न बुडवता? Microsoft Intune स्वयंचलित प्रमाणपत्र लाइफसायकल मॅनेजमेंटद्वारे हे सोडवते. SCEP (Simple Certificate Enrollment Protocol) किंवा PKCS (Public Key Cryptography Standards) प्रमाणपत्र प्रोफाइल्सचा लाभ घेऊन, IT टीम्स मॅनेज्ड एंडपॉइंट्सवर ट्रस्टेड रूट आणि क्लायंट प्रमाणपत्रे सायलेंटली पुश करू शकतात.
हे मार्गदर्शक Intune WiFi प्रमाणपत्र उपयोजनासाठी एक निश्चित आर्किटेक्चरल ब्लूप्रिंट आणि चरण-दर-चरण अंमलबजावणी धोरण प्रदान करते. आम्ही SCEP आणि PKCS मधील महत्त्वपूर्ण फरक शोधू, यशासाठी आवश्यक असलेल्या अचूक उपयोजन क्रमाचा तपशील देऊ आणि तुमचे Guest WiFi आणि कॉर्पोरेट नेटवर्क्स सुरक्षित आणि कार्यक्षम राहतील याची खात्री करण्यासाठी रिअल-वर्ल्ड रिस्क मिटिगेशन धोरणांची रूपरेषा मांडू.
सोबतचे पॉडकास्ट ब्रीफिंग ऐका:
तांत्रिक सखोल माहिती: SCEP विरुद्ध PKCS
तुमची Intune WiFi प्रमाणपत्र उपयोजन धोरण डिझाइन करताना, पहिला आर्किटेक्चरल निर्णय प्रमाणपत्र वितरण यंत्रणा निवडणे हा असतो. Intune SCEP आणि PKCS दोन्हीला सपोर्ट करते, परंतु ते मूलभूतपणे वेगळ्या पद्धतीने कार्य करतात.
SCEP (Simple Certificate Enrollment Protocol)
SCEP हे एंटरप्राइझ डिव्हाइस एनरोलमेंटसाठी उद्योगाचे मानक आहे. SCEP वर्कफ्लोमध्ये, Intune सेवा एंडपॉइंटला स्वतःची खाजगी/सार्वजनिक की जोडी तयार करण्यास सांगते. डिव्हाइस नंतर एक प्रमाणपत्र स्वाक्षरी विनंती (CSR) तयार करते आणि ती नेटवर्क डिव्हाइस एनरोलमेंट सर्व्हिस (NDES) सर्व्हरद्वारे तुमच्या प्रमाणपत्र प्राधिकरणाकडे (CA) पाठवते. CA विनंतीवर स्वाक्षरी करते आणि सार्वजनिक प्रमाणपत्र डिव्हाइसला परत करते.
SCEP चा महत्त्वाचा सुरक्षा फायदा असा आहे की खाजगी की कधीही डिव्हाइस सोडत नाही. ती स्थानिक पातळीवर तयार केली जाते, डिव्हाइसच्या सुरक्षित एन्क्लेव्हमध्ये (जसे की Windows वरील TPM किंवा iOS वरील Secure Enclave) संग्रहित केली जाते आणि नेटवर्कवर कधीही प्रसारित केली जात नाही. यामुळे 802.1X ऑथेंटिकेशनसाठी SCEP हा अत्यंत शिफारस केलेला दृष्टिकोन बनतो.
PKCS (Public Key Cryptography Standards)
याउलट, PKCS सह, प्रमाणपत्र प्राधिकरण सार्वजनिक आणि खाजगी दोन्ही की मध्यवर्तीरित्या तयार करते. Microsoft Intune प्रमाणपत्र कनेक्टर नंतर ही की जोडी सुरक्षितपणे एक्सपोर्ट करतो आणि ती लक्ष्यित डिव्हाइसवर पुश करतो.
जरी PKCS मुळे NDES सर्व्हर उपयोजित करण्याची आणि देखरेख करण्याची आवश्यकता संपुष्टात येते—ज्यामुळे इन्फ्रास्ट्रक्चरचा विस्तार सुलभ होतो—तरीही यामुळे एक सैद्धांतिक सुरक्षा जोखीम निर्माण होते कारण खाजगी की नेटवर्कवर प्रसारित केली जाते. PKCS सामान्यतः अशा वापराच्या प्रकरणांसाठी अधिक योग्य आहे जिथे की एस्क्रो आवश्यक आहे, जसे की S/MIME ईमेल एन्क्रिप्शन, नेटवर्क ऑथेंटिकेशनऐवाजी.

अंमलबजावणी मार्गदर्शक: उपयोजन क्रम
802.1X साठी Intune WiFi प्रोफाइल यशस्वीरित्या कॉन्फिगर करण्यासाठी विशिष्ट उपयोजन क्रमाचे काटेकोरपणे पालन करणे आवश्यक आहे. Intune प्रोफाइल अवलंबित्व असे सांगते की ऑथेंटिकेशन कॉन्फिगर करण्यापूर्वी विश्वास प्रस्थापित करणे आवश्यक आहे.
पायरी १: ट्रस्टेड रूट प्रमाणपत्र प्रोफाइल उपयोजित करा
कोणतेही डिव्हाइस क्लायंट प्रमाणपत्राची विनंती करण्यापूर्वी किंवा तुमच्या RADIUS सर्व्हरवर विश्वास ठेवण्यापूर्वी, त्याने जारी करणाऱ्या प्रमाणपत्र प्राधिकरणावर विश्वास ठेवला पाहिजे.
- तुमचे Root CA प्रमाणपत्र (आणि कोणतेही इंटरमीडिएट CA प्रमाणपत्रे)
.cerफाइल्स म्हणून एक्सपोर्ट करा. - Microsoft Endpoint Manager ॲडमिन सेंटरमध्ये, Devices > Configuration profiles > Create profile वर जा.
- लक्ष्यित प्लॅटफॉर्म निवडा (उदा. Windows 10 आणि नंतरचे) आणि Trusted certificate प्रोफाइल प्रकार निवडा.
.cerफाइल अपलोड करा आणि हे प्रोफाइल तुमच्या लक्ष्यित डिव्हाइस ग्रुप्सवर उपयोजित करा.
थंब रूल: उपयोजन विसंगती टाळण्यासाठी नेहमी सर्व संबंधित प्रोफाइल्समध्ये एकाच ग्रुप्सना (एकतर युजर्स किंवा डिव्हाइसेस) लक्ष्य करा.
पायरी २: SCEP प्रमाणपत्र प्रोफाइल कॉन्फिगर करा
एकदा विश्वास प्रस्थापित झाला की, डिव्हाइसेसना त्यांचे क्लायंट प्रमाणपत्र कसे मिळवायचे याबद्दल सूचना देण्यासाठी SCEP प्रोफाइल कॉन्फिगर करा.
- एक नवीन कॉन्फिगरेशन प्रोफाइल तयार करा आणि SCEP certificate निवडा.
- Subject name format कॉन्फिगर करा. युजर-ड्रिव्हन ऑथेंटिकेशनसाठी,
CN={{UserPrincipalName}}मानक आहे. डिव्हाइस ऑथेंटिकेशनसाठी,CN={{AAD_Device_ID}}वापरा. - Key usage ला
Digital signatureआणिKey enciphermentवर सेट करा. - Extended key usage अंतर्गत,
Client Authentication(OID: 1.3.6.1.5.5.7.3.2) निर्दिष्ट करा. - हे प्रोफाइल पायरी १ मध्ये तयार केलेल्या ट्रस्टेड रूट प्रमाणपत्र प्रोफाइलशी लिंक करा.
- तुमच्या NDES सर्व्हरची बाह्य URL प्रदान करा.
पायरी ३: 802.1X WiFi प्रोफाइल उपयोजित करा
शेवटची पायरी म्हणजे WiFi कॉन्फिगरेशन पुश करणे जे प्रमाणपत्रांना नेटवर्क SSID शी जोडते.
- एक Wi-Fi कॉन्फिगरेशन प्रोफाइल तयार करा.
- तुमच्या Wireless Access Points द्वारे प्रसारित केल्याप्रमाणे Network name (SSID) अचूकपणे प्रविष्ट करा.
- सुरक्षा प्रकार म्हणून WPA2-Enterprise किंवा WPA3-Enterprise निवडा.
- EAP type ला EAP-TLS वर सेट करा.
- ऑथेंटिकेशन सेटिंग्जमध्ये, पायरी २ मध्ये तयार केलेले SCEP प्रमाणपत्र प्रोफाइल क्लायंट ऑथेंटिकेशन प्रमाणपत्र म्हणून निवडा.
- डिव्हाइस केवळ तुमच्या कायदेशीर RADIUS सर्व्हरशी कनेक्ट होईल याची खात्री करण्यासाठी सर्व्हर व्हॅलिडेशनसाठी ट्रस्टेड रूट प्रमाणपत्र निर्दिष्ट करा.

सर्वोत्तम पद्धती आणि उद्योग मानके
Intune WiFi प्रमाणपत्र उपयोजन लागू करताना, अनुपालन आणि विश्वासार्हता सुनिश्चित करण्यासाठी खालील विक्रेता-तटस्थ सर्वोत्तम पद्धतींचे पालन करा.
NDES सर्व्हर प्लेसमेंट आणि सुरक्षा
रिमोट डिव्हाइसेसना साइटवर येण्यापूर्वी प्रमाणपत्रे प्रोव्हिजन करण्याची परवानगी देण्यासाठी NDES सर्व्हर इंटरनेटवरून ॲक्सेस करण्यायोग्य असणे आवश्यक आहे. तथापि, अंतर्गत सर्व्हर थेट इंटरनेटवर उघड करणे ही एक मोठी सुरक्षा जोखीम आहे.
शिफारस: Azure AD ॲप्लिकेशन प्रॉक्सी वापरून NDES URL प्रकाशित करा. हे इनबाउंड फायरवॉल पोर्ट्स न उघडता सुरक्षित रिमोट ॲक्सेस प्रदान करते आणि तुम्हाला एनरोलमेंट फ्लोवर कंडिशनल ॲक्सेस पॉलिसी लागू करण्याची परवानगी देते.
RADIUS आणि CRL चेकिंग
प्रमाणपत्र उपयोजन हे अर्धेच सुरक्षा समीकरण आहे; रिव्होकेशन तितकेच महत्त्वाचे आहे. जर एखाद्या कर्मचाऱ्याला कामावरून काढून टाकले असेल, तर त्यांचे Active Directory खाते अक्षम केल्याने त्यांचा WiFi ॲक्सेस त्वरित रद्द होणार नाही जर त्यांचे क्लायंट प्रमाणपत्र वैध राहिले आणि RADIUS सर्व्हर प्रमाणपत्र रिव्होकेशन लिस्ट (CRL) काटेकोरपणे तपासत नसेल.
शिफारस: तुमचे नेटवर्क पॉलिसी सर्व्हर (NPS) किंवा RADIUS सर्व्हर कडक CRL चेकिंग लागू करण्यासाठी कॉन्फिगर करा. तुमचे CRL डिस्ट्रिब्युशन पॉइंट्स (CDPs) उच्च उपलब्धतेमध्ये असल्याची खात्री करा; जर RADIUS सर्व्हर CRL पर्यंत पोहोचू शकला नाही, तर ऑथेंटिकेशन अयशस्वी होईल, ज्यामुळे मोठ्या प्रमाणावर आउटेज होईल.
सुरक्षित नेटवर्क डिझाइनबद्दल अधिक माहितीसाठी, The Core SD WAN Benefits for Modern Businesses पहा.
ट्रबलशूटिंग आणि जोखीम कमी करणे
सूक्ष्म नियोजनानंतरही, प्रमाणपत्र उपयोजनात समस्या येऊ शकतात. येथे सामान्य बिघाड मोड आणि ते कमी करण्याची धोरणे आहेत.
समस्या: WiFi प्रोफाइल लागू होण्यास अपयशी ठरते
लक्षण: डिव्हाइसला ट्रस्टेड रूट आणि SCEP प्रमाणपत्रे मिळतात, परंतु WiFi प्रोफाइल Intune मध्ये 'Error' किंवा 'Not Applicable' म्हणून दिसते.
मूळ कारण: हे जवळजवळ नेहमीच ग्रुप टार्गेटिंगमधील विसंगतीमुळे होते. जर SCEP प्रोफाइल युजर ग्रुपला नियुक्त केले असेल, परंतु WiFi प्रोफाइल डिव्हाइस ग्रुपला नियुक्त केले असेल, तर Intune अवलंबित्व सोडवू शकत नाही.
उपाय: तुमच्या असाइनमेंट्सचे ऑडिट करा. ट्रस्टेड रूट, SCEP आणि WiFi प्रोफाइल्स सर्व एकाच Azure AD ग्रुपवर उपयोजित केल्याची खात्री करा.
समस्या: NDES 403 Forbidden एरर्स
लक्षण: डिव्हाइसेस SCEP प्रमाणपत्र मिळवण्यात अपयशी ठरतात आणि NDES IIS लॉग्स HTTP 403 एरर्स दाखवतात.
मूळ कारण: Intune प्रमाणपत्र कनेक्टर सर्व्हिस अकाउंटकडे प्रमाणपत्र टेम्प्लेटवर आवश्यक परवानग्या नसतात किंवा तुमच्या फायरवॉलवरील URL फिल्टरिंग SCEP द्वारे वापरल्या जाणाऱ्या विशिष्ट क्वेरी स्ट्रिंग पॅरामीटर्सना ब्लॉक करत असते.
उपाय: कनेक्टर अकाउंटकडे CA टेम्प्लेटवर 'Read' आणि 'Enroll' परवानग्या असल्याची पडताळणी करा. ?operation=GetCACaps असलेल्या URL ब्लॉक केल्या जात नाहीत याची खात्री करण्यासाठी फायरवॉल लॉग्स तपासा.
ROI आणि व्यवसायावर होणारा परिणाम
Microsoft Intune 802.1X प्रमाणपत्र उपयोजनाकडे वळल्याने सुरक्षा आणि ऑपरेशन्समध्ये मोजता येण्याजोगा परतावा मिळतो.
- हेल्पडेस्क तिकीट कपात: पासवर्ड-आधारित WiFi मोठ्या प्रमाणात सपोर्ट तिकिटे तयार करते (पासवर्ड एक्सपायरी, लॉकआउट्स, टायपिंग चुका). प्रमाणपत्र-आधारित ऑथेंटिकेशन वापरकर्त्यासाठी अदृश्य असते, ज्यामुळे सामान्यतः WiFi-संबंधित हेल्पडेस्क व्हॉल्यूम ७०-८०% कमी होतो.
- वर्धित सुरक्षा स्थिती: EAP-TLS क्रेडेंशियल हार्वेस्टिंग आणि मॅन-इन-द-मिडल (MitM) हल्ल्यांचा धोका दूर करते. PCI DSS आणि GDPR सारख्या फ्रेमवर्कच्या पालनासाठी हे महत्त्वपूर्ण आहे, विशेषतः Healthcare आणि रिटेल वातावरणात.
- अखंड ऑनबोर्डिंग: Windows सोबत Apple डिव्हाइसेसचा मोठा ताफा व्यवस्थापित करणाऱ्या संस्थांसाठी, अस्तित्वात असलेल्या MDM वर्कफ्लोसह Intune समाकलित करणे (आमचे मार्गदर्शक Jamf and RADIUS: Certificate-Based WiFi Authentication for Apple Device Fleets पहा) पहिल्या दिवसापासून युनिफाइड, झिरो-टच प्रोव्हिजनिंग अनुभव सुनिश्चित करते.
महत्त्वाच्या संज्ञा आणि व्याख्या
SCEP (Simple Certificate Enrollment Protocol)
A protocol that allows devices to request digital certificates from a Certificate Authority, where the private key is generated and stored securely on the device itself.
The recommended method for deploying WiFi authentication certificates due to its high security and scalability.
PKCS (Public Key Cryptography Standards)
A set of standards where both the public and private keys are generated by the Certificate Authority and then securely delivered to the endpoint.
Often used for S/MIME email encryption, but less ideal for WiFi due to the network transmission of the private key.
NDES (Network Device Enrollment Service)
A Microsoft Windows Server role that acts as a bridge, allowing devices without domain credentials to obtain certificates via SCEP.
A required infrastructure component when implementing SCEP certificate deployment with Microsoft Intune.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
The most secure 802.1X authentication method, requiring both the server and the client to present valid digital certificates.
The target authentication protocol that the Intune WiFi and certificate profiles are designed to enable.
CRL (Certificate Revocation List)
A list published by the Certificate Authority containing the serial numbers of certificates that have been revoked before their expiration date.
Critical for security; RADIUS servers must check the CRL to ensure terminated employees cannot access the WiFi using an otherwise valid certificate.
Intune Certificate Connector
A software agent installed on an on-premises Windows Server that brokers requests between Microsoft Intune and the internal Certificate Authority.
Required for both SCEP (to validate requests) and PKCS (to export keys) deployments.
Subject Alternative Name (SAN)
An extension to a digital certificate that allows multiple values (like UPN, email, or MAC address) to be associated with the certificate.
Configured in the Intune SCEP profile to ensure the RADIUS server can accurately identify the user or device.
Azure AD Application Proxy
A feature that provides secure remote access to on-premises web applications without requiring a VPN or opening inbound firewall ports.
The best practice method for securely publishing the internal NDES server URL to the internet for remote device enrollment.
केस स्टडीज
A national retail chain with 500 locations is migrating from WPA2-Personal (Pre-Shared Key) to WPA3-Enterprise for their store associate tablets (Android Enterprise Dedicated Devices). They use Intune for MDM. How should they architect the certificate deployment?
- Deploy an NDES server published via Azure AD App Proxy.
- Create a Device-based SCEP certificate profile in Intune, as these are dedicated (kiosk) devices not tied to a specific user. Use
CN={{AAD_Device_ID}}for the Subject Name. - Deploy the Root CA profile to the 'All Store Tablets' Azure AD Device Group.
- Deploy the SCEP profile to the same 'All Store Tablets' group.
- Create a Wi-Fi profile configured for WPA3-Enterprise, EAP-TLS, referencing the SCEP profile, and deploy it to the same group.
- Configure the central RADIUS servers to authenticate the device certificates against the Active Directory computer objects.
A large conference centre uses Purple for their [WiFi Analytics](/products/wifi-analytics) and Guest WiFi, but needs to secure their internal staff network. Staff use a mix of corporate-owned Windows laptops and BYOD iOS devices. How do they handle the Intune deployment for the BYOD devices?
- Require BYOD users to enroll their iOS devices via Intune User Enrollment (creating a secure work partition).
- Create a User-based SCEP certificate profile using
CN={{UserPrincipalName}}. - Deploy the Root CA, SCEP, and Wi-Fi profiles to an Azure AD User Group (e.g., 'All Staff').
- When the user enrolls their personal device, Intune pushes the profiles specifically to the managed work partition.
- The device connects to the staff SSID using the user's identity, allowing the RADIUS server to apply role-based access control (VLAN assignment) based on their AD group membership.
परिस्थिती विश्लेषण
Q1. You have deployed the Root CA, SCEP, and Wi-Fi profiles to your Windows 10 devices. The certificates install successfully, but the Wi-Fi profile fails to apply, showing 'Error' in the Intune console. What is the most likely cause?
💡 संकेत:Check how the profiles are assigned to Azure AD groups.
शिफारस केलेला दृष्टिकोन दाखवा
The most likely cause is a mismatch in group targeting. If the SCEP profile was assigned to a User Group, but the Wi-Fi profile was assigned to a Device Group, Intune cannot resolve the dependency between them. All three profiles (Root, SCEP, Wi-Fi) must be targeted to the exact same group type.
Q2. Your security team mandates that private keys must never be transmitted across the network, even if encrypted. Which certificate deployment method must you use in Intune, and what additional infrastructure server is required?
💡 संकेत:Think about where the key pair is generated.
शिफारस केलेला दृष्टिकोन दाखवा
You must use SCEP (Simple Certificate Enrollment Protocol). Because SCEP instructs the endpoint device to generate the private key locally, it never traverses the network. This deployment requires a Network Device Enrollment Service (NDES) server to act as a bridge to the Certificate Authority.
Q3. A remote employee provisions a new laptop at home via Windows Autopilot. The Intune profiles deploy successfully, but the device fails to obtain the SCEP certificate. What infrastructure configuration is likely missing?
💡 संकेत:How does the device reach the internal CA from the internet?
शिफारस केलेला दृष्टिकोन दाखवा
The NDES server has likely not been published to the internet. For remote devices to request certificates before arriving at the corporate office, the NDES URL must be externally accessible, ideally published securely via Azure AD Application Proxy.
महत्त्वाचे निष्कर्ष
- ✓802.1X EAP-TLS is the standard for secure enterprise WiFi, requiring client certificates on all devices.
- ✓Microsoft Intune automates certificate deployment at scale using SCEP or PKCS profiles.
- ✓SCEP is highly recommended for WiFi as the private key is generated locally and never leaves the device.
- ✓Deployment requires a strict sequence: 1) Trusted Root, 2) SCEP Profile, 3) Wi-Fi Profile.
- ✓Group targeting (User vs. Device) must be identical across all three profiles to prevent dependency failures.
- ✓NDES servers should be published via Azure AD App Proxy to allow secure, remote certificate provisioning.
- ✓Strict CRL checking on the RADIUS server is mandatory to ensure revoked certificates cannot access the network.



