WEB AUTH problem on WISM

HiGuys We are facing issue in authenticating guest user via web authentication on WiSM.We have WiSM with 270 APs. We have guest ssid with web-auth enabled.we are running 4.2.061 code. It was working fine till last week, now suddenly it keeps getting off. Users are not getting web-auth login page. We had to disable the web-auth & reenable it then it again starts working. I dont know wht to do in this case. didnt find any log..whts going on in background.
need help to resolve it.
Thanks
NK

I had the same basic issue and after reseaching found caveat CSCsk54969 which is a pretty close match. This caveat has been fixed in release 4.2.130. I have just upgraded to this release over the week end so to soon to tell yet.... fingers crossed...

Similar Messages

Guest WLAN Web Auth problem

Was just wondering whether anyone else had seen this problem as it is defeating TAC right now…
We have a number of 4402 WLCs on various sites and another one in a DMZ acting as an anchor controller for the guest network. We’re using just the basic web auth built into the WLC for access out on to the Internet for visiting third parties. All the EOIP stuff is setup and working and all clients can associate and get an IP address.
All clients get redirected to the authentication page and all clients appear to authenticate successfully. With the exception of a few clients, at this stage most get stuck and cannot browse the web; the pages just time out. All other Internet traffic (SSH, TELNET, SMTP, ICMP) works fine once authenticated , just not HTTP/HTTPS.
We have upgraded the WLCs to the latest code on the advice of TAC (6.0.196) but this made no difference. The problem seems to happen on all OSs (Mac, XP, Vista, Windows 7, Ubuntu, iPhone) and all browsers (IE6, IE7, IE8, Safari, Firefox, Chrome). We have tried upgrading drivers and changing browser settings, but nothing seems to help. We have working XP laptops and non-working XP latops; it just doesn’t make any sense.
The attached packet capture shows a non-working laptop and the only thing I noticed was very large window sizes (512k) which seems a bit odd.
Any ideas?
Thanks

hi there
apparently i have a fix for the issue, it has just been tested for over 8 hours and my computer running wireless on windows 7 never disconected anymore (and i don't have either quick 1 second hangs anymore)....HOW????? it was the wireless driver!!
my computer has an Atheros 928x wireless card and i was running version 8.0.0... (can't remember the exact version) which as far as i know was the version bundled with the original installation alhough i dont remember if i had an update from somewhere else... anyway. i did this:
1. went to device manager, clicked on the wireless card, clicked delete, then confirm with the box about deletion of the software connected with the device.... then clicked on "scan for hardware changes" - in theory i wanted to update the driver with another .exe i downloaded but i thought let's give a go... and long story short, win 7 found in "his" files another suitable driver, probably the "generic" one, but nevertheless works as a charm, driver version is 2.0.0.74, driver date 09/06/2009, driver provider: microsoft, digital signer: microsoft windows, driver name : Atheros AR928X Wireless Network Adapter.
if you need more info about the driver let me know!
gabrio

WiSM 7.0.116 Web-Auth Fail & GUI Management Fail

Dears,
I find two log:
*spamReceiveTask: Jul 28 08:38:28.078: %LWAPP-3-RADIUS_ERR: spam_radius.c:137 Could not send join reply, AP authorization failed; AP:00:14:69:3b:ee:20
*emWeb: Jul 28 08:38:17.314: %PEM-1-WEBAUTHFAIL: pem_api.c:4990 Web authentication failure for station 00:25:d3:9a:cb:da
Then, Wireless Client cannnot access web-auth page, and I cannot access the controller management GUI.
When the first Radius Fail, It happened!!!
I don't know why happen it @@"
Device:
WiSM
7.0.196

- Model of AP?
- Console log of this AP as it boots up?
- From WLC CLI, send "show network summary"
- From WLC GUI, send snapshot of
Managment > HTTP-HTTPS
Security > WebAuth > Certificate
Controller > Interfaces
- Did you try adding the mac address of AP 00:14:69:3b:ee:20 in the AP authorization list OR under mac filtering
- On WLC GUI, capture a snapshot of Security > AP Policies
Then under same tab, click on Add > enter mac address of AP 00:14:69:3b:ee:20 > enter certificate type MIC
and see if this AP can join

Web Auth Re-Authentication Problem

2500 series controller. 1140 APs.
I have set my idle and session timout to both be 57600 (16 hours) yet we have users getting re-prompted for web auth every few hours.
Please advise.
(Cisco Controller) >
(Cisco Controller) >*pemReceiveTask: May 02 18:28:02.826: 60:fa:cd:a8:9c:8e Sent an XID frame
*apfReceiveTask: May 02 18:33:01.538: 60:fa:cd:a8:9c:8e 172.16.60.15 WEBAUTH_REQD (8) Web-Auth Policy timeout
*apfReceiveTask: May 02 18:33:01.538: 60:fa:cd:a8:9c:8e 172.16.60.15 WEBAUTH_REQD (8) Pem timed out, Try to delete client in 10 secs.
*apfReceiveTask: May 02 18:33:01.538: 60:fa:cd:a8:9c:8e Scheduling deletion of Mobile Station: (callerId: 12) in 10 seconds
*osapiBsnTimer: May 02 18:33:11.538: 60:fa:cd:a8:9c:8e apfMsExpireCallback (apf_ms.c:589) Expiring Mobile!
*apfReceiveTask: May 02 18:33:11.538: 60:fa:cd:a8:9c:8e apfMsExpireMobileStation (apf_ms.c:5584) Changing state for mobile 60:fa:cd:a8:9c:8e on AP 3c:ce:73:49:7f:30 from Associated to Disassociated
*apfReceiveTask: May 02 18:33:11.538: 60:fa:cd:a8:9c:8e Scheduling deletion of Mobile Station: (callerId: 45) in 10 seconds
*osapiBsnTimer: May 02 18:33:21.538: 60:fa:cd:a8:9c:8e apfMsExpireCallback (apf_ms.c:589) Expiring Mobile!
*apfReceiveTask: May 02 18:33:21.538: 60:fa:cd:a8:9c:8e Sent Deauthenticate to mobile on BSSID 3c:ce:73:49:7f:30 slot 0(caller apf_ms.c:5678)
*apfReceiveTask: May 02 18:33:21.538: 60:fa:cd:a8:9c:8e apfMsAssoStateDec
*apfReceiveTask: May 02 18:33:21.538: 60:fa:cd:a8:9c:8e apfMsExpireMobileStation (apf_ms.c:5716) Changing state for mobile 60:fa:cd:a8:9c:8e on AP 3c:ce:73:49:7f:30 from Disassociated to Idle
*apfReceiveTask: May 02 18:33:21.538: 60:fa:cd:a8:9c:8e pemApfDeleteMobileStation2: APF_MS_PEM_WAIT_L2_AUTH_COMPLETE = 0.
*apfReceiveTask: May 02 18:33:21.538: 60:fa:cd:a8:9c:8e 172.16.60.15 WEBAUTH_REQD (8) Deleted mobile LWAPP rule on AP [3c:ce:73:49:7f:30]
*apfReceiveTask: May 02 18:33:21.538: 60:fa:cd:a8:9c:8e apfMs1xStateDec
*apfReceiveTask: May 02 18:33:21.538: 60:fa:cd:a8:9c:8e Deleting mobile on AP 3c:ce:73:49:7f:30(0)
*pemReceiveTask: May 02 18:33:21.540: 60:fa:cd:a8:9c:8e 172.16.60.15 Removed NPU entry.

Its happening with multiple types of devices. Apple laptops, iPhones, Windows Mobile Phones, etc. A user will connect to the wireless and accept the agreement on the web auth page. A few hours later, she will try to surf the web again and be re-prompted with the page to authenticate. We do not want this. We only want this page to come up every 16 hours.

Problem with Web Auth

hi
i have two wireless networks,one for the guests and the other one extends the corporate network.i created two vlan on my 6509 swicth and mapped the vlns to to the wlans.All is working fine but when i enable web auth for guest i can no longer ping my gateway or browse and even web auth is not authenticating against the internal users configured on the WLC...web auth just wont work.
what could be wrong..i really need to authenticate using web auth.

ok, SO this is what i need
send me show custom-web details
S if you open the page do you get the default cisco webauth redirected page ; are you able to put the user name and password ?
can you send me the screen shot of events
Regards
Seema

Web auth not working on new controllers

We are currently experiencing a problem with web auth on one of our sites. This uses WiSM2 controllers running version 7.2.110.0 of the software.
The affected SSID is set up for web auth exactly the same way as our other site and that works (although that uses WiSMs running 7.0.230.0).
Both sites use the same web auth bundle and the same certificate. We have a DNS entry that points back to the virtual interface IP they all use which is 1.1.1.1.
When users connect to the SSID they are not being presented with the login page. Running a preview on the controller at the problem sites shows the correct page that should be being displayed.
The controllers have had the certificate re-applied, the web auth bundle reloaded on and have been upgraded from 7.2.103.0 to 7.2.110.0 but none of these have resolved the issue. All other SSIDs work fine, but this is the only one that uses web auth.
As I say, the only configuration difference is the hardware (WiSM2 vs WiSM) and the software level.
Any suggestions?

When you mention that the login page does not open, that usually means that is a DNS issue. Make sure that you allow DNS from the guest subnet to the DNS server in which the FQDN of the certificate is being resolved.
Are you anchoring the guest ssid to an anchor controller? It would be the same troubleshooting, but make sure the anchor is configured correctly. The foreign wlc guest ssid needs to have a mobility anchor to the anchor wlc and the FW needs to allow DNS back in if your using an internal DNS server.
If you are not using an anchor wlc, the best way to test is to map the guest to another dynamic interface on the inside network that is working. If that works, your FW is blocking DNS on the guest subnet. You also can remove the FQDN (make sure it was entered correctly) from the VIP and test. If that fixes it, then DNS was not resolving the certificate FQDN.
Hope this helps
Sent from Cisco Technical Support iPad App

"Auth type not supported by External DB" error for web-auth SSIDs

Hello
We're having a problem with web-authentication on our 4404/WisM controllers since we moved to software rev 5.x (currently running 5.1.151.0).
With software rev 4.x our web-auth SSIDs would send the authentication requests to a Cisco ACS4.0 which would then authenticate the users against MS Active directory.
Now (with rev 5.x) the same SSIDs cannot authenticate users against AD, the error in the ACS is:
Auth type not supported by External DB
Found the following Cisco Doc regarding the problem: Cisco Secure ACS and Windows AD EAP/802.1x port authentication fails with the Auth type not supported by External DB error message - Case Number K24308566. Done a packet capture on ACS to see authentications coming in and the ones that fail with above error are using CHAP - from the Cisco documentation, MS AD doesn't support CHAP.
Any ideas on how I can get the web-auth working again with software rev 5.x ?
Thanks
Andy

my apologies - theres a setting under Controller - General for Web Radius Authentication. changed this from CHAP to PAP and its now working ok.

Web Auth Type: Customized(downloaded) Redirect URL after login not working.

         5508WLC as anchor controller with WLC1 and WLC2 with WCS. I have 2 public ssids set up to go directly to the internet.
Everything is working as it should. I downloaded the web auth bundle from Cisco and will just use a disclaimer page and then if the user clicks on the accept button they will be redirected to our company web page, and then they can get out to the internet.
I have edited the aup.html and login.html to say what I want it to. I have 2 different login.html pages and bundle to a .tar file like the documentation says. I download it via tftp to the controller and it is successful. The disclaimer page opens up when I connect and it looks as it should. The problem is I cannot seem to get the accept button to work. It redirects to a web page but it is undefined.
   I must be missing some setting somewhere, but I just can not seem to find it. Is there any line I need to edit in the login.html files that will redirect the page.    The config on the Web Login Page Redirect URL after login is http://www.mccg.org which is our home page.
Any help will be appreciated. I cannot seem to fine very good documentation, or I am just overlooking something.
Thanks
John

Your HTML code is wrong. Attach your code if your okay with it and I can check.
Sent from Cisco Technical Support iPhone App

ISE, WLC: web auth, blocking user account

Hello!
We are implementing BYOD concept with ISE (1.1.4) and WLC 5508 (7.4.100).
On WLC there is SSID(WLAN) with MAC filtering without L2 security. For authentication user is redirected to the ISE Guest Portal.
Credentials are created at the ISE sponsor portal.
We create user account in ISE sponsor portal with one hour lease.
In 10 minutes we delete (or block) user credentials.
In spite of it the user is still able to work. Even if we manually disconnect client and reconnect it again, client opens the browser and there is no redirection to the ISE web auth page.
This happens because WLC thinks, that client is still associated.
There are session and idle timeout timers in WLC WLAN, but they can't solve the problem of automatic client session removing.
From my point of you, ISE must send some kind of reauth request to the user after account deletion, to make user authentication impossible .
In practice, ISE doesn't tell wlc or user, that client sesssion is blocked.
How the user account blocking process can be automated without manually deleting the client session from WLC client database?

It seems that there is some bug about CoA when deleting Guest accounts
CSCuc82135
Guests need to be removed from the network on Suspend/Delete/Expiration
When a guest user is deleted from the system, the RADIUS sessions associated with that guest user still exists.
Workaround Reissue the Change of Authorization using the session information from Monitoring reports for the sessions associated with that guest user.
http://www.cisco.com/en/US/docs/security/ise/1.1.1/release_notes/ise111_rn.html#wp411891
from BUG Toolkit there is Release-Pending in "Fixed-in" option.

WLC 5508 Web Auth Splash Page: Is it possible to place a download?

Hi,
I know it is possible to create custom web auth splash pages on the WLC 5508. Is it also possible to embedd a small document (less than 1MB) that users can download directly from the controller? I need this for providing the terms of use for the Guest WLAN.
Thanks
Michael

It could be done, but you will want to stay within the limits of the WebAuth bundle size (~ <10MB I believe). This shouldn't be a problem considering a .doc size, but I have to ask the same question. Why would you want to do this as opposed to just putting your terms of use inline to the page as just text/html? Maybe there is a good reason, but I can't really think of any scenario. Feel free to elaborate.

Web-Auth with 802.1x

Environment is WLC 2106 with 4 LWAPP access points. Currently running 2 WLANs: 1 using 802.1x authentication with a Windows IAS (RADIUS) server for Active Directory authentication; 1 using basic WEP for guest access that drops the user in it's own secure VLAN.
I am trying create a 3rd WLAN that uses Web-Authentication using 802.1x RADIUS that passes the username/password to the Windows IAS server. I can see the request being passed to the IAS server, but it is being logged on the IAS server as:
An Access-Request message was received from RADIUS client WLAN Controller without a message authenticator attribute when a messages authenticator attribute is required. Verify the configuration of the RADIUS client in the Internet Authentication Service snap-in (the "Client must always send the message authenticator attribute in the request" checkbox) and the configuration of the network access server.
I already have the one WLAN using 802.1x where the RADIUS client on the IAS server has the "Request must contain the Message Authenticator attribute" checkbox checked and it works jsut fine. It is just the Web-Auth using 802.1x where it seem the authentication isn't being passed properly to the RADIUS server. I cannot figure out what I am doing wrong or missing.

Hi,
I don't know if you have resolved the problem or not, But I will propose my solution anyway,
There are two ways to solve this problem, either to make the controller send the radius request with md5 or make the windows reply to the radius requests that does not contain a md5 hash
Microsoft Solution:
When you add the Radius Client using the wizard there are certain options that don't show; for instance the md5 attribute that is causing the IAS to drop the web auth requests. So what you need to do is after you use the wizard, you right click on the client that you added (in our case the WLC) and uncheck the box that says "Access-Request message must contain the Message-Authenticator attribute" (attached is a screenshot).
That should make the IAS respond to the web auth requests.
WLC Solution:
I haven't tested this solution, but I think it will work. if you did test it, please let me know how it turned out.
By default, the Web Radius Authentication is set to "PAP" (can be found in the Controller Tab @ the WLC GUI), you need to set it to MD5-CHAP. (attached is another screenshot).
Hope that solves your problem, and please let me know how the problem was solved.

Web auth with , intenal web page of WLC and ISE as radius server

Hi All ,
We have created a SSID as web auth with internal web page for login . In advanced tab we configured AAA server. AD is integrated with ISE .
When the user tries to get connect , he is getting redirect URL . But during the authentication , we are getting error in ISE as
"ise has problems communicating with active directory using its machine credentials " and authentication getting failed .
When we have L2 security mechanism enabled with PEAP , ISE is able to read the AD and providing authentication .
Only for L3 web auth it is not happening..
Any clue on this ..???
Thanks,
Regards,
Vijay.

Machine credentials requires a lookup on the computer OU and that has to be defined on the client side.
Thanks,
Scott
Help out other by using the rating system and marking answered questions as "Answered"

Guest WLAN and Web Auth?

Hi Guys,
Maybe someone can help me out?
I just finished setting up a trial "Cisco Virtual Wireless Controller" with nearly the same configuration as our Physical
"Cisco Wireless Controller" with the exception of having 2 ports. Anyhow, I managed to get everything working except for the WEB AUTH on the Guest WLAN. When a client connects, he gets a DHCP address from our ASA but when we try to get to a website, we never reach the WEB AUTH page.
What I tried so far is..
add a DNS Host Name to the virtual interface and assign it to our internal DNS server.dns name was resolving but we were unable to ping 1.1.1.1
changed the virtual ip from 1.1.1.1 to 2.2.2.2 and modified the DNS entrydns name resoved but still could not ping 2.2.2.2(I think this is normal)
changed the virtual IP to a private address of 192.168.102.1 and modified the dns entrysame result
I've attached some screenshots of our configuration.

Troubleshooting Web Authentication
After you configure web authentication, if the feature does not work as expected, complete these
troubleshooting steps:
Check if the client gets an IP address. If not, users can uncheck
DHCP Required
on the WLAN and
give the wireless client a static IP address. This assumes association with the access point. Refer to
the
IP addressing issues
section of
Troubleshooting Client Issues in the Cisco Unified Wireless
Network for troubleshooting DHCP related issues
1.
On WLC versions earlier than 3.2.150.10, you must manually enter
https://1.1.1.1/login.html
in
order to navigate to the web authentication window.
The next step in the process is DNS resolution of the URL in the web browser. When a WLAN client
connects to a WLAN configured for web authentication, the client obtains an IP address from the
DHCP server. The user opens a web browser and enters a website address. The client then performs
the DNS resolution to obtain the IP address of the website. Now, when the client tries to reach the
website, the WLC intercepts the HTTP Get session of the client and redirects the user to the web
authentication login page.
2.
Therefore, ensure that the client is able to perform DNS resolution for the redirection to work. On
Windows, choose
Start > Run
, enter
CMD
in order to open a command window, and do a nslookup
www.cisco.com" and see if the IP address comes back.
On Macs/Linux: open a terminal window and do a nslookup www.cisco.com" and see if the IP
address comes back.
If you believe the client is not getting DNS resolution, you can either:
Enter either the IP address of the URL (for example, http://www.cisco.com is
http://198.133.219.25)
♦
Try to directly reach the controller's webauth page with
https:///login.html. Typically this is http://1.1.1.1/login.html.
♦
Does entering this URL bring up the web page? If yes, it is most likely a DNS problem. It might also
be a certificate problem. The controller, by default, uses a self−signed certificate and most web
browsers warn against using them.
3.
For web authentication using customized web page, ensure that the HTML code for the customized
web page is appropriate.
You can download a sample Web Authentication script from Cisco Software Downloads. For
example, for the 4400 controllers, choose
Products > Wireless > Wireless LAN Controller >
Standalone Controllers > Cisco 4400 Series Wireless LAN Controllers > Cisco 4404 Wireless
LAN Controller > Software on Chassis > Wireless Lan Controller Web Authentication
Bundle−1.0.1
and download the
webauth_bundle.zip
file.
These parameters are added to the URL when the user's Internet browser is redirected to the
customized login page:
4.
ap_mac The MAC address of the access point to which the wireless user is associated.
♦
switch_url The URL of the controller to which the user credentials should be posted.
♦
redirect The URL to which the user is redirected after authentication is successful.
♦
statusCode The status code returned from the controller's web authentication server.
♦
wlan The WLAN SSID to which the wireless user is associated.
♦
These are the available status codes:
Status Code 1: "You are already logged in. No further action is required on your part."
♦
Status Code 2: "You are not configured to authenticate against web portal. No further action
is required on your part."
♦
Status Code 3: "The username specified cannot be used at this time. Perhaps the username is
already logged into the system?"
♦
Status Code 4: "You have been excluded."
♦
Status Code 5: "The User Name and Password combination you have entered is invalid.
Please try again."
♦
All the files and pictures that need to appear on the Customized web page should be bundled into a
.tar file before uploading to the WLC. Ensure that one of the files included in the tar bundle is
login.html. You receive this error message if you do not include the login.html file:
Refer to the Guidelines for Customized Web Authentication section of Wireless LAN Controller Web
Authentication Configuration Example for more information on how to create a customized web
authentication window.
Note:
Files that are large and files that have long names will result in an extraction error. It is
recommended that pictures are in .jpg format.
5.
Internet Explorer 6.0 SP1 or later is the browser recommended for the use of web authentication.
Other browsers may or may not work.
6.
Ensure that the
Scripting
option is not blocked on the client browser as the customized web page on
the WLC is basically an HTML script. On IE 6.0, this is disabled by default for security purposes.
7.
Note:
The Pop Up blocker needs to be disabled on the browser if you have configured any Pop Up
messages for the user.
Note:
If you browse to an
https
site, redirection does not work. Refer to Cisco bug ID CSCar04580
(registered customers only) for more information.
If you have a
host name
configured for the
virtual interface
of the WLC, make sure that the DNS
resolution is available for the host name of the virtual interface.
Note:
Navigate to the
Controller > Interfaces
menu from the WLC GUI in order to assign a
DNS
hostname
to the virtual interface.
8.
Sometimes the firewall installed on the client computer blocks the web authentication login page.
Disable the firewall before you try to access the login page. The firewall can be enabled again once
the web authentication is completed.
9.
Topology/solution firewall can be placed between the client and web−auth server, which depends on
the network. As for each network design/solution implemented, the end user should make sure these
ports are allowed on the network firewall.
Protocol
Port
HTTP/HTTPS Traffic
TCP port 80/443
CAPWAP Data/Control Traffic
UDP port 5247/5246
LWAPP Data/Control Traffic
(before rel 5.0)
UDP port 12222/12223
EOIP packets
IP protocol 97
Mobility
UDP port 16666 (non
secured) UDP port 16667
(secured IPSEC tunnel)
10.
For web authentication to occur, the client should first associate to the appropriate WLAN on the
WLC. Navigate to the
Monitor > Clients
menu on the WLC GUI in order to see if the client is
associated to the WLC. Check if the client has a valid IP address.
11.
Disable the Proxy Settings on the client browser until web authentication is completed.
12.
The default web authentication method is PAP. Ensure that PAP authentication is allowed on the
RADIUS server for this to work. In order to check the status of client authentication, check the
debugs and log messages from the RADIUS server. You can use the
debug aaa all
command on the
WLC to view the debugs from the RADIUS server.
13.
Update the hardware driver on the computer to the latest code from manufacturer's website.
14.
Verify settings in the supplicant (program on laptop).
15.
When you use the Windows Zero Config supplicant built into Windows:
Verify user has latest patches installed.
♦
Run debugs on supplicant.
♦
16.
On the client, turn on the EAPOL (WPA+WPA2) and RASTLS logs from a command window, Start
> Run > CMD:
netsh ras set tracing eapol enable
netsh ras set tracing rastls enable
In order to disable the logs, run the same command but replace enable with disable. For XP, all logs
will be located in C:\Windows\tracing.
17.
If you still have no login web page, collect and analyze this output from a single client:
debug client
debug dhcp message enable
18.
debug aaa all enable
debug dot1x aaa enable
debug mobility handoff enable
If the issue is not resolved after you complete these steps, collect these debugs and use the TAC
Service Request Tool (registered customers only) in order to open a Service Request.
debug pm ssh−appgw enable
debug pm ssh−tcp enable
debug pm rules enable
debug emweb server enable
debug pm ssh−engine enable packet

5760 Central Web Auth with ISE

Hi,
I am having problems with getting central web auth to work on the 5760, I cant seem to find any documentation for the 5760-Central Web Auth.
The setup is with a Cisco 5760 and Cisco ISE, for guest users to be re-directed to ISE guest portal to authenticate. Has anyone configured this or have any advice, that would be great.
Thanks

Hi Roger,
I have gotten CWA running on the 5760 with ISE, below is the config for the guest SSID:
wlan Guest 1 TEST-guest
aaa-override
ip dhcp required
mac-filtering cwa_macfilter
mobility anchor 10.1.1.100
nac
no security wpa
no security wpa akm dot1x
no security wpa wpa2
no security wpa wpa2 ciphers aes
security dot1x authentication-list ISE_Auth_Group
session-timeout 14400
no shutdown
! ***You will need the following commands as well:
ip http server
ip http authentication local
ip http secure-server
aaa authentication login ISE_Auth_Group group ISE
aaa authorization network cwa_macfilter group ISE
Hope it helps =)

Web-Auth Admin Page not loading

I have a WLC 2504 Controller which is set up for guest wireless using the Web-Auth feature / Lobby Ambassador.
When I web browse to the Controller and enter my credentials no page is displayed.
The log file displays the following error:
#CLI-3-LOGIN_FAILED: cliutil.c:632 Login failed. User:lobby-admin, Service type:11. unknown service type.
However when I run a debug aaa events I see the following event that the user passed authentication.
*emWeb: Mar 17 18:54:53.120: Authentication succeeded for lobby-admin
The wireless controller version 7.6.130.0
There is genuinely nothing fancy about the set up and done these loads of times.
I have tried this with Google Chrome, IE and Firefox using both HTTPS and HTTP and it's still exactly the same problem.
Regards
Greg

Which authentication protocol do you want use and does the request from the WLC hit the correct policy on the authentication server?
If you want to use radius as the authentication protocol you need to return the radius "Service-Type" attribute with value "Callback Administrative" for a lobby admin user. If you go with tacacs you need to use role based authentication. For example "role1=ALL" gives the user access to all the tabs in the GUI.

WEB AUTH problem on WISM

Similar Messages

Maybe you are looking for