cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3694
Views
0
Helpful
3
Replies

LOCAL webauth with Wireless Lan Controller and ISE

Leroy Plock
Level 1
Level 1

Greetings,

We are planning to set up a guest wireless network with sponsored centralized webauth. I didn't realize this won't work with our current WLC code (6.0.199.4 ) as 7.2 or later is required.

We have a project in place to upgrade the WLCs but it won't be ready before the deadline for completion of the guest wireless.

I am thinking of using Local WebAuth temporarily until the WLCs are ready. My questions are:

1. Am I correct I can still authenticate against ISE?

2. Since local webauth does not support CoA, does this mean I can't apply an ACL pre or post auth?

3. Can someone point me to a good guide for configuring local webauth?

 

Thanks!

2 Accepted Solutions

Accepted Solutions

Hello Leroy,

In CWA you can push desire AVPs in the final result due to the nature of the flow:

-Guest connects to SSID.

- WLC send Wireless MAB Request( 1st authentication ). In response ISE returns Accept with url-redirect-acl and url-redirect.

- WLC updates client session  and once HTTP(s) is generated WLC redirects client to ISE as per AVPs received in 1st auth(MAB request).

- Client enters credentials in portal. ISE validates creds  and sends back to WLC a  CoA type Re-authenticate.

- WLC re authenticates the client's session( 2nd authentication)  and at this point ISE can push down  custom AVPs  like dynamic VLANs, Interfaces  or Airspace ACLs names.

- WLC overrides the client session  with new attributes.

 

Local Web Auth as you mentioned,  there are 2 stages  but the WLC "considers" this a  single thread.

For LWA the flow is as follows:

- Client connects  to SSID.  Since there is no L2 auth involved client goes through DHCP,  grabs an IP and gets to WebAuth_Required. Redirect URL is statically configured on WLC and pre auth ACL allows the client access to ISE during auth stage.

- Client opens the browser  and WLC redirects client to ISE,  but within the redirection  there is a "return to WLC" action that instructs ISE to send client back to WLC virtual IP containing credentials the client used  during auth in guest portal.

- This way the WLC now "knows" the creds presented to ISE and this way there is a formal radius request that WLC sends out to ISE asking for these creds. ISE returns back an accept, and   this is how the WLC now "knows"  that auth is correct and that it should move client to RUN.

 

LWA the easiest way  would be to define a  guest Interface and apply statically a restrictive ACL to the interface level instead of expecting the AVP from AAA server.

LWA is supported in this version at very low and basic level,  but if you want a complex  flow involving dynamic attribute push you'll need to something higher than 7.2.110.0.

Recommended version would be 7.6.130.0 as  for now.

Regards,  

Antonio

View solution in original post

LWA flow

 

CWA Flow

View solution in original post

3 Replies 3

Leroy Plock
Level 1
Level 1

As a followup, I've already confirmed that we can authenticate against ISE.

The important thing is to distinguish between INTERNAL webauth on the WLC vs EXTERNAL webauth on the WLC. External webauth doesn't appear to be that different than centralized webauth: http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/116217-configure-ISE-00.html

We can definitely apply a pre-auth ACL. I think we can apply a post--auth ACL because there is a second authentication done by the WLC on the guest's behalf, we can apply the Airespace ACL there.

Can anyone tell me what I'm missing out on by using external webauth on the WLC vs. Centralized Webauth? (We will still move to centralized after the WLC upgrade.)

 

Thanks!

Hello Leroy,

In CWA you can push desire AVPs in the final result due to the nature of the flow:

-Guest connects to SSID.

- WLC send Wireless MAB Request( 1st authentication ). In response ISE returns Accept with url-redirect-acl and url-redirect.

- WLC updates client session  and once HTTP(s) is generated WLC redirects client to ISE as per AVPs received in 1st auth(MAB request).

- Client enters credentials in portal. ISE validates creds  and sends back to WLC a  CoA type Re-authenticate.

- WLC re authenticates the client's session( 2nd authentication)  and at this point ISE can push down  custom AVPs  like dynamic VLANs, Interfaces  or Airspace ACLs names.

- WLC overrides the client session  with new attributes.

 

Local Web Auth as you mentioned,  there are 2 stages  but the WLC "considers" this a  single thread.

For LWA the flow is as follows:

- Client connects  to SSID.  Since there is no L2 auth involved client goes through DHCP,  grabs an IP and gets to WebAuth_Required. Redirect URL is statically configured on WLC and pre auth ACL allows the client access to ISE during auth stage.

- Client opens the browser  and WLC redirects client to ISE,  but within the redirection  there is a "return to WLC" action that instructs ISE to send client back to WLC virtual IP containing credentials the client used  during auth in guest portal.

- This way the WLC now "knows" the creds presented to ISE and this way there is a formal radius request that WLC sends out to ISE asking for these creds. ISE returns back an accept, and   this is how the WLC now "knows"  that auth is correct and that it should move client to RUN.

 

LWA the easiest way  would be to define a  guest Interface and apply statically a restrictive ACL to the interface level instead of expecting the AVP from AAA server.

LWA is supported in this version at very low and basic level,  but if you want a complex  flow involving dynamic attribute push you'll need to something higher than 7.2.110.0.

Recommended version would be 7.6.130.0 as  for now.

Regards,  

Antonio

LWA flow

 

CWA Flow