Configuring a Wi-Fi network with RADIUS (802.1X) authentication on Windows through Swif.ai involves setting up the RADIUS Wi-Fi profile, trusting the RADIUS server’s certificate, and providing a client certificate for authentication. This step-by-step guide will walk you through creating a Windows RADIUS Wi-Fi policy in Swif.ai that is provider-agnostic (meaning you can use any RADIUS and SCEP certificate provider). We’ll cover entering the Wi-Fi SSID and network settings (including hidden SSID and auto-switch options), obtaining the necessary Root CA certificate from your RADIUS provider, setting up SCEP for client certificates, and deploying the policy to devices. Follow the steps below to ensure a smooth configuration.
Step 1: Create a New Windows RADIUS Wi-Fi Policy in Swif.ai
Navigate to Policies: Log in to the Swif.ai portal and go to the Device Management section. Open the Policies tab.
Start a New Policy: Click on the option to create a new policy (for example, "Create from scratch"). In the policy type search or list, find and select the RADIUS Wi-Fi Configuration Policy for Windows devices. This begins the RADIUS Wi-Fi policy creation process.
Policy Name and Description: Give the policy a clear name (e.g., "Corporate Wi-Fi (RADIUS)") and an optional description. This helps identify the policy later.
Step 2: Enter Wi-Fi SSID and Network Details
Once the RADIUS Wi-Fi policy template is open, you'll need to configure the Wi-Fi network settings:
SSID (Network Name): Enter the SSID of the wireless network exactly. SSIDs are case-sensitive, so make sure it matches the network’s name precisely. If your organization uses an SSID prefix pattern (for example, multiple campus networks starting with "CorpWiFi"), and Swif.ai offers an SSID prefix option, you can use that; otherwise, use the full SSID.
Hidden/Non-Broadcast Network: If the Wi-Fi network does not broadcast its name (hidden SSID), enable the option for Hidden Network or Non-Broadcast SSID. This tells the device to proactively seek out the network even if it's not advertising its presence. (On some systems this is described as “Connect even if the network is not broadcasting its SSID”.)
Auto-Switch (Preferred Network Behavior): Decide on the Auto Switch setting (sometimes labeled "Connect to more preferred network if available"). If your devices know multiple networks, enabling auto-switch allows them to jump to a more preferred network when available. For example, if you have both a guest network and this corporate network saved, you might disable auto-switch (set to “No” for Connect to a more preferred network) to ensure devices stay on the corporate network when it's in range. Conversely, if you want the device to roam to, say, a stronger or more preferred Wi-Fi, keep it enabled.
Step 3: Trust the RADIUS Server – Add the Root CA Certificate
For 802.1X authentication, the RADIUS server presents a certificate to the client. To avoid any trust warnings and to ensure security, the client (Windows device) must trust the certificate authority that issued the RADIUS server’s certificate:
Get the Root CA (or intermediate CA) certificate that signed your RADIUS server’s certificate. This might come from:
Your RADIUS service provider’s dashboard or documentation. (For example, Foxpass provides a downloadable “Client CA” certificate in its console (Windows Manually).)
Your organization’s internal Certificate Authority, if you run your own RADIUS (e.g., Microsoft NPS with Active Directory Certificate Services). In that case, export the root CA certificate.
Another cloud RADIUS or Cloud PKI provider (refer to their docs for obtaining the trust anchor certificate).
Add the Root CA to the Policy: In the Swif.ai RADIUS Wi-Fi policy settings, look for a section to validate server certificates or Root Certificates for the Wi-Fi network. Copy and paste the Root CA certificate file content obtained in the previous step. This ensures the Windows device will trust the RADIUS server’s certificate during the EAP handshake (Windows Manually).
Note: If your RADIUS server uses a publicly trusted certificate (signed by a well-known CA like DigiCert, Let’s Encrypt, etc.), many Windows devices will already trust it by default. In that case, adding the root certificate to the profile is not strictly required. However, it doesn’t hurt to include it for completeness (and is necessary if the CA is private or not universally trusted by Windows).
Step 4: Configure SCEP for Client Certificate Enrollment
For EAP-TLS authentication, each device needs its own identity certificate. Swif.ai can leverage SCEP (Simple Certificate Enrollment Protocol) to automatically issue and install a client certificate on the Windows device:
In the RADIUS Wi-Fi policy configuration, find the section to configure the Identity Certificate or SCEP settings for the Wi-Fi:
SCEP Generate Certificate API Endpoint URL: Paste the API endpoint to generate SCEP client certificates for enrollment from your provider into the appropriate field. Double-check for any formatting requirements.
API Key: Enter the API key required to authenticate and request a certificate using the Generate Certificate API in the provided field. This will be used by the device to request the certificate.
Currently, Swif supports Foxpass and SCEPman as SCEP certificate providers. Under the SCEP Service Provider section, select either Foxpass or SCEPman depending on your setup.
If you use Foxpass, you need:
API Key: Enter the API key required to authenticate and request a certificate using the Generate Certificate API in the provided field. This will be used by the device to request the certificate.
If you use SCEPman:
Prerequisites: Follow the Step 1: Set Up an Azure App Registration for SCEPman to set up Swif SCEP API and configure SCEPman in the Azure Portal.
For SCEPman, enter the following keys in the Swif RADIUS policy:
Tenant ID
Client ID
Client Secret
SCEPMan API App ID
SCEP App Service Default Domain
To obtain these details, follow the Step 2: Obtain Required SCEPman Keys from Azure documentation.
Save SCEP Configuration: Ensure these SCEP settings are saved/applied within the RADIUS Wi-Fi policy. SWIF will now know how to obtain a client certificate for any device that receives this policy. During deployment, the device will contact the SCEP Provider with the provided keys to fetch a certificate, which it will use for Wi-Fi authentication.
Step 5: Review and Deploy the RADIUS Wi-Fi Policy
With all parameters set, finalize the policy and push it to your devices:
Review Settings: Double-check the RADIUS Wi-Fi profile details before saving. Confirm the SSID is correct, the hidden network option is appropriately set, auto-connect/switch as desired, the Root CA is added, and the SCEP info is correct. Scanning through the summary or configuration screen can prevent mistakes.
Save/Publish the Policy: Click Next or Save to finalize the policy configuration. If prompted, you can assign the policy to target devices or groups. Choose the Windows device(s) or group that needs this Wi-Fi configuration. (If not prompted, you may need to go to the policy list afterward and assign the policy to devices or a Smart Group.)
Ensure Connectivity for Deployment: Once deployed, the policy will be sent to the device over the Internet. Important: The device must be online to receive this policy. If the device is currently using Wi-Fi and you are replacing that network or disconnecting it, be cautious. It’s best to have the device on a wired connection or otherwise online during the rollout. This ensures it can reach the Swif.ai service to get the new settings before losing any existing Wi-Fi connection.
Connection Establishment: The Windows device will install the new Wi-Fi profile. It will place the Root CA certificate into the trusted store (if not already present) and request a client certificate via SCEP. After that, it should automatically attempt to connect to the Wi-Fi SSID using the credentials (certificate) provided:
You should see the Wi-Fi network appear as “Connected” on the device if everything is correct. No user action is required if auto-connect was enabled and the certificate was obtained silently.
If it doesn’t connect automatically, have the user select the network (which will show up with the “Connection name” you configured, if applicable) and attempt to connect. They should not be prompted for a password since a certificate is used; the authentication will happen in the background.
Step 6: Troubleshooting Tips
If the device fails to connect after policy deployment, consider these troubleshooting steps:
Certificate Trust Issues: If you get a warning about “unable to find a certificate” or “server not trusted,” recheck that the Root CA was correctly added to the policy. On the Windows device, you can open Certificates (Local Computer) > Trusted Root Certification Authorities to verify the CA is installed. Also confirm the RADIUS server’s certificate is valid (not expired, and issued by that CA). The RADIUS Wi-Fi profile should have “Validate server certificate” enabled with the correct CA (Windows Manually).
SCEP/Certificate Enrollment Problems: Ensure the device can reach the SCEP Generate Certificate API URL. If the SCEP API key was incorrect, the certificate enrollment would fail. You might see errors in the Swif.ai console or event logs on Windows (Event Viewer under Microsoft > Windows > WLAN-AutoConfig or DeviceManagement-Enterprise-Diagnostic channels). If using a third-party CA, check their logs or dashboard to see if a request came in. Correct the URL or key if needed and re-push the policy.
Network Name and Availability: Verify the SSID is in range of the device and the name matches. If the network is hidden, ensure the hidden option is enabled so the device is actively probing for it. If possible, test by broadcasting the SSID (temporarily) to rule out issues with hidden networks.
RADIUS Server Logs: Check your RADIUS server’s logs to see if the device is hitting the server and if there are authentication errors. Common issues can be an untrusted client certificate (e.g., the RADIUS only trusts certificates from a specific CA or with specific attributes—ensure your SCEP-issued cert meets those), or the device might be presenting a user certificate when the server expects a machine certificate or vice versa (adjust the authentication mode if so).
Conclusion
By following these steps, you have configured a Swif.ai policy that allows Windows machines to connect to a RADIUS-protected Wi-Fi network using enterprise authentication. The process involved specifying the Wi-Fi details, enabling hidden network and auto-connect settings as needed, and setting up the necessary certificate infrastructure (trusting the RADIUS server’s CA and issuing a client certificate via SCEP). Once deployed, your users’ Windows devices should automatically and securely connect to the Wi-Fi network without needing to enter credentials, thanks to the certificate-based (EAP-TLS) authentication (Extensible Authentication Protocol (EAP) for network access in Windows | Microsoft Learn). This improves security and user experience by leveraging a robust, passwordless Wi-Fi login.
Enjoy your securely connected network, and if you need to adjust any settings, you can update the policy in Swif.ai and redeploy it. Happy networking!