802.1x
Cisco CAT Switches
When configured as a fallback mechanisms, MAB is deployed after IEEE 802.1X times out. If the endpoint's Pre-eXecution Environment (PXE) process times out, or if Dynamic Host Configuration Protocol (DHCP) gets deep into the exponential backoff process before the timeout occurs, the endpoint may not be able to communicate even though the port has been opened. To the end user, it will appear as if network access has been denied. There are three potential solutions to this problem:
- Decrease the IEEE 802.1X timeout value. See Section 2.4.1.1.1 for more information about relevant timers.
- Use a low-impact deployment scenario that allows time-critical traffic such as DHCP prior to authentication. See Section 4 for additional reading about deployment scenarios.
- If your network has many non-IEEE 802.1X-capable endpoints that need instantaneous access to the network, you can use the Flexible Authentication feature set that allows you to configure the order and priority of authentication methods. Instead of waiting for IEEE 802.1X to time out before performing MAB, you can configure the switch to perform MAB first and fallback to IEEE 802.1X only if MAB fails. See Section 4 for additional reading about Flexible Authentication.
MAB Prio / order
[[1]]
By default gaat de switch eerst naar dot1x kijken en pas na deze timeout (30 sec x3) komt MAB aan bod. Het is mogelijk om deze volgorde aan te passen.
If no fallback authentication or authorization methods are configured, the switch will stop the authentication process and the port will remain unauthorized. You can configure the switch to restart authentication after a failed MAB attempt by configuring authentication timer restart on the interface. Enabling this timer means that unknown MAC addresses will periodically fail authentication until the endpoint disconnects from the switch or the address gets added to a MAC database. To prevent the unnecessary control-plane traffic associated with restarting failed MAB sessions, Cisco generally recommends leaving authentication timer restart disabled.
Inactivity timer zorgt ervoor dat sessies worden opgeruimd wanneer een link-down scenario niet waarschijnlijk is (VoIP toestel of hub enz). Deze timer kan je static instellen op de switchport of middels radius attribute 28 vanuit ISE opgeven.
Een andere relevante timer is de reauthentication timer. Maar deze doet niets in het geval van MAB:
The reauthentication timer for MAB is the same as for IEEE 802.1X. The timer can be statically configured on the switch port, or it can be dynamically assigned by sending the Session-Timeout attribute (Attribute 27) and the RADIUS Termination-Action attribute (Attribute 29) with a value of RADIUS-Request in the Access-Accept message from the RADIUS server. For IEEE 802.1X endpoints, the reauthentication timer is sometimes used as a keepalive mechanism. This feature does not work for MAB. Upon MAB reauthentication, the switch does not relearn the MAC address of the connected endpoint or verify that the endpoint is still active; it simply sends the previously learned MAC address to the RADIUS server. Essentially, a null operation is performed.
Tenslotte is er ook nog een absolute session timer:
The absolute session timer can be used to terminate a MAB session, regardless of whether the authenticated endpoint remains connected. The session timer uses the same RADIUS Session-Timeout attribute (Attribute 27) as the server-based reauthentication timer described earlier with the RADIUS Termination-Action attribute (Attribute 29) set to Default. The switch will terminate the session after the number of seconds specified by the Session-Timeout Attribute and immediately restart authentication. If IEEE 802.1X is configured, the switch will start over with IEEE 802.1X, and network connectivity will be disrupted until IEEE 802.1X times out and MAB succeeds. This process can result in significant network outage for MAB endpoints. As an alternative to absolute session timeout, consider configuring an inactivity timeout as described in Section 2.2.6.3.
[[2]]
MAB before 802.1x
authentication order mab dot1x authentication prio mab dot1x
Make sure that all devices that perform IEEE 802.1X authentication are not in your MAC address database and that your policy never returns an access-accept event for unknown MAC addresses. IEEE 802.1X devices must fail MAB if they are to perform IEEE 802.1X authentication. As a consequence, many MAB failure records will be generated in the course of normal operation.
- Use next-method for IEEE 802.1X failure handing only if local WebAuth is configured.
- If the next method is not local WebAuth, the only option for granting access after IEEE 802.1X authentication failure is the auth-fail VLAN.
MAB before 802.1x with dot1x as prio
authentication order mab dot1x authentication prio dot1x mab
In summary, three points to remember if MAB precedes IEEE 802.1X authentication in order but IEEE 802.1X authentication has priority:
- IEEE 802.1X-capable endpoints can be in the MAC address database.
- Using next-method for IEEE 802.1X authentication failure handling without local WebAuth can lead to unpredictable behavior and intermittent network access (as described earlier, with MAB cycling to IEEE 802.1X authentication failure).
- For deterministic behavior upon IEEE 802.1X authentication failure after successful MAB, use the auth-fail VLAN or local WebAuth.
Conclusion
Changing the default order of authentication affects the behavior of the system in multiple ways. Before making this change, be sure to address the concerns described in Table 3.
Table 3. Points to Consider
Effect |Resolution | All devices will be subject to MAB |Plan for increased control-plane traffic. Authentication priority affects MAB |If MAB has priority, IEEE 802.1X-capable devices |must fail MAB. |If IEEE 802.1X authentication has priority, IEEE |802.1X-capable devices may pass or fail MAB. MAB cannot be used as a next method for |Use next-method with WebAuth or the auth-fail IEEE 802.1X authentication failures |VLAN