Microsoft Intune का उपयोग करके डिवाइसों पर WiFi प्रमाणपत्रों को कैसे पुश करें

HOW TO USE MICROSOFT INTUNE TO PUSH WIFI CERTIFICATES TO DEVICES A Purple Enterprise WiFi Intelligence Briefing [INTRODUCTION & CONTEXT — approximately 1 minute] Welcome back. I'm speaking today on behalf of Purple, the enterprise WiFi intelligence platform, and this episode is a focused briefing on one of the most practical — and honestly, most underrated — capabilities in the Microsoft Intune toolkit: automated certificate deployment for 802.1X WiFi authentication. If you're managing WiFi across a hotel estate, a retail chain, a stadium, or a public-sector estate, you'll know the pain point I'm about to describe. You've got hundreds or thousands of managed devices. You want them to connect to your corporate WiFi automatically, securely, without users typing passwords, without IT touching every single device. And you want that connection to be cryptographically strong — not just a shared password that someone's already emailed to half the organisation. That's exactly what Intune certificate deployment solves. And in the next nine minutes, I'm going to walk you through how it works, how to deploy it, and the pitfalls that catch most teams out on the first attempt. [TECHNICAL DEEP-DIVE — approximately 5 minutes] Let's start with the architecture. The foundation here is IEEE 802.1X — the port-based network access control standard that's been the backbone of enterprise WiFi security for over two decades. When a device connects to your WiFi, 802.1X requires it to authenticate before it gets any network access. The authentication conversation happens between three parties: the device — called the supplicant — your WiFi access point, which acts as the authenticator, and your RADIUS server, which is the authentication server that makes the final decision. Now, 802.1X supports multiple authentication methods. The most secure is EAP-TLS — Extensible Authentication Protocol with Transport Layer Security. EAP-TLS uses mutual certificate authentication: the device presents a certificate to prove its identity, and the RADIUS server presents a certificate to prove its identity. No passwords involved. No credentials that can be phished. This is what we're aiming for. The challenge has always been getting those certificates onto devices at scale. That's where Microsoft Intune comes in. Intune supports two certificate deployment mechanisms: SCEP — Simple Certificate Enrollment Protocol — and PKCS, which stands for Public Key Cryptography Standards. Understanding the difference matters. With SCEP, the private key is generated on the device itself. The device creates a Certificate Signing Request, sends it to your Certificate Authority via an intermediary server called NDES — the Network Device Enrollment Service — and the CA issues the certificate back. The private key never leaves the device. This is the more secure approach and is recommended for BYOD environments and high-security deployments. With PKCS, the Certificate Authority generates the key pair, and the Intune Certificate Connector delivers the private key and certificate to the device. It's simpler to set up — no NDES server required — but the private key does transit through the connector, which is a consideration for your security posture. For most enterprise deployments I'd recommend SCEP for BYOD and mixed-device environments, and PKCS where you have a homogeneous fleet of corporate-owned Windows devices and want to minimise infrastructure complexity. Now, let's talk about the deployment sequence — because the order matters and getting it wrong is the most common cause of failed rollouts. Step one: configure your Certificate Authority. You need a certificate template on your Active Directory Certificate Services instance — or if you're fully cloud-native, Microsoft's Intune Cloud PKI is now generally available and removes the on-premises CA requirement entirely. The template needs the correct key usage extensions: Client Authentication is mandatory. Set the minimum key size to 2048 bits, or 4096 if your organisation's security policy requires it. Step two: deploy the trusted root certificate. Before any device can validate the RADIUS server's certificate, it needs to trust the CA that issued it. You create a Trusted Certificate configuration profile in Intune, upload the root CA certificate, and assign it to your device groups. This must land on devices before any WiFi profile or client certificate profile. If you get the sequencing wrong, devices will reject the RADIUS server and you'll spend an afternoon staring at Event ID 20271 in the Windows event log. Step three: deploy the client certificate profile. This is either your SCEP profile — pointing at your NDES server URL — or your PKCS profile, pointing at your Certificate Authority. The Subject Alternative Name should include the User Principal Name for user certificates, or the AAD Device ID for device certificates. This distinction matters: user certificates authenticate the logged-in user, device certificates authenticate the machine itself, which means the device can connect to WiFi before a user logs in — useful for domain join scenarios and kiosk deployments. Step four: create the WiFi configuration profile. In Intune, this is under Devices, Configuration Profiles, Templates, Wi-Fi. Set the WiFi type to Enterprise, enter your SSID, set EAP type to EAP-TLS, configure the server trust settings — this is where you reference the RADIUS server certificate name — and for client authentication, reference the certificate profile you created in step three. Step five: assign everything to the right groups and validate. Assign your root certificate, client certificate, and WiFi profiles to the same device or user groups. Use Intune's built-in reporting to monitor profile deployment status. A successful deployment shows all three profiles as Succeeded in the device's configuration profile list. One critical point on NPS configuration for Windows Server environments: from early 2024, Microsoft tightened certificate mapping requirements. If you're using device certificates with Azure AD-joined devices authenticating against on-premises NPS, you need to ensure the altSecurityIdentities attribute on the computer object in Active Directory is populated with the certificate's thumbprint. This doesn't happen automatically — you need a script or a workflow to handle it, typically triggered when the CA issues a new certificate. [IMPLEMENTATION RECOMMENDATIONS & PITFALLS — approximately 2 minutes] Let me give you the three pitfalls that I see most frequently in enterprise deployments. Pitfall one: certificate chain gaps. The device needs to trust every certificate in the chain from the root CA down to the RADIUS server's certificate. If your RADIUS server certificate was issued by an intermediate CA, you need to deploy both the root and the intermediate to devices. I've seen deployments fail for weeks because someone deployed the root but not the intermediate. Pitfall two: profile assignment timing. Intune profiles don't land on devices instantaneously. In a large estate, it can take 15 to 30 minutes for profiles to propagate after assignment. Don't test immediately after creating profiles. Use the Sync button in the Intune portal to force a check-in, then wait. Also, client certificate profiles must be deployed and confirmed before the WiFi profile is applied — if the WiFi profile references a certificate that doesn't exist yet, the profile will fail silently on some platforms. Pitfall three: BYOD certificate revocation. When a device is unenrolled from Intune — because an employee leaves, or a device is lost — you need a process to revoke the certificate. If you're using SCEP with ADCS, configure the Certificate Revocation List distribution point correctly and ensure your RADIUS server is checking CRL or OCSP on every authentication. This is a compliance requirement under frameworks like PCI DSS, which mandates that access control mechanisms be revoked promptly when no longer needed. On the topic of compliance: if you're operating in a PCI DSS scope — retail payment environments, for example — certificate-based 802.1X authentication is your strongest control for wireless network access. It satisfies PCI DSS Requirement 1.3 around network access controls and Requirement 8.6 around authentication factors. Document your certificate lifecycle management process as part of your compliance evidence. For GDPR-regulated environments, particularly in hospitality and public-sector, the separation between your corporate 802.1X network and your guest WiFi network is critical. Your corporate Intune-managed network should be on a completely separate VLAN and SSID from any guest or visitor network. Purple's guest WiFi platform handles the visitor-facing side — captive portal, consent capture, analytics — while your Intune-managed corporate network handles staff and operational devices. These two networks should never share authentication infrastructure. [RAPID-FIRE Q&A — approximately 1 minute] Let me run through a few questions that come up regularly. Can I use Intune Cloud PKI instead of on-premises ADCS? Yes. Microsoft's Intune Cloud PKI, released in 2024, provides a fully managed CA in Azure. It removes the NDES server requirement for SCEP and simplifies the connector setup significantly. For greenfield deployments or organisations without existing ADCS infrastructure, it's the recommended path. Does this work for macOS and iOS devices? Yes. Intune supports certificate profiles for Windows, iOS, iPadOS, Android, and macOS. The profile types and configuration options vary slightly by platform, but the core architecture — trusted root, client certificate, WiFi profile — is consistent. What about personal devices in a BYOD programme? SCEP is your friend here. With Intune's device compliance policies, you can require that a device meets minimum security standards before a certificate is issued. If the device falls out of compliance — no screen lock, outdated OS — the certificate can be revoked and network access removed automatically. Can Purple integrate with this architecture? Absolutely. Purple's platform sits on the guest network side, handling captive portal authentication, consent management, and analytics. The corporate 802.1X network and Purple's guest WiFi operate in parallel — same physical infrastructure, different SSIDs and VLANs — giving you complete separation between staff connectivity and visitor engagement. [SUMMARY & NEXT STEPS — approximately 1 minute] To wrap up: deploying WiFi certificates via Intune is a five-step process — CA configuration, trusted root deployment, client certificate profile, WiFi profile, and group assignment. Choose SCEP for BYOD and high-security environments; PKCS for simpler corporate-owned fleets. Get the sequencing right, handle the NPS certificate mapping requirement, and build a certificate revocation workflow from day one. The business case is straightforward: you eliminate shared WiFi passwords, you get per-device and per-user authentication logs, you satisfy PCI DSS and ISO 27001 wireless security requirements, and you reduce the IT overhead of managing WiFi credentials across a large estate. If you're planning a deployment and want to understand how Purple's guest WiFi and analytics platform fits alongside your corporate network architecture, visit purple.ai. We've got detailed guides on Azure Entra ID integration, 802.1X architecture, and guest network design for hospitality, retail, and public-sector environments. Thanks for listening. Until next time.