Security

Hi,

I configured a captive portal in Aruba Controller 6.5.4.3. The external captive portal (Clearpass) is shown but the RADIUS auth-request packet is not sent by the controller, as shown by stats, i.e.

"show aaa authentication-server radius statistics" counters for our RADIUS group are not incremented. No events or tracking issues are seen at CPPM. If you use the "radius test" on diagnostics controller's section it works, counters are incremented and the request reaches CPPM.

 

On the other side, "IP address" field in Clearpass NAS vendor settings for Clearpass portal is a name (network-login.xxx.org), whose server certificate is already installed on the controller:

crypto-local pki ServerCert certificadonetworklogin network-login.xxx.org.p12

 

Any clue? Why the radius group is not used by the captive-portal profile? The controller should intercept the POST and generate the RADIUS request.

 

This is the configuration of the aaa profile for the  virtual-ap:

show aaa profile aaa-prof-portal-FORM-PROF

AAA Profile "aaa-prof-portal-FORM-PROF"
------------------------------------------
Parameter Value
--------- -----
Initial role FORM_PROF_preauth
MAC Authentication Profile N/A
MAC Authentication Default Role guest
MAC Authentication Server Group default
802.1X Authentication Profile N/A
802.1X Authentication Default Role guest
802.1X Authentication Server Group N/A
Download Role from CPPM Disabled
Set username from dhcp option 12 Disabled
L2 Authentication Fail Through Disabled
Multiple Server Accounting Disabled
User idle timeout 1800 sec
Max IPv4 for wireless user 2
RADIUS Accounting Server Group radius_form_profes
RADIUS Roaming Accounting Disabled
RADIUS Interim Accounting Enabled
XML API server N/A
RFC 3576 server N/A
User derivation rules N/A
Wired to Wireless Roaming Enabled
SIP authentication role N/A
Device Type Classification Enabled
Enforce DHCP Enabled
PAN Firewall Integration Disabled
Open SSID radius accounting Disabled

------------------------------------------------------

------------------------------------------------------

user-role FORM_PROF_preauth
captive-portal "FORM_PROF-Portal"
access-list session global-sacl
access-list session apprf-FORM_PROF_preauth-sacl
access-list session logon-control
access-list session captiveportal
!

aaa authentication captive-portal "FORM_PROF-Portal"
default-role "rol_profesor_edu"
server-group "radius_form_profes"
guest-logon
no logout-popup-window
max-authentication-failures 3
login-page "https://myclearpass.xxx.org/guest/portal_login.php"
welcome-page "http://www.google.com"
white-list "CPPM_Lista_Blanca"
!
---------------------

aaa server-group "radius_form_profes"
auth-server grad-prepro-01
!
------------
aaa authentication-server radius "grad-prepro-01"
host "172.22.13.27"
key xxxxxxxxxxxxxxxxxxxxx
source-interface vlan 478 ip6addr ::

 

 

Thanks in advance

 

Just a quick glance it looks like you’re Mac auth server group is default. I believe it needs to be CPPM.

I don't need mac caching for guest users.

Anyway, I configured the same server group for mac auth with identical result: counters for my radius server don't increase after authentication through captive portal

 

 

Can you take a look at the Monitoring > Event Viewer
And see if any RADIUS errors are showing up there

Couple of things:
- Make sure the RADIUS shared key matches
- Under Security > Authentication > Advanced > RADIUS Client
It needs to be the local controller management IP (by default it uses the master controller)

Thanks Victor,

The event viewer does not show anything. In addition, if you route requests from the controller to Clearpass through a firewall, only ssl packets are seen, but not radius packets. This is consistent with radius statistics data supplied by the controller CLI.
 
On the radius client side, defined on the controller, the source IP configured is actually the IP controller, on vlan 466. This configuration should be overwritten by the particular radius server and its vlan source-interface, shouldn't it?

In my original scenario, previous to this post, the route to clearpass was set through this vlan interface(valn 466)  but it didn't work. Anyway I tried again configuring routing to Clearpass through the IP controller's vlan and deleting the source-interface line (vlan 478) from the definition of the radius server for the captive portal definition. The result is identical. No packets are received on Clearpass (event viewer)

Were you able to make this work?

 

Please also check with the 'show datapath fqdn' command on the controller that your certificate was properly loaded and matches the name network-login.xxx.org as you configured it in the ClearPass Guest page configuration.

 

Another step you can take is to revert back to the local captive portal on the controller, but still use ClearPass as authentication server, to see if that part works properly.

Thanks Herman,

 

show datapath fqdn

Datapath FQDN Entries
---------------------
network-login.xxx.org

 

I did another check using Chrome's Developer Tools. I thought that the RADIUS packet was issued by the controller on receiving a POST request addressed to "network-login.xxx.org" by the client. On the other hand, I see a request to Clearpass sending a POST request containing user and password. Why?  How could the controller intercept the POST in this way?

 

On reviewing "login form options" at Clearpass, I can confirm that "pre-auth check" is marked, what means this: "If checked, the username and password will be checked locally before proceeding to the NAS authentication. This option should not be selected if an external authentication server is in use.". This should led me to not configure this option, but the fact is that this captive portal is working on a production controller without issues. 

 

What the pre-auth feature does, is that the client first posts credentials to ClearPass which triggers an Application/internal/RADIUS/direct check against the Guest user database. That authentication should be handled and successful, so you should see (except for the direct/internal) an authentication from the local system coming into ClearPass.

 

One of the features of that, is that ClearPass can provide a fully skinned message back to the user on that and why the authentication fails. The authentication on the controller just says 'authentication failed'.

 

After that first authentication, the credentials are posted (again by the client) to the network-login.xxx.org, which should then issue a RADIUS request from the controller to ClearPass.

 

If you don't see the browser connecting to network-login.xxx.org, the config needs to be fixed.

 

If you disable pre-auth, the credentials will be posted to the controller immediately, so that will help you to determine if the issue is in the pre-auth or not.

Thanks a lot for your detailed explaination, defining a new captive portal without pre-auth checked, the client sends the POST request to the controller and a RADIUS request is produced.

 

So, I can confirm that the issue was produced by Clearpass pre-check functionality. I understood that I should see an authentication request (from internal source) but I cannot see it. Is there any log where the failed pre-auth check may be guessed?

 

Which setting did you put your Pre-Auth check on?

RADIUS is the 'safe bet' as it will pop an probably unmatched authentication in the Access Tracker. App Authentication/Authorization might need one of those as service configured and Local will never show up as it will do a lookup in the Guest user database directly (so doesn't support any other authentication source).

Clearpass 6.6.2 does not have the possibility to chose any option. I guess it only performs "local auth" which probable means direct access to the guest database, doesn't it?

Please upgrade as ClearPass 6.6.2 has known security vulnerabilities.

 

If you are using a Self registration flow, the setting is somewhat hidden. If you are in the flow overview screen, click on Login Message:

When you scroll up in the following screen, you will see the selector:

I don't have a 6.6, but I'm pretty confident that this still works the same.