Local WebAuth Deployment Guide
Available Languages
Table Of Contents
About Cisco Validated Design (CVD) Program
Local WebAuth Deployment Guide
Operation 1—Before Web Authentication, IEEE 802.1X Times Out or Fails
Operation 2—Switch Opens Port for Limited Access
Operation 3—User Traffic Triggers Web Authentication Session State
Operation 4—User Gets Login Page
Operation 5—Authentication Server Authorizes User
Operation 6—Switch Applies New Policy and Redirects Page
Operation 7—Session Termination
Failed Authentications and Denial-of-Service Attacks
Multidomain-Authentication Host Mode
Preventing Authentication Failure with a Static Port ACL
Cisco Discovery Protocol Bypass
Using Cisco Catalyst Integrated Security Features
Configuring Web Authentication
Configuring the Switch in Cisco Secure ACS
Creating a User in Cisco Secure ACS Internal User Database
Creating a Downloadable ACL in Cisco Secure ACS
Creating an Authorization Profile in Cisco Secure ACS
Creating a Web Authentication Access Service
Creating a Web Authentication Service Selection Rule
Verifying Existing IEEE 802.1X Configuration
Enabling AAA for Web Authentication
Creating a Web Authentication Fallback Profile
Assigning the Web Authentication Fallback Profile to an Interface
Modifying Web Authentication Timers (Optional)
Session (Absolute) Timeout (Optional)
Configuring Customized Web Pages (Optional)
Supporting External Links in Customized Pages (Optional)
Configuring Web Authentication AAA Fail Policy (Optional)
Enabling Web Authentication for IEEE 802.1X Failures (Optional)
Configuring the IP Admission Watch List (Optional)
Monitoring and Troubleshooting Web Authentication
Local WebAuth Deployment GuideLast Updated: March 14, 2012
Building Architectures to Solve Business Problems
About Cisco Validated Design (CVD) Program
The CVD program consists of systems and solutions designed, tested, and documented to facilitate faster, more reliable, and more predictable customer deployments. For more information visit http://www.cisco.com/go/designzone.
ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS (COLLECTIVELY, "DESIGNS") IN THIS MANUAL ARE PRESENTED "AS IS," WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS ARE SOLELY RESPONSIBLE FOR THEIR APPLICATION OF THE DESIGNS. THE DESIGNS DO NOT CONSTITUTE THE TECHNICAL OR OTHER PROFESSIONAL ADVICE OF CISCO, ITS SUPPLIERS OR PARTNERS. USERS SHOULD CONSULT THEIR OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS. RESULTS MAY VARY DEPENDING ON FACTORS NOT TESTED BY CISCO.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at http://www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
Local WebAuth Deployment Guide
© 2011 Cisco Systems, Inc. All rights reserved.
Local WebAuth Deployment Guide
WebAuth is a convenient, well-understood method for authenticating end users. This document describes WebAuth network design considerations, outlines a framework for implementation, and provides step-by-step procedures for configuration. This document includes the following sections:
•
Configuring Web Authentication
•
WebAuth Overview
This section introduces WebAuth and includes the following topics:
What is WebAuth?
WebAuth enables network administrators to control network access and enforce policy based on the authenticated identity of a user. WebAuth helps prevent unauthorized access yet still enables network access for end hosts that do not support IEEE 802.1X authentication. When combined with other security elements such as infrastructure protection, threat identification and mitigation, and secure connectivity, WebAuth increases the ability of the network to defend itself.
In today's diverse workplaces, partners, consultants, contractors, and even guests need to access network resources over the same LAN connections as regular employees. Although IEEE 802.1X authentication secures the internal network by requiring employees to present valid credentials before accessing the network, provision must be made for users without IEEE 802.1X supplicants.
When used as a fallback mechanism to IEEE 802.1X, web authentication (WebAuth) provides supplemental authentication while maintaining the benefits of an IEEE 802.1X-protected network. IEEE 802.1X is a secure, standards-based, Layer 2 authentication mechanism. Because the switch first attempts IEEE 802.1X authentication, end hosts with IEEE 802.1X supplicants are subjected to a highly secure authentication procedure while also taking advantage of IEEE 802.1X-enabled features such as secure, standards-based authentication, dynamic VLAN assignment, Microsoft Windows machine authentication, and user authentication that is transparent to the user.
When the switch determines that the end host does not have an IEEE 802.1X supplicant or does not have valid credentials, the switch can fall back to WebAuth. WebAuth authenticates the user at the access edge by providing a web-based login page on which the user can enter credentials. After the user is identified, the user's identity can be employed by mapping identities to policies that grant or deny granular network access.
WebAuth Benefits
WebAuth offers the following benefits:
•
The ubiquity of browsers helps ensure that most users can use WebAuth. This aspect of WebAuth allows contractors, vendors, or others with unmanaged devices to get access to the network without having to install new software on their PCs.
•
•
Employees, partners, contractors, and guests can plug into the same wired port and dynamically acquire identity-based granular access through different authentication methods. The ubiquity of the configuration and policy deployment allows device mobility and faster, more efficient rollouts in heterogeneous environments.
•
•
Customizable web pages enable administrators to give these pages the look and feel of their organizations.
WebAuth Limitations
Although WebAuth is a convenient mechanism for user authentication on unmanaged devices, it has a number of limitations that restrict its use, including the following:
•
•
•
For temporary access (for example, guest, partner, contractor, or new machine), the need for multiple logins is typically well understood. However, for employees and managed assets, the capability to perform single sign-on with strong credentials is often considered essential to productivity. In the latter case, IEEE 802.1X is more appropriate than WebAuth because most IEEE 802.1X supplicants (clients) can be configured to reuse previously entered credentials (such as Microsoft Windows Active Directory-based passwords and X.509 certificates).
•
Note
•
•
•
For all of these reasons, Cisco recommends that WebAuth be used only as a means to provide supplemental access in an IEEE 802.1X-enabled network.
WebAuth Solution Components
The following hardware platforms and software releases are the minimum versions required to configure all the features described in this guide:
•
•
•
•
•
Note
•
Although other platforms were not tested as part of this solution, the Cisco Catalyst 4948 Switch is expected to perform similarly with these software releases.
This document does not discuss related technologies, including:
•
•
See the "References" section for information about these related technologies.
Sequence of Operations
This section describes the sequence of operations that occur during WebAuth, and includes the following topics:
•
•
•
•
•
•
•
Operation Sequence Overview
Successful WebAuth is the result of several operations. Although most of these operations are invisible to the end user, a clear understanding of these steps is helpful when deploying and maintaining WebAuth. The high-level sequence of operations is illustrated in Figure 1.
Figure 1 WebAuth Sequence of Operations
1.
2.
3.
4.
5.
6.
These steps are described in the sections that follow.
Note
Operation 1—Before Web Authentication, IEEE 802.1X Times Out or Fails
WebAuth is a fallback authentication mechanism for IEEE 802.1X-enabled networks. This means that WebAuth is used after the switch has attempted to authenticate the client with IEEE 802.1X. WebAuth is intended to provide only an alternative means of authentication when no IEEE 802.1X supplicant is available, or when an IEEE 802.1X supplicant exists but the authentication fails.
IEEE 802.1X Timeout
Cisco Catalyst switches initiate IEEE 802.1X authentication as soon as a host plugs into a port by sending an Extensible Authentication Protocol (EAP) Identity-Request message. If the host does not respond within a certain amount of time, the switch resends the Identity-Request message. By default, the switch resends the Identity-Request message twice before timing out the IEEE 802.1X authentication. The interval between each message is 30 seconds. In the default configuration, the switch takes a total of 90 seconds to time out. Both the interval and the number of retries can be configured. Only after IEEE 802.1X has timed out does the switch attempt another authentication method such as WebAuth. Figure 2 illustrates the IEEE 802.1X timeout process.
Figure 2 IEEE 802.1X Timeout Process
When determining the optimal IEEE 802.1X timer and retry values for your network, you should consider several factors.
In the default configuration, all traffic that is not EAP over LAN (EAPoL) traffic (including DHCP) is dropped until IEEE 802.1X times out. Therefore, the value of the timeout can significantly affect the DHCP client on the end host. Long IEEE 802.1X timeouts may prevent DHCP from functioning correctly after the IEEE 802.1X timeout expires. Without DHCP, a client cannot acquire an IP address and cannot use WebAuth. If an end user opens a browser before IEEE 802.1X times out, the end user experiences a Server Not Found error.
To prevent DHCP clients from timing out, one solution is to use lower IEEE 802.1X timer and retry values to help ensure that IEEE 802.1X times out before the DHCP client times out. Because DHCP timeouts can vary widely, Cisco recommends testing the DHCP clients in your network to discover how long they take to time out and setting the IEEE 802.1X timers accordingly.
After IEEE 802.1X has timed out and the port falls back to WebAuth, the switch no longer initiates IEEE 802.1X authentication by sending EAP Identity-Request messages. If a supplicant later becomes active on the port, the switch does not initiate an IEEE 802.1X session. The supplicant must initiate IEEE 802.1X by sending an EAPoL-Start frame to the switch. Almost all supplicants send (or can be configured to send) EAPoL-Start frames. In the rare instance in which a supplicant does not send an EAPoL-Start frame and the IEEE 802.1X timeout period is so short that the host does not boot up fast enough to launch the supplicant before IEEE 802.1X times out, the IEEE 802.1X-capable client may miss the opportunity to perform IEEE 802.1X authentication and is prompted for WebAuth instead. Therefore, Cisco recommends always deploying a supplicant that sends EAPoL-Start frames in accordance with the IEEE 802.1X specification.
Clearly, setting the IEEE 802.1X timer to an arbitrarily long or short value can have unintended consequences for network operation. Each network has a different optimal value. Therefore, as a best practice, Cisco recommends that you test the IEEE 802.1X timer values in your own network to determine the best value.
IEEE 802.1X Failure
By default, IEEE 802.1X authentication fails if the host has an IEEE 802.1X supplicant but does not have valid credentials. Cisco Catalyst switches can be configured to attempt WebAuth after IEEE 802.1X fails.
When IEEE 802.1X fails, it usually fails quickly, particularly if the supplicant has been configured for single sign-on. Therefore, problems associated with DHCP client timeouts and Server Not Found errors are typically not of concern in this use case.
In most respects, WebAuth works the same way whether it was triggered by IEEE 802.1X timeout or IEEE 802.1X failure. However, the trigger (failure or timeout) does become important if the user attempts (or reattempts) IEEE 802.1X authentication after WebAuth has started. The port "remembers" whether IEEE 802.1X timed out or failed, even after WebAuth has been initiated. If IEEE 802.1X times out, the switch listens for EAPoL-Start messages from the client and restarts IEEE 802.1X.
Note
Operation 2—Switch Opens Port for Limited Access
By default, IEEE 802.1X requires that, prior to authentication, the port is closed to all traffic except EAP packets. If the port were to remain in this state, the client would not be able to acquire an IP address or use a web browser for login. WebAuth is a Layer 3 authentication method that requires that the end host have an IP address. Therefore, after IEEE 802.1X (or MAB) has timed out or failed, the port must be opened long enough to allow the packets required for WebAuth.
During the WebAuth process, the switch restricts access on the port through a configurable ACL. Before deploying the ACL, however, the switch must open the port in some VLAN. Cisco Catalyst switches running Cisco IOS Software open the port in the default data VLAN that is configured on the port. Therefore, the default data VLAN is used for WebAuth. This is true regardless of whether IEEE 802.1X has timed out or IEEE 802.1X has failed prior to the start of WebAuth.
Note
For the highest level of traffic isolation, dynamic VLAN assignment can be used to assign endpoints authenticated by IEEE 802.1X and MAB to a different VLAN.
Note
By dynamically assigning a VLAN that is different from the default VLAN, the switch can completely isolate traffic from authenticated IEEE 802.1X and MAB endpoints from traffic from WebAuth endpoints. Moreover, the logical isolation provided by separate VLANs can be extended to the routed portion of the network using the path isolation techniques of network virtualization. By creating dedicated logical networks, network virtualization can provide end-to-end solutions for guest access and partner access scenarios. For more information about network virtualization, see http://www.cisco.com/en/US/netsol/ns658/index.html.
Note
After the port has been opened, the switch enforces a preconfigured ACL. By default, the preconfigured ACL is dynamically applied only when WebAuth is initiated. This initiation is accomplished using a WebAuth fallback profile. The preconfigured ACL in the fallback profile does not apply to ports in the critical VLAN, the auth-fail VLAN, or the guest VLAN.
At a minimum, the preconfigured ACL should allow the traffic required to complete the WebAuth process. In most cases, the ACL should at least allow DHCP (so the client can acquire an address) and DNS (so the client can trigger WebAuth when using fully qualified domain names in URLs). Additional access can be allowed according to the organization's security policy.
Operation 3—User Traffic Triggers Web Authentication Session State
After the switch has opened the port for limited access, it is the responsibility of the end host to trigger the WebAuth session state. Session state is created when the switch sees a DHCP transaction or an Address Resolution Protocol (ARP) packet. The switch depends on the host to send DHCP or ARP traffic to trigger WebAuth. If the host launches a browser before session state has been triggered, the user does not receive the web login page.
When the initial ARP or DHCP packet is received, the device is entered in the IP device tracking table. IP device tracking maintains a table of known devices and periodically sends ARP probes to verify that they are still active. A successful IP device tracking probe initiates session state.
After session state has been triggered, the init-state timer is started. See the init-state timer details in the "Operation 7—Session Termination" section for more information about configuring the init-state timer. The end user must enter valid credentials before the init-state timer expires or else the session state is cleared. After the session state is cleared, it must be re-established using one of the methods described in the preceding paragraphs.
Operation 4—User Gets Login Page
After session state has been created and the end user launches a browser, WebAuth is triggered and the switch returns the web login page. The login page contains fields for the user to enter a username and password. The login page can optionally be customized to contain additional information.
Note
After the user enters credentials at the login page and clicks the Submit button, the switch authenticates the credentials to a back-end authentication server using the RADIUS protocol.
The switch itself acts as the web server and provides the default login page. No external web server is required. Because the switch serves the page, it must be able to switch traffic to the host. This can be accomplished in two ways: using a switched virtual interface (SVI) or a default route. The choice of method depends in part on your existing network design. In either case, the connectivity requirements most likely already exist as part of the basic network design, but it is worthwhile to review them here.
If the switch has an SVI for the host's data VLAN, the switch has a Layer 3 address on the host's subnet and is able to route the login page directly to the host. If your network already supports the use of SVIs for data VLANs at the access edge, no additional configuration is required.
Note
If the switch is not configured for SVIs on the data VLANs, the switch can send the login page to the host using a default route. When a default route is used, all traffic from the switch to the host is sent to the default router, which may be one or more hops away. The default router then routes the traffic to the host back through the access switch. Figure 3 shows the initial TCP traffic flow for this situation.
Figure 3 TCP Traffic Flow for Login Page When No Layer 3 SVI for Host VLAN Exists on Access Switch
Although this approach introduces additional hops in the return path from the switch to the host, it produces negligible load on the default router and intervening infrastructure because only the WebAuth traffic from the switch to the host follows this path. In campus designs that do not use SVIs on the data VLAN, a default route is typically already configured.
Note
In this case, no additional configuration is required to support WebAuth. However, problems may arise in the case in which traffic to the default router is bridged through a stateful firewall. The original SYN packet in the TCP handshake is consumed by the access switch, so the first packet that the firewall sees is the SYN-ACK packet from the access switch. Stateful firewalls typically drop SYN-ACK packets if they have not seen the original SYN packet. In this case, you need to turn off stateful inspection for ports 80 and 443 on the firewall.
When a non-crypto image is used, Cisco IOS Software automatically redirects all HTTP packets (TCP port 80) to itself. URLs that reference HTTPS (TCP port 443) do not trigger redirection. If HTTPS support is required, a Cisco IOS Software crypto image is necessary. Cisco IOS Software crypto images redirect HTTPS traffic and can be configured to redirect HTTP traffic as well. URLs that contain a port other than 80 or 443 (for example, http://my-acs-server:2002) do not trigger redirection.
Note
If the crypto image is used and HTTPS is also configured, the switch initiates an SSL session, even if the initial HTTP request was to port 80. The advantage of this approach is that the user's credentials are sent over an encrypted channel to the switch and cannot be snooped. The disadvantage is that the browser prompts the end user to accept the switch's certificate, adding another step to the authentication process. By default, the switch sends a self-signed certificate. Some browsers display a warning or error message when receiving a self-signed certificate. Even if the certificate is signed by a trusted CA, the nature of the redirection process may still cause some browsers to display a warning message.
There are four web pages used in WebAuth that can be customized: login, authentication fail, authentication success, and authentication expired pages. If any one page is customized, the other pages must also be configured as customized pages.
The following design considerations must be addressed when customizing web pages:
•
•
Note
•
•
•
Sample web pages that can be used as the base of customized pages are provided in the "Sample Customizable Pages" section.
Operation 5—Authentication Server Authorizes User
After the end user enters their username and password, the switch sends a RADIUS Access-Request message to the AAA server. This is a normal Password Authentication Protocol (PAP) authentication request that contains user's name and hashed password.
Note
How the AAA server validates the user's name and password depends on the AAA server. The simplest authentication involves referencing an internal database of usernames and passwords locally configured on the AAA server. Some AAA servers also allow validation of credentials against external databases. The use of external databases often depends on what use case needs to be supported. For example, suppose an employee failed IEEE 802.1X because of an expired certificate and fell back to WebAuth. If the employee enters an Active Directory username and password on the login page, the AAA server must be able to query Active Directory to authenticate those credentials. Another use case might involve a guest without a supplicant or a contractor with a supplicant but without a valid IEEE 802.1X credential. The guest or contractor might then be provided with a temporary username and password that can be used for WebAuth. In those cases, the AAA server would need to query the sponsored guest credential repository (such as the network admission control [NAC] guest server).
Regardless of where the credentials are stored, if the user's credentials are valid, the AAA server sends a RADIUS Access-Accept message to the switch with an authorization policy that determines what level of access the user receives. This authorization policy takes the form of an ACL, which can permit or deny traffic based on IP address and upper-layer application.
Note
Because dACLs are currently the only ubiquitous dynamic ACL, only dACLs are discussed in this document.
A WebAuth request can be uniquely identified by looking at the Service-Type attribute in the initial Access-Request message from the switch. WebAuth requests from Cisco Catalyst switches running Cisco IOS Software always set the Service-Type attribute to 5. Table 1 shows the value of this attribute for other authentication types.
By filtering each Access-Request message based on the Service-Type attribute, the AAA server can identify the type of authentication request and use this as another condition or attribute in creating authorization policy rules. In Cisco Secure ACS 5.0, filtering can be accomplished using service selection rules.
Note
Operation 6—Switch Applies New Policy and Redirects Page
When the switch receives an Access-Accept message with the new ACL information from the authentication server, the switch customizes the ACL by adding the IP address of the end host as the source address in each line of the downloaded ACL. This process helps ensure that only the authenticated host can gain access using this ACL. The switch then adds this customized ACL to the preconfigured ACL. By adding the new ACL to the existing ACL, the switch is able to grant the user additional network access beyond the limited access that was allowed for the WebAuth process. The new combined ACL grants granular, per-user access to the network. The customized ACL can specify an IP address or subnet. It can also be configured to permit or deny access to specific applications (through the specification of TCP or User Datagram Protocol [UDP] ports).
Although ACLs are conceptually very simple, they can become very complex in real-world networks. Networks with an addressing scheme that is not summarized or networks in which related resources cannot be logically grouped together (for instance, in the same subnet) can result in long ACLs that are difficult to define, maintain, and troubleshoot. Good network design and well-considered security policy planning can reduce the problems associated with ACL scalability.
Management is not the only scalability concern with ACL-based authorization. Switches use ternary content addressable memory (TCAM) for hardware-based ACL processing. By processing ACLs in hardware, Cisco switches enable secure, high-bandwidth communication within the campus. However, long ACLs applied across numerous ports can overwhelm a switch's TCAM space. When selecting ACLs as an authorization method, be sure that your switches have sufficient TCAM capacity to handle the number and size of ACLs that you plan to deploy. Be aware that the total ACL length includes the port ACL in fallback profile and the dACL.
When designing dynamic ACLs, Cisco recommends using the shortest and simplest possible format. Using a simple ACL optimizes TCAM resources and makes ACL-based authorization more manageable.
After the dACL has been applied, the switch displays a customizable Authentication Success page and then redirect the user's browser to the original URL that the user was trying to access before WebAuth occurred.
Operation 7—Session Termination
This section describes how a WebAuth session can be terminated and includes the following topics:
•
Init-state Timer
If the user fails to enter valid credentials in the login page before the IP admission init-state timer expires, the session state is cleared and the session state must be reestablished by ARP or DHCP traffic from the host before WebAuth can be attempted again. Barring new DHCP or ARP traffic from the host itself, the WebAuth session state is reinstated by the first IP device tracking probe following the init-state timeout. By default, IP device tracking probes are sent every 30 seconds.
Link Down
The most direct way to terminate a WebAuth session is to unplug the host. When the link state of the port goes down, the switch completely clears the session. If the original host (or a new host) plugs in, the switch restarts authentication from the beginning, starting with IEEE 802.1X and MAB if so configured.
Absolute Session Timer
The absolute session timer is optionally returned in attribute 27 by the AAA server during the initial authentication. After this timer expires, the dACL is removed from the port, and the user's access is restricted until WebAuth is successfully completed. The absolute timer applies only to WebAuth; the switch does not restart IEEE 802.1X authentication or MAB when the absolute timer expires. If no absolute timer is specified in the RADIUS Access-Accept message, the session remains active unless it is terminated by a link-down event or the inactivity timer.
Inactivity Timer
The inactivity timer for WebAuth is controlled by the IP device tracking probe interval and retry count.
Note
IP device tracking maintains a table of known devices and periodically probes those devices to verify that they are still active. If no response is received, the switch repeats the probe until the configured count is reached. If all probes go unanswered, the WebAuth session is taken down. The switch does not restart IEEE 802.1X authentication or MAB after an inactivity timeout, but the original host (or any new host) is required to retrigger the session state and re-authenticate using WebAuth. Because the host is removed from the IP device tracking table after the inactivity timeout, no further probes are sent, and the inactive end host must send DHCP or ARP traffic to reinitiate session state.
An important application of the inactivity timer involves indirectly connected devices, such as a laptop connected behind an IP phone or through a hub. Because the switch has no direct knowledge of the link state of the indirectly connected device, it cannot terminate the session when that device unplugs. The best solution is to use the intelligence of the intermediary device to alert the switch when the device unplugs. For example, Cisco IP Phones and switches support the Cisco Discovery Protocol Second Port Status type and length value (TLV) that allows the phone to communicate to the switch when the device behind the phone unplugs, enabling the switch to clear the WebAuth session. For phones that do not support the Cisco Discovery Protocol Second Port Status TLV or for unmanaged devices (such as hubs) that have no way of communicating link-state information, the only solution is to use the IP device tracking-based inactivity timer. Without the inactivity timer, WebAuth sessions on indirectly connected devices would be maintained indefinitely (or until the absolute timer expired).
If you want to increase the inactivity timer for WebAuth, Cisco recommends increasing the IP device tracking probe count, not the probe interval, because the length of the IP device tracking probe interval can have a significant effect on other aspects of the end-user experience. As discussed above, IP device tracking is responsible for initializing the session state after an init-state timeout and when the open-access feature is used. Increasing the probe interval also increases the maximum amount of time a user may wait to receive a login page. Increasing the probe retry count increases the overall inactivity timer without affecting the amount of time a user may wait to receive a login page.
Failed Authentications and Denial-of-Service Attacks
If the user enters invalid credentials, the authentication server sends an Access-Reject message, and the switch makes no changes to the preconfigured ACL. The user receives a customizable Authentication Failed pop-up message.
During the WebAuth session, all HTTP packets are sent to the CPU for processing. To prevent a malicious user from exploiting this route to launch a denial-of-service (DoS) attack on the switch, an end host is put in a SERVICE_DENIED state after exceeding the maximum number of login attempts. By default, the user is allowed five login attempts before being locked out. By default, users who fail authentication five times are locked out for two minutes. A user who is locked out receives a customizable Authentication Expired pop-up message.
To change the default behavior for failed login attempts (five attempts and a 2-minute lockout), enable the IP admission watch list. If the IP admission watch list is enabled, an end host is added to the watch list if that user fails to authenticate after the maximum number of login attempts. After the host's IP address is on the watch list, the switch does not intercept HTTP packets from that host or perform WebAuth processing until the expiry timer has expired (default is 30 minutes). If the watch list is disabled, the default behavior (five attempts maximum with a 2-minute service denial) is restored.
After a session is terminated, the user must re-authenticate before being granted expanded access to the network again.
WebAuth Feature Interaction
This section includes the following topics:
MAC Authentication Bypass
MAB can be used for authenticating managed devices that do not have an IEEE 802.1X supplicant. During MAB, the switch learns the MAC address of the connected device and forwards it to the authentication server. The authentication server verifies that the MAC address matches that of a known device and instructs the switch to allow access according to the policy for that device.
WebAuth is fully compatible with MAB. In the event that a port is configured for IEEE 802.1X, MAB, and fallback WebAuth, the port first attempts to authenticate the user through IEEE 802.1X authentication. If IEEE 802.1X authentication times out or fails, the switch attempts MAB. If MAB fails, the switch attempts WebAuth.
The flow chart in Figure 4 shows the interaction between IEEE 802.1X timeout, MAB, and WebAuth.
Figure 4 Fallback WebAuth and MAB
Guest VLAN
If both the Guest VLAN and WebAuth are configured on Cisco IOS Software platforms, the guest VLAN configuration is ignored and the switch falls back to WebAuth when IEEE 802.1X times out.
Auth-Fail VLAN
After an IEEE 802.1X authentication failure, the switch can be configured to deploy the auth-fail VLAN or proceed to the next authentication method (MAB or WebAuth). In this sense, auth-fail VLAN and WebAuth are mutually exclusive when IEEE 802.1X fails. However, it is possible to configure the auth-fail VLAN for IEEE 802.1X failures (the client has a supplicant but does not have valid credentials) and still retain WebAuth for IEEE 802.1X timeouts (the client has no supplicant).
The auth-fail VLAN applies only to IEEE 802.1X failures. If WebAuth fails, the auth-fail VLAN is not applied. After a failed WebAuth attempt, the user is allowed to retry WebAuth until the maximum number of login attempts is reached. After that, the user is denied access for a configurable amount of time, as described in the "Operation 7—Session Termination" section.
Figure 5 illustrates the interaction of the auth-fail VLAN and WebAuth.
Figure 5 Fallback WebAuth and Auth-Fail VLAN
Inaccessible-Auth Bypass
Fallback WebAuth can be configured with inaccessible authentication (inaccessible-auth) bypass (also known as critical authentication or AAA fail-open). If a port is configured for both inaccessible-auth bypass and fallback WebAuth, the final state of the port when the AAA server is unavailable is determined by the timing of the connectivity loss and when the switch learns that the AAA server has failed.
If the switch already knows that the AAA server has failed, the port is immediately deployed for the critical VLAN as soon as the link comes up. Because the switch has multiple mechanisms for learning that the AAA server has failed, this outcome is the most likely.
If the switch determines that the AAA server has failed during an IEEE 802.1X or MAB authentication (for example, if this is the first device to connect to the switch after connectivity has been lost), the port is moved to the critical VLAN.
If the switch does not know that the AAA server has failed when the port falls back to WebAuth, the IEEE 802.1X-critical VLAN configuration has no effect. The port is moved to the data VLAN with the preconfigured ACL in the fallback profile. If a user attempts to use WebAuth under these conditions, an authentication failure results, and access to the port continues to be restricted by the default-port ACL. To change the default behavior, use the WebAuth AAA fail policy. The AAA fail policy (which applies only to WebAuth, not IEEE 802.1X or MAB) enables a user to connect by applying a specified policy (in effect, a new ACL) if the AAA server is not available. When the AAA server returns, the AAA fail policy is removed, and the end user is required to authenticate again.
Figure 6 illustrates the interaction of fallback WebAuth with inaccessible-auth bypass and AAA fail policy when the switch is not already aware that the AAA server has failed.
Figure 6 Interaction of WebAuth, AAA Fail Policy, and Inaccessible-Auth Bypass
Note
Port ACLs
When both a statically configured port ACL and a WebAuth fallback profile ACL are configured on the same port, the statically configured port ACL governs access to the port. The ACL in the fallback profile is ignored. Therefore, make sure that the statically configured port ACL allows at least enough access (DNS and DHCP) for the WebAuth process to be performed.
Open Access
WebAuth is compatible with the open-access feature as long as some additional design considerations are addressed.
By default, IEEE 802.1X drops all traffic prior to a successful IEEE 802.1X (or MAB) authentication or WebAuth initialization. This is sometimes referred to as closed mode. Cisco switches can be configured for open-access mode, which allows all traffic prior to successful authentication.
The first design consideration is the value of the IEEE 802.1X timeout that precedes WebAuth. Open-access mode allows configurable traffic types (such as DHCP) before IEEE 802.1X times out, which allows the DHCP client to acquire an IP address before IEEE 802.1X times out. However, even though the client has an IP address, the port does not begin the WebAuth process before IEEE 802.1X times out. Because WebAuth has not yet started redirecting traffic to the login page, the web traffic is subject to the port ACL, which will most likely deny all web traffic. Therefore, if an end user opens a browser before IEEE 802.1X times out, the end user experiences a Server Not Found error. Therefore, in open-access mode, Cisco recommends setting the IEEE 802.1X timers to account for the amount of time it usually takes for an end user to connect to the network and open a browser.
The second design consideration when using WebAuth with open-access mode is how the session state is triggered. The WebAuth session state is triggered when the switch detects DHCP or ARP traffic from the host. In the default closed mode, the host requests an address and ARP for its default gateway only after IEEE 802.1X has timed out or failed and the port has been opened for limited access for WebAuth. Prior to falling back to WebAuth, a port in closed mode drops all traffic, including DHCP and ARP traffic. In open-access mode, however, the port may allow DHCP and ARP traffic while IEEE 802.1X is still running. Thus, a host may have its address and the MAC address of the default gateway long before WebAuth begins. So when the port does fall back to WebAuth, there is no further DHCP or ARP traffic from the host to trigger session state.
The mechanism that helps ensure session state initialization in open-access mode is IP device tracking. IP device tracking maintains a table of known devices and periodically probes those devices using ARP to verify that they are still active. In the absence of DHCP or ARP traffic from the host, WebAuth session state is triggered by the first IP device tracking probe following the fallback to WebAuth. By default, IP device tracking probes are sent every 30 seconds. Therefore, in open-access mode, a user might wait up to 30 seconds (in addition to the time it takes IEEE 802.1X to time out) before the session state is triggered and the switch sends back the login page.
Using Host Modes
The host mode on a port determines the number and type of devices allowed on a port. WebAuth adheres to the host mode configured on the port. With the exception of multihost mode, all host modes are compatible with WebAuth with some design considerations.
Single-Host Mode
WebAuth is compatible with single-host mode. In single-host mode, only a single MAC or IP address can be authenticated (by any method) on a port. If a different MAC address is detected on the port after a host has authenticated with IEEE 802.1X, MAB, or WebAuth, a security violation is triggered on the port.
Multi-Auth Host Mode
WebAuth is compatible with multi-auth host mode. If the port is configured for multi-auth mode, multiple hosts can be authenticated separately using any method, including WebAuth, as long as each device downloads a dACL as a result of its authentication. Any device that does not download a dACL is subject to the port ACL after authentication.
Multidomain-Authentication Host Mode
WebAuth is compatible with multidomain-authentication host mode. For more information, see the "Multidomain Authentication" section.
Multihost Mode
Because WebAuth uses user-based ACL policies, multihost mode is not compatible with WebAuth.
Preventing Authentication Failure with a Static Port ACL
To prevent authorization failures caused by downloading a dACL when no port ACL is present, a static port ACL must be configured when the port is configured for WebAuth and multi-auth or multidomain host mode.
For example, suppose there are multiple devices on the same port: one that authenticates using WebAuth, and one that authenticates using IEEE 802.1X (or MAB). If the WebAuth device authenticates first, the port ACL in the fallback profile is applied, and the dACL for both the WebAuth device and the IEEE 802.1X device are successfully applied. However, if the IEEE 802.1X device authenticates before the WebAuth fallback profile has been applied, there is no port ACL. This behavior is a problem because the current implementation of dACLs requires a static port ACL on the port before any dACL can be applied. Therefore, in this situation, a dACL applied as a result of an IEEE 802.1X (or MAB) authentication could trigger an authorization failure.
This problem is exacerbated in IP telephony environments because the IP phone is often authenticated by IEEE 802.1X or MAB before the device behind the phone begins the WebAuth process.
To avoid this race condition, statically configure a port ACL on the port (not in the fallback profile). With a static ACL on the port, there is always be a port ACL when any device authenticates by any method. This configuration prevents any authorization failures caused by downloading of a dACL when no port ACL is present.
IP Telephony
This section includes the following topics:
•
Cisco Discovery Protocol Bypass
WebAuth is not compatible with Cisco IP Phones that use Cisco Discovery Protocol Bypass to access the voice infrastructure.
The ACLs that are used to restrict access before and after WebAuth are applied at the port level. This means that the data and voice VLANs are both subject to the ACL. If the phone uses Cisco Discovery Protocol to bypass authentication, it cannot download a dACL to open the port ACL for full access. Therefore, ports that are configured to allow phones using Cisco Discovery Protocol Bypass should not be configured for WebAuth.
Multidomain Authentication
Cisco IOS Software WebAuth is compatible with IP telephony when multidomain authentication host mode is used.
Unlike Cisco Discovery Protocol Bypass, which allows the phone free access to the network without authentication, multidomain authentication requires the phone to authenticate (using IEEE 802.1X or MAB). Because the phone authenticates, it can download its own dACL to access the port.
Note
IP Telephony and Link State
When WebAuth devices behind IP phones disconnect from the phones, the switch has no direct knowledge of the link state of the WebAuth session. Therefore, the switch does not know that it should take down the WebAuth session.
Cisco IP Phones and switches support a feature called Cisco Discovery Protocol Second Port Status TLV that allows the phone to communicate with the switch when the device behind the phone unplugs, enabling the switch to clear the WebAuth session. For phones that do not support Cisco Discovery Protocol Second Port Status, the only solution is to use the inactivity timer.
RADIUS Accounting
WebAuth supports RADIUS accounting, although the message format is not identical to that generated for a session authenticated by IEEE 802.1X or MAB. For specific details, see the "Sample Customizable Pages" section. In addition, a WebAuth session has two start records: one when the switch opens the port to begin WebAuth, and another when the user has successfully entered a username and password.
Using Cisco Catalyst Integrated Security Features
Note the following regarding WebAuth and Cisco Catalyst integrated security features:
•
•
•
•
Deployment Scenarios
When deploying IEEE 802.1X, Cisco recommends a phased deployment model that gradually deploys identity-based access control to the network. The three scenarios for phased deployment are as follows:
•
WebAuth is not recommended in monitor mode.
The primary goal of monitor mode is to enable authentication without imposing any form of access control. This approach allows network administrators to see who is on the network and prepare for access control in a later phase without affecting end users in any way.
If WebAuth is enabled, end users that fail or timeout IEEE 802.1X authentication and MAB have their HTTP traffic intercepted and are forced to enter credentials on the web login page (although all other forms of non-HTTP network access are still permitted). This effect on end users contradicts one of the primary goals of monitor mode, so WebAuth should not be enabled in this mode.
•
WebAuth is supported in low-impact mode as long as the following feature interactions are understood:
–
–
–
•
WebAuth is supported in high-security mode. However, because high-security mode uses multidomain authentication for IP telephony environments, all the design considerations described in the "Multidomain Authentication" section must be addressed.
For more information about scenario-based deployments, see http://www.cisco.com/go/ibns.
Configuring Web Authentication
This section includes the following sections:
•
•
•
•
•
•
•
This section describes how to configure a system based on Cisco IOS Software for IEEE 802.1X with WebAuth fallback. The sample configurations given in this section highlight the following features:
•
•
•
•
•
All features discussed in this section are required to configure basic WebAuth. Optional features and optimizations are discussed in later sections.
Configuring the Switch in Cisco Secure ACS
To add the switch that performs WebAuth as an AAA client in Cisco Secure ACS, complete the following steps.
Procedure
Step 1
Step 2
The window shown in Figure 7 appears.
Figure 7 Network Devices and AAA Clients
Step 3
Optionally, add Description, Location, and Device Type information.
The RADIUS shared secret must match the key configured on the switch. The IP address must match the IP address of the RADIUS source interface that the switch uses to source RADIUS packets for Cisco Secure ACS. See the "Configuring the Switch" section for information about how to configure the key and the RADIUS source interface on the switch.
Creating a User in Cisco Secure ACS Internal User Database
In this section, a WebAuth user is created in the Cisco Secure ACS internal user database. External databases can also be used for WebAuth. See the Cisco Secure ACS product documentation for more information about configuring external databases. To create a WebAuth user in the Cisco Secure ACS internal user database, complete the following steps.
Procedure
Step 1
Step 2
Step 3
The window shown in Figure 8 appears.
Figure 8 Users and Identity Stores
Step 4
Creating a Downloadable ACL in Cisco Secure ACS
To create a downloadable ACL in Cisco Secure ACS to be used in the authorization policy in a subsequent step, complete the following steps.
Procedure
Step 1
Step 2
The window shown in Figure 9 appears.
Figure 9 Downloadable ACLs
Step 3
A very simple example (granting full network access) is shown. The syntax for the ACL must conform to the requirements for extended Layer 3 ACLs in Cisco IOS Software with the additional requirement that the source of the ACL must be "any."
Tip
The switch replaces the source "any" in each ACL element with the IP address of the end host when it applies the dACL to the port.
Creating an Authorization Profile in Cisco Secure ACS
In this section, an authorization profile is created in Cisco Secure ACS. This profile is used in the authorization policy in a subsequent step. The authorization profile has three parts: the profile name, a dACL, and a manually entered RADIUS attribute that enables the switch to apply the dACL. To create an authorization profile, complete the following steps.
Procedure
Step 1
Step 2
The window shown in Figure 10 appears.
Figure 10 Authorization Profiles
Step 3
Step 4
In this example, the dACL is PERMIT-IP-ANY-ANY (see Figure 11).
Figure 11 Authorization Profiles—Downloadable ACL Name
Step 5
a.
b.
c.
d.
Note
Figure 12 RADIUS Attributes
Creating a Web Authentication Access Service
In this section, a WebAuth access service is created in Cisco Secure ACS. This access service is used in the service selection rules in a subsequent step. The access service profile has four parts: the service name, the allowed protocol filter, the identity policy, and the authorization policy. To create a WebAuth access service, complete the following steps.
Procedure
Step 1
Step 2
The list of existing access services appears.
Step 3
The window shown in Figure 13 appears.
Figure 13 Access Policies
Step 4
a.
b.
c.
d.
e.
The window shown in Figure 14 appears.
Figure 14 Access Policies—Allowed Protocols
Step 5
a.
b.
c.
d.
Step 6
The window shown in Figure 15 appears.
Figure 15 Access Policies—Access Services
Step 7
Step 8
a.
b.
c.
An Authorization Profiles dialog box appears.
Step 9
Figure 16 Authorization Profiles
Step 10
Creating a Web Authentication Service Selection Rule
This section describes how to create a service selection rule for WebAuth in Cisco Secure ACS. This service selection rule helps to ensure that the policies defined in the WebAuth access service applied to WebAuth requests. To create a service selection rule for WebAuth, complete the following steps.
Procedure
Step 1
Step 2
The list of existing service selection rules appears.
Step 3
The Service Selection Rule dialog box appears (see Figure 17).
Figure 17 Service Selection Rule
Step 4
a.
b.
c.
d.
e.
f.
g.
h.
i.
The Service Selection rule summary appears with the new rule, as shown in Figure 18.
Figure 18 Service Selection Rule Summary
Step 5
Configuring the Switch
In this section, the Cisco IOS Software switch is configured for WebAuth. Everything in this section is required to configure basic WebAuth. Optional features and optimizations are discussed in later sections.
This section includes the following topics:
•
•
•
•
•
•
•
•
•
•
Verifying Existing IEEE 802.1X Configuration
Because WebAuth is being configured as a fallback for IEEE 802.1X authentication, the first step is to verify the existing IEEE 802.1X configuration. A basic configuration of IEEE 802.1X includes global AAA settings, global RADIUS settings, global IEEE 802.1X settings, and interface IEEE 802.1X settings. These settings are summarized in Table 2. An example of a working configuration appears at the end of this section.
The following example shows a basic IEEE 802.1X configuration that should be configured prior to enabling WebAuth. The IEEE 802.1X timeout using this configuration is 15 seconds: tx-period * (max-reauth-req +1) = 5 * 3 = 15 seconds.
aaa new-modelaaa authentication dot1x default group radiusaaa authorization network default group radiusaaa accounting dot1x default start-stop group radius!dot1x system-auth-control!interface Gigabit 1/0/5switchport mode accessswitchport access vlan 30authentication port-control autodot1x pae-authenticatordot1x tx-period 5!radius-server host 10.100.10.117 1813 key cisco123radius-server vsa send
Note
Enabling AAA for Web Authentication
AAA must be enabled for WebAuth (see Table 3).
The following example shows the mandatory basic AAA configuration for WebAuth:
aaa authentication login default group radiusaaa authorization auth-proxy default group radiusaaa accounting auth-proxy default start-stop group radiusradius-server vsa send authenticationIt is important to note that the current implementation of WebAuth requires the use of the default login authentication group as RADIUS. As soon as it is configured, the default login group applies to all login attempts for the switch, including virtual teletype terminal (VTY) and console access. Everyone attempting to use Telnet to access the switch or to access the console is required to authenticate through RADIUS. To prevent the default AAA login configuration from applying to the console and VTY sessions, define a nondefault login group and apply this to the VTYs and the console. The following example configures a group named "none" that requires no authentication on VTYs or the console:
aaa authentication login LINE-CON none!line console 0login authentication LINE-CONline vty 0 4login authentication LINE-CONEnabling IP Device Tracking
IP device tracking is required to initiate the WebAuth session state, to maintain inactivity timers, and to correctly apply dACLs for authenticated devices (see Table 4).
The following example shows how to globally enable device tracking:
ip device trackingEnabling HTTP and HTTPS
To use WebAuth, the switch must have an HTTP server enabled. To intercept HTTPS requests and receive credentials over an encrypted link, a secure HTTP server (HTTPS) must also be enabled (see Table 5).
The following example shows how to enable both the HTTP and HTTPS servers on the switch:
ip http serverip http secure-serverCreating a Web Authentication Fallback Profile
The WebAuth fallback includes an IP admission rule and an access list (see Table 6).
The following example shows a WebAuth fallback profile:
ip admission name IP_ADMIN_RULE proxy httpip access-list extended PRE_WEBAUTH_POLICYpermit udp any any eq bootpspermit udp any any eq domainfallback profile WEB_AUTH_PROFILEip access-group PRE_WEBAUTH_POLICY inip admission IP_ADMIN_RULEAssigning the Web Authentication Fallback Profile to an Interface
The fallback profile must be assigned to an interface to take effect. The same profile can be assigned to multiple interfaces (see Table 7).
Table 7 Interface Settings for WebAuth Fallback Profile
authentication fallback fallback-profile
Enables the specified profile on the interface
The following example shows how to assign a WebAuth fallback profile to an interface:
interface Gigabit 1/0/5authentication fallback WEB_AUTH_PROFILEReviewing the Configuration
The following example shows all the required elements of a configuration for IEEE 802.1X with WebAuth fallback in the order they would appear in the command-line interface (CLI):
aaa new-model!aaa authentication dot1x default group radiusaaa authentication login default group radiusaaa authorization network default group radiusaaa authorization auth-proxy default group radiusaaa accounting dot1x default start-stop group radiusaaa accounting auth-proxy default start-stop group radius!ip device trackingip admission name IP_ADMIN_RULE proxy http!fallback profile WEB_AUTH_PROFILEip access-group PRE_WEBAUTH_POLICY inip admission IP_ADMIN_RULE!dot1x system-auth-control!interface Gigabit 1/0/5switchport mode accessswitchport access vlan 30authentication port-control autoauthentication fallback WEB_AUTH_PROFILEdot1x pae-authenticatordot1x tx-period 5!ip http serverip http secure-server!ip access-list extended PRE_WEBAUTH_POLICYpermit udp any any eq bootpspermit udp any any eq domain!radius-server host 10.100.10.117 key cisco123radius-server vsa send authenticationModifying Web Authentication Timers (Optional)
This section describes how to modify the timers that affect WebAuth.
Init-State Timer (Optional)
The default init-state timer is 2 minutes. To change the init-state timer, use the following global configuration (where the timer is specified in minutes):
ip admission init-state-time 5Inactivity Timeout (Optional)
By default, the switch sends IP device tracking probes at intervals of 30 seconds and declares the host inactive after three unanswered probes. To change these defaults, use the following commands (where the interval is given in seconds):
ip device tracking probe interval 200ip device tracking probe count 2Session (Absolute) Timeout (Optional)
The session timeout setting is specified in the RADIUS server configuration. The session timeout setting is controlled by IETF RADIUS attribute 27, Session Timeout. In this example, the WebAuth authorization profile in Cisco Secure ACS 5.0 is modified to send a session timeout of 600 seconds (10 minutes).
Procedure
Step 1
Step 2
Step 3
The window shown in Figure 19 appears.
Figure 19 Authorization Profiles—Common Tasks
Step 4
Step 5
Note
Configuring Customized Web Pages (Optional)
To specify the use of custom authentication proxy web pages, first store the custom HTML files on the switch's internal disk or flash memory. Four pages are required: login, success, fail, and expired. The filenames are arbitrary. In the following example, the four required pages are stored on disk1, and they are named login.htm, success.htm, fail.htm, and expired.htm:
ip admission proxy http login page file disk1:login.htmip admission proxy http success page file disk1:success.htmip admission proxy http fail page file disk1:fail.htmip admission proxy http login expired page file disk1:expired.htmSample web pages are provided in the "Sample Customizable Pages" section.
Supporting External Links in Customized Pages (Optional)
Any customized pages can include external links. A common application of an external link is to reference an image stored on a different server.
Suppose your login page includes a link to a company logo stored on another server:
switch# more login.html | include img srcimg src="http://10.100.10.119:8080/logo.jpg" alt="Company Logo">As discussed in the "Operation 4—User Gets Login Page" section, the destination port in the URL must be something other than TCP port 80 or 443. In addition, the ACL in the fallback profile must allow traffic to the URL. In the preceding example, the URL of the external image has been specified as port 8080 (assuming that the HTTP server on 10.100.10.119 is listening on that port). Therefore, the preconfigured ACL must be modified to allow access to 10.100.10.119 port 8080:
ip access-list extended PRE_WEBAUTH_POLICYpermit udp any any eq bootpspermit udp any any eq domainpermit tcp any host 10.100.10.119 eq 8080Configuring Web Authentication AAA Fail Policy (Optional)
The AAA fail policy consists of an ACL that is applied to the port when a user attempts web authentication when the AAA server is unavailable. There are three steps to configuring an AAA fail policy:
Step 1
ip access-list extended PERMITpermit ip any anyStep 2
identity policy FAILOPENaccess-group PERMITStep 3
ip admission name IP_ADMIN_RULE proxy http event timeout aaa policy identity FAILOPEN
Enabling Web Authentication for IEEE 802.1X Failures (Optional)
By default, WebAuth applies only when IEEE 802.1X times out because there is no supplicant on the end host. To also enable WebAuth when IEEE 802.1X fails, add the following to the switch interface configuration:
authentication event fail action next-methodConfiguring the IP Admission Watch List (Optional)
To enable the watch list, use the following command:
ip admission watch-list enableTo change the amount of time that users on the watch list are denied access to WebAuth, use the following command (where the expiry time is specified in minutes):
ip admission watch-list expiry-time 60To manually add or delete addresses from the watch list, use the following commands:
ip admission watch-list add-item 66.66.66.66no ip admission watch-list add-item 10.100.10.4To manually change the number of times that a user is allowed to attempt authentication before being added to the watch list, use the following command:
ip admission max-login-attempts 3To see active entries in the watch list, use the following command:
switch# show ip admission watch-listAuthentication Proxy Watch-list is enabledWatch-list expiry timeout is 30 minutesTotal number of watch-list entries: 2Source IP Type Violation-count66.66.66.66 CFGED N/A10.100.10.56 MAX_RETRY MAX_LIMITTotal number of black-listed users: 2Monitoring and Troubleshooting Web Authentication
This section describes how to monitor WebAuth.
Step 1
switch# show authentication sessions interface G1/13Interface: GigabitEthernet1/13MAC Address: 0014.5e95.d6ccIP Address: 10.100.60.201Status: Authz SuccessDomain: DATAOper host mode: multi-domainOper control dir: bothAuthorized By: Authentication ServerVlan Policy: N/ASession timeout: N/AIdle timeout: N/ACommon Session ID: 0A640A050000001705BD5664Acct Session ID: 0x00000019Handle: 0x20000017Runnable methods list:Method Statedot1x Failed overwebauth Authc Success
Note
Step 2
This entry indicates that the switch has detected ARP or DHCP traffic from the host. The host should be in the ACTIVE state.
switch# show IP Device Tracking allIP Device Tracking = EnabledIP Device Tracking Probe Count = 3IP Device Tracking Probe Interval = 30--------------------------------------------------------------IP Address MAC Address Interface STATE--------------------------------------------------------------10.100.60.200 0014.5e95.d6cc GigabitEthernet1/13 ACTIVEStep 3
The INIT state indicates that the switch is ready to receive credentials from the host.
switch# show ip admission cacheAuthentication Proxy CacheTotal Sessions: 1 Init Sessions: 0Client IP 10.100.60.200 Port 0, timeout 60, state INITStep 4
switch# show ip admission cacheAuthentication Proxy CacheClient IP 10.100.60.200 Port 4884, timeout 60, state ESTABUse the reporting capabilities on Cisco Secure ACS to verify the session details, as shown in Figure 20.
Figure 20 Session Details
Table 8 summarizes some common problems encountered when configuring WebAuth.
References
This section provides a list of references.
•
•
•
•
•
•
•
Sample Customizable Pages
The following section contains sample web pages that can be used to begin customization.
Login Page<HTML><HEAD><TITLE>Authentication Proxy Login Page</TITLE><script language="JavaScript"><!-- Beginvar pxypromptwindow1;var pxysubmitted = false;function doreload() {if(pxypromptwindow1.closed){window.location.reload(true);} else {reloadtimeout=setTimeout("doreload()", 300);}}function submitreload() {if(pxysubmitted == false){pxypromptwindow1=window.open('', 'pxywindow1','resizable=no,width=300,height=300,scrollbars=yes');reloadtimeout=setTimeout( "doreload()", 1000);pxysubmitted = true;return true;} else {alert("This page can not be submitted twice.");return false;}} // --></script> </HEAD><BODY BGCOLOR="#FFFFFF" LINK="#ffcc00" ALINK="#ffffff" VLINK="#ffcc00" ><H1> <BR><BR><FORM method=post action="/" target="pxywindow1"><input type=hidden name=au_pxytimetag value="612790020">Username: <input type=text name=uname><BR><BR>Password: <input type=password name=pwd><BR><BR><input type=submit name=ok value=OK onClick="return submitreload()"></H1></FORM></script></BODY></HTML>Expired Page<html><head><meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"><title>Authentication Proxy Login Failure Page</title></head><body><noscript><h1 id="noScript">Please enable Javascript</h1></noscript><h1 id="expire">Expired</h1></body></html>Login Failed Page<html><head><meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"><title>Authentication Proxy Login Failure Page</title></head><body><noscript><h1 id="noScript">Please enable Javascript</h1></noscript><h1 id="failure">Failed</h1></body></html>Login Success Page<html><head><meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"><title>Authentication Proxy Login Page</title></head><body><script type="text/javascript">var q = window.location.search;q = q.replace('?','');q = q.split('&');for(var i in q) {var aux = q[i].split('=');if (aux[0] == 'redirect_url') {var site = aux[1];break;}}if (site) {window.location.replace(unescape(site));}</script><h1>You are now logged in</h1></body></html>References
TrustSec 1.99 Documents
•
•
•
•
•
•
•
•
Related Documents
•
•
•
•
•
Feedback