05-14-2015 09:13 AM - edited 03-12-2019 05:45 PM
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!
Solved! Go to Solution.
05-16-2015 08:25 PM
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
05-20-2015 12:24 AM
05-14-2015 03:03 PM
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!
05-16-2015 08:25 PM
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
05-20-2015 12:24 AM
LWA flow
CWA Flow
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide