Consolidated Platform Configuration Guide, Cisco IOS Release 15.2(4)E (Catalyst 2960-X Switches)

Web-Based Authentication Overview

Use the web-based authentication feature, known as web authentication proxy, to authenticate end users on host systems that do not run the IEEE 802.1x supplicant.

When you initiate an HTTP session, web-based authentication intercepts ingress HTTP packets from the host and sends an HTML login page to the users. The users enter their credentials, which the web-based authentication feature sends to the authentication, authorization, and accounting (AAA) server for authentication.

If authentication succeeds, web-based authentication sends a Login-Successful HTML page to the host and applies the access policies returned by the AAA server.

If authentication fails, web-based authentication forwards a Login-Fail HTML page to the user, prompting the user to retry the login. If the user exceeds the maximum number of attempts, web-based authentication forwards a Login-Expired HTML page to the host, and the user is placed on a watch list for a waiting period.

Note

HTTPS traffic interception for central web authentication redirect is not supported.

Note

You should use global parameter-map (for method-type, custom, and redirect) only for using the same web authentication methods like consent, web consent, and webauth, for all the clients and SSIDs. This ensures that all the clients have the same web-authentication method.

If the requirement is to use Consent for one SSID and Web-authentication for another SSID, then you should use two named parameter-maps. You should configure Consent in first parameter-map and configure webauth in second parameter-map.

Note

The traceback that you receive when webauth client tries to do authentication does not have any performance or behavioral impact. It happens rarely when the context for which FFM replied back to EPM for ACL application is already dequeued (possibly due to timer expiry) and the session becomes ‘unauthorized’.

Based on where the web pages are hosted, the local web authention can be categorozied as follows:

Internal—The internal default HTML pages (Login, Success, Fail, and Expire) in the controller are used during the local web authentication.
Customized—The customized web pages (Login, Success, Fail, and Expire) are downloaded onto the controller and used during the local web authentication.
External—The customized web pages are hosted on the external web server instead of using the in-built or custom web pages.

Based on the various web authentication pages, the types of web authentication are as follows:

Webauth—This is a basic web authentication. Herein, the controller presents a policy page with the user name and password. You need to enter the correct credentials to access the network.
Consent or web-passthrough—Herein, the controller presents a policy page with the Accept or Deny buttons. You need to click the Accept button to access the network.
Webconsent—This is a combination of webauth and consent web authentication types. Herein, the controller presents a policy page with Accept or Deny buttons along with user name or password. You need to enter the correct credentials and click the Accept button to access the network.

Device Roles

With web-based authentication, the devices in the network have these specific roles:

Client—The device (workstation) that requests access to the LAN and the services and responds to requests from the switch. The workstation must be running an HTML browser with Java Script enabled.
Authentication server—Authenticates the client. The authentication server validates the identity of the client and notifies the switch that the client is authorized to access the LAN and the switch services or that the client is denied.
Switch—Controls the physical access to the network based on the authentication status of the client. The switch acts as an intermediary (proxy) between the client and the authentication server, requesting identity information from the client, verifying that information with the authentication server, and relaying a response to the client.

Figure 1. Web-Based Authentication Device Roles. This figure shows the roles of these devices in a network.

Host Detection

The switch maintains an IP device tracking table to store information about detected hosts.

Note

By default, the IP device tracking feature is disabled on a switch. You must enable the IP device tracking feature to use web-based authentication.

For Layer 2 interfaces, web-based authentication detects IP hosts by using these mechanisms:

ARP based trigger—ARP redirect ACL allows web-based authentication to detect hosts with a static IP address or a dynamic IP address.
Dynamic ARP inspection
DHCP snooping—Web-based authentication is notified when the switch creates a DHCP-binding entry for the host.

Session Creation

When web-based authentication detects a new host, it creates a session as follows:

Reviews the exception list.

If the host IP is included in the exception list, the policy from the exception list entry is applied, and the session is established.
Reviews for authorization bypass

If the host IP is not on the exception list, web-based authentication sends a nonresponsive-host (NRH) request to the server.

If the server response is access accepted, authorization is bypassed for this host. The session is established.
Sets up the HTTP intercept ACL

If the server response to the NRH request is access rejected, the HTTP intercept ACL is activated, and the session waits for HTTP traffic from the host.

Authentication Process

When you enable web-based authentication, these events occur:

The user initiates an HTTP session.
The HTTP traffic is intercepted, and authorization is initiated. The switch sends the login page to the user. The user enters a username and password, and the switch sends the entries to the authentication server.
If the authentication succeeds, the switch downloads and activates the user’s access policy from the authentication server. The login success page is sent to the user.
If the authentication fails, the switch sends the login fail page. The user retries the login. If the maximum number of attempts fails, the switch sends the login expired page, and the host is placed in a watch list. After the watch list times out, the user can retry the authentication process.
If the authentication server does not respond to the switch, and if an AAA fail policy is configured, the switch applies the failure access policy to the host. The login success page is sent to the user.
The switch reauthenticates a client when the host does not respond to an ARP probe on a Layer 2 interface, or when the host does not send any traffic within the idle timeout on a Layer 3 interface.
The switch reauthenticates a client when the host does not respond to an ARP probe on a Layer 2 interface.
The feature applies the downloaded timeout or the locally configured session timeout.
If the terminate action is RADIUS, the feature sends a nonresponsive host (NRH) request to the server. The terminate action is included in the response from the server.
If the terminate action is default, the session is dismantled, and the applied policy is removed.

Using Authentication Proxy

The authentication proxy feature requires some user interaction on the client host. The table below describes the interaction of the authentication proxy with the client host.

Table 1. Authentication Proxy Interaction with the Client Host
Authentication Proxy Action with Client	Description
Triggering on HTTP connections	If a user is not currently authenticated at the firewall router, any HTTP connection initiated by the user triggers the authentication proxy. If the user is already authenticated, the authentication proxy is transparent to the user.
Logging in using the login page	Triggering the authentication proxy generates an HTML-based login page. The user must enter a username and password to be authenticated with the AAA server. The Authentication Proxy Login Page figure, in the How the Authentication Proxy Works module, illustrates the authentication proxy login page.
Authenticating the user at the client	Following the login attempt, the authentication proxy action can vary depending on whether JavaScript is enabled in the browser. If JavaScript is enabled, and authentication is successful, the authentication proxy displays a message indicating the status of the authentication as shown in the Authentication Proxy Login Status Message figure, in the How the Authentication Proxy Works module. After the authentication status is displayed, the proxy automatically completes the HTTP connection. If JavaScript is disabled, and authentication is successful, the authentication proxy generates a popup window with additional instructions for completing the connection. See the Authentication Proxy Login Status Message with JavaScript Disabled figure, in the Secure Authentication module. If authentication is unsuccessful in any case, the user must log in again from the login page.

When to Use the Authentication Proxy

The following are some situations in which you can use the authentication proxy:

You want to manage access privileges on an individual (per-user) basis using the services provided by the authentication servers instead of configuring access control based on host IP address or global access policies. Authenticating and authorizing users from any host IP address also allows network administrators to configure host IP addresses using DHCP.
You want to authenticate and authorize local users before permitting access to intranet or Internet services.
You want to authenticate and authorize remote users before permitting access to local services.
You want to control access for specific extranet users. For example, you might want to authenticate and authorize the financial officer of a corporate partner with one set of access privileges while authorizing the technology officer for that same partner to use another set of access privileges.
You want to use the authentication proxy in conjunction with VPN client software to validate users and to assign specific access privileges.
You want to use the authentication proxy in conjunction with AAA accounting to generate “start” and “stop” accounting records that can be used for billing, security, or resource allocation purposes, thereby allowing users to track traffic from the authenticated hosts.

Applying Authentication Proxy

Apply the authentication proxy in the inbound direction at any interface on the router where you want per-user authentication and authorization. Applying the authentication proxy inbound at an interface causes it to intercept the initial connection request from an user, before that request is subjected to any other processing. If the user fails to gain authentication with the AAA server, the connection request is dropped.

How you apply the authentication proxy depends on your security policy. For example, you can block all traffic through an interface and enable the authentication proxy feature to require authentication and authorization for all user-initiated HTTP connections. Users are authorized for services only after successful authentication with the AAA server.

The authentication proxy feature also allows you to use standard access lists to specify a host or group of hosts whose initial HTTP traffic triggers the proxy.

The figure below shows the authentication proxy applied at the LAN interface with all network users required to be authenticated upon the initial connection (all traffic is blocked at each interface).

Figure 2. Applying the Authentication Proxy at the Local Interface

The figure below shows the authentication proxy applied at the dial-in interface with all network traffic blocked at each interface.

Figure 3. Applying the Authentication Proxy at an Outside Interface

Local Web Authentication Banner

With Web Authentication, you can create a default and customized web-browser banners that appears when you log in to a switch.

The banner appears on both the login page and the authentication-result pop-up pages. The default banner messages are as follows:

Authentication Successful
Authentication Failed
Authentication Expired

The Local Web Authentication Banner can be configured in legacy and new-style (Session-aware) CLIs as follows:

Legacy mode—Use the ip admission auth-proxy-banner http global configuration command.
New-style mode—Use the parameter-map type webauth global banner global configuration command.

The default banner Cisco Systems and Switch host-name Authentication appear on the Login Page. Cisco Systems appears on the authentication result pop-up page.

Figure 4. Authentication Successful Banner

The banner can be customized as follows:

Add a message, such as switch, router, or company name to the banner:
- Legacy mode—Use the ip admission auth-proxy-banner http banner-text global configuration command.
- New-style mode—Use the parameter-map type webauth global banner global configuration command.
Add a logo or text file to the banner:
- Legacy mode—Use the ip admission auth-proxy-banner http file-path global configuration command.
- New-style mode—Use the parameter-map type webauth global banner global configuration command.
Figure 5. Customized Web Banner

If you do not enable a banner, only the username and password dialog boxes appear in the web authentication login screen, and no banner appears when you log into the switch.

Web Authentication Customizable Web Pages

During the web-based authentication process, the switch internal HTTP server hosts four HTML pages to deliver to an authenticating client. The server uses these pages to notify you of these four-authentication process states:

Login—Your credentials are requested.
Success—The login was successful.
Fail—The login failed.
Expire—The login session has expired because of excessive login failures.

Guidelines

