This article explains how to create and apply a Windows RADIUS Policy that instructs enrolled Windows devices to use secure Wi-Fi (WPA2/WPA3 Enterprise) via RADIUS authentication. By pushing this policy, you ensure all enrolled Windows endpoints automatically connect with the correct SSID, EAP settings, root certificates, and SCEP-issued certificates (if applicable).
Prerequisites
RADIUS Server: Make sure your RADIUS server (e.g., Windows NPS or third-party) is properly configured for WPA2/WPA3 Enterprise.
Certificates:
If using server validation, the RADIUS server must have a valid SSL certificate from a trusted CA.
If using device certificates (EAP-TLS), ensure you have either a root or intermediate CA certificate to push to clients and a mechanism for issuing client certs (SCEP).
Swif Admin Access: You need permission to create policies and configure SCEP or certificate distribution in the Swif console.
1. Create a New Windows RADIUS Policy
Navigate to Policies
In your Swif console, go to Policies → Create Policy.
Enable RADIUS Wi-Fi
Select Windows RADIUS Policy in the policy type
Name the Policy
Policy Name: For consistency, name it something like:
Windows RADIUS Policy
2. Important Wi-Fi Fields or XML to Configure
When creating your Windows RADIUS Policy, you will see a set of Wi-Fi parameters after selecting "Configure Wifi" and adding a "Wifi Profile".
You can upload a Wi-Fi XML:
VPN/Profile Name: A friendly name shown in Windows, e.g.
MyCorporateVPN.VPN/Profile XML: Paste the XML snippet that defines your Wi-Fi profile. This is where you specify the authentication and shared key. For more information, visit the WLAN_profile schema.
<WLANProfile xmlns="http://www.microsoft.com/networking/WLAN/profile/v1">
<name>MERT_TEST</name>
<SSIDConfig>
<SSID>
<hex>4d4552545f54455354</hex>
<name>SSID</name>
</SSID>
</SSIDConfig>
<connectionType>ESS</connectionType>
<connectionMode>auto</connectionMode>
<MSM>
<security>
<authEncryption>
<authentication>WPA2PSK</authentication>
<encryption>AES</encryption>
<useOneX>false</useOneX>
</authEncryption>
<sharedKey>
<keyType>passPhrase</keyType>
<protected>false</protected>
<keyMaterial>12344321</keyMaterial>
</sharedKey>
</security>
</MSM>
<MacRandomization xmlns="http://www.microsoft.com/networking/WLAN/profile/v3">
<enableRandomization>false</enableRandomization>
</MacRandomization>
</WLANProfile>
Alternatively, below are the critical fields to define:
2.1 SSID Name
SSID: Enter the exact Wi-Fi network name (e.g.,
CorpSecureWiFi).If the network is hidden, set Hidden SSID to “true” or equivalent, so Windows knows to search for it.
2.2 Authentication and Encryption Settings
Under Wi-Fi Policy → MSM → Security → authEncryption:
Authentication: Usually
WPA2orWPA3.
Use One X: Set to “true” (enables 802.1X/EAP).
Under Wi-Fi Policy → MSM → Security → Shared Key:
Key Type: May be used if you have a fallback or a separate pre-shared key scenario (commonly set to “networkKey” or “passPhrase” if you have a fallback WPA2-PSK network; often not used for RADIUS-based networks).
2.3 PMK Cache & Pre-Auth Settings
Under Wi-Fi Policy → MSM → Security:
PMKCacheMode
PMKCacheTTL
PMKCacheSize
PreAuthMode
These fields control how Windows devices cache Pairwise Master Keys (PMK) and whether they pre-authenticate to APs. Common defaults are:
PMKCacheMode: EnabledPMKCacheTTL: 720 minutes (12 hours)PMKCacheSize: 32PreAuthMode: Typically “disabled” unless you want pre-auth for roaming scenarios.
2.4 802.1X (OneX) Fields
Under Wi-Fi Policy → MSM → Security → OneX:
Auth Mode: Determines if authentication is per-user, per-machine, or “user or computer.” The typical setting for domain-joined devices is
machineOrUser.
2.4.1 EAP Configuration
Under Wi-Fi Policy → MSM → Security → OneX → EAP Config → EAP Host Config:
EAP Method → Type: The overarching EAP method, such as
13for EAP-TLS or25for PEAP, depending on the schema used. Enter Vendor ID, Vendor Type, and Auth ID if you have values.
Config → EAP → Type: The overarching EAP method, such as
13for EAP-TLS or25for PEAP, depending on the schema used.
Config → EAP → EAP Type → Credentials Source → Certificate Store → Simple Cert Selection: Enabling Simple Cert Selection streamlines the EAP-TLS flow: Windows quietly handles the certificate decision behind the scenes, improving user experience and minimizing misconfiguration.
Config → EAP → EAP Type → Server Validation → Disable User Prompt For Server Validation: If set to “true,” Windows won’t prompt end-users to confirm the RADIUS server’s certificate. This is recommended in managed environments.
Config → EAP → EAP Type → Different Username: Controls whether you can specify a separate username for authentication (often left “false”).
Config → EAP → EAP Type → Perform Server Validation: Usually set to “true” to ensure clients validate the RADIUS server certificate.
3. Configure the Root Certificate
If you want Windows endpoints to trust your RADIUS server certificate (and you’re using an internal CA or a CA not universally trusted), you must push a root certificate policy:
Configure Security Root Certificate
Check the box or enable the toggle to add a root or intermediate CA certificate.
Certificate Root Policy → Encoded Certificate
Paste in the base64-encoded certificate content. This ensures Windows devices trust the RADIUS server’s cert chain.
4. Set Up SCEP (If Using Client Certificates)
If your RADIUS configuration requires client/device certificates (EAP-TLS): Choose SCEP Service Provider
In your RADIUS Wi-Fi policy, you’ll see an option like SCEP Service Provider.
You can select a dedicated SCEP provider (e.g., SCEPMan) from the dropdown.
For instructions on using SCEPMan specifically, see How to Configure Swif.ai RADIUS Wi-Fi Policy Using SCEPMan.
Once configured, each Windows device will automatically request a client certificate via SCEP, then use that cert for RADIUS EAP-TLS.
5. Save and Deploy the Policy
Review Your Settings
Double-check the SSID, authentication modes, EAP types, and any certificate info.
Save
Click Create or Save to finalize.
Assign to Devices
Assign the Windows RADIUS Policy to your desired groups or devices.
Devices typically sync the next time they check in or run a policy update.
6. Verify the Connection
Check on a Test Device
After policy deployment, confirm the test Windows device automatically associates with the correct SSID.
Monitor RADIUS Logs
On the RADIUS server, verify successful EAP handshakes.
Validate Certificate Presence
If using SCEP, open certmgr.msc (for user certs) or the Local Machine store (for device certs) to see the newly issued certificate.
Troubleshooting
Device Won’t Connect
Ensure correct SSID and security type (WPA2-Enterprise or WPA3-Enterprise) are configured.
Verify the RADIUS server’s shared secret and the AP’s RADIUS settings match.
Certificate Errors
Check that the root or intermediate CA is installed on clients if you’ve enabled server validation.
If using SCEP for client certs, confirm the SCEP server is reachable, and the challenge is correct.
Authentication Prompt
If you set
Perform Server Validation= “false,” Windows may prompt users to accept a certificate. Switch it to “true” (and disable user prompt) for a silent, managed experience.
Conclusion
By configuring these fields in a Windows RADIUS Policy, you can seamlessly push WPA2/WPA3-Enterprise Wi-Fi settings to enrolled Windows devices, manage certificate trust via root cert distribution, and optionally use SCEP for client certificates (EAP-TLS). This ensures a secure, automatic connection to your RADIUS-managed Wi-Fi network with minimal user intervention.
If you need assistance or encounter any issues, reach out to Swif.ai Support or your internal IT team. Once set up, your Windows endpoints will enjoy a streamlined, enterprise-grade wireless experience backed by the robust authentication of RADIUS.