如何使用 Microsoft Intune 將 WiFi 憑證推送到裝置

Executive Summary

For enterprise IT leaders managing large-scale environments across Hospitality , Retail , or public-sector venues, secure wireless access is a baseline operational requirement. Relying on shared PSKs (Pre-Shared Keys) or username/password authentication (PEAP-MSCHAPv2) exposes the network to credential theft, phishing, and compliance failures. The industry standard for robust enterprise WiFi security is 802.1X with EAP-TLS (Extensible Authentication Protocol with Transport Layer Security), which mandates mutual certificate-based authentication between the device and the network.

However, the primary barrier to EAP-TLS adoption has historically been the operational overhead of certificate lifecycle management. Microsoft Intune resolves this by automating the delivery, renewal, and revocation of digital certificates to managed devices at scale.

This technical reference details the architecture, deployment methodologies (SCEP vs PKCS), and implementation steps required to push WiFi certificates via Microsoft Intune. It provides actionable guidance for network architects and systems engineers tasked with securing corporate communications while maintaining strict separation from visitor networks, such as those managed by a Guest WiFi platform.

Technical Deep-Dive: Architecture and Protocols

To implement certificate-based authentication effectively, IT teams must understand the interaction between the Mobile Device Management (MDM) platform, the Public Key Infrastructure (PKI), and the network access control layer.

The 802.1X Authentication Framework

The IEEE 802.1X standard defines port-based network access control. In a wireless context, it prevents a device from passing any traffic (other than EAP authentication frames) until its identity is verified. The architecture consists of three components:

1. Supplicant: The client device (laptop, smartphone, tablet) requesting network access.
2. Authenticator: The wireless access point or wireless LAN controller that blocks traffic until authentication succeeds.
3. Authentication Server: The RADIUS (Remote Authentication Dial-In User Service) server, such as Microsoft Network Policy Server (NPS) or Cisco ISE, which validates the credentials and authorises access.

EAP-TLS and Mutual Authentication

EAP-TLS is the most secure EAP method because it requires mutual authentication. The RADIUS server presents its certificate to the supplicant to prove it is the legitimate corporate network (preventing evil-twin attacks), and the supplicant presents its client certificate to the RADIUS server to prove it is an authorised device or user.

Intune Certificate Deployment Mechanisms: SCEP vs PKCS

Microsoft Intune supports two primary protocols for deploying client certificates to devices. Selecting the appropriate mechanism is a critical architectural decision.

Simple Certificate Enrollment Protocol (SCEP)

With SCEP, the private key is generated directly on the client device. The device creates a Certificate Signing Request (CSR) and submits it via Intune to the Network Device Enrollment Service (NDES) server, which acts as a proxy to the Active Directory Certificate Services (ADCS) infrastructure. The CA issues the certificate, which is returned to the device.

Because the private key never leaves the device, SCEP is considered highly secure and is the recommended approach for BYOD (Bring Your Own Device) deployments and zero-trust architectures.

Public Key Cryptography Standards (PKCS)

With PKCS, the Intune Certificate Connector requests the certificate from the CA on behalf of the device. The CA generates both the public certificate and the private key, which the connector then securely delivers to the device via Intune.

While PKCS simplifies the infrastructure requirements (no NDES server is needed), the private key is transmitted across the network. This model is generally acceptable for corporate-owned, fully managed device fleets where the MDM platform is already a highly trusted component.

Implementation Guide: Step-by-Step Deployment

Deploying Wi-Fi certificates via Intune requires precise sequencing. Deploying profiles out of order is the most common cause of implementation failure.

Step 1: Prepare the Public Key Infrastructure (PKI)

Whether utilising on-premises ADCS or a cloud-native solution like Microsoft Cloud PKI, the Certificate Authority must be configured with the appropriate templates.

• Key Usage: The template must include the Client Authentication OID (1.3.6.1.5.5.7.3.2).
• Key Size: Configure a minimum key size of 2048 bits (RSA) to align with modern cryptographic standards.
• Subject Name: For user certificates, the Subject Alternative Name (SAN) should be configured to use the User Principal Name (UPN). For device certificates, use the Azure AD Device ID.

Step 2: Deploy the Trusted Root Certificate

Before a device can authenticate, it must trust the CA that issued the RADIUS server's certificate.

1. Export the Root CA certificate (and any intermediate CA certificates) in .cer format.
2. In the Intune admin centre, navigate to Devices > Configuration profiles > Create profile.
3. Select the platform and choose the Trusted certificate profile type.
4. Upload the .cer file and assign the profile to the target device or user groups.

Note: This profile must successfully apply to devices before proceeding to the next steps.

Step 3: Deploy the Client Certificate Profile

Create either a SCEP or PKCS certificate profile to deliver the identity certificate to the supplicant.

1. Navigate to Devices > Configuration profiles > Create profile.
2. Select the platform and choose either SCEP certificate or PKCS certificate.
3. Configure the Subject Name format and SAN according to your identity requirements (User vs. Device).
4. Specify the Key Storage Provider (KSP) — typically the Trusted Platform Module (TPM) for hardware-backed security.
5. Assign the profile to the same groups targeted in Step 2.

Step 4: Configure the WiFi Profile

The final component binds the certificates to the wireless network settings.

1. Navigate to Devices > Configuration profiles > Create profile.
2. Select the platform and choose the Wi-Fi profile type.
3. Set the Wi-Fi type to Enterprise and enter the exact SSID.
4. Set the EAP type to EAP-TLS.
5. Under Server Trust, specify the exact name of the RADIUS server certificate and select the Trusted Root certificate profile deployed in Step 2.
6. Under Client Authentication, select the SCEP or PKCS certificate profile deployed in Step 3.
7. Assign the profile to the target groups.

Best Practices & Strategic Recommendations

Device vs. User Certificates

Network architects must decide whether to issue certificates to the device (machine authentication) or the user (user authentication).

• Device Certificates: Allow the machine to connect to the WiFi network before a user logs in. This is critical for initial device provisioning, Group Policy processing, and password resets at the login screen. Recommended for corporate-owned devices.
• User Certificates: Tie network access to the individual's identity. This provides granular auditing and role-based access control. Recommended for BYOD scenarios.

Network Segmentation and Guest Access

A fundamental security principle is the strict logical separation of the corporate 802.1X network from visitor or public access networks. The Intune-managed infrastructure should be dedicated exclusively to corporate devices and authenticated staff.

For visitor access, organisations should deploy a dedicated Guest WiFi SSID backed by a captive portal. This ensures that unmanaged devices are isolated, while still allowing the business to capture visitor analytics via a WiFi Analytics platform. To learn more about securing DNS infrastructure across both segments, review our guide on how to Protect Your Network with Strong DNS and Security .

Addressing the NPS Certificate Mapping Requirement

For organisations utilising Microsoft Network Policy Server (NPS) with Azure AD-joined devices, a critical configuration change was introduced by Microsoft. NPS now requires strong certificate mapping.

When using device certificates, the computer object in the on-premises Active Directory must have its altSecurityIdentities attribute populated with the certificate's details (typically the X509IssuerSerialNumber). IT teams must implement a scheduled script or event-driven workflow to update this attribute when Intune issues a new certificate, otherwise authentication will fail.

Troubleshooting & Risk Mitigation

When an 802.1X deployment fails, the issue almost always resides in the certificate chain or the Intune profile sequencing.

Common Failure Modes

1. Silent WiFi Profile Failure: If the Intune WiFi profile is applied to a device before the client certificate has been successfully provisioned, the WiFi profile will often fail to install or will fail silently. Always verify certificate presence in the device's Personal store (certmgr.msc on Windows) before troubleshooting the WiFi configuration.
2. Server Trust Validation Errors: If the device rejects the RADIUS server, verify that the server name specified in the Intune WiFi profile exactly matches the Subject Name or SAN on the RADIUS server's certificate. Additionally, ensure that the entire certificate chain (Root and Intermediate) is present in the device's Trusted Root Certification Authorities store.
3. Certificate Revocation List (CRL) Unavailability: If the RADIUS server cannot reach the CA's CRL distribution point to verify the client certificate's status, authentication will be denied. Ensure the CRL URL is highly available and accessible from the RADIUS server.

ROI & Business Impact

Transitioning to certificate-based WiFi authentication via Intune delivers significant operational and security returns.

• Risk Mitigation: Eliminates the risk of credential harvesting, pass-the-hash attacks, and unauthorised network access via shared PSKs.
• Operational Efficiency: Reduces IT helpdesk tickets related to password expirations and WiFi connectivity issues. The automated lifecycle management means certificates are renewed transparently without user intervention.
• Compliance Enablement: Satisfies stringent regulatory requirements. For retail environments, it directly addresses PCI DSS requirements for robust wireless encryption and authentication. For public sector and healthcare, it aligns with zero-trust network access (ZTNA) principles.

By leveraging Microsoft Intune for certificate deployment, IT teams can achieve a frictionless, highly secure wireless experience that operates silently in the background, allowing the business to focus on core operations.