Security

Do you have any technote or samples for integrating ClearPass with Cisco WLC using two phase approach:

 

1- MAC Authentication Bypass where ClearPass return url-redirect link and ACL to WLC

2- Webauth

 

my main confusion is whether CoA should be sent or WLC will accept radius message in the 2nd phase even if the session is active.

 

Customer is looking for Guest Internet access after acespting AUP. He prefers this method as it is more flexible and different webpages can be pushed for different SSIDs and this can be managud comletely from ClearPass

I can tell you it works, I've had it setup for awhile, but I can't easily explain how to set it all up. I couldn't find any comprehensive guide either, so I had to piece it all together. I believe I used the wizard to create a service for 'Guest access with MAC caching' then customized it from there. 

 

Here's the basic workflow:

1. MAC Auth service
   1. Authentication set to 'Allow All MAC Auth'
   2. Role mappings based on Guest Role ID (from clearpass guest) for traditional guest/contractor/employee, but then I also setup different roles for different captive portals, and map those roles based on AP Name, SSID, etc. 
   3. Enforcement. If the MAC auth maps to the MAC Caching role (built by the wizard), then send back an Accept along with a guest profile, this will send back to the Cisco WLC the username of the guest, for example.If the guest was MAC cached previously, authentication is done. 
   4. Now, If is NOT a MAC cache client, here's where we have to redirect. So my next enforcement profiles are matching my different roles to dofferent CoA Redirects. I have different ones for different captive portals. This is where you use Radius, Cisco-AVPair with url-redirect and url-redirect-acl. The ACL must already exist on the WLCs and provide access to the CP server via HTTPS and DNS servers at a minimum. DHCP is assumed I believe. 
   5. Client gets redirected to CP guest, your guest page needs to be setup for Cisco, and I have the Guest page setup for server-initiated CoA. I'm pretty sure I had this setup for controller-initiated in the beginning, but changed it to CoA to better match up with the Aruba suggested configs. 
2. WebAuth Service. 
   1. Now that the client is at the Guest page, when they login (or just click 'accept') Clearpass guest hit's the WebAuth service. 
   2. The enforcement here sends back the MAC Caching profile/expiration date, then a CoA for Radius:Cisco:Cisco-AVPair subscriber:command=reauthenticate. This is what forces the user to re-authenticate, they now hit the MAC Auth service again, but this time are MAC cached, and authenticated with access-allow. 

That was a long answer to your question I think. TL;DR: in the second phase, I send a CoA to force the user to re-auth. They then hit the MAC Auth service again, this time already cached, and are then given the access-accept. So really it makes it 3 steps, 1. MAC Auth (URL redirect), 2. WebAuth (CoA Reauth), 3. MAC Auth, cached (accept)

 

This solution actually works really well, just complicated to setup. It's nice because there is a ton of flexibility doing all the url-redirects from CPPM, we have multiple captive portals that can be chosen dynamically based on attributes. It's actually a little easier to do this with Cisco even than it is with Aruba in my experience (we are migrating from Cisco to Aruba WLCs and IAPs)

Thank you, this is the answer I was looking for. I will test this and will add snapshots from final setup.

 

Thank you,

Did you manage to take the prints?

I'm trying to setup the same scenario, but i'm having a couple of problems.

I can authenticate the user in portal, the caching is ok, but everytime i connect to the SSID the portal fires up.

We decided to move away from this method and use "controller initiated" methid for few reasons:

 

1- Customer controllers has old OS. only CoA terminate was accepted by that controllers (no reauthenticte)

 

2- Apple splash page didnt work. Customer didnt want to diasble CNA, but when CoA terminate was sent to apple devices they start a new session and they receive the splash page again (loop).

---

@cm119 wrote:

I can tell you it works, I've had it setup for awhile, but I can't easily explain how to set it all up. I couldn't find any comprehensive guide either, so I had to piece it all together. I believe I used the wizard to create a service for 'Guest access with MAC caching' then customized it from there. 

 

Here's the basic workflow:

1. MAC Auth service
   1. Authentication set to 'Allow All MAC Auth'
   2. Role mappings based on Guest Role ID (from clearpass guest) for traditional guest/contractor/employee, but then I also setup different roles for different captive portals, and map those roles based on AP Name, SSID, etc. 
   3. Enforcement. If the MAC auth maps to the MAC Caching role (built by the wizard), then send back an Accept along with a guest profile, this will send back to the Cisco WLC the username of the guest, for example.If the guest was MAC cached previously, authentication is done. 
   4. Now, If is NOT a MAC cache client, here's where we have to redirect. So my next enforcement profiles are matching my different roles to dofferent CoA Redirects. I have different ones for different captive portals. This is where you use Radius, Cisco-AVPair with url-redirect and url-redirect-acl. The ACL must already exist on the WLCs and provide access to the CP server via HTTPS and DNS servers at a minimum. DHCP is assumed I believe. 
   5. Client gets redirected to CP guest, your guest page needs to be setup for Cisco, and I have the Guest page setup for server-initiated CoA. I'm pretty sure I had this setup for controller-initiated in the beginning, but changed it to CoA to better match up with the Aruba suggested configs. 
2. WebAuth Service. 
   1. Now that the client is at the Guest page, when they login (or just click 'accept') Clearpass guest hit's the WebAuth service. 
   2. The enforcement here sends back the MAC Caching profile/expiration date, then a CoA for Radius:Cisco:Cisco-AVPair subscriber:command=reauthenticate. This is what forces the user to re-authenticate, they now hit the MAC Auth service again, but this time are MAC cached, and authenticated with access-allow. 

That was a long answer to your question I think. TL;DR: in the second phase, I send a CoA to force the user to re-auth. They then hit the MAC Auth service again, this time already cached, and are then given the access-accept. So really it makes it 3 steps, 1. MAC Auth (URL redirect), 2. WebAuth (CoA Reauth), 3. MAC Auth, cached (accept)

 

This solution actually works really well, just complicated to setup. It's nice because there is a ton of flexibility doing all the url-redirects from CPPM, we have multiple captive portals that can be chosen dynamically based on attributes. It's actually a little easier to do this with Cisco even than it is with Aruba in my experience (we are migrating from Cisco to Aruba WLCs and IAPs)

---

@cm119Do you have any screenshots from the config?

command=reauthenticate didnt work as WLC OS is old and customer cant upgrade as he has old APs. At the end, we switches to controller iniitated logic.

---

@Ahmad Enaya wrote:

command=reauthenticate didnt work as WLC OS is old and customer cant upgrade as he has old APs. At the end, we switches to controller iniitated logic.

---

Do you have screenshots from WLC and from ClearPass?

I'm trying to config the same scenario.

I have both the server-initiated (CoA) config with Cisco WLCs and the controller-initiated with Aruba IAP/WLC. It's a lot though, any idea where you might be stuck so we can narrow down what you need? 

Hi,

 

regarding integration clearpass guest and cisco wlc using server initiate, could you please share what attributes enforcement did you push in webauth service ?

i have some issue, after guest already succes login, they still get enforcement redirect to guest portal again.

 

thanks

 

Are the guests able to login after a second or third attempt? One issue with this method is that the CoA re-auth can happen faster than the CPPM database can reflect the MAC Cache attributes of the endpoint, ESPECIALLY if your WLC is hitting a subscriber node for radius rather then the publisher which handles the webauth and endpoint update. If this is the issue you are seeing, in clear pass services, async network services, increase the CoA timer, I ended up using 9 seconds. Note you also have to update your guest portal login page to use a ~10 second login delay as well. 

Hello cm119
Server initiated seems to be working alot better previously, but after a certain cppm version the update basically stopped working. It just seems like the second mac-auth - regardless of how long the coa timer is set - use cached data and not the updated data from endpoint database. With a coa timer of 9 seconds I can verify visually that the endpoint database is updated within a couple of seconds, but still the second mac-auth does not obtain the same data.

Server-initiated with Aruba Controller and IAP is easy, as we just change the role and don't have to rely on a new mac-auth. This doesn't see to be possible with other vendors.. Like just send a new acl-id to allow the client internet-access without reauth / disconnect.

------------------------------
John-Egil Solberg |
ACMX | ACCX
------------------------------

Original Message:
Sent: Feb 20, 2020 01:01 AM
From: Craig Monks
Subject: ClearPass integration with Cisco WLC using MAB + Web Auth

Are the guests able to login after a second or third attempt? One issue with this method is that the CoA re-auth can happen faster than the CPPM database can reflect the MAC Cache attributes of the endpoint, ESPECIALLY if your WLC is hitting a subscriber node for radius rather then the publisher which handles the webauth and endpoint update. If this is the issue you are seeing, in clear pass services, async network services, increase the CoA timer, I ended up using 9 seconds. Note you also have to update your guest portal login page to use a ~10 second login delay as well. 

We ended up using this configuration without any mac caching