Re: WLC 4404, 5508 and 5520: Custom WebAuth Error 405 in Firefox

mon08 · ‎10-23-2017

I'm using and Custom WebAuth package on WLC 4404, 5508 and 5520 on the same mobility group. certain ssid's using custom webauth package is getting error after login from mozilla firefox (error 405 method not allowed) PC version while on MS Edge and IE 11 it is working properly also on mobile devices. Only on Desktop versions of FF has errors.

I've already read a related to this case for Firefox from bug search tool "CSCtd66990".
Base on the case (CSCtd66990) it is only known in FF.

BTW, authentication is from LDAP server (Win AD).

Bell26 · ‎05-28-2018

Hi there,

I had the same problem with a virtual WLC. The authentication with Chrome or FF (on Android Devices or PC) wasn't possible. IOS device were able to autheticate properly. The solution for my Problem was following line in the <script> area of the html File;

document.forms[0].action = args.switch_url;

this code is stored in the loadAction function and was commented out, when i first got it from cisco.

the whole function looks like this

function loadAction(){
	var url = window.location.href;
	var args = new Object();
	var query = location.search.substring(1);
	var pairs = query.split("&");
	for(var i=0;i<pairs.length;i++){
		var pos = pairs[i].indexOf('=');
		if(pos == -1) continue;
		var argname = pairs[i].substring(0,pos);
		var value = pairs[i].substring(pos+1);
		args[argname] = unescape(value);
	}
	//alert( "AP MAC Address is " + args.ap_mac);
	//alert( "The Switch URL to post user credentials is " + args.switch_url);
	document.forms[0].action = args.switch_url;

	// This is the status code returned from webauth login action
	// Any value of status code from 1 to 5 is error condition and user
	// should be shown error as below or modify the message as it suits
	// the customer
	if(args.statusCode == 1){
		alert("You are already logged in. No further action is required on your part.");
	}
	else if(args.statusCode == 2){
		alert("You are not configured to authenticate against web portal. No further action is required on your part.");
	}
	else if(args.statusCode == 3){
		alert("The username specified cannot be used at this time. Perhaps the username is already logged into the system?");
	}
	else if(args.statusCode == 4){
		alert("The User has been excluded. Please contact the administrator.");
	}
	else if(args.statusCode == 5){
		alert("Username or password is wrong. Please try again.");
	}
}

Hope this helps anyone, if you're suffering of the same problem

sbhadrav@cisco.com · ‎07-10-2018

How to Make an Internal (Local) WebAuth Work with an Internal Page
If you need to configure a WLAN with an operational dynamic interface, the clients should also receive a DNS server IP address through DHCP. Before you set any webauth, you should test that your WLAN works properly, that you can resolve DNS requests (nslookup), and that you can browse web pages. Then, you can set the web authentication as Layer 3 security features. You can create your users in the local database or on an external RADIUS server, for example. Refer to the Wireless LAN Controller Web Authentication Configuration Example document.

How to Configure a Custom Local WebAuth with Custom Page
Custom webauth can be configured with redirectUrl from the Security tab. This forces a redirect to a specific web page you enter. When the user is authenticated, it overrides the original URL the client requested and displays the page for which the redirect was assigned.

The custom feature allows you to use a custom HTML page instead of the default login page. Upload your html and image files bundle to the controller. In the upload page, look for webauth bundle in a tar format. Usually, PicoZip creates tars that work compatibly with the WLC. For an example of a WebAuth bundle, refer to the Download Software page for Wireless Controller WebAuth Bundles. Be sure to select the appropriate release for your WLC. A good recommendation is to customize a bundle that exists; do not create a bundle from scratch.

There are some limitations with custom webauth that vary with versions and bugs. Things to watch for include:

the .tar file size (no more than 1Mb)

the number of files in the .tar

the filename length of the files (should be no more than 30 characters)

If your customer package does not work, try with a simple custom package. Then add files and complexity one at a time to reach the package the customer tried to use. This should help you identify the problem. For an example on how to configure a custom page, refer to Creating a Customized Web Authentication Login Page, a section within the Cisco Wireless LAN Controller Configuration Guide, Release 7.0.

Override Global Configuration Technique
For each WLAN, you configure with the override global config command and set a WebAuth type for each WLAN. This means you can have an internal/default WebAuth with a custom internal/default WebAuth for another WLAN. This also allows you to configure different custom pages for each WLAN. You must combine all your pages in the same bundle and upload them to the WLC. Then, you can set your custom page with the override global config command on each WLAN and select which file is the login page from all of the files within the bundle. You can choose a different login page inside the bundle for each WLAN.

Redirection Issue
There is a variable within the HTML bundle that allows the redirection. Do not put your forced redirection URL there. For any redirection issues in custom WebAuth, Cisco recommends to check the bundle. If you enter a redirect URL with += in the WLC GUI, this could overwrite or add to the URL defined inside the bundle. For example, in the WLC GUI, the redirectURL field is set to www.cisco.com; however, in the bundle it shows: redirectURL+= 'www.google.com'. The += redirects users to www.cisco.comwww.google.com, which is an invalid URL.

How to Make an External (Local) Web Authentication Work with an External Page
As already briefly explained, the utilization of an external WebAuth server is just an external repository for the login page. The user credentials are still authenticated by the WLC. The external web server only allows you to use a special or different login page. Here are the steps performed for an external WebAuth:

The client (end user) opens a web browser and enters a URL.

If the client is not authenticated and external web authentication is used, the WLC redirects the user to the external web server URL. In other words, the WLC sends an HTTP redirect to the client with the website's spoofed IP address and points to the external server IP address. The external web authentication login URL is appended with parameters such as the AP_Mac_Address, the client_url (www.website.com), and the action_URL that the customer needs to contact the switch web server.

The external web server URL sends the user to a login page. Then the user can use a pre-authentication access control list (ACL) in order to access the server. The ACL is needed for all WLC models except 4400 series and Wism1.

The login page takes the user credentials input and sends the request back to the action_URL, such as http://1.1.1.1/login.html, of the WLC web server. This is provided as an input parameter to the customer redirect URL, where 1.1.1.1 is the virtual interface address on the switch.

The WLC web server submits the username and password for authentication.

The WLC initiates the RADIUS server request or uses the local database on the WLC, and then authenticates the user.

If authentication is successful, the WLC web server either forwards the user to the configured redirect URL or to the URL the client entered.

If authentication fails, then the WLC web server redirects the user back to the customer login URL.