Access Security Guide K/KA/KB.15.15

• Using port-based 802.1X authentication when a port on the switch is configured as an
authenticator, one authenticated client opens the port. Other clients not running an 802.1X
supplicant application can have access to the switch and network through the opened port.
If another client uses an 802.1X supplicant application to access the opened port,
re-authentication occurs using the RADIUS configuration response for the latest client to
authenticate. To control access by all clients, use the user-based method.
• Where a switch port is configured with user-based authentication to accept multiple 802.1X
(and/or Web- or MAC-Authentication) client sessions, all authenticated clients must use the
same port-based, untagged VLAN membership assigned for the earliest, currently active client
session. Thus, on a port where one or more authenticated client sessions are already running,
all such clients will be on the same untagged VLAN. If a RADIUS server subsequently
authenticates a new client, but attempts to re-assign the port to a different, untagged VLAN
than the one already in use for the previously existing, authenticated client sessions, the
connection for the new client will fail. For more on this topic, see “802.1X Open VLAN mode”
(page 342).
NOTE: If the port is statically configured with any tagged VLAN memberships, any
authenticated client configured to use these tagged VLANs will have access to them.
• If a port on switch "A" is configured as an 802.1X supplicant and is connected to a port on
another switch, "B", that is not 802.1X-aware, access to switch "B" will occur without 802.1X
security protection.
• On a port configured for 802.1X with RADIUS authentication, if the RADIUS server specifies
a VLAN for the supplicant and the port is a trunk member, the port will be blocked. If the port
is later removed from the trunk, the port will allow authentication of the supplicant. Similarly,
if the supplicant is authenticated and later the port becomes a trunk member, the port will be
blocked. If the port is then removed from the trunk, it will allow the supplicant to re-authenticate.
• If a client already has access to a switch port when you configure the port for 802.1X
authenticator operation, the port will block the client from further network access until it can
be authenticated.
• Meshing is not supported on ports configured for 802.1X port-access security.
• A port can be configured as an authenticator or an 802.1X supplicant, or both. Some
configuration instances block traffic flow or allow traffic to flow without authentication. See
“Configuring Switch Ports as 802.1X Authenticators” (page 458) and “Configuring Switch Ports
To Operate As Supplicants for 802.1X Connections to Other Switches” (page 478).
• To help maintain security, 802.1X and LACP cannot both be enabled on the same port. If you
try to configure 802.1X on a port already configured for LACP (or the reverse) you will see a
message similar to the following:
Error configuring port X: LACP and 802.1X cannot be run
together.
Applying Web Authentication or MAC Authentication Concurrently with Port- Based 802.1X Authentication
While 802.1X port-based access control can operate concurrently with Web Authentication or
MAC Authentication, port-based access control is subordinate to Web-Auth and MAC-Auth
operation. If 802.1X operates in port-based mode and MAC or Web authentication is enabled
on the same port, any 802.1X authentication has no effect on the ability of a client to access the
controlled port. That is, the client's access will be denied until the client authenticates through
Web-Auth or MAC-Auth on the port. Note: A client authenticating with port-based 802.1X does
not open the port in the same way that it would if Web-Auth or MAC-Auth were not enabled. Any
non-authenticating client attempting to access the port after another client authenticates with
port-based 802.1X still has to authenticate through Web-Auth or MAC-Auth.
Overview 341