Overview
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.
About web and MAC authentication
Web-based authentication
The web-based authentication method uses a web page 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.
MAC authentication
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.
| NOTE: 802.1X port-access, web-based authentication, and MAC authentication can be configured at the same time on the same port. The client limit is 256 clients per port for MAC-auth and Web-auth; the client limit for 802.1X is 32 clients per port. The MAC-auth and Web-auth limit of 256 clients only applies when there are fewer than 16,384 authentication clients on the entire switch. After the limit of 16,384 clients is reached, no additional authentication clients are allowed on any port for any method. The default is one client. Web-based and/or MAC authentication and MAC lockdown, MAC lockout, and port-security are mutually exclusive on a given port. If you configure any of these authentication methods on a port, you must disable LACP on the port. |
Concurrent web-based and MAC authentication
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.
Authorized and unauthorized client VLANs
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.
RADIUS-based authentication
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:
A RADIUS-assigned VLAN.
An authorized VLAN specified in the web-based or MAC authentication configuration for the subject port.
A static, port-based, untagged VLAN to which the port is configured. A RADIUS-assigned VLAN has priority over switch-port membership in any VLAN.
Wireless clients
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.
How web-based and MAC authentication operate
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.
Web-based authentication
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 web pages to use for web-based authentication login and present them to clients who try to connect to the network, see Customizing user login web pages.
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.
Order of priority for assigning VLANs
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
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.
MAC authentication
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.
Operating notes and guidelines
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):
MAC lockout
MAC lockdown or Port Security
Port-based Access Control (802.1X) or web-based authentication or MAC authentication
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 web pages you prepare for client login. The use of customized web pages is enabled after you configure the valid IP address or host name of an EWA server.
Customizing HTML templates
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 web pages (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.
Customizable HTML templates
The sample HTML files described 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.
Filename: index.html
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.
Filename: accept.html
The accept.html file is the
web page used to confirm a valid client login. This web page 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 web page requested by the client.
Filename: authen.html
The authen.html file is the
web page used to process a client login and is refreshed while user
credentials are checked and verified.
Invalid credentials page
The reject_unauthvlan.html file
is the web page 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.
Filename: timeout.html
The timeout.html file is the
web page 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.
Filename: retry_login.html
The retry_login.html file
is the web page 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.
Filename: sslredirect.html
The sslredirect file is the
web page 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.
Filename: reject_novlan.html
The reject_novlan file is
the web page 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.
Configuring a DNS Server for Enhanced web authentication
If you use a host name to configure access to a web server on which customized login web pages 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.
Operating notes and guidelines for implementing customized web-Auth pages
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 web pages 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 web pages 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.
Customizable HTML templates
To help you create your own set of HTML files, use the templates found on the download page for 'K' software.
User Login page (index.html)
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.
Access Granted page (accept.html)
The accept.html file is the
web page used to confirm a valid client login. This web page 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 web page requested by the client.
Authenticating page (authen.html)
The authen.html file is the
web page used to process a client login and is refreshed while user
credentials are checked and verified.
Invalid Credentials page (reject_unauthvlan.html)
The reject_unauthvlan.html file
is the web page 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.
Timeout page (timeout.html)
The timeout.html file is the
web page 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.
Retry Login page (retry_login.html)
The retry_login.html file
is the web page 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.
SSL Redirect page (sslredirect.html)
The sslredirect file is the
web page 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.
Access Denied page (reject_novlan.html)
The reject_novlan file is
the web page 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.
Client status
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. |