I have been conducting a structured evaluation of JumpCloud's RADIUS capabilities as part of a broader identity and device management comparison, focusing on its integration with enterprise WiFi systems. During my test cycle, I have encountered a persistent and puzzling scenario that I believe warrants a detailed community discussion.
The core issue is as follows: the JumpCloud RADIUS Proxy logs within the Admin Console show successful authentication events (Access-Accept) for specific devices attempting to connect to our configured SSID. The logs indicate the correct user and device are being processed, and the authentication appears to succeed from JumpCloud's perspective. However, the end-state result is that the devices (a mix of macOS and Windows 10/11, all domain-joined or managed) fail to connect to the WiFi network. The failure on the client side typically manifests as a generic "can't connect" or "authentication failed" message after a prolonged attempt.
My methodology has been to isolate variables in the following order:
* **Client Configuration:** Verified 802.1X settings, certificate validity (for EAP-TLS), and user credential correctness.
* **Network Device (WAP/Controller) Configuration:** Confirmed RADIUS shared secret, IP addresses, and ports (1812/1813) are correctly set. Ensured the JumpCloud RADIUS Proxy IPs are allowed.
* **JumpCloud RADIUS User/System Group Mapping:** Validated that the users and devices are placed in the correct System Groups that are bound to the RADIUS application.
* **JumpCloud Policies:** No conflicting policies that would alter network settings post-authentication.
Despite this, the discrepancy between log and outcome remains. This points me to investigate areas where my visibility may be limited.
My primary hypotheses for the community to scrutinize are:
1. **Attribute Return:** The Access-Accept packet from JumpCloud's RADIUS Proxy may be missing specific Vendor-Specific Attributes (VSAs) that our wireless infrastructure (in this case, Cisco and Aruba) requires for final connection authorization, such as tunnel attributes for dynamic VLAN assignment. A "success" log entry does not guarantee the presence of these critical attributes.
2. **Network Path or Firewall:** While the initial authentication request (Access-Request) reaches JumpCloud and triggers a success, the subsequent accounting or post-authentication packets (perhaps on different ports) between the network device and JumpCloud, or between the network device and the client, could be blocked.
3. **Certificate Chain Issues (for EAP-TLS):** The JumpCloud-sourced certificate or the intermediate chain might not be fully trusted by the client or the network device in a specific way that only disrupts the connection phase after authentication.
I am particularly interested in hearing from members who have operationalized JumpCloud RADIUS in production, especially if you've encountered similar "logical success, practical failure" states. Detailed insights into:
* Your process for validating returned RADIUS attributes.
* Any required VSAs for your specific wireless vendors.
* Debugging steps on the network controller side (e.g., what a "successful" log entry looks like there versus a truly successful connection).
* Experiences with EAP-PEAP vs. EAP-TLS in this context.
A comparative analysis of how other IDP platforms handle attribute passing in their RADIUS implementations would also be valuable for contextualizing this as a potential JumpCloud-specific configuration gap versus a general architectural consideration.
This is a classic case where the RADIUS accept is just one piece of the puzzle. Your structured approach is spot on, but you've stopped at the network device. The Access-Accept packet from JumpCloud will contain specific RADIUS attributes that dictate what happens next.
You need to verify what's being passed in that Accept. The most common culprit I've seen in these integrations is a mismatch in the tunneling or VLAN assignment attributes (like Tunnel-Private-Group-ID) between what JumpCloud is configured to send and what your WAPs expect. The authentication succeeds, but the network device then fails to place the device into the correct network segment, causing the client to time out. Can you capture a RADIUS packet trace on your WAP or controller to see the exact attribute payload being returned? That's usually where the disconnect is.