On Sep 14, 2022, at 8:05 PM, Evan Sharp <evan.sharp@coastmountainacademy.ca> wrote:
I am trying to configure FreeRADIUS to authenticate users on a guest SSID with Aruba's Instant virtual controller captive portal.
OK.
The FreeRADIUS server is currently configured only to perform an EAP-TTLS/GTC 802.1X authentication for supplicants on the Aruba IAPs (as client) using a LDAPS lookup.
That's good.
What I have found comparing debug outputs from successful 802.1X binds with unsuccessful captive portal client requests is that the Aruba Instant controller does not specify an EAP type (EAP-message attribute) in the request; credentials are sent in plaintext.
Yes, that's how captive portals typically work.
The server immediately rejects the bind because no other auth method than EAP-TTLS is configured. The Aruba Instant apparently cannot be configured to encrypt the captive portal request.
Yes,
My thought is that if I configured a secondary non-EAP authorization method, the FreeRADIUS could use it to process the captive portal requests. What auth method could work?
Typically PAP.
How can I secure this so that FreeRADIUS only uses it for the captive portal requests?
The simplest approach is to read the debug output to see what else is different between captive portal and 802.1X requests. Then, key off of that. if (matches captive port) { do captive portal stuff } Alan DeKok.