Web-based and MAC authentication are designed for employment on the "edge" of a network to provide port-based security measures for protecting private networks and a switch from unauthorized access. Because neither method requires clients to run special supplicant software (unlike 802.1X authentication), both web and MAC authentication are suitable for legacy systems and temporary access situations where introducing supplicant software is not an attractive option. Only a web browser (for web-based authentication) or a MAC address (for MAC authentication) is required.
Both web and MAC authentication methods rely on a RADIUS server to authenticate network access. This simplifies access security management by allowing the control of access from a master database in a single server. Up to three RADIUS servers can be used for backup in case access to the primary server fails. It also means the same credentials can be used for authentication, regardless of which switch or switch port is the current access point into the LAN.
On a port configured for web-based or MAC authentication, the switch operates as a port-access authenticator using a RADIUS server and the CHAP protocol. Inbound traffic is processed by the switch alone, until authentication occurs. Some traffic from the switch to an unauthorized client is supported (for example, broadcast or unknown destination packets) before authentication occurs.
The web-based authentication method uses a webpage login to authenticate users for access to the network. When a client connects to the switch and opens a web browser, the switch automatically presents a login page.
|
|
|
![[NOTE: ]](images/note.gif) |
NOTE: A proxy server is not supported for use by a browser on a client device that accesses the network through a port configured for web-based authentication. |
|
|
In the login page, a client enters a user name and password, which the switch forwards to a RADIUS server for authentication. After authenticating a client, the switch grants access to the secured network. Besides a web browser, the client needs no special supplicant software.
The MAC authentication method grants access to a secure network by authenticating devices for access to the network. When a device connects to the switch, either by direct link or through the network, the switch forwards the device's MAC address to the RADIUS server for authentication. The RADIUS server uses the device MAC address as the user name and password, and grants or denies network access in the same way that it does for clients capable of interactive logons. The process does not use either a client device configuration or a logon session. MAC authentication is well-suited for clients not capable of providing interactive logons, such as telephones, printers, and wireless access points. Also, because most RADIUS servers allow for authentication to depend on the source switch and port through which the client connects to the network, you can use MAC authentication to "lock" a particular device to a specific switch and port.
Web-based authentication and MAC authentication can be configured at the same time on a port. It is assumed that MAC authentication uses an existing MAC address. The following conditions apply for concurrent authentication:
-
A specific MAC address cannot be authenticated by both web and MAC authentication at the same time.
-
Each new web-based/MAC authentication client always initiates a MAC authentication attempt. This same client can also initiate web-based authentication at any time before the MAC authentication succeeds. If either authentication succeeds then the other authentication (if in progress) is ended. No further web-based/MAC authentication attempts are allowed until the client is de-authenticated.
-
Web-based and MAC authentications are not allowed on the same port if an unauthenticated (guest) VLAN is enabled for MAC authentication. An unauthenticated VLAN cannot be enabled for MAC authentication if web-based and MAC authentication are both enabled on the port.
-
Hitless reauthentication must be of the same type (MAC) that was used for the initial authentication. Non-hitless reauthentication can be of any type.
The remaining web-based/MAC functionality, including interactions with 802.1X, remains the same. web and MAC authentication can be used for different clients on the same port.
Normally, MAC authentication finishes much sooner than web authentication. However, if web authentication completes first, MAC authentication ceases, even though MAC authentication could succeed. There is no guarantee that MAC authentication ends before web-based authentication begins for the client.
Concurrent web-based and MAC authentication is backward compatible with all existing user configurations.
Web-based and MAC Authentication provide a port-based solution in which a port belongs to one untagged VLAN at a time. The switch supports up to 32 simultaneous client sessions per port. All authenticated client sessions operate in the same untagged VLAN. To simultaneously support multiple client sessions in different VLANs for a network application, design the system so clients request network access on different switch ports.
In the default configuration, the switch blocks access to all clients that the RADIUS server does not authenticate. However, you can configure an individual port to provide limited network services and access to unauthorized clients by using an "unauthorized" VLAN for each session. The unauthorized VLAN ID assignment can be the same for all ports, or different, depending on the services and access you plan to allow for unauthenticated clients.
You configure access to an optional, unauthorized VLAN when you configure web-based and MAC authentication on a port.
In web-based and MAC authentication, you use a RADIUS server to temporarily assign a port to a static VLAN to support an authenticated client. When a RADIUS server authenticates a client, the switch-port membership during the client's connection is determined according to the following hierarchy:
You can allow wireless clients to move between switch ports under web-based/MAC authentication control. Clients can move from one web-authorized port to another or from one MAC-authorized port to another. This capability allows wireless clients to move from one access point to another without having to reauthenticate.
Before gaining access to the network, a client first presents authentication credentials to the switch. The switch then verifies the credentials with a RADIUS authentication server. Successfully authenticated clients receive access to the network, as defined by the System Administrator. Clients who fail to authenticate successfully receive no network access or limited network access as defined by the System Administrator.
When a client connects to a web-based authentication enabled port, communication is redirected to the switch. A temporary IP address is assigned by the switch and a login screen is presented for the client to enter their user name and password.
The default User Login screen is shown in Default User Login screen. You can also prepare customized webpages to use for web-based authentication login and present them to clients who try to connect to the network, see Customizing user login webpages.
When a client connects to the switch, it sends a DHCP request to receive an IP address to connect to the network. To avoid address conflicts in a secure network, you can specify a temporary IP address pool to be used by DHCP by configuring the dhcp-addr and dhcp-lease options when you enable web-based authentication with the aaa port-access web-based command.
The Secure Socket Layer (SSLv3/TLSv1) feature provides remote web-based access to the network via authenticated transactions and encrypted paths between the switch and management station clients capable of SSL/TLS. If you have enabled SSL on the switch, you can specify the ssl-login option when you configure web-based authentication so that clients who log in to specified ports are redirected to a secure login page (https://...) to enter their credentials.
The switch passes the supplied user name and password to the RADIUS server for authentication and displays the following progress message:
If the client is authenticated and the maximum number of clients allowed on the port (client-limit) has not been reached, the port is assigned to a static, untagged VLAN for network access. After a successful login, a client can be redirected to a URL if you specify a URL value (redirect-url) when you configure web-based authentication.
The assigned VLAN is determined, in order of priority, as follows:
-
If there is a RADIUS-assigned VLAN, then, for the duration of the client session, the port belongs to this VLAN and temporarily drops all other VLAN memberships.
-
If there is no RADIUS-assigned VLAN, then, for the duration of the client session, the port belongs to the authorized VLAN (
auth-vidif configured) and temporarily drops all other VLAN memberships. -
If neither 1 or 2, above, apply, but the port is an untagged member of a statically configured, port-based VLAN, then the port remains in this VLAN.
-
If neither 1, 2, or 3, above, apply, then the client session does not have access to any statically configured, untagged VLANs and client access is blocked.
The assigned port VLAN remains in place until the session ends. Clients can be forced to reauthenticate after a fixed period of time (reauth-period) or at any time during a session (reauthenticate). An implicit logoff period can be set if there is no activity from the client after a given amount of time (logoff-period). In addition, a session ends if the link on the port is lost, requiring reauthentication of all clients. Also, if a client moves from one port to another and client moves have not been enabled (-client-moves) on the ports, the session ends and the client must reauthenticate for network access. At the end of the session the port returns to its pre-authentication state. Any changes to the port's VLAN memberships made while it is an authorized port take affect at the end of the session.
A client can not be authenticated due to invalid credentials or a RADIUS server timeout. The max-retries parameter specifies how many times a client can enter their credentials before authentication fails. The server-timeoutparameter sets how long the switch waits to receive a response from the RADIUS server before timing out. The max-requests parameter specifies how many authentication attempts can result in a RADIUS server timeout before authentication fails. The switch waits a specified amount of time (quiet-period) before processing any new authentication requests from the client.
Network administrators can assign unauthenticated clients to a specific static, untagged VLAN (unauth-vid), to provide access to specific (guest) network resources. If no VLAN is assigned to unauthenticated clients the port is blocked and no network access is available. Should another client successfully authenticate through that port any unauthenticated clients on the unauth-vid are dropped from the port.
Clientless Endpoint Integrity (CEI) allows a switch to validate the security software that a client is running before allowing the client to connect to the network. By using the CEI feature on a switch deployed at the edge of the network, there is no need to require a client to install special software to perform the endpoint integrity check. CEI verifies that a client is running the necessary security patches, service packs, virus definitions, and the last scan date.
CEI is embedded in the login process for web-based authentication to verify a client's integrity. After you configure CEI, a client simply connects to the network and goes through the login process. During the login process, the software installed on the client is automatically checked by a CEI server on your network. If the endpoint integrity check fails and CEI reports that a client needs to install a more current patch or a new virus definition file, the client is redirected to a quarantine network to install the required updates.
CEI enhances your ability to secure your network from unknown or known clients who try to connect without requiring clients to install special security software.
To enable CEI, configure the IP address of the CEI server (using the cei-server parameter) when you enable web-based authentication. To set up the CEI server and quarantine network, follow the instructions in the “Diagnostic Tools” section in the “Troubleshooting” chapter of management and configuration guide for your switch.
When a client connects to a MAC authentication enabled port traffic is blocked. The switch immediately submits the client's MAC address (in the format specified by the addr-format) as its certification credentials to the RADIUS server for authentication.
If the client is authenticated and the maximum number of MAC addresses allowed on the port (addr-limit) has not been reached, the port is assigned to a static, untagged VLAN for network access.
-
The switch supports concurrent 802.1X , web and MAC authentication operation on a port (with up to 32 clients allowed). However, concurrent operation of web and MAC authentication with other types of authentication on the same port is not supported. That is, the following authentication types are mutually exclusive on a given port:
-
Web-based and/or MAC authentication (with or without 802.1X)
-
MAC lockdown
-
MAC lockout
-
Port-Security
-
-
Order of Precedence for Port Access Management (highest to lowest):
NOTE: When configuring a port for web-based or MAC authentication, be sure that a higher precedent port access management feature is not enabled on the port. For example, be sure that Port Security is disabled on a port before configuring the port for web-based or MAC authentication. If Port Security is enabled on the port this misconfiguration does not allow web-based or MAC authentication to occur.
-
VLANs: If your LAN does not use multiple VLANs, then you do not need to configure VLAN assignments in your RADIUS server or consider using either authorized or unauthorized VLANs. If your LAN does use multiple VLANs, then some of the following factors can apply to your use of web-based authentication and MAC authentication.
-
web-based authentication and MAC authentication operate only with port-based VLANs. Operation with protocol VLANs is not supported, and clients do not have access to protocol VLANs during web-based authentication and MAC authentication sessions.
-
A port can belong to one, untagged VLAN during any client session. Where multiple authenticated clients can simultaneously use the same port, they must all be capable of operating on the same VLAN.
-
During an authenticated client session, the following hierarchy determines a port's VLAN membership:
-
If there is a RADIUS-assigned VLAN, then, for the duration of the client session, the port belongs to this VLAN and temporarily drops all other VLAN memberships.
-
If there is no RADIUS-assigned VLAN, then, for the duration of the client session, the port belongs to the authorized VLAN (if configured) and temporarily drops all other VLAN memberships.
-
If neither 1 or 2, above, apply, but the port is an untagged member of a statically configured, port-based VLAN, then the port remains in this VLAN.
-
If neither 1, 2, or 3, above, apply, then the client session does not have access to any statically configured, untagged VLANs and client access is blocked.
-
-
After an authorized client session begins on a given port, the port's VLAN membership does not change. If other clients on the same port become authenticated with a different VLAN assignment than the first client, the port blocks access to these other clients until the first client session ends.
-
The optional "authorized" VLAN (
auth-vid) and "unauthorized" VLAN (unauth-vid) you can configure for web-based or MAC authentication must be statically configured VLANs on the switch. Also, if you configure one or both of these options, any services you want clients in either category to access must be available on those VLANs.
-
-
Where a given port's configuration includes an unauthorized client VLAN assignment, the port allows an unauthenticated client session only while there are no requests for an authenticated client session on that port. In this case, if there is a successful request for authentication from an authorized client, the switch terminates the unauthorized-client session and begins the authorized-client session.
-
When a port on the switch is configured for web-based or MAC authentication and is supporting a current session with another device, rebooting the switch invokes a re-authentication of the connection.
-
When a port on the switch is configured as a web-based or MAC authenticator, it blocks access to a client that does not provide the proper authentication credentials. If the port configuration includes an optional, unauthorized VLAN (
unauth-vid), the port is temporarily placed in the unauthorized VLAN if there are no other authorized clients currently using the port with a different VLAN assignment. If an authorized client is using the port with a different VLAN or if there is no unauthorized VLAN configured, the unauthorized client does not receive access to the network. -
web-based or MAC authentication and LACP cannot both be enabled on the same port.
Web-based/MAC authentication and LACP are not supported at the same time on a port. The switch automatically disables LACP on ports configured for web or MAC authentication.
-
Use the
show port-access web-basedcommands to display session status, port-access configuration settings, and statistics for web-based authentication sessions. -
When spanning tree is enabled on a switch that uses 802.1X, web-based authentication, or MAC authentication, loops can go undetected. For example, spanning tree packets that are looped back to an edge port are not processed because they have a different broadcast/multicast MAC address from the client-authenticated MAC address. To ensure that client-authenticated edge ports get blocked when loops occur, you should enable loop protection on those ports. See "Multiple Instance Spanning-Tree Operation" in the advanced traffic management guide for your switch.
-
Because enhanced web-based authentication is configured per switch, each web-based authentication enabled port displays the customized webpages you prepare for client login. The use of customized webpages is enabled after you configure the valid IP address or host name of an EWA server.
When you customize an HTML template, follow these guidelines:
-
Do not change the name of each HTML file (
index.html,accept.html, and so on). -
Some template pages use Embedded Switch Includes (ESIs) or Active Server Pages. These should not be modified when customizing HTML files. ESIs behave as follows:
-
A client’s web browser sends a request for an HTML file. The switch passes the request to a configured web server.
-
The web server responds by sending a customized HTML page to the switch. Each ESI call in the HTML page is replaced with the value (in plain text) retrieved by the call.
-
The switch sends the final version of the HTML page to the client’s web browser.
-
-
Store all customized login webpages (including any graphics) that you create for client login on each web server at the path you configure with the
aaa port-access web-based ewa-servercommand.
The sample HTML files discribed in the following sections are customizable templates. To help you create your own set HTML files, a set of the templates can be found on the download page for “K” software.
The index.html file is the first login page displayed, in which a client requesting access to the network enters a user name and password. In the index.html template file, you can customize any part of the source code except for the form that processes the user name and password entered by a client.
The accept.html file is the webpage used to confirm a valid client login. This webpage appears after you enter a valid user name and password.
The client device is then granted access to the network. To configure the VLAN used by authorized clients, specify a VLAN ID with the aaa port-access web-based auth-vid command parameter when you enable web-based authentication.
The accept.html file contains the following ESIs which should not be modified:
-
The getwauthredirecttime ESI inserts the value for the waiting time used by the switch to redirect an authenticated client while the client renews its IP address and gains access to the network.
-
The getwauthredirecturl ESI inserts the URL configured with the
redirect-urlparameter to redirect a client login or the first webpage requested by the client.
The authen.html file is the webpage used to process a client login and is refreshed while user credentials are checked and verified.
The reject_unauthvlan.html file is the webpage used to display login failures in which an unauthenticated client is assigned to the VLAN configured for unauthorized client sessions. You can configure the VLAN used by unauthorized clients with the aaa port-access web-based ewa-server command when you enable web-based authentication.
The getwauthredirecttime ESI inserts the value for the waiting time used by the switch to redirect an unauthenticated client while the client renews its IP address and gains access to the VLAN for unauthorized clients. This ESI should not be modified.
The timeout.html file is the webpage used to return an error message if the RADIUS server is not reachable. You can configure the time period (in seconds) that the switch waits for a response from the RADIUS server used to verify client credentials with the aaa port-access web-based ewa-server-timeout command when you enable web-based authentication.
The retry_login.html file is the webpage displayed to a client that has entered an invalid user name and/or password, and is given another opportunity to log in.
The getwauthretriesleft ESI displays the number of login retries that remain for a client that entered invalid login credentials. You can configure the number of times that a client can enter their user name and password before authentication fails with the aaa port-access web-based max-retries command when you enable web-based authentication. This ESI should not be modified.
The sslredirect file is the webpage displayed when a client is redirected to an SSL server to enter credentials for web-based authentication. If you have enabled SSL on the switch, you can enable secure SSL-based web-based authentication by entering the aaa port-access web-based ssl-login command when you enable web-based authentication.
The getwauthsslsrv ESI inserts the URL that redirects a client to an SSL-enabled port on an EWA server to verify the client's user name and password. This ESI should not be modified.
The reject_novlan file is the webpage displayed after a client login fails and no VLAN is configured for unauthorized clients.
The getwauthquiettime ESI inserts the time period used to block an unauthorized client from attempting another login. To specify the time period before a new authentication request can be received by the switch, configure a value for the aaa port-access web-based quiet-period command when you enable web-based authentication. This ESI should not be modified.
If you use a host name to configure access to a web server on which customized login webpages are stored, you must first configure a Domain Name System (DNS) server to resolve the web server's host name into a target IP address. (If you specify an IP address to configure a web server, it is not necessary to configure a DNS server.)
For example, the following web server host name requires the configuration of a DNS server to resolve the host (webserver1) and domain name (accounts.hp.com) into a target IP address.
To configure switch access to a DNS server to support the use of a host name in the aaa port-access web-based ewa server command, see the “Troubleshooting” chapter in the management and configuration guide for your switch.
-
Customized web authentication pages are configured per switch, so that each web-Auth enabled port displays the same customized pages at client login.
-
The customized webpages you create can be hosted on up to three web servers in your network. Implementing multiple web servers provides redundancy in case access to any of the other servers fail.
-
To configure a web server on your network, follow the instructions in the documentation provided with the server.
-
Before you enable custom web authentication pages, you should:
-
Determine the IP address or host name of the web servers that host your custom pages.
-
Determine the path on the servers where the HTML files (including all graphics) used for the login pages are stored.
-
Configure and start the web servers.
-
Create the customized webpages as described in Customizing HTML templates, and store them in the document path on the designated servers.
-
Test that they are accessible at the designated URLs.
-
To help you create your own set of HTML files, use the templates found on the download page for 'K' software.
The index.html file is the first login page displayed, in which a client requesting access to the network enters a user name and password. In the index.html template file, you can customize any part of the source code except for the form that processes the user name and password entered by a client.
The accept.html file is the webpage used to confirm a valid client login. This webpage is displayed after a valid user name and password are entered and accepted.
The client device is then granted access to the network. To configure the VLAN used by authorized clients, specify a VLAN ID with the aaa port-access web-based auth-vid command parameter when you enable web authentication.
The accept.html file contains the following ESIs, which should not be modified:
-
The GETWAUTHREDIRECTTIME ESI inserts the value for the waiting time used by the switch to redirect an authenticated client while the client renews its IP address and gains access to the network.
-
The GETWAUTHREDIRECTURL ESI inserts the URL configured with the
redirect-urlparameter to redirect a client login or the first webpage requested by the client.
The authen.html file is the webpage used to process a client login and is refreshed while user credentials are checked and verified.
The reject_unauthvlan.html file is the webpage used to display login failures in which an unauthenticated client is assigned to the VLAN configured for unauthorized client sessions. You can configure the VLAN used by unauthorized clients with the aaa port-access web-based unauth-vid command when you enable web authentication.
The GETWAUTHREDIRECTTIME ESI inserts the value for the waiting time used by the switch to redirect an unauthenticated client while the client renews its IP address and gains access to the VLAN for unauthorized clients. This ESI should not be modified.
The timeout.html file is the webpage used to return an error message if the RADIUS server is not reachable. You can configure the time period (in seconds) that the switch waits for a response from the RADIUS server used to verify client credentials with the aaa port-access web-based server-timeout command when you enable web authentication.
The retry_login.html file is the webpage displayed to a client that has entered an invalid user name and/or password, and is given another opportunity to log in.
The GETWAUTHRETRIESLEFT ESI displays the number of login retries that remain for a client that entered invalid login credentials. You can configure the number of times that a client can enter their user name and password before authentication fails with the aaa port-access web-based max-retries commands when you enable web authentication.This ESI should not be modified.
The sslredirect file is the webpage displayed when a client is redirected to an SSL server to enter credentials for web authentication. If you have enabled SSL on the switch, you can enable secure SSL-based web authentication by entering the aaa port-access web-based ssl-login command when you enable web authentication .
The GETWAUTHSSLSRV ESI inserts the URL that redirects a client to an SSL-enabled port on a server to verify the client's user name and password. This ESI should not be modified.
The reject_novlan file is the webpage displayed after a client login fails and no VLAN is configured for unauthorized clients.
The GETWAUTHQUIETTIME ESI inserts the time period used to block an unauthorized client from attempting another login. To specify the time period before a new authentication request can be received by the switch, configure a value for the aaa port-access web-based quiet-period command when you enable web authentication. This ESI should not be modified.
The table below shows the possible client status information that can be reported by a web-based or MAC 'show... clients'command.
| Reported Status | Available Network Connection | Possible Explanations |
|---|---|---|
| authenticated | Authorized VLAN | Client authenticated. Remains connected until logoff-period or reauth-period expires. |
| authenticating | Switch only | Pending RADIUS request. |
| rejected-no vlan | No network access |
|
| rejected-unauth vlan | Unauthorized VLAN only |
|
| timed out-no vlan | No network access | RADIUS request timed out. If unauth-vid is specified it cannot be successfully applied to the port. An authorized client on the port has precedence. Credentials resubmitted after quiet-period expires. |
| timed out-unauth vlan | Unauthorized VLAN only | RADIUS request timed out. After the quiet-period expires credentials are resubmitted when client generates traffic. |
| unauthenticated | Switch only | Waiting for user credentials. |