Security

Hello,

 

is there a way to have already registered guests bypass Captive Portal authentication?

 

I am using a 7200 series controller running ArubaOS 6.2.1.1 as well as ClearPass Policy Manager 6.1 and ClearPass Guest 6.1

 

If a guest user disconnects from the guest SSID it takes a few minutes for the session to disappear from the controller.

 

Of course, once the guest user reconnects it is being put into its initial role and not into its authenticated role on the controller.

 

I have already fiddled around with the MAC Authentication Plugin on ClearPass Guest as well as the MAC Caching Enforcement Policy on CPPM but as far as I can see the controller doesn't even send a RADIUS request to the CPPM appliance.

 

Any help is appreciated! Thanks!

 

cheers,

Harald

At minimum you would need to configure a mac authentication profile in the AAA profile for that WLAN on the controller side.  That will send the mac address of the user from the controller to clearpass and bypass the captive portal.  You should then be able to see the mac authentication requests in the access tracker on ClearPass for those users.

 

Hello,

 

thanks, you did point me in the right direction!

 

I can now see the MAC address in the list of authentication requests on ClearPass. For some reason there is no service associated with the auth request. Of course, ClearPass does not know how to treat this request and rejects it.

 

What could be the reason for the auth request not having a service associated with it?

 

cheers,

Harald

If you are on 6.1 and you used a service template to create your guest configuration in CPPM, it would already be created.  If not, you would have to create it yourself.

 

If you are on 6.1, I would delete my manually created guest service and use the service template to create your guest network with MAC caching:

 

 

Yes, I am running 6.1 and I followed your suggestion. I have now used a service template to create a new guest configuration and disabled the manually created service.

 

However, the Service Name still isn't being transferred so ClearPass does not know which service to use.

 

Is this something that needs to be configured on the controller?

---

@hmayr wrote:

Yes, I am running 6.1 and I followed your suggestion. I have now used a service template to create a new guest configuration and disabled the manually created service.

 

However, the Service Name still isn't being transferred so ClearPass does not know which service to use.

 

Is this something that needs to be configured on the controller?

---

Okay,

 

Let us look at the service that was created.  Locate your Service that says Guest Authentication Guest Mac authentication check.  Click on the service rules tab.  The value of the second rule must match whatever SSID your guests are attaching to, otherwise the service will NOT handle the mac authentication.  If the incoming mac authentication cannot be classified, that second rule most likely is your issue:

 

Bloody hell... you look at the stuff a thousand times and you just don't see whats right in front of you...

 

I accidentally disabled the MAC authentication service that was created by the template because I thought it was the old service that I created manually.

 

Now I finally see the right service name but I get a REJECT for some reason. Thats something I can figure out tomorrow.

 

Thanks so much for pointing me in the right direction with the service template and everything!

Please look in the "Alerts" tab and see why it is rejected.

It could be rejected because that is a new user that has never authenticated, so there is no mac address for them, which is normal.

I still get an "Authentication failure" and "Access denied by policy".

 

I have attached the RADIUS log but as far as I can see the user (i.e. the MAC address) is found in the local database.

 

For some reason the DENY profile is applied to this request...

What does the Alerts Tab say?

 

From what it looks like, even though it gets the [user authenticated] and the [mac caching] profile, it denies for some reason.  Your policy should be checking for both and permitting this user on.

The alerts tab says

 

Error Code: 206

Error Category: Authentication failure

Error Message: Access denied by policy

 

It looks like the service template built a new database named MAC-Guest-Check and uses it for authorization.

 

I am not sure if ClearPass is able to get information from both this newly created database or the Insight database. The enforcement policy references them both in the conditions.

What are the rules in your enforcement policy?  This is what mine looks like:

 

This is the enforcement policy that was created by the service template:

 

Guest Authentication Mac Authentication Check should be the policy that you hit....

 

I finally opened a support case and the problem was more complex than I thought...

 

First of all the reason why I couldn't authenticate with the MAC address was because the endpoints (i.e. the Laptops or Smartphones from our Guest Users) did not have any "Guest Role ID" associated with them.

 

The "Guest Role ID" is supposed to be set to "1" for the Contractor role, "2" for the Guest Role and "3" for the Employee role.

 

This "Guest Role ID" is referenced as one condition in the Enforcement Profile of the MAC authentication service for the Guest SSID.

 

The reason why "Guest Role ID" was not set correctly was because I referenced the WLAN controller with two different IP addresses in ClearPass. In one instance I referenced the WLC with its physical address, in the other with its VRRP address.

 

That is why in the RADIUS logs I always got this message:

ERROR Common.NadClientTable - getNadClient: Unknown NadClient 172.22.2.10 

 

So I now have three network devices in ClearPass. The master controller with its physical IP address, the standby controller with its physical IP address and one for the VRRP address.

 

This way we got rid of the "Unknown NadClient" messages and the "Guest Role ID" is now set correctly.

 

As a result, my Guest WLAN now works the way I want! :-)