Wireless Access

Airheads Community

Airheads Community		remove preview
Airheads Community View the selected document's details View this on Airheads Community >

In the documentation here the text reads "The default captive portal workflow for Aruba controllers uses a controller-initiated login where the client browser submits the required credential to the controller, and the controller sends a RADIUS request to the AAA server to validate the credentials." So far, so good. 

However, I don't understand what the 'aruba-controller.xyz.com' field is specifying. I understand this needs to match with a cert installed on the controller. But why?

In the excellent AOS YouTube video on the subject, there's a great graphic showing the client-controller-clearpass exhange that's happening: 

But there's a mysterious step here: "Login to captive-portal (certificate name)". This seems to be the same concept covered in the documentation, but what exactly is happening here? 

There's an airheads post in which the great cjoseph references a now-broken link to documentation that looks relevant, but alas, that content appears to be no longer available.

Any help would be greatly appreciated!

Controller/IAP will intercept DNS request to this address and  resolve it locally to the controller/IAP address so it can respond with captive portal page.

Best, Gorazd

Ok that makes some sense, but what causes the client to send a DNS request to this address in the first place? I thought the redirect was handled solely by the controller via the http/s redirect specified in the role. 

Basic flow when using an external captive portal:

1. Client initiates request for HTTP/HTTPS resource (we can ignore the DNS request for this) and the controller/AP intercepts the request
2. Controller/AP responds to HTTP/HTTPS with a redirect pointing the client device at the captive portal URL (this is technically a man-in-the-middle action since the controller/AP will respond on behalf of the originally requested server)
3. Client follows the redirect to the captive portal and goes through the login process
4. Captive portal credential submission includes instruction for the client to POST credentials to the Controller/AP, using the FQDN as noted
5. RADIUS authentication happens

The FQDN of the controller/AP must have an associated certificate, and that certificate must be specified for the purpose of captive portal.  The controller/AP will then intercept DNS requests for that FQDN and respond with the device IP, important point here is that the FQDN used by the controller/AP for captive portal should NOT be resolvable via normal DNS.  This implementation allows the client to securely submit credentials to the controller/AP without having to know the IP address of the specific controller/AP that the client is associated with and also allows the controller/AP captive portal certificate to be used on all controllers/APs in the network.

This is great, thanks very much for the explanation!