You can substitute your own HTML pages for the default internal HTML pages.
You can use a logo or specify text in the login, success, failure, and expire web pages.
On the banner page, you can specify text in the login page.
The pages are in HTML.
You must include an HTML redirect command in the success page to access a specific URL.
The URL string must be a valid URL (for example, http://www.cisco.com). An incomplete URL might cause page not found or similar errors on a web browser.
If you configure web pages for HTTP authentication, they must include the appropriate HTML commands (for example, to set the page time out, to set a hidden password, or to confirm that the same page is not submitted twice).
The CLI command to redirect users to a specific URL is not available when the configured login form is enabled. The administrator should ensure that the redirection is configured in the web page.
If the CLI command redirecting users to specific URL after authentication occurs is entered and then the command configuring web pages is entered, the CLI command redirecting users to a specific URL does not take effect.
Configured web pages can be copied to the switch boot flash or flash.
The login page can be on one flash, and the success and failure pages can be another flash (for example, the flash on the active switch or a member switch).
You must configure all four pages.
The banner page has no effect if it is configured with the web page.
All of the logo files (image, flash, audio, video, and so on) that are stored in the system directory (for example, flash, disk0, or disk) and that must be displayed on the login page must use web_auth_<filename> as the file name.
The configured authentication proxy feature supports both HTTP and SSL.

You can substitute your HTML pages for the default internal HTML pages. You can also specify a URL to which users are redirected after authentication occurs, which replaces the internal Success page.

Figure 7. Customizable Authentication Page

Authentication Proxy Web Page Guidelines

When configuring customized authentication proxy web pages, follow these guidelines:

To enable the custom web pages feature, specify all four custom HTML files. If you specify fewer than four files, the internal default HTML pages are used.
The four custom HTML files must be present on the flash memory of the switch. The maximum size of each HTML file is 8 KB.
Any images on the custom pages must be on an accessible HTTP server. Configure an intercept ACL within the admission rule.
Any external link from a custom page requires configuration of an intercept ACL within the admission rule.
To access a valid DNS server, any name resolution required for external links or images requires configuration of an intercept ACL within the admission rule.
If the custom web pages feature is enabled, a configured auth-proxy-banner is not used.
If the custom web pages feature is enabled, the redirection URL for successful login feature is not available.
To remove the specification of a custom file, use the no form of the command.

Because the custom login page is a public web form, consider these guidelines for the page:

The login form must accept user entries for the username and password and must show them as uname and pwd.
The custom login page should follow best practices for a web form, such as page timeout, hidden password, and prevention of redundant submissions.

Redirection URL for Successful Login Guidelines

When configuring a redirection URL for successful login, consider these guidelines:

If the custom authentication proxy web pages feature is enabled, the redirection URL feature is disabled and is not available in the CLI. You can perform redirection in the custom-login success page.
If the redirection URL feature is enabled, a configured auth-proxy-banner is not used
To remove the specification of a redirection URL, use the no form of the command.
If the redirection URL is required after the web-based authentication client is successfully authenticated, then the URL string must start with a valid URL (for example, http://) followed by the URL information. If only the URL is given without http://, then the redirection URL on successful authentication might cause page not found or similar errors on a web browser.

Web Authentication Redirection to Original URL Overview

The Web Authentication Redirection to Original URL feature enables networks to redirect guest users to the URL that they had originally requested. This feature is enabled by default and requires no configuration.

Guest networks are network connections provided by an enterprise to allow their guests to gain access to the Internet and to their own enterprise networks without compromising the security of the host enterprise. Guest users of an enterprise network can connect to the guest access network through either a wired Ethernet connection or a wireless connection.

Guest access uses a captive portal to gather all web requests made by guests and redirect these requests to one of the guest on-boarding web pages. When guests successfully complete the guest workflow, they are redirected to the page that they had originally requested.

The originally requested URL is passed as metadata along with the Cisco Identity Services Engine (ISE) guest access redirect URL. The Cisco ISE is a security policy management and control platform. It automates and simplifies access control and security compliance for wired, wireless, and VPN connectivity. The requested URL is added at the end of the Cisco ISE guest URL so that the device can send the redirect URL to the guest client. The Cisco ISE parses the URL and redirects the guest to the original URL after completing the on-boarding.

The following is an example of a redirect URL along with the original requested URL:

https://10.64.67.92:8443/guestportal/gateway?sessionId=0920269E0000000B0002426B&action=cwa&redirect_
url=http://www.cisco.com/

In this example, the URL, https://10.64.67.92:8443/guestportal/gateway?sessionId= 0920269E0000000B0002426B&action=cwa is the URL for the guest portal, “&” tells the browser that what follows is a list of name value pairs, and redirect_url=http://www.cisco.com identifies the URL that the user originally requested and to which the user is redirected after completing the guest workflow.

This illustration displays the packet flow that redirects a user to the originally requested URL:

Figure 8. Original URL Redirection Packet Flow

A user accesses a network for the first time and sends an HTTP request to access www.google.com. When the user first accesses the network, a MAC authentication bypass (MAB) is triggered and the MAC address is sent to the Cisco ISE.
The Cisco ISE returns a RADIUS access-accept message (even if the MAC address is not received) along with the redirect access control list (ACL), the ACL-WEBAUTH-REDIRECT message, and the guest web portal URL to the device.

The RADIUS message instructs the device to open a port that is restricted based on the configured port and the redirect ACLs, for regular network traffic.
When the user launches a web browser, the device intercepts the HTTP traffic and redirects the browser to the Cisco ISE central web authentication (CWA) guest web portal URL; the user-requested URL is extracted and appended to the Cisco ISE guest URL.
When the user is authenticated, the Cisco ISE sends the Device Registration page to the user. The user enters the required information, and the page is returned to the Cisco ISE. The Cisco ISE downloads user profiles and redirects the user to the originally requested URL: www.google.com.

Web-based Authentication Interactions with Other Features

802.1x Authentication

These are the 802.1x authentication configuration guidelines:

When 802.1x authentication is enabled, ports are authenticated before any other Layer 2 or Layer 3 features are enabled.
If the VLAN to which an 802.1x-enabled port is assigned changes, this change is transparent and does not affect the switch. For example, this change occurs if a port is assigned to a RADIUS server-assigned VLAN and is then assigned to a different VLAN after re-authentication.

If the VLAN to which an 802.1x port is assigned to shut down, disabled, or removed, the port becomes unauthorized. For example, the port is unauthorized after the access VLAN to which a port is assigned shuts down or is removed.
The 802.1x protocol is supported on Layer 2 static-access ports, voice VLAN ports, and Layer 3 routed ports, but it is not supported on these port types:
- Dynamic ports—A port in dynamic mode can negotiate with its neighbor to become a trunk port. If you try to enable 802.1x authentication on a dynamic port, an error message appears, and 802.1x authentication is not enabled. If you try to change the mode of an 802.1x-enabled port to dynamic, an error message appears, and the port mode is not changed.
- EtherChannel port—Do not configure a port that is an active or a not-yet-active member of an EtherChannel as an 802.1x port. If you try to enable 802.1x authentication on an EtherChannel port, an error message appears, and 802.1x authentication is not enabled.
- Switched Port Analyzer (SPAN) and Remote SPAN (RSPAN) destination ports—You can enable 802.1x authentication on a port that is a SPAN or RSPAN destination port. However, 802.1x authentication is disabled until the port is removed as a SPAN or RSPAN destination port. You can enable 802.1x authentication on a SPAN or RSPAN source port.
Before globally enabling 802.1x authentication on a switch by entering the dot1x system-auth-control global configuration command, remove the EtherChannel configuration from the interfaces on which 802.1x authentication and EtherChannel are configured.
Cisco IOS Release 12.2(55)SE and later supports filtering of system messages related to 802.1x authentication.

AAA Accounting with Authentication Proxy

Using the authentication proxy, you can generate “start” and “stop” accounting records with enough information to be used for billing and security auditing purposes. Thus, you can monitor the actions of authenticated hosts that use the authentication proxy service.

When an authentication proxy cache and associated dynamic access control lists (ACLs) are created, the authentication proxy will start to track the traffic from the authenticated host. Accounting saves data about this event in a data structure stored with the data of other users. If the accounting start option is enabled, you can generate an accounting record (a “start” record) at this time. Subsequent traffic from the authenticated host will be recorded when the dynamic ACL created by the authentication proxy receives the packets.

When an authentication proxy cache expires and is deleted, additional data, such as elapsed time, is added to the accounting information and a “stop” record is sent to the server. At this point, the information is deleted from the data structure.

The accounting records for the authentication proxy user session are related to the cache and the dynamic ACL usage.

ACLs

If you configure a VLAN ACL or a Cisco IOS ACL on an interface, the ACL is applied to the host traffic only after the web-based authentication host policy is applied.

For Layer 2 web-based authentication, it is more secure, though not required, to configure a port ACL (PACL) as the default access policy for ingress traffic from hosts connected to the port. After authentication, the web-based authentication host policy overrides the PACL. The Policy ACL is applied to the session even if there is no ACL configured on the port.

You cannot configure a MAC ACL and web-based authentication on the same interface.

You cannot configure web-based authentication on a port whose access VLAN is configured for VACL capture.

Context-Based Access Control

Web-based authentication cannot be configured on a Layer 2 port if context-based access control (CBAC) is configured on the Layer 3 VLAN interface of the port VLAN.

EtherChannel

You can configure web-based authentication on a Layer 2 EtherChannel interface. The web-based authentication configuration applies to all member channels.

Gateway IP

You cannot configure Gateway IP (GWIP) on a Layer 3 VLAN interface if web-based authentication is configured on any of the switch ports in the VLAN.

You can configure web-based authentication on the same Layer 3 interface as Gateway IP. The host policies for both features are applied in software. The GWIP policy overrides the web-based authentication host policy.

LAN Port IP

You can configure LAN port IP (LPIP) and Layer 2 web-based authentication on the same port. The host is authenticated by using web-based authentication first, followed by LPIP posture validation. The LPIP host policy overrides the web-based authentication host policy.

If the web-based authentication idle timer expires, the NAC policy is removed. The host is authenticated, and posture is validated again.

Port Security

You can configure web-based authentication and port security on the same port. Web-based authentication authenticates the port, and port security manages network access for all MAC addresses, including that of the client. You can then limit the number or group of clients that can access the network through the port.

Default Web-Based Authentication Configuration

The following table shows the default web-based authentication configuration.

Table 2. Default Web-based Authentication Configuration
Feature	Default Setting
AAA	Disabled
RADIUS server IP address UDP authentication port Key	None specified 1645 None specified
Default value of inactivity timeout	3600 seconds
Inactivity timeout	Enabled

Web-Based Authentication Configuration Guidelines and Restrictions

Web-based authentication is an ingress-only feature.
You can configure web-based authentication only on access ports. Web-based authentication is not supported on trunk ports, EtherChannel member ports, or dynamic trunk ports.
External web authentication, where the switch redirects a client to a particular host or web server for displaying login message, is not supported.
You cannot authenticate hosts on Layer 2 interfaces with static ARP cache assignment. These hosts are not detected by the web-based authentication feature because they do not send ARP messages.
By default, the IP device tracking feature is disabled on a switch. You must enable the IP device tracking feature to use web-based authentication.
You must enable SISF-Based device tracking to use web-based authentication. By default, SISF-Based device tracking is disabled on a switch.
You must configure at least one IP address to run the switch HTTP server. You must also configure routes to reach each host IP address. The HTTP server sends the HTTP login page to the host.
Hosts that are more than one hop away might experience traffic disruption if an STP topology change results in the host traffic arriving on a different port. This occurs because the ARP and DHCP updates might not be sent after a Layer 2 (STP) topology change.
Web-based authentication does not support VLAN assignment as a downloadable-host policy.
Web-based authentication supports IPv6 in Session-aware policy mode. IPv6 Web-authentication requires at least one IPv6 address configured on the switch and IPv6 Snooping configured on the switchport.
Web-based authentication and Network Edge Access Topology (NEAT) are mutually exclusive. You cannot use web-based authentication when NEAT is enabled on an interface, and you cannot use NEAT when web-based authentication is running on an interface.
Identify the following RADIUS security server settings that will be used while configuring switch-to-RADIUS-server communication:
- Host name
- Host IP address
- Host name and specific UDP port numbers
- IP address and specific UDP port numbers
The combination of the IP address and UDP port number creates a unique identifier, that enables RADIUS requests to be sent to multiple UDP ports on a server at the same IP address. If two different host entries on the same RADIUS server are configured for the same service (for example, authentication) the second host entry that is configured functions as the failover backup to the first one. The RADIUS host entries are chosen in the order that they were configured.

When you configure the RADIUS server parameters:

Specify the key string on a separate command line.
For key string , specify the authentication and encryption key used between the switch and the RADIUS daemon running on the RADIUS server. The key is a text string that must match the encryption key used on the RADIUS server.
When you specify the key string , use spaces within and at the end of the key. If you use spaces in the key, do not enclose the key in quotation marks unless the quotation marks are part of the key. This key must match the encryption used on the RADIUS daemon.

You can globally configure the timeout, retransmission, and encryption key values for all RADIUS servers by using with the radius-server host global configuration command. If you want to configure these options on a per-server basis, use the radius-server timeout , radius-server transmit, and the radius-server key global configuration commands.

Note

You need to configure some settings on the RADIUS server, including: the switch IP address, the key string to be shared by both the server and the switch, and the downloadable ACL (DACL). For more information, see the RADIUS server documentation.

Configuring the Authentication Rule and Interfaces

Follow these steps to configure the authentication rule and interfaces:

SUMMARY STEPS

enable
configure terminal
ip admission name name proxy http
interface type slot/port
ip access-group name
ip admission name
exit
ip device tracking
end
show ip admission status
copy running-config startup-config

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: `Switch> enable`	Enables privileged EXEC mode. Enter your password if prompted.
Step 2	configure terminal Example: `Switch# configure terminal`	Enters global configuration mode.
Step 3	ip admission name `name` proxy http Example: `Switch(config)# ip admission name webauth1 proxy http`	Configures an authentication rule for web-based authorization.
Step 4	interface `type` `slot/port` Example: `Switch(config)# interface gigabitethernet 1/0/1`	Enters interface configuration mode and specifies the ingress Layer 2 or Layer 3 interface to be enabled for web-based authentication. type can be fastethernet, gigabit ethernet, or tengigabitethernet.
Step 5	ip access-group `name` Example: `Switch(config-if)# ip access-group webauthag`	Applies the default ACL.
Step 6	ip admission name Example: `Switch(config)# ip admission name`	Configures an authentication rule for web-based authorization for the interface.
Step 7	exit Example: `Switch(config-if)# exit`	Returns to configuration mode.
Step 8	ip device tracking Example: `Switch(config)# ip device tracking`	Enables the IP device tracking table.
Step 9	end Example: `Switch(config)# end`	Returns to privileged EXEC mode.
Step 10	show ip admission status Example: `Switch# show ip admission status`	Displays the configuration.
Step 11	copy running-config startup-config Example: `Switch# copy running-config startup-config`	(Optional) Saves your entries in the configuration file.

Configuring AAA Authentication

Note

Beginning with Cisco IOS Release 15.2(7)E3, the legacy command tacacs-server is deprecated. Use the tacacs server command if the software running on your device is Cisco IOS Release 15.2(7)E3 or later release.

SUMMARY STEPS

aaa new-model
aaa authentication login default group {tacacs+ | radius}
aaa authorization auth-proxy default group {tacacs+ | radius}
tacacs server server-name
key {key-data}

DETAILED STEPS

	Command or Action	Purpose
Step 1	aaa new-model Example: `Switch(config)# aaa new-model`	Enables AAA functionality.
Step 2	aaa authentication login default group {tacacs+ \| radius} Example: `Switch(config)# aaa authentication login default group tacacs+`	Defines the list of authentication methods at login. named_authentication_list refers to any name that is not greater than 31 characters. AAA_group_name refers to the server group name. You need to define the server-group server_name at the beginning itself.
Step 3	aaa authorization auth-proxy default group {tacacs+ \| radius} Example: `Switch(config)# aaa authorization auth-proxy default group tacacs+`	Creates an authorization method list for web-based authorization.
Step 4	tacacs server `server-name` Example: `Switch(config)# tacacs server yourserver`	Specifies an AAA server.
Step 5	key {`key-data`} Example: `Switch(config-tacacs-server)# key goaway`	Configures the authorization and encryption key used between the switch and the TACACS server.

Configuring Switch-to-RADIUS-Server Communication

Follow these steps to configure the RADIUS server parameters:

SUMMARY STEPS

enable
configure terminal
ip radius source-interface vlan vlan interface number
radius-server host {hostname | ip-address} test username username
radius-server key string
radius-server dead-criteria tries num-tries
end

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: `Switch> enable`	Enables privileged EXEC mode. Enter your password if prompted.
Step 2	configure terminal Example: `Switch# configure terminal`	Enters global configuration mode.
Step 3	ip radius source-interface vlan `vlan interface number` Example: `Switch(config)# ip radius source-interface vlan 80`	Specifies that the RADIUS packets have the IP address of the indicated interface.
Step 4	radius-server host {`hostname` \| `ip-address`} test username `username` Example: `Switch(config)# radius-server host 172.l20.39.46 test username user1`	Specifies the host name or IP address of the remote RADIUS server. The test username `username` option enables automated testing of the RADIUS server connection. The specified `username` does not need to be a valid user name. The key option specifies an authentication and encryption key to use between the switch and the RADIUS server. To use multiple RADIUS servers, reenter this command for each server.
Step 5	radius-server key `string` Example: `Switch(config)# radius-server key rad123`	Configures the authorization and encryption key used between the switch and the RADIUS daemon running on the RADIUS server.
Step 6	radius-server dead-criteria tries `num-tries` Example: `Switch(config)# radius-server dead-criteria tries 30`	Specifies the number of unanswered sent messages to a RADIUS server before considering the server to be inactive. The range of `num-tries` is 1 to 100.
Step 7	end Example: `Switch(config)# end`	Returns to privileged EXEC mode.

Configuring the HTTP Server

To use web-based authentication, you must enable the HTTP server within the Switch. You can enable the server for either HTTP or HTTPS.

Note

The Apple psuedo-browser will not open if you configure only the ip http secure-server command. You should also configure the ip http server command.

Follow the procedure given below to enable the server for either HTTP or HTTPS:

SUMMARY STEPS

enable
configure terminal
ip http server
ip http secure-server
end

DETAILED STEPS

Command or Action Purpose

Step 1

enable

Example:


Switch> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:


Switch# configure terminal

Enters global configuration mode.

Step 3

ip http server

Example:


Switch(config)# ip http server

Enables the HTTP server. The web-based authentication feature uses the HTTP server to communicate with the hosts for user authentication.

Step 4

ip http secure-server

Example:


Switch(config)# ip http secure-server

Enables HTTPS.

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 5

end

Example:


Switch(config)# end

Returns to privileged EXEC mode.

Customizing the Authentication Proxy Web Pages

You can configure web authentication to display four substitute HTML pages to the user in place of the Switch default HTML pages during web-based authentication.

Follow these steps to specify the use of your custom authentication proxy web pages:

Before you begin

Store your custom HTML files on the Switch flash memory.

SUMMARY STEPS

enable
configure terminal
ip admission proxy http login page file device:login-filename
ip admission proxy http success page file device:success-filename
ip admission proxy http failure page file device:fail-filename
ip admission proxy http login expired page file device:expired-filename
end

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: `Switch> enable`	Enables privileged EXEC mode. Enter your password if prompted.
Step 2	configure terminal Example: `Switch# configure terminal`	Enters global configuration mode.
Step 3	ip admission proxy http login page file `device:login-filename` Example: `Switch(config)# ip admission proxy http login page file disk1:login.htm`	Specifies the location in the Switch memory file system of the custom HTML file to use in place of the default login page. The `device:` is flash memory.
Step 4	ip admission proxy http success page file `device:success-filename` Example: `Switch(config)# ip admission proxy http success page file disk1:success.htm`	Specifies the location of the custom HTML file to use in place of the default login success page.
Step 5	ip admission proxy http failure page file `device:fail-filename` Example: `Switch(config)# ip admission proxy http fail page file disk1:fail.htm`	Specifies the location of the custom HTML file to use in place of the default login failure page.
Step 6	ip admission proxy http login expired page file `device:expired-filename` Example: `Switch(config)# ip admission proxy http login expired page file disk1:expired.htm`	Specifies the location of the custom HTML file to use in place of the default login expired page.
Step 7	end Example: `Switch(config)# end`	Returns to privileged EXEC mode.

Specifying a Redirection URL for Successful Login

Follow these steps to specify a URL to which the user is redirected after authentication, effectively replacing the internal Success HTML page:

SUMMARY STEPS

configure terminal
configure terminal
ip admission proxy http success redirect url-string
end

DETAILED STEPS

	Command or Action	Purpose
Step 1	configure terminal Example: `Switch# configure terminal`	Enters global configuration mode.
Step 2	configure terminal Example: `Switch# configure terminal`	Enters global configuration mode.
Step 3	ip admission proxy http success redirect `url-string` Example: `Switch(config)# ip admission proxy http success redirect www.example.com`	Specifies a URL for redirection of the user in place of the default login success page.
Step 4	end Example: `Switch(config)# end`	Returns to privileged EXEC mode.

Configuring Web-Based Authentication Parameters

Follow these steps to configure the maximum number of failed login attempts before the client is placed in a watch list for a waiting period:

SUMMARY STEPS

enable
configure terminal
ip admission max-login-attempts number
exit

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: `Device> enable`	Enables privileged EXEC mode. Enter your password if prompted.
Step 2	configure terminal Example: `Device# configure terminal`	Enters global configuration mode.
Step 3	ip admission max-login-attempts `number` Example: `Device(config)# ip admission max-login-attempts 10`	Sets the maximum number of failed login attempts. The range is 1 to 2147483647 attempts. The default is 5.
Step 4	exit Example: `Device# exit`	Exits global configuration mode and returns to privileged EXEC mode.

Configuring a Web Authentication Local Banner

For the equivalent Session Aware Networking configuration example for this feature, see the section "Configuring a Parameter Map for Web-Based Authentication" in the chapter, "Configuring Identity Control Policies" of the book,"Session Aware Networking Configuration Guide, Cisco IOS XE Release 3SE (Catalyst 3850 Switches)."

Beginning in privileged EXEC mode, follow these steps to configure a local banner on a switch that has web authentication configured.

SUMMARY STEPS

configure terminal
ip auth-proxy auth-proxy-banner http [banner-text | file-path]
end
copy running-config startup-config

DETAILED STEPS

	Command or Action	Purpose
Step 1	configure terminal Example: `Switch# configure terminal`	Enters global configuration mode.
Step 2	ip auth-proxy auth-proxy-banner http [`banner-text` \| `file-path`] Example: `Switch(config)# aaa ip auth-proxy auth-proxy-banner C My Switch C`	Enables the local banner. (Optional) Create a custom banner by entering C banner-text C, where C is a delimiting character or a file-path indicates a file (for example, a logo or text file) that appears in the banner.
Step 3	end Example: `Switch(config)# end`	Returns to privileged EXEC mode.
Step 4	copy running-config startup-config Example: `Switch(config)# copy running-config startup-config`	(Optional) Saves your entries in the configuration file.

Configuring Web-Based Authentication without SVI

You configure the web-based authentication without SVI feature to redirect the HTML login page to the client without creating an IP address in the routing table. These steps are optional.

You configure the web-based authentication without SVI feature to redirect the HTML login page to the client. This is done without creating an IP address in the SVI interface which then would be applied to the WebAuth enabled interface. These steps are optional.

SUMMARY STEPS

enable
configure terminal
parameter-map type webauth global
l2-webauth-enabled
end
show running-config
copy running-config startup-config

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: `Switch> enable`	Enables privileged EXEC mode. Enter your password if prompted.
Step 2	configure terminal Example: `Switch# configure terminal`	Enters global configuration mode.
Step 3	parameter-map type webauth global Example: `Switch (config)# parameter-map type webauth global`	Creates a parameter map and enters parameter-map webauth configuration mode. The specific configuration commands supported for a global parameter map defined with the global keyword differ from the commands supported for a named parameter map defined with the parameter-map-name argument.
Step 4	l2-webauth-enabled Example: `Switch (config-params-parameter-map)# l2-webauth-enabled`	Enables the web-based authentication without SVI feature
Step 5	end Example: `Switch(config)# end`	Returns to privileged EXEC mode.
Step 6	show running-config Example: `Switch# show running-config`	Verifies your entries.
Step 7	copy running-config startup-config Example: `Switch# copy running-config startup-config`	(Optional) Saves your entries in the configuration file.

Configuring Web-Based Authentication with VRF Aware

You configure the web-based authentication with VRF aware to redirect the HTML login page to the client. These steps are optional.

SUMMARY STEPS

enable
configure terminal
parameter-map type webauth global
webauth-vrf-aware
end
show running-config
copy running-config startup-config

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: `Switch> enable`	Enables privileged EXEC mode. Enter your password if prompted.
Step 2	configure terminal Example: `Switch# configure terminal`	Enters global configuration mode.
Step 3	parameter-map type webauth global Example: `Switch (config)# parameter-map type webauth global`	Creates a parameter map and enters parameter-map webauth configuration mode. The specific configuration commands supported for a global parameter map defined with the global keyword differ from the commands supported for a named parameter map defined with the parameter-map-name argument.
Step 4	webauth-vrf-aware Example: `Switch (config-params-parameter-map)# webauth-vrf-aware`	Enables the web-based authentication VRF aware feature on SVI.
Step 5	end Example: `Switch(config)# end`	Returns to privileged EXEC mode.
Step 6	show running-config Example: `Switch# show running-config`	Verifies your entries.
Step 7	copy running-config startup-config Example: `Switch# copy running-config startup-config`	(Optional) Saves your entries in the configuration file.

Removing Web-Based Authentication Cache Entries

Follow these steps to remove web-based authentication cache entries:

SUMMARY STEPS

enable
clear ip auth-proxy cache {* | host ip address}
clear ip admission cache {* | host ip address}

DETAILED STEPS

Command or Action Purpose

Step 1

enable

Example:


Switch> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

clear ip auth-proxy cache {* | host ip address}

Example:


Switch# clear ip auth-proxy cache 192.168.4.5

Delete authentication proxy entries. Use an asterisk to delete all cache entries. Enter a specific IP address to delete the entry for a single host.

Step 3

clear ip admission cache {* | host ip address}

Example:


Switch# clear ip admission cache 192.168.4.5

Delete authentication proxy entries. Use an asterisk to delete all cache entries. Enter a specific IP address to delete the entry for a single host.

Monitoring Web-Based Authentication Status

Use the commands in this topic to display the web-based authentication settings for all interfaces or for specific ports.

Table 3. Privileged EXEC show Commands
Command	Purpose
show authentication sessions method webauth	Displays the web-based authentication settings for all interfaces for fastethernet, gigabitethernet, or tengigabitethernet
show authentication sessions  interface `type slot/port`[details]	Displays the web-based authentication settings for the specified interface for fastethernet, gigabitethernet, or tengigabitethernet. In Session Aware Networking mode, use the show access-session interface command.

Displaying Web-Based Authentication Status

Perform this task to display the web-based authentication settings for all interfaces or for specific ports:

SUMMARY STEPS

show authentication sessions {interfacetype/ slot}

DETAILED STEPS

Command or Action Purpose

Command or Action	Purpose
show authentication sessions {interface`type/ slot`} Example: This example shows how to view only the global web-based authentication status: `Switch# show authentication sessions` Example: This example shows how to view the web-based authentication settings for gigabit interface 3/27: `Switch# show authentication sessions interface gigabitethernet 3/27`	Displays the web-based authentication settings. type = fastethernet, gigabitethernet, or tengigabitethernet (Optional) Use the interface keyword to display the web-based authentication settings for a specific interface

show authentication sessions {interfacetype/ slot}

Example:

This example shows how to view only the global web-based authentication status:

Switch# show authentication sessions

Example:

This example shows how to view the web-based authentication settings for gigabit interface 3/27:

Switch# show authentication sessions interface gigabitethernet 3/27

Displays the web-based authentication settings.

type = fastethernet, gigabitethernet, or tengigabitethernet

(Optional) Use the interface keyword to display the web-based authentication settings for a specific interface

Monitoring HTTP Authentication Proxy

Perform the following task to troubleshoot your HTTP authentication proxy configuration:

SUMMARY STEPS

enable
debug ip auth-proxy detailed

DETAILED STEPS

Command or Action Purpose

Step 1

enable

Example:


Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

debug ip auth-proxy detailed

Example:


Device# debug ip auth-proxy detailed

Displays the authentication proxy configuration information on the device.

Verifying HTTPS Authentication Proxy

To verify your HTTPS authentication proxy configuration, perform the following optional steps:

SUMMARY STEPS

enable
show ip auth-proxy configuration
show ip auth-proxy cache
show ip http server secure status

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: `Device> enable`	Enables privileged EXEC mode. Enter your password if prompted.
Step 2	show ip auth-proxy configuration Example: `Device# show ip auth-proxy configuration`	Displays the current authentication proxy configuration.
Step 3	show ip auth-proxy cache Example: `Device# show ip auth-proxy cache`	Displays the list of user authentication entries. The authentication proxy cache lists the host IP address, the source port number, the timeout value for the authentication proxy, and the state of the connection. If the authentication proxy state is HTTP_ESTAB, the user authentication was successful.
Step 4	show ip http server secure status Example: `Device# show ip http server secure status`	Displays HTTPS status.

Example: Configuring the Authentication Rule and Interfaces

This example shows how to enable web-based authentication on Fast Ethernet port 5/1 :


Switch(config)# ip admission name webauth1 proxy http
Switch(config)# interface fastethernet 5/1
Switch(config-if)# ip admission webauth1
Switch(config-if)# exit
Switch(config)# ip device tracking

This example shows how to verify the configuration:


Switch# show ip admission status
IP admission status:
  Enabled interfaces            0
  Total sessions                0
  Init sessions                 0     Max init sessions allowed     100
    Limit reached               0     Hi watermark                  0
  TCP half-open connections     0     Hi watermark                  0
  TCP new connections           0     Hi watermark                  0
  TCP half-open + new           0     Hi watermark                  0
  HTTPD1 Contexts               0     Hi watermark                  0

  Parameter Map: Global
    Custom Pages
      Custom pages not configured
    Banner
      Banner not configured

Example: AAA Configuration


aaa new-model
aaa authentication login default group tacacs group radius
! Set up the aaa new model to use the authentication proxy.
aaa authorization auth-proxy default group tacacs group radius
! Define the AAA servers used by the router.
aaa accounting auth-proxy default start-stop group tacacs+
! Set up authentication proxy with accounting.
tacacs-server host 172.31.54.143 
tacacs-server key cisco
radius-server host 172.31.54.143
radius-server key cisco

Example: HTTP Server Configuration


! Enable the HTTP server on the router.
ip http server
! Set the HTTP server authentication method to AAA.
ip http authentication aaa
! Define standard access list 61 to deny any host.
access-list 61 deny any 
! Use ACL 61 to deny connections from any host to the HTTP server.
ip http access-class 61

Example: Customizing the Authentication Proxy Web Pages

This example shows how to configure custom authentication proxy web pages:


Switch(config)# ip admission proxy http login page file flash:login.htm
Switch(config)# ip admission proxy http success page file flash:success.htm
Switch(config)# ip admission proxy http fail page file flash:fail.htm
Switch(config)# ip admission proxy http login expired page flash flash:expired.htm

This example shows how to verify the configuration of a custom authentication proxy web pages:


Switch# show ip admission configuration
Authentication proxy webpage 
Login page : flash:login.htm 
Success page : flash:success.htm 
Fail Page : flash:fail.htm 
Login expired Page : flash:expired.htm 
  
Authentication global cache time is 60 minutes 
Authentication global absolute time is 0 minutes 
Authentication global init state time is 2 minutes 
Authentication Proxy Session ratelimit is 100 
Authentication Proxy Watch-list is disabled 
Authentication Proxy Auditing is disabled 
Max Login attempts per user is 5

Example: Specifying a Redirection URL for Successful Login

Configuring redirection URL for successful login


Switch(config)# ip admission proxy http success redirect www.cisco.com

Verifying redirection URL for Successful Login

This example shows how to configure a redirection URL for successful login:


Switch# show ip admission status 
 Enabled interfaces            0
 Total sessions                0
 Init sessions                 0     Max init sessions allowed     100
   Limit reached               0     Hi watermark                  0
 TCP half-open connections     0     Hi watermark                  0
 TCP new connections           0     Hi watermark                  0
 TCP half-open + new           0     Hi watermark                  0
 HTTPD1 Contexts               0     Hi watermark                  0

 Parameter Map: Global
   Custom Pages
     Custom pages not configured
   Banner
     Banner not configured

Additional References for Web-Based Authentication

Related Topic	Document Title
IBNS commands	Cisco IOS Identity-Based Networking Services Command Reference
Wired guest access	Wired Guest Access chapter

Technical Assistance


Description	Link
The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies. To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds. Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.	http://www.cisco.com/support

Feature Information for Web-Based Authentication


Release	Feature Information
Cisco IOS Release 15.0(2)EX	This feature is introduced.

Bias-Free Language

Results

Chapter: Configuring Web-Based Authentication

Configuring Web-Based Authentication

Web-Based Authentication Overview

Device Roles

Host Detection

Session Creation

Authentication Process

Using Authentication Proxy

When to Use the Authentication Proxy

Applying Authentication Proxy

Local Web Authentication Banner

Web Authentication Customizable Web Pages

Guidelines

Authentication Proxy Web Page Guidelines

Redirection URL for Successful Login Guidelines

Web Authentication Redirection to Original URL Overview

Web-based Authentication Interactions with Other Features

802.1x Authentication

AAA Accounting with Authentication Proxy

ACLs

Context-Based Access Control

EtherChannel

Gateway IP

LAN Port IP

Port Security

Default Web-Based Authentication Configuration

Web-Based Authentication Configuration Guidelines and Restrictions

Configuring the Authentication Rule and Interfaces

SUMMARY STEPS

DETAILED STEPS

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Configuring AAA Authentication

SUMMARY STEPS

DETAILED STEPS

Example:

Example:

Example:

Example:

Example:

Configuring Switch-to-RADIUS-Server Communication

SUMMARY STEPS

DETAILED STEPS

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Configuring the HTTP Server

SUMMARY STEPS

DETAILED STEPS

Example:

Example:

Example:

Example:

Example:

Customizing the Authentication Proxy Web Pages

Before you begin

SUMMARY STEPS

DETAILED STEPS

Example:

Example:

Example:

Example:

Example:

Example: