Web-Based Authentication

This chapter describes how to configure web-based authentication on the device. It contains these sections:

Local web authentication

Local web authentication is a network security mechanism that

  • authenticates users through a web browser login page

  • enables access control on host systems that do not run IEEE 802.1X supplicants, and

  • communicates with authentication, authorization, and accounting (AAA) servers to enforce security policies.

Feature history

Feature Name

Release

Description

Built-in Captive Portal Improvement

Cisco IOS XE 17.1.1

This release introduces support for special characters in the login portal banner title and banner text. The number of characters supported on the banner text has doubled to 400.

The exec-character-bits command has been introduced.

Presentation options for local web authentication web pages

Local web authentication intercepts HTTP sessions on Layer 2 interfaces, and in some cases, Layer 3 interfaces (with restrictions for some switch models). When users try to access the network, local web authentication displays a login page and verifies user credentials with AAA servers, granting or denying access accordingly.

Local web authentication is categorized by the location where its web pages are hosted.

  • Internal: Uses HTML pages (login, success, fail, and expire) stored on the embedded wireless controller .

  • Customized: Uses customized HTML pages (login, success, fail, and expire) downloaded onto the embedded wireless controller for a customized user experience.

  • External: Uses HTML pages hosted on an external web server.

We recommend that you follow the Cisco guidelines to create a customized web authentication login page. If you use the latest versions of Google Chrome or Mozilla Firefox browsers, ensure that your webauth bundle uses this line in the login.html file: 
<body onload="loadAction();">

Web authentication modes

The types of web authentication differ according to the available web authentication pages.

  • Webauth—The embedded wireless controller displays a page with the user name and password. Users enter valid credentials to gain network access.

  • Consent or web-passthrough—The controller presents a policy page with the Accept and Deny buttons. Users simply click Accept to access the network – no credentials are required.

  • Webconsent—This mode combines the features of Webauth and Consent. The embedded wireless controller displays a policy page with Accept or Deny buttons along with user name or password. Users must enter the correct credentials and click Accept to access the network.

Additional reference information

  • You can view the webauth parameter-map information using the show running-config command.

  • If you see tracebacks during client authentication, performance and behavior are not affected. Tracebacks may occur if Flexible Forwarding Mode (FFM) replies to Endpoint Profiler Module (EPM) for ACL application after the session is dequeued, usually because a timer expired or the session became unauthorized.

  • You can configure web-based authentication on Layer 2 and layer 3 interfaces.

  • When a client reaches the maximum limit of 200 HTTP connections, the system resets TCP connections and excludes your client from the network.

How local web authentication works

Summary

authentication enables secure network access for clients by prompting users to authenticate through a web login page. The process coordinates actions between the user, authentication server, and the network switch. The key components are:

  • User: Initiates the HTTP session and enters authentication credentials.

  • Network switch: Intercepts traffic, presents login pages, applies policies, and communicates with the authentication server.

  • Authentication server: Verifies credentials and provides policy enforcement details.

Workflow

These are the stages of the process.

  1. Session initiation: The user starts an HTTP session by attempting to access the network.
  2. Traffic interception and login page presentation: The network switch intercepts the HTTP request and triggers the authorization process. It presents a login page for the user to enter their username and password.
  3. Credential submission and authentication: After the user submits credentials, the switch forwards them to the authentication server
  4. Authentication outcome:
    • If authentication succeeds, the switch downloads and activates the access policy assigned to the user from the server, then displays a login success page.
    • If authentication fails, the switch displays a login failure page. After a maximum number of failures, the login expired window appears, and the host is put on a watch list. Once the timeout expires, the user may try again
  5. Server non-response handling: If the authentication server does not respond, and an AAA fail policy is in place, the switch applies the failure policy to the host and displays a login success page.
  6. Reauthentication triggers: The switch reauthenticates a client if the host does not respond to an ARP probe (Layer 2) or does not send traffic within an idle timeout (Layer 3) suppress-feature-id="uabu_2960l_sw".
  7. Session timeout enforcement: The switch applies either the session timeout configured locally or provided by the server. The default local web authentication session timeout on controller is 1800 seconds from Cisco IOS XE 16.1.1 and later. The default session timeout value was infinite seconds, prior to Cisco IOS XE Denali 16.1.1.
  8. Session termination:
    • If the terminate action is set to RADIUS, the switch sends a nonresponsive host request to the server; the server’s response dictates the next action.
    • If the terminate action is set to default, the switch dismantles the session and removes the access policy.

Result

If authentication succeeds and the correct policies are applied, the user gains network access. If authentication fails, failure policies or timeout mechanisms may deny access.

Restrictions

  • You cannot configure bypass authentication with the wireless web authentication feature.

  • To update the redirect login URL, enable and then disable the WLAN. The redirect login URL specified in the web authentication parameter map changes when an AP rejoins.

  • If authentication fails, users receive a failure page and can try to log in again. If the number of allowed attempts is exceeded, users may be excluded and receive a specific reason for the exclusion.

  • Use the local web authentication feature to authenticate end users on host systems that do not run the IEEE 802.1x supplicant.

Roles of devices in local web authentication

In a local web authentication scenario, network devices assume specific roles to manage authentication and access to the LAN.

  • Client: A device, such as a workstation, that requests network access and responds to authentication requests from the switch. The client must have an HTML browser with JavaScript enabled.

  • Authentication server: A server that validates the identity of the client. The authentication server notifies the switch if the client is allowed or denied access to the LAN and related services.

  • Switch: A network device that manages physical access to the network based on the authentication status of the client. The switch relays identity information and authorization responses between the client and the authentication server.

These device roles work together to ensure secure access control through local web authentication processes.

Figure 1. Local web authentication device roles
The diagram shows the following sequence: the client requests authentication from the switch, the switch communicates with the authentication server, and the server validates the client’s identity, enabling access to the LAN

Banner messages for local web authentication

Local web authentication banners provide visual feedback to users during authentication on switches. The banners can display default or customized messages. They may also include branding or additional information on the login and result screens.

Default banner messages

When web authentication is enabled, one of these default messages appears on both the login screen and the authentication result pop-up page:

  • Authentication Successful

  • Authentication Failed

  • Authentication Expired

Commands to configure local web authentication banner

You can configure the local web authentication banner using the .

Use the command in the global configuration mode:

Device(config)# parameter map type webauth global
Device(config-params-parameter-map)# banner ?
file <file-name>
text <Banner text>
title <Banner title>

You can add a custom message, such as a switch, router, or company name, to the banner using the command:

Device(config)# parameter map type webauth global
Device(config-params-parameter-map)# banner text <text>

You can add a logo or text file to the banner using the command:

Device(config)# parameter map type webauth global
Device(config-params-parameter-map)# banner text <filepath>

Banner examples

Figure 2. Customized web banner: Authentication Successful
Customized web banner with 'Authentication Successful
Figure 3. Login screen with no banner
Login screen showing no banner present.

Banner usage and behavior

  • The default banners are Cisco Systems and Switch host-name Authentication. These banners appear on the login page. The Cisco Systems banner also appears on the authentication result pop-up page.

  • The default banners appear unless custom banners are configured.

  • If you do not enable a banner, only username and password dialog boxes appear on the web authentication login screen. You will not see a banner when you log into the switch.

Authentication states in customized local web authentication

During local web authentication, the switch’s internal HTTP server hosts four HTML pages that communicate authentication states to the client.

You can replace the default internal HTML pages or specify a URL that redirects users after authentication. This URL replaces the internal Success page.

The four authentication pages and states are:

  • Login: Credentials are requested from the client.

  • Success: The client has authenticated successfully.

  • Fail: Authentication attempt failed.

  • Expire: The session expires after excessive failures.

You must configure all four pages. You can specify text or add a logo to each of the four pages.

Banner examples

Figure 4. Customizable Authentication Page
Customizable Web Authentication banner

Best practices for customizing web authentication pages

  • Add appropriate text to the banner and login pages as needed.

  • Always include a valid HTML redirect command in the success page to redirect users to a specific URL after login

  • Ensure the URL string is well-formed (for example, "http://www.cisco.com") to avoid browser errors.

  • If you configure web pages for HTTP authentication, include the appropriate HTML commands. For example, HTML commands to set the page time out, to set a hidden password, or to confirm that the same page is not submitted twice.

  • You can copy the configured web pages to the switch boot flash or the flash.

  • The login page can reside on one flash device, while the success and failure pages can be stored on another flash device

  • You must configure all four pages.

  • All logo files—including image, flash, audio, video, and similar file types—stored in the system directory must use web_auth_<filename> as the file name. System directory examples are flash, disk0, or disk.

  • You can copy the configured web pages to the switch boot flash or the flash.

Restrictions for customizing web authentication pages

  • The banner page has no effect if it is configured together with a web authentication page.

  • When the configured login form is enabled, the CLI command for redirecting users to a specific URL is unavailable. Configure redirection in the web page.

  • If you enter the CLI command to redirect users to a specific URL after authentication and then configure web pages, the redirect command does not take effect.

  • The configured authentication proxy feature supports both HTTP and SSL.

Guidelines for configuring a redirection URL for Successful Login page

  • If you enable the custom authentication proxy web pages feature, you cannot use the redirection URL feature in the CLI. To redirect users after login, configure redirection in the custom login success page.

  • If you enable the redirection URL feature, the configured authorization proxy banner is not be used.

  • To remove the specification of a redirection URL, use the no form of the command.

  • If a redirection URL is required after successful authentication, it must begin with a valid protocol prefix (such as http://) followed by the URL. If http:// is omitted, the browser might show a page not found error or similar issue

How to configure local web authentication

Configure default local web authentication

Table 1. Default local web authentication configuration

Feature

Default Setting

AAA

Disabled

RADIUS server

  • IP address

  • UDP authentication port

  • Key

  • None specified

Default value of inactivity timeout

3600 seconds

Inactivity timeout

Enabled

Configure AAA authentication (GUI)

Set up AAA authentication to control network access using the GUI.

Use this task to define and assign authentication methods and server groups for device access.

Before you begin

Confirm that server groups are configured if you plan to use them.

Procedure

Step 1

Choose Configuration > Security > AAA.

Step 2

In the Authentication section, click Add.

Step 3

In the Quick Setup: AAA Authentication window that is displayed, enter a name for your method list.

Step 4

Choose the type of authentication you want to perform before allowing access to the network, in the Type drop-down list.

Step 5

In the Group Type drop-down list, select either a group of servers as your access server or a local server to authenticate access.

Step 6

To configure a local server to act as a fallback method when servers in the group are unavailable, check the Fallback to local check box.

Step 7

Choose the server groups you want to use to authenticate access to your network, from the Available Server Groups list and click > icon to move them to the Assigned Server Groups list.

Step 8

Click Save & Apply to Device.

The controller is now configured with AAA authentication, and users are authenticated using the chosen methods.

Configure AAA authentication (CLI)

Enable authentication, authorization, and accounting (AAA) on the device to manage login methods and network access.

AAA centralizes user authentication for device access and network services. Select a named method list or the default list, depending on your VTY line configuration.

If no method list is configured under VTY lines, add the default method list to the AAA configuration.”

line vty 0 4 
 authorization commands 15 abc
aaa authorization commands 15 abc group tacacs+
If a method-list is not configured under VTY lines, you must add the default method list to the AAA configuration: 
line vty 0 4
 aaa authorization commands 15 default group tacacs+

Note

Use the default list for AAA authorization if you plan to use features such as dACL.

Before you begin

Ensure that the TACACS+ server address and group name are available.

Procedure

Step 1

Enable AAA functionality.

Example:

Device
(config)# aaa new-model

Step 2

Define the list of authentication methods at login using the aaa authentication login {default | named_authentication_list} group AAA_group_name command.

Example:


Device(config)# aaa authentication login default group AAA_group_name

named_authentication_list refers to any name that is not greater than 31 characters.

AAA_group_name refers to the server group name. Define the server_name at the beginning of the configuration.

Step 3

Create an authorization method list for web-based authorization using the aaa authorization network {default | named_authorization_list} group AAA_group_name command.

Example:


Device(config)# aaa authorization network default group group1

Step 4

Specify a AAA server.

Example:


Device(config)# tacacs-server host 10.1.1.1

Configure the HTTP or HTTPS server (GUI)

Set up HTTP and HTTPS access to enable secure web-based management of the device.

HTTP provides basic web access; HTTPS secures connections with SSL encryption. You can configure access ports, authentication, trust points, and session policies to meet your security requirements.

Before you begin

Confirm necessary certificates are available if using HTTPS trust points.

Procedure

Step 1

Choose Administration > Management > HTTP/HTTPS/Netconf.

Step 2

In the HTTP/HTTPS Access Configuration section, enable HTTP Access and enter the port that will listen for HTTP requests. The default port is 80. Valid values are 80, and ports between 1025 and 65535.

Step 3

Enable HTTPS Access on the device and enter the designated port to listen for HTTPS requests. The default port is 1025. Valid values are 443 and ports between 1025 and 65535. Data exchanged over a secure HTTP connection is encrypted before transmission across the Internet. SSL encryption over HTTP enables secure configuration of the switch through a web browser.

Step 4

Choose the Personal Identity Verification as enabled or disabled.

Step 5

In the HTTP Trust Point Configuration section, enable Enable Trust Point to use Certificate Authority servers as trustpoints.

Step 6

From the Trust Points drop-down list, choose a trust point.

Step 7

In the Timeout Policy Configuration section, enter the HTTP timeout policy in seconds. Enter a value between one to 600 seconds.

Step 8

Enter the number of minutes of inactivity allowed before the session times out. Enter a value between 180 and 1200 seconds.

Step 9

Enter the server life time in seconds. Enter a value between one and 86400 seconds.

Step 10

Enter the maximum number of requests the device can accept. Valid values range from one and 86400 requests.

Step 11

Save the configuration.

The device is configured for HTTP or HTTPS access according to your specified settings.

Configure the HTTP server (CLI)

Enable HTTP or HTTPS server functionality on your device to support local web authentication.

Local web authentication requires the HTTP server to be enabled on the controller.

You can configure both HTTP and HTTPS servers to support device management and user authentication.

Both HTTP and HTTPS servers can be configured to support device management and user authentication.

Note that some browsers, such as the Apple psuedo-browser, do not open if you configure only the ip http secure-server command. You should also configure the ip http server command.

Procedure

Step 1

Enable the HTTP server. The local web authentication feature uses the HTTP server to communicate with the hosts for user authentication.

Example:


Device(config)# ip http server

Step 2

Enable HTTPS.

Example:


Device(config)# ip http secure-server

You can configure custom authentication proxy web pages or specify a redirection URL for successful login.

Note

 

To ensure secure authentication when you enter the ip http secure-server command, the login page is always in HTTPS (secure HTTP) even if the user sends an HTTP request.

Step 3

Return to privileged EXEC mode.

Example:


Device(config)# end

The controller is now configured with the HTTP or HTTPS or both. This enables local web authentication and secure browser access for users.

Allow special characters for serial port

Configure the serial port to support special characters for advanced device communication.

Use this procedure when the connected device or application must process special characters on the serial console port.

Procedure

Step 1

Enter global configuration mode.

Example:

Device# configure terminal

Step 2

Configure the primary terminal line number.

Example:

Device(config)# line console 0

Step 3

Configure the time to disconnect idle EXEC sessions using the exec-timeout mins sec command.

Example:

Device(config-line)# exec-timeout 12 0

Step 4

Configure login authentication checking using the login authentication word default command.

Example:

Device(config-line)# login authentication NO_LOGIN
You can configure an authentication list with a name or use the default authentication list

Step 5

Configure the character widths of EXEC command characters using the exec-character-bit { 7 | 8} command.

Example:

Device(config-line)# exec-character-bit 8

Step 6

Configure the stop bits for the console port using the stopbits { 1 | 1.5| 2} command.

Example:

Device(config-line)# stopbits 1

Step 7

Return to privileged EXEC mode.

Example:

Device(config-line)# end

The serial port is now configured to support special characters according to your settings.

Allow special characters for VTY port

Enable the use of special (non-standard) characters in the banner text for Virtual Teletype (VTY) ports, which enhances customization options and supports global character sets.

You can allow special (non-standard) characters in the banner text for Virtual Teletype (VTY) ports. This lets you customize banners and support global character sets.

You may want to allow special characters in the banner displayed on the VTY port—for example, to include accented letters, non-English text, or symbols for branding or user communication.

Before you begin

Ensure you have determined the desired banner text and any required special characters.

Procedure

Step 1

Enter global configuration mode.

Example:

Device# configure terminal

Step 2

Create a parameter map and enter parameter-map webauth configuration mode.

Example:

Device(config)# parameter-map type webauth global

Step 3

Create a custom banner using the banner text text command.

Example:

Device(config-params-parameter-map)# banner text #Hêllö#

You can create a custom banner (of up to 400 characters) by entering c <banner-text> c, where c is a delimiting character.

If the banner text exceeds 400 characters (400 characters is about 250 words), you see an error message and the configuration is rejected. The parser limits each line to 254 characters (about 150 words), including CLI keywords. If you need more than 254 characters, split the banner text into multiple lines.

The webauth login page displays only the default banner strings, if banner command is not configured.

Step 4

Return to privileged EXEC mode.

Example:

Device(config-params-parameter-map)# end

You can now use special characters in the VTY port banner. When users connect through VTY, they see your custom banner.

Create a parameter map (GUI)

Define criteria-based policies to control device and user access within the local policy framework.

Use this task to create a parameter map by specifying match criteria and associating service templates. This enables dynamic policy application based on device type, user role, and other attributes.

Before you begin

Ensure you have the required policy details and service templates ready.

Procedure

Step 1

Choose Configuration > Security > Local Policy.

Step 2

Click Add.

Step 3

Click Policy Map.

Step 4

Enter Policy Map Name.

Step 5

In the Match Criteria List settings, click Add.

Step 6

In the Add Match Criteria settings, choose the service template from the Service Template drop-down list.

Step 7

Choose the filters from Device Type, User Role, User Name, OUI, and MAC Address drop-down lists.

Step 8

Click Add Criteria.

Step 9

Click Apply to Device.

The parameter map is created and applied, enabling policy enforcement based on the selected criteria.

Configure the maximum web authentication request retries

Set the maximum number of web authentication request retries to define how many times the system attempts authentication before it stops.

Configure this setting to adjust the tolerance for failed web authentication attempts, which can improve network security and user experience.

Before you begin

Ensure you are in global configuration mode on your device.

Procedure

Step 1

Configure the maximum web authentication request retries.

Example:


Device(config)# wireless security web-auth retries  number

number is the maximum number of web authentication request retries. The valid range is 0-20.

Step 2

Return to privileged EXEC mode.

Example:


Device(config)# end

You have configured the specified maximum number of web authentication request retries.

Configure a local banner in web authentication page (GUI)

Present a custom banner to users on the web authentication page to meet organizational messaging or compliance requirements.

Use this task to configure a banner that will display on the login page for web authentication sessions.

Procedure

Step 1

Choose Configuration > Security > Web Auth.

Step 2

In the Webauth Parameter Map tab, click the parameter map name. The Edit WebAuth Parameter window is displayed.

Step 3

In the General tab and choose the required Banner Type:

  • If you choose Banner Text, enter the required banner text to be displayed.

  • If you choose File Name, specify the path of the file from which the banner text has to be picked up.

Step 4

Click Update & Apply.

The specified banner displays on the web authentication page as configured.

Configure a local banner in web authentication page (CLI)

Present a custom banner to users on the Web Authentication page to meet organizational messaging or compliance requirements.

Use this task to configure a banner that displays on the login page for web authentication sessions.

Procedure

Step 1

Enter global configuration mode.

Example:

Device# configure terminal

Step 2

Configure the web authentication parameters. Enters the parameter map configuration mode.

Example:

Device(config)# parameter-map type webauth param-map

Step 3

Enable the local banner using the banner [ file | banner-text | title] command.

Example:

Device(config-params-parameter-map)# banner http C My Switch C

Create a custom banner by entering C banner-text C (where C is a delimiting character), or file that indicates a file (for example, a logo or text file) that appears in the banner, or title that indicates the title of the banner.

Step 4

Return to privileged EXEC mode.

Example:

Device(config-params-parameter-map)# end

The specified banner displays on the web authentication page as configured.

Configuration examples for local web authentication

Example: obtain a web authentication certificate

This example shows how to obtain web authentication certificate. 

DeviceDevice# configure terminal
Device(config)# crypto pki import cert pkcs12 tftp://10.1.0.100/ldapserver-cert.p12 cisco
Device(config)# end
Device# show crypto pki trustpoints cert
	Trustpoint cert:
    Subject Name: 
    e=rkannajr@cisco.com
    cn=sthaliya-lnx
    ou=WNBU
    o=Cisco
    l=SanJose
    st=California
    c=US
          Serial Number (hex): 00
    Certificate configured.
Device# show  crypto pki certificates cert
Certificate
  Status: Available
  Certificate Serial Number (hex): 04
  Certificate Usage: General Purpose
  Issuer: 
    e=rkannajr@cisco.com
    cn=sthaliya-lnx
    ou=WNBU
    o=Cisco
    l=SanJose
    st=California
    c=US
  Subject:
    Name: ldapserver
    e=rkannajr@cisco.com
    cn=ldapserver
    ou=WNBU
    o=Cisco
    st=California
    c=US
  Validity Date: 
    start date: 07:35:23 UTC Jan 31 2012
    end   date: 07:35:23 UTC Jan 28 2022
  Associated Trustpoints: cert ldap12 
  Storage: nvram:rkannajrcisc#4.cer

CA Certificate
  Status: Available
  Certificate Serial Number (hex): 00
  Certificate Usage: General Purpose
  Issuer: 
    e=rkannajr@cisco.com
    cn=sthaliya-lnx
    ou=WNBU
    o=Cisco
    l=SanJose
    st=California
    c=US
  Subject: 
    e=rkannajr@cisco.com
    cn=sthaliya-lnx
    ou=WNBU
    o=Cisco
    l=SanJose
    st=California
    c=US
  Validity Date: 
    start date: 07:27:56 UTC Jan 31 2012
    end   date: 07:27:56 UTC Jan 28 2022
  Associated Trustpoints: cert ldap12 ldap 
  Storage: nvram:rkannajrcisc#0CA.cer

Example: display a web authentication certificate

This example shows how to display a web authentication certificate. 

Device# show crypto ca certificate verb
					Certificate
  			Status: Available
  			Version: 3
  			Certificate Serial Number (hex): 2A9636AC00000000858B
  			Certificate Usage: General Purpose
  			Issuer:
    cn=Cisco Manufacturing CA
    o=Cisco Systems
  		Subject:
    Name: WS-C3780-6DS-S-2037064C0E80
    Serial Number: PID:WS-C3780-6DS-S SN:FOC1534X12Q
    cn=WS-C3780-6DS-S-2037064C0E80
    serialNumber=PID:WS-C3780-6DS-S SN:FOC1534X12Q
  		CRL Distribution Points:
    http://www.cisco.com/security/pki/crl/cmca.crl
  		Validity Date:
    start date: 15:43:22 UTC Aug 21 2011
    end   date: 15:53:22 UTC Aug 21 2021
  		Subject Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public Key: (1024 bit)
  		Signature Algorithm: SHA1 with RSA Encryption
  		Fingerprint MD5: A310B856 A41565F1 1D9410B5 7284CB21
  		Fingerprint SHA1: 04F180F6 CA1A67AF 9D7F561A 2BB397A1 0F5EB3C9
 			X509v3 extensions:
    X509v3 Key Usage: F0000000
      Digital Signature
      Non Repudiation
      Key Encipherment
      Data Encipherment
    X509v3 Subject Key ID: B9EEB123 5A3764B4 5E9C54A7 46E6EECA 02D283F7
    X509v3 Authority Key ID: D0C52226 AB4F4660 ECAE0591 C7DC5AD1 B047F76C
    Authority Info Access:
  		Associated Trustpoints: CISCO_IDEVID_SUDI
  		Key Label: CISCO_IDEVID_SUDI

Example: choose the default web authentication login page

This example shows how to choose a default web authentication login page. 

Device# configure terminal
Device(config)# parameter-map type webauth test
This operation will permanently convert all relevant authentication commands to their CPL control-policy equivalents. As this conversion is irreversible and will 
disable the conversion CLI 'authentication display [legacy|new-style]', you are strongly advised to back up your current configuration before proceeding.
Do you wish to continue? [yes]: yes
Device(config)# wlan wlan50
Device(config-wlan)# shutdown
Device(config-wlan)# security web-auth authentication-list test
Device(config-wlan)# security web-auth parameter-map test
Device(config-wlan)# no shutdown
Device(config-wlan)# end
Device# show running-config | section wlan50
wlan wlan50 50 wlan50
 security wpa akm wpa2
 security wpa wpa1
 security wpa wpa1 ciphers aes
 security wpa wpa1 ciphers tkip
 security web-auth authentication-list test
 security web-auth parameter-map test
 session-timeout 1800
 no shutdown

Device# show running-config | section parameter-map type webauth test
parameter-map type webauth test
 type webauth

Example: choosing a CWA login page from an IPv4 external web server

This example shows how to choose a customized web authentication login page from an IPv4 external web server. 

Device# configure terminal
Device(config)# parameter-map type webauth global
Device(config-params-parameter-map)# virtual-ip ipv4 192.0.2.1.
Device(config-params-parameter-map)# parameter-map type webauth test
Device(config-params-parameter-map)# type webauth
Device(config-params-parameter-map)# redirect for-login http://9.1.0.100/login.html
Device(config-params-parameter-map)# redirect portal ipv4 9.1.0.100
Device(config-params-parameter-map)# end
Device# show running-config | section parameter-map
parameter-map type webauth global
virtual-ip ipv4 192.0.2.1.
parameter-map type webauth test
type webauth
redirect for-login http://10.1.0.100/login.html
redirect portal ipv4 10.1.0.100
security web-auth parameter-map rasagna-auth-map
security web-auth parameter-map test

Example: choose a customized web authentication login page from an IPv6 external web server

This example shows how to choose a customized web authentication login page from an IPv6 external web server. 

Device# configure terminal
Device(config)# parameter-map type webauth global
Device(config-params-parameter-map)# virtual-ip ipv6 2001:DB8::/48
Device(config-params-parameter-map)# parameter-map type webauth test
Device(config-params-parameter-map)# type webauth
Device(config-params-parameter-map)# redirect for-login http://9:1:1::100/login.html
Device(config-params-parameter-map)# redirect portal ipv6 9:1:1::100
Device(config-params-parameter-map)# end
Device# show running-config | section parameter-map
parameter-map type webauth global
virtual-ip ipv6 2001:DB8::/48
parameter-map type webauth test
type webauth
redirect for-login http://10:1:1::100/login.html
redirect portal ipv6 10:1:1::100
security web-auth parameter-map rasagna-auth-map
security web-auth parameter-map test

Example: assigning login, login failure, and logout pages per WLAN

This example shows how to assign login, login failure and logout pages per WLAN. 

Device# configure terminal
Device(config)# parameter-map type webauth test
Device(config-params-parameter-map)# custom-page login device flash:loginsantosh.html
Device(config-params-parameter-map)# custom-page login expired device flash:loginexpire.html
Device(config-params-parameter-map)# custom-page failure device flash:loginfail.html
Device(config-params-parameter-map)# custom-page success device flash:loginsucess.html
Device(config-params-parameter-map)# end
Device# show running-config | section parameter-map type webauth test
	parameter-map type webauth test
 type webauth
 redirect for-login http://10.1.0.100/login.html
 redirect portal ipv4 10.1.0.100
 custom-page login device flash:loginsantosh.html
 custom-page success device flash:loginsucess.html
 custom-page failure device flash:loginfail.html
 custom-page login expired device flash:loginexpire.html

Example: configure preauthentication ACL

This example shows how to configure preauthentication ACL. 

Device# configure terminal
Device(config)# wlan fff
Device(config-wlan)# shutdown
Device(config-wlan)# ip access-group web preauthrule
Device(config-wlan)# no shutdown
Device(config-wlan)# end
Device# show wlan name fff

Example: configure webpassthrough

This example shows how to configure webpassthrough. 

Device# configure terminal
Device(config)# parameter-map type webauth webparalocal
Device(config-params-parameter-map)# type consent
Device(config-params-parameter-map)# end
Device# show running-config | section parameter-map type webauth test
	parameter-map type webauth test
 type webauth
 redirect for-login http://10.1.0.100/login.html
 redirect portal ipv4 10.1.0.100

Verify web authentication type

To verify the web authentication type, run the command:

Device# show parameter-map type webauth all
Type Name
---------------------------------
Global global
Named webauth
Named ext
Named redirect
Named abc
Named glbal
Named ewa-2

Device# show parameter-map type webauth global
Parameter Map Name : global
Banner:
Text : CisCo
Type : webauth
Auth-proxy Init State time : 120 sec
Webauth max-http connection : 100
Webauth logout-window : Enabled
Webauth success-window : Enabled
Consent Email : Disabled
Sleeping-Client : Enabled
Sleeping-Client timeout : 60 min
Virtual-ipv4 : 10.0.2.1.
Virtual-ipv4 hostname :
Webauth intercept https : Disabled
Webauth Captive Bypass : Disabled
Webauth bypass intercept ACL :
Trustpoint name :
HTTP Port : 80
Watch-list:
Enabled : no
Webauth login-auth-bypass:
Device# show parameter-map type webauth name global
Parameter Map Name : global
Type : webauth
Auth-proxy Init State time : 120 sec
Webauth max-http connection : 100
Webauth logout-window : Enabled
Webauth success-window : Enabled
Consent Email : Disabled
Sleeping-Client : Disabled
Webauth login-auth-bypass:

External Web Authentication

Configure EWA with single WebAuth server address and default ports (80/443) (CLI)

Configure External Web Authentication (EWA) on your device to use a single WebAuth server address with default ports (80 or 443).

Use this procedure to redirect guest WLAN clients to a specific WebAuth portal using default HTTP or HTTPS ports.

Procedure

Step 1

Enter global configuration mode.

Example:

Device# configure terminal

Step 2

Define the authentication method at login.

Example:

Device(config)# aaa authentication login WEBAUTH local

Step 3

Create the parameter map using the parameter-map type webauth parameter-map-name command.

Example:

Device(config)# parameter-map type webauth ISE-Ext-Webauth_IP

The parameter-map-name must not exceed 99 characters.

Step 4

Configure the webauth type parameter.

Example:

Device(config-params-parameter-map)# type webauth

Step 5

Configure the URL string for redirect during login using the redirect for-login URL-String command.

Example:

Device(config-params-parameter-map)#  redirect for-login https://192.168.0.98:443/portal/PortalSetup.action?portal=ad64b062-1098-11e7-8591-005056891b52

Step 6

Configure the external portal IPv4 address.

Example:

Device(config-params-parameter-map)# redirect portal ipv4 192.168.0.98

Step 7

Return to global configuration mode.

Example:

Device(config-params-parameter-map)# exit

Step 8

Configure a WLAN using the wlan wlan-name wlan-id SSID-name command.

Example:

Device(config)#  wlan EWLC3-GUEST 3 EWLC3-GUEST

Step 9

Disable adaptive 11r.

Example:

Device(config-wlan)# no security ft adaptive

Step 10

Disable WPA security.

Example:

Device(config-wlan)# no security wpa

Step 11

Disable WPA2 security.

Example:

Device(config-wlan)# no security wpa wpa2

Step 12

Disable WPA2 ciphers for AES.

Example:

Device(config-wlan)# no security wpa wpa2 ciphers aes

Step 13

Disable security AKM for dot1x.

Example:

Device(config-wlan)# no security wpa akm dot1x

Step 14

Enable web authentication for WLAN.

Example:

Device(config-wlan)# security web-auth

Step 15

Enable authentication list for dot1x security using the security web-auth authentication-list authenticate-list-name command.

Example:

Device(config-wlan)# security web-auth authentication-list WEBAUTH

Step 16

Configure the parameter map using the security web-auth parameter-map parameter-map-name command.

Example:

Device(config-wlan)# security web-auth parameter-map ISE-Ext-Webauth_IP

Note

 

If parameter map is not associated with a WLAN, the configuration uses the global parameter map.

Step 17

Return to privileged EXEC mode.

Example:

Device(config-wlan)# end

Once enabled for the configured WLAN, web authentication redirects clients to the specified WebAuth portal using default ports.

Configure EWA with multiple web servers and/or ports different than default (80/443)

Configure an External Web Authentication (EWA) workflow to support multiple web servers and custom port numbers using CLI.

Enable guest access using EWA if there are multiple external web servers or if web authentication must use ports other than the default ports of 80 or 443.

Procedure

Step 1

Enter global configuration mode.

Example:

Device# configure terminal

Step 2

Define an extended IPv4 access list using a name, and enters access-list configuration mode.

Example:

Device(config)# ip access-list extended preauth_ISE_Ext_WA

Step 3

Permit access from any host to the first external web server port number 8443.

Example:

Device(config)# access-list-number permit tcp any host external_web_server_ip_address1 eq port-number

Example:

Device(config)# 10 permit tcp any host 192.168.0.98 eq 8443

Step 4

Permit access from any host to the second external web server port number 8443.

Example:

Device(config)# access-list-number permit tcp any host external_web_server_ip_address2 eq port-number

Example:

Device(config)# 10 permit tcp any host 192.168.0.99 eq 8443

Step 5

Permit DNS UDP traffic.

Example:

Device(config)# access-list-number permit udp any eq domain

Example:

Device(config)# 20 permit udp any any eq domain

Step 6

Permit DHCP traffic using the bootpc .

Example:

Device(config)# 30 permit udp any any eq bootpc

Example:

Device(config)# access-list-number permit udp any any eq bootpc

Step 7

Permit DHCP traffic using bootps .

Example:

Device(config)# access-list-number permit udp any any eq bootps

Example:

Device(config)# 40 permit udp any any eq bootps

Step 8

Permit the access from the first external web server port 8443 to any host.

Example:

Device(config)# access-list-number permit tcp any host external_web_server_ip_address1 eq port-number any

Example:

Device(config)# 50 permit tcp host 192.168.0.98 eq 8443 any

Step 9

Permit the access from the second external web server port 8443 to any host.

Example:

Device(config)# access-list-number permit tcp any host external_web_server_ip_address2 eq port-number any

Example:

Device(config)# 50 permit tcp host 192.168.0.99 eq 8443 any

Step 10

Permit DNS TCP traffic.

Example:

Device(config)# access-list-number permit tcp any eq domain

Example:

Device(config)# 60 permit tcp any any eq domain

Step 11

Deny all the other traffic.

Example:

Device(config)# access-list-number deny ip any any

Example:

Device(config)# 70 deny ip any any

Step 12

Create the WLAN using the wlan wlan-name wlan-id ssid command.

Example:

Device(config)# wlan wlan-name wlan-id ssid

Example:

Device(config)# wlan EWLC3-GUEST 3 EWLC3-GUEST

Step 13

Configure the IPv4 WLAN web ACL

Example:

Device(config-wlan)# ip access-group web name
The variable name specifies the user-defined IPv4 ACL name

Step 14

Return to privileged EXEC mode.

Example:

Device(config-wlan)# end

This configuration allows EWA with multiple external web servers and ports. It supports DNS or DHCP traffic and blocks unauthorized traffic.

Configure wired guest EWA with multiple web servers, ports different than default (80/443)

Configure Wired Guest External Web Authentication (EWA) when using multiple web servers or ports other than the default ports of 80 or 443 using CLI.

Wired Guest LAN profiles do not allow manual ACL assignment directly. To support multiple web servers or custom ports, use the bypass ACL in the global parameter map.

Procedure

Step 1

Enter global configuration mode.

Example:

Device# configure terminal

Step 2

Define an extended IPv4 access list using a name, and enter access-list configuration mode.

Example:

Device(config)# ip access-list extended BYPASS_ACL

Step 3

Allow the traffic to switch centrally.

Example:

Device(config)# 10 deny ip any host 192.168.0.45

Step 4

Allow the traffic to switch centrally

Example:

Device(config)# access-list-number  deny ip any host hostname

Example:

Device(config)# 20 deny ip any host 4.0.0.1

Step 5

Creates a parameter map and enter parameter-map webauth configuration mode.

Example:

Device(config)# parameter-map type webauth global

Step 6

Create a WebAuth bypass intercept using the ACL name.

Example:

Device(config-params-parameter-map)# webauth-bypass-intercept BYPASS_ACL

Note

 

You cannot manually apply an ACL to the wired guest profile to configure external web authentication with multiple IP addresses or different ports. To work around this, use the bypass ACL in the wired guest profile.

Step 7

Return to privileged EXEC mode.

Example:

Device(config-params-parameter-map)# end

The wired guest profile uses the bypass ACL, enabling external web authentication with multiple web servers or custom ports.

Authentication of Sleeping Client

Authenticating sleeping clients

A sleeping client is a wireless device that

  • has completed web authentication and been granted guest access

  • is allowed to enter sleep mode and wake up without reauthenticating through the login page, and

  • the controller stores sleeping client information for a configurable duration before requiring reauthentication.

The valid range is 10 minutes to 43200 minutes, with the default being 720 minutes. You can also configure this duration on WebAuth parameter map that is mapped to a WLAN. The sleeping client timer is activated when conditions such as idle timeout, session timeout, WLAN disabling, or AP nonoperational status occur.


Caution

If the MAC address of a client in sleep mode is spoofed, a fake device, such as a laptop, can be mistakenly authenticated.

Feature History

Feature Name

Release

Description

Webauth Sleeping Client Support

Cisco IOS XE 17.1.1s

The web authentication sleeping clients feature supports multiple combinations of authentications for a given client, which are configured on the WLAN profile.

Scenarios where sleeping clients do not need reauthentication

  • Suppose there are two embedded wireless controller s in a mobility group. A client that is associated with one embedded wireless controller goes to sleep and then wakes up and gets associated with the other embedded wireless controller.

  • Suppose there are three embedded wireless controller s in a mobility group. A client that is associated with the second embedded wireless controller that is anchored to the first controller goes to sleep, wakes up, and gets associated with the third embedded wireless controller.

  • A client sleeps, wakes up and gets associated with the same or different export foreign embedded wireless controller that is anchored to the export anchor.

Guidelines for mobility scenarios

  • This feature is supported on the FlexConnect scenario with local switching and central authentication.

  • L2 roaming in the same subnet is supported.

  • Anchor sleeping timer is applicable.

  • The sleeping client information is shared between multiple auto anchors when a sleeping client moves from one anchor to another.

Restrictions on authenticating sleeping clients

  • If the MAC address of a client in sleep mode is spoofed, a fake device, such as a laptop, can be mistakenly authenticated.

  • The sleep client feature works only for WLAN configured with WebAuth security.

  • You can configure the sleeping clients only on a per WebAuth parameter-map basis.

  • The authentication of sleeping clients feature is supported only on WLANs that have Layer 3 security enabled.

  • When Layer 3 security is enabled, the Authentication, Passthrough, and On MAC Filter failure web policies are supported. The Splash Page Web Redirect web policy is not supported.

  • The central web authentication of sleeping clients is not supported.

  • The authentication of sleeping clients feature is not supported on guest LANs and remote LANs.

  • A guest access sleeping client that has a local user policy is not supported. In this case, the WLAN-specific timer is applied.

Configure authentication for sleeping clients (GUI)

Enable authentication for sleeping clients to ensure devices can maintain secure network access even after entering sleep mode.

Sleeping clients, such as laptops or mobile devices, periodically enter low-power states. You configure authentication to ensure they reconnect securely and seamlessly when they wake.

Procedure

Step 1

Choose Configuration > Security > Web Auth.

Step 2

In the Webauth Parameter Map tab, click the parameter map name. The Edit WebAuth Parameter window is displayed.

Step 3

Check Sleeping Client Status check box.

Step 4

Click Update & Apply to Device.

Authentication for sleeping clients is now enabled. Devices entering sleep mode will reconnect securely without manual intervention.

Configure authentication for sleeping clients (CLI)

Configure authentication parameters to manage sleeping wireless clients and control their session persistence on the device.

Sleeping clients are wireless devices that temporarily disconnect due to power-saving or roaming behaviors. Configuring authentication for sleeping clients ensures they are recognized and handled appropriately during these periods.

Procedure

Step 1

Create a parameter map and enters parameter-map webauth configuration mode.

Example:

Device(config)# parameter-map type webauth global

Step 2

Configure the sleeping client timeout to 100 minutes.

Example:

Device(config-params-parameter-map)# sleeping-client timeout 100

Valid range is between 10 minutes and 43200 minutes.

Note

 

If you do not use the timeout keyword, the sleeping client is configured with the default timeout value of 720 minutes.

Step 3

Exit parameter-map webauth configuration mode and returns to privileged EXEC mode.

Example:

Device# end

Step 4

(Optional) Show the MAC address of the clients and the time remaining in their respective sessions.

Example:

Device# show wireless client sleeping-client

Step 5

(Optional) Delete sleeping client entries from the sleeping client cache.

  • clear wireless client sleeping-client —Deletes all sleeping client entries from the sleeping client cache.

  • clear wireless client sleeping-client mac-address mac-addr —Deletes the specific MAC entry from the sleeping client cache.

Example:

Device# clear wireless client sleeping-client 
mac-address 00e1.e1e1.0001

The device displays the global configuration prompt, allowing you to make configuration changes.

Multiple Authentication Combinations with 802.1X and LWA

Multiauthentication combinations with 802.1X authentication and local web authentication

A multiauthentication combination is a network access control strategy that

  • allows multiple authentication methods (such as 802.1X and web authentication) to be used in sequence

  • enables enforcement of security and user consent policies in wireless networks, and

  • supports policy merging to maintain consistent access controls throughout device connections.

Expanded Explanation

In a wireless setup, for example, in a university, clients authenticate through 802.1X authentication. Because the 802.1X (dot1X) authentication process is secure and does not require user intervention, the end-users are unaware of the network that their devices are connected to. This could lead to serious concerns if they connect to the university's wireless network and post inappropriate content or access restricted content.

To avoid this situation, web authentication (webauth) and 802.1X authentication are configured in the network. End-user consent is used as a part of webauth to inform users that they are connected to the university's Wi-Fi network.

When the end-users accept the credentials for consent, AAA policies are not applied. The AAA policies that were applied earlier are deleted, resulting in a VLAN change and client disconnection.

A new command is introduced in Cisco IOS XE Dublin 17.11.1 to fix this issue. When you run the consent activation-mode merge command, the policy that is applied through consent is merged with the policy applied for 802.1X or MAC Authentication Bypass (MAB) authentication, thereby allowing clients to access the network. This command is available in parameter-map mode, which is configured with type consent command.

Feature History

Release

Feature

Feature Information

Cisco IOS XE Dublin 17.11.1

Multiauthentication Combination of 802.1X and Local Web Authentication

This feature supports the merging of applied policies during multiauthentication of 802.1X or MAC authentication bypass (MAB) and local web authentication (LWA).

Limitations for multi authentication combination of 802.1X and local web authentication

  • It is not possible to configure this feature on the controller GUI.

  • SNMP is not supported.

  • When the consent activation-mode merge command is not configured on the webauth parameter map, the default activation mode is Replace. This means that the user profile for consent replaces all the user profile policies that were previously applied.

Enable the multiauthentication combinations of 802.1X authentication and local web authentication (CLI)

Configure multiauthentication by combining 802.1X authentication and local web authentication (LWA) on the device using CLI commands.

Use this procedure when you want to allow users to authenticate through both 802.1X and browser-based local web authentication. This is commonly needed for networks supporting multiple authentication types on a single interface.

Before you begin

Ensure that you have working knowledge of multiauthentication concepts, LWA (consent), and AAA override.

Procedure

Step 1

Enter global configuration mode.

Example:

Device# configure terminal

Step 2

Configure the webauth type parameter. Enters the parameter map configuration mode.

Example:

Device(config)# parameter-map type webauth parameter-map1

Step 3

Configure the type as consent .

Example:

Device(config-params-parameter-map)# type consent

Step 4

Enable policy activation mode and merges the previous policy using the [no] consent {activation-mode merge | email} command.

Example:

Device(config-params-parameter-map)# consent activation-mode merge

Run the no form of this command to disable the feature.

Multiauthentication combining 802.1X authentication and local web authentication is enabled on the device.

Verify multiauthentication combination with 802.1X authentication and local web authentication

To verify the multiauthentication combination with 802.1X authentication and LWA, run the command:
Device# show parameter-map type webauth lwa-consent
Parameter Map Name               : lwa_consent
  Banner Title                   : Consent Title
  Banner Text                    : Please accept the consent
  Type                           : consent
  Auth-proxy Init State time     : 300 sec
  Webauth max-http connection    : 200
  Webauth logout-window          : Enabled
  Webauth success-window         : Enabled
  Consent Email                  : Disabled
  Activation Mode                : Merge
  Sleeping-Client                : Disabled
  Webauth login-auth-bypass:

Title

Device