MAC Authentication Bypass Deployment Guide
Available Languages
Table Of Contents
About Cisco Validated Design (CVD) Program
MAC Authentication Bypass Deployment Guide
High Level Functional Sequence
Cisco Discovery Protocol Enhancement for Second Port Disconnect
Reauthentication and Absolute Session Timeout
RADIUS Change of Authorization
MAB Databases and RADIUS Servers
Using MAB in IEEE 802.1X Environments
Using MAB with Web Authentication
Dynamic Guest and Authentication Failure VLAN
Multidomain Authentication Host Mode
Multi-Authentication Host Mode
Cisco Catalyst Integrated Security Features
Sample Configuration for Standalone MAB
MAC Authentication Bypass Deployment GuideLast Updated: September 6, 2011
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.
MAC Authentication Bypass Deployment Guide
© 2011 Cisco Systems, Inc. All rights reserved.
MAC Authentication Bypass Deployment Guide
MAC Authentication Bypass (MAB) is a convenient, well-understood method for authenticating end users. This document describes MAB network design considerations, outlines a framework for implementation, and provides step-by-step procedures for configuration. This document includes the following sections:
•
Sample Configuration for Standalone MAB
MAB Overview
This section introduces MAB and includes the following topics:
What is MAB?
The need for secure network access has never been greater. Consultants, contractors, and even guests now require access to network resources over the same LAN connections as regular employees, who may themselves bring unmanaged devices into the workplace. As data networks become increasingly indispensable in day-to-day business operations, the possibility that unauthorized people or devices will gain access to controlled or confidential information also increases.
The best and most secure solution to vulnerability at the access edge is to use the intelligence of the network. One access control technique that Cisco provides is called MAC Authentication Bypass (MAB). MAB uses the MAC address of a device to determine the level of network access to provide. MAB offers visibility and identity-based access control at the network edge for endpoints that do not support IEEE 802.1X. With the appropriate design and well-chosen components, you can meet the needs of your security policy while reducing the impact on your infrastructure and end users.
This document focuses on deployment considerations specific to MAB.
To learn more about solution-level uses cases, design, and a phased deployment methodology, see the following URL: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6638/whitepaper_C11-530469.html.
For step-by-step configuration guidance, see the following URL: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6638/W hitepaper_c11-532065.html.
How MAB Works
MAB enables port-based access control using the MAC address of the endpoint. A MAB-enabled port can be dynamically enabled or disabled based on the MAC address of the device to which it connects. Figure 1 shows the default behavior of a MAB-enabled port.
Figure 1 Default Network Access Before and After IEEE 802.1X
Before MAB authentication, the identity of the endpoint is unknown and all traffic is blocked. The switch examines a single packet to learn and authenticate the source MAC address. After MAB succeeds, the identity of the endpoint is known and all traffic from that endpoint is allowed. The switch performs source MAC address filtering to help ensure that only the MAB-authenticated endpoint is allowed to send traffic.
MAC address authentication itself is not a new idea. An early precursor to MAB is the Cisco VLAN Management Policy Server (VMPS) architecture. With VMPS, you create a text file of MAC addresses and the VLANs to which they belong. That file is loaded into the VMPS server switch using the Trivial File Transfer Protocol (TFTP). All other switches then check with the VMPS server switch to determine to which VLAN those MAC addresses belong. MAB represents a natural evolution of VMPS. Instead of storing MAC addresses on a VMPS server switch, MAB validates addresses stored on a centralized, and thus more easily managed, repository that can be queried using the standard RADIUS protocol.
MAB Benefits and Limitations
MAB offers the following benefits on wired networks:
•
•
•
•
•
MAB enables visibility and security, but it also has the following limitations that your design must take into account or address:
•
•
•
•
MAB Sequence of Operations
This section includes the following topics:
•
High Level Functional Sequence
Figure 2 shows the way that MAB works when configured as a fallback mechanism to IEEE 802.1X. If IEEE 802.1X is not enabled, the sequence is the same except that MAB starts immediately after link up instead of waiting for IEEE 802.1X to time out.
Figure 2 High-Level MAB Sequence
Session Initiation
From the perspective of the switch, the authentication session begins when the switch detects link up on a port. The switch initiates authentication by sending an Extensible Authentication Protocol (EAP) Request-Identity message to the endpoint. If the switch does not receive a response, the switch retransmits the request at periodic intervals. If no response is received after the maximum number of retries, the switch allows IEEE 802.1X to time out and proceeds to MAB.
MAC Address Learning
During the MAC address learning stage, the switch begins MAB by opening the port to accept a single packet from which it learns the source MAC address of the endpoint. Packets sent before the port has fallen back to MAB (that is, during the IEEE 802.1X timeout phase) are discarded immediately and cannot be used to learn the MAC address.
The switch can use almost any Layer 2 and Layer 3 packets to learn MAC addresses, with the exception of bridging frames such as Cisco Discovery Protocol, Link Layer Discovery Protocol (LLDP), Spanning Tree Protocol (STP), and Dynamic Trunking Protocol (DTP).
NoteAfter the switch learns the source MAC address, it discards the packet. The switch then crafts a RADIUS Access-Request packet. A sample MAB RADIUS Access-Request packet is shown in the sniffer trace in Figure 3.
Figure 3 Sample RADIUS Access-Request Packet for MAB
By default, the Access-Request message is a Password Authentication Protocol (PAP) authentication request, The request includes the source MAC address in the following three attributes:
•
•
•
Although the MAC address is the same in each attribute, the format of the address differs. This feature is important because different RADIUS servers may use different attributes to validate the MAC address. Some RADIUS servers may look at only Attribute 31 (Calling-Station-Id), while others actually verify the username and password in Attributes 1 and 2.
Table 1 summarizes the MAC address format for each attribute.
Because MAB uses the MAC address as a username and password, make sure that the RADIUS server can differentiate MAB requests from other types of requests for network access. This precaution prevents other clients from attempting to use a MAC address as a valid credential. Cisco switches uniquely identify MAB requests by setting Attribute 6 (Service-Type) to 10 (Call-Check) in a MAB Access-Request message. Therefore, you can use Attribute 6 to filter MAB requests at the RADIUS server.
Optionally, Cisco switches can be configured to perform MAB as EAP-MD5 authentication, in which case the Service-Type attribute is set to 1 (Framed). However, because the MAC address is sent in the clear in Attribute 31 (Calling-Station-Id), MAB EAP does not offer any additional security by encrypting the MAC address in the password. In addition, because the service type for MAB EAP is the same as an IEEE 802.1X request, the RADIUS server is not able to easily differentiate MAB EAP requests from IEEE 802.1X requests.
Session Authorization
If the MAC address is valid, the RADIUS server returns a RADIUS Access-Accept message. This message indicates to the switch that the endpoint should be allowed access to the port. Optionally, the RADIUS server may include dynamic network access policy instructions, such as a dynamic VLAN or access control list (ACL) in the Access-Accept message. In the absence of dynamic policy instructions, the switch simply opens the port. No further authentication methods are tried if MAB succeeds.
If the MAC address is not valid or is not allowed to access the network for policy reasons, the RADIUS server returns a RADIUS Access-Reject message. This message indicates to the switch that the endpoint should not be allowed access to the port based on the MAC address. Depending on how the switch is configured, several outcomes are possible. If alternative authentication or authorization methods are configured, the switch may attempt IEEE 802.1X or web authentication, or deploy the guest VLAN. The interaction of MAB with these features is described in the "MAB Feature Interaction" section.
If no fallback authentication or authorization methods are configured, the switch stops the authentication process and the port remains 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 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.
Session Accounting
If the switch can successfully apply the authorization policy, the switch can send a RADIUS Accounting-Request message to the RADIUS server with details about the authorized session.
Session Termination
This section discusses the ways that a MAB session can be terminated. It includes the following topics:
•
•
•
Session Termination Overview
Session termination is an important part of the authentication process. To help ensure the integrity of the authenticated session, sessions must be cleared when the authenticated endpoint disconnects from the network. Sessions that are not terminated immediately can lead to security violations and security holes. Ideally, session termination occurs as soon as the endpoint physically unplugs, but this is not always possible if the endpoint is connected indirectly; for example, through an IP phone or hub.
Multiple termination mechanisms may be needed to address all use cases. Table 2 summarizes the mechanisms and their applications.
Link Down
The most direct way to terminate a MAB session is to unplug the endpoint. When the link state of the port goes down, the switch completely clears the session. If the original endpoint or a new endpoint plugs in, the switch restarts authentication from the beginning.
Cisco Discovery Protocol Enhancement for Second Port Disconnect
For IP telephony deployments with Cisco IP phones, the best way to help ensure that all MAB sessions are properly terminated is to use Cisco Discovery Protocol. Cisco IP phones can send a Cisco Discovery Protocol message to the switch indicating that the link state for the port of the data endpoint is down, allowing the switch to immediately clear the authenticated session of the data endpoint.
TipInactivity Timer
When the inactivity timer is enabled, the switch monitors the activity from authenticated endpoints. When the inactivity timer expires, the switch removes the authenticated session.
The inactivity timer for MAB can be statically configured on the switch port, or it can be dynamically assigned using the RADIUS Idle-Timeout attribute (Attribute 28). Cisco recommends setting the timer using the RADIUS attribute because this approach lets gives you control over which endpoints are subject to this timer and the length of the timer for each class of endpoints. For example, endpoints that are known to be quiet for long periods of time can be assigned a longer inactivity timer value than chatty endpoints.
The inactivity timer is an indirect mechanism that the switch uses to infer that a endpoint has disconnected. An expired inactivity timer cannot guarantee that a endpoint has disconnected. Therefore, a quiet endpoint that does not send traffic for long periods of time, such as a network printer that services occasional requests but is otherwise silent, may have its session cleared even though it is still connected. That endpoint must then send traffic before it can be authenticated again and have access to the network.
Reauthentication and Absolute Session Timeout
Reauthentication cannot be used to terminate MAB-authenticated endpoints. Absolute session timeout should be used only with caution.
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.
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 terminates the session after the number of seconds specified by the Session-Timeout attribute and immediately restarts authentication. If IEEE 802.1X is configured, the switch starts over with IEEE 802.1X, and network connectivity is 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 the "Inactivity Timer" section.
RADIUS Change of Authorization
RADIUS change of authorization (CoA) allows a RADIUS server to dynamically instruct the switch to alter an existing session. Cisco Catalyst switches support four actions for CoA: reauthenticate, terminate, port shutdown, and port bounce. The reauthenticate and terminate actions terminate the authenticated session in the same way as the reauthentication and session timeout actions discussed in the "Reauthentication and Absolute Session Timeout" section. The port down and port bounce actions clear the session immediately, because these actions result in link-down events.
Design Considerations
This section discusses important design considerations to evaluate before you deploy MAB. It includes the following topics:
•
MAC Address Discovery
Before deploying MAB, you must determine which MAC addresses you want to allow on your network. There are several approaches to collecting the MAC addresses that are used to populate your MAC address database.
The easiest and most economical method is to find preexisting inventories of MAC addresses. For example, in some companies the purchasing department keeps rigorous records of the MAC address of every device that has ever been approved for purchase. Another good source for MAC addresses is any existing application that uses a MAC address in some way. For example, Cisco Unified Communication Manager keeps a list of the MAC addresses of every registered IP phone on the network. Cisco VMPS users can reuse VMPS MAC address lists. After existing inventories of MAC addresses have been identified, they can be exported from the existing repository and then imported into a MAB database.
In the absence of existing MAC address inventories, you may be able to use information from the network to discover the MAC addresses that exist in your network today. One option is to enable MAB in a monitor mode deployment scenario. In monitor mode, MAB is performed on every endpoint, but the network access of the endpoint is not affected regardless of whether MAB passes or fails. In this way, you can collect MAC addresses in a non-intrusive way by parsing RADIUS authentication records. For more information about monitor mode, see the "Monitor Mode" section. Simple Network Management Protocol (SNMP) MAC address notification traps, syslogs, and network management tools such as CiscoWorks LAN Management Solution (LMS) may also contain MAC address information.
Another option is to use MAC address prefixes or wildcards instead of actual MAC addresses. When assigning MAC addresses to devices, vendors set the first three octets to a specific value called the organizationally unique identifier (OUI). OUIs are assigned by the IEEE and uniquely identify the manufacturer of a given device. If an endpoint vendor has an OUI or set of OUIs that are exclusively assigned to a particular class of device, you can create a wildcard rule in your RADIUS server policy that allows any device that presents a MAC address beginning with that OUI to be authenticated and authorized.
With the exception of a preexisting inventory, the approaches described here tell you only what MAC addresses currently exist on your network. No automated method can tell you which endpoints are valid corporate-owned assets. If this is a necessary distinction for your security policy, some sort of manual process such as an export from an existing asset inventory is required.
MAB Databases and RADIUS Servers
After you have discovered and classified the allowed MAC addresses for your network, you must store them in a database that can be accessed by the RADIUS server during the MAB attempt. Where you choose to store your MAC addresses depends on many factors, including the capabilities of your RADIUS server. This section discusses the deployment considerations for the following:
Internal Databases
An obvious place to store MAC addresses is on the RADIUS server itself. With some RADIUS servers, you simply enter the MAC addresses in the local user database, setting both the username and password to the MAC address. Other RADIUS servers, such as Cisco Secure Access Control Server (ACS) 5.0, are more MAB aware. Cisco Secure ACS 5.0 stores MAC addresses in a special host database that contains only allowed MAC addresses. For example, instead of treating the MAB request as a PAP authentication, Cisco Secure ACS 5.0 recognizes a MAB request by Attribute 6 (Service-Type) = 10 and compares the MAC address in the Calling- Station-Id attribute to the MAC addresses stored in the host database.
Before choosing to store MAC addresses on the RADIUS server, you should address the following concerns:
•
•
•
LDAP Databases
A common choice for an external MAC database is a Lightweight Directory Access Protocol (LDAP) server. LDAP is a widely used protocol for storing and retrieving information on the network. After you have collected all the MAC addresses on your network, you can import them to the LDAP directory server and configure your RADIUS server to query that server.
Because external databases are dedicated servers, they can scale to greater numbers of MAC addresses than can internal databases. They can also be managed independently of the RADIUS server.
The first consideration you should address is whether your RADIUS server can query an external LDAP database. Although LDAP is a very common protocol, not all RADIUS servers can perform LDAP queries to external databases. For example, Microsoft IAS and NPS servers cannot query external LDAP databases.
Because the LDAP database is external to the RADIUS server, you also need to give special consideration to availability. Because the LDAP database is essential to MAB, redundant systems should be deployed to help ensure that the RADIUS server can contact the LDAP server. To address the possibility that the LDAP server may become completely unavailable, the RADIUS server should be configured with an appropriate failback policy; for example, fail open or fail closed, based on your security policy.
Microsoft Active Directory
Microsoft Active Directory is a widely deployed directory service that many organizations use to store user and domain computer identities. If centralizing all identities in a single store is important to you, Active Directory can be used as a MAC database. In fact, in some cases, you may not have a choice. For Microsoft NPS and IAS, Active Directory is the only choice for MAC address storage. In any event, before deploying Active Directory as your MAC database, you should address several considerations.
Starting with Microsoft Windows Server 2003 Release 2 (R2) and Windows Server 2008, Microsoft Active Directory provides a special object class for MAC addresses called ieee802Device. By using this object class, you can streamline MAC address storage in Active Directory and avoid password complexity requirements. Unfortunately, in earlier versions of Active Directory, the ieee802Device object class is not available.
In the absence of that special object class, you can store MAC addresses as users in Microsoft Active Directory. Unfortunately, this method adds unnecessary attributes and objects to the users group and does not work in an Active Directory forest in which a password complexity policy is enabled. Remember that for MAB, username = password = MAC address, which is a situation that is intentionally disallowed by password complexity requirements in Active Directory. Another option that avoids the password complexity requirements is to load your MAC addresses as text (TXT) records in a Domain Name System (DNS) zone that is stored inside Active Directory.
If you are going to store MAC addresses in Microsoft Active Directory, make sure that your RADIUS server can access account information in Active Directory. Microsoft IAS and NPS do this natively. Some RADIUS servers, such as the Cisco Secure ACS, accomplish this by joining the Active Directory domain. Alternatively, you can create a lightweight Active Directory instance that can be referred to using LDAP.
MAB Feature Interaction
This section includes the following topics:
•
•
•
•
Using MAB in IEEE 802.1X Environments
MAB is an important part of most IEEE 802.1X deployments, and is one of the features Cisco provides to accommodate non-IEEE 802.1X endpoints. After IEEE 802.1X times out or fails, the port can move to an authorized state if MAB succeeds.
Figure 4 shows the MAB process when IEEE 802.1X times out because the endpoint cannot perform IEEE 802.1X authentication.
Figure 4 MAB as Fallback Mechanism for Non-IEEE 802.1X Endpoints
When configured as a fallback mechanisms, MAB is deployed after IEEE 802.1X times out. If the Pre- eXecution Environment (PXE) process of the endpoint 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 appears as if network access has been denied. There are three potential solutions to this problem:
•
•
•
MAB can also be used as a failover mechanism if the endpoint supports IEEE 802.1X but presents an invalid credential. Figure 5 illustrates this use of MAB in an IEEE 802.1X environment.
Figure 5 MAB as a Failover Mechanism for Failed IEEE Endpoints
Because MAB begins immediately after an IEEE 802.1X failure, there are no timing issues. However, to trigger MAB, the endpoint must send a packet after the IEEE 802.1X failure. In other words, the IEEE 802.1X supplicant on the endpoint must fail open.
For more information about IEEE 802.1X, see the "References" section.
Timers and Variables
This section describes the timers on the switch that are relevant to the MAB authentication process in an IEEE 802.1X-enabled environment.
dot1x timeout tx-period and dot1x max-reauth-req
This section discusses the timers that control the timeout and retry behavior of a MAB-enabled port in an IEEE 802.1X-enabled environment.
If IEEE 802.1X is enabled in addition to MAB, the switch sends an EAP Request-Identity frame upon link up. The switch waits for a period of time defined by dot1x timeout tx-period and then sends another Request- Identity frame. The number of times it resends the Request-Identity frame is defined by dot1x max-reauth-req.
Figure 6 shows the effect of the tx-period timer and the max-reauth-req variable on the total time to network access.
Figure 6 Tx-period, max-reauth-req, and Time to Network Access
The combination of tx-period and max-reauth-req is especially important to MAB endpoints in an IEEE 802.1X- enabled environment. MAB endpoints must wait until IEEE 802.1X times out before attempting network access through a fallback mechanism. The total time it takes for IEEE 802.1X to time out is determined by the following formula:
Timeout = (max-reauth-req +1) * tx-period
Cisco Catalyst switches have default values of tx-period = 30 seconds and max-reauth-req = 2. Applying the formula, it takes 90 seconds by default for the port to start MAB. By modifying these two settings, you can decrease the total timeout to a minimum value of 2 seconds.
Unlike with IEEE 802.1X, there is no timeout associated with the MAC address learning phase. The switch waits indefinitely for the endpoint to send a packet. Therefore, although the time needed for IEEE 802.1X to time out and fall back to MAB is determined precisely by the configured IEEE 802.1X timeout value and retry count, the time needed for the MAC address to be learned is indeterminate, because the time depends on the endpoint sending of some kind of traffic. Therefore, the total amount of time from link up to network access is also indeterminate. For chatty devices that send a lot of traffic, MAB is triggered shortly after IEEE 802.1X times out. For quiet devices or for devices that have gone quiet because, for example, the DHCP client timed out before IEEE 802.1X did, MAB may not occur for some time.
Because of the impact on MAB endpoints, most customers change the default values of tx-period and max- reauth-req to allow more rapid access to the network. When modifying these values, consider the following:
•
•
TipUsing MAB with Web Authentication
MAB is compatible with Web Authentication (WebAuth). Cisco Catalyst switches can be configured to attempt WebAuth after MAB fails. Access to the network is granted based on the success or failure of WebAuth. The sequence of events is shown in Figure 7.
Figure 7 MAB and Web Authentication After IEEE 802.1X Timeout
For more information about WebAuth, see the "References" section.
Guest VLAN
MAB is compatible with the Guest VLAN feature (see Figure 8). If IEEE 802.1X either times out or is not configured and MAB fails, the port can be moved to the Guest VLAN, a configurable VLAN for which restricted access can be enforced. Using the Guest VLAN, you can tailor network access for endpoints without valid credentials. For example, the Guest VLAN can be configured to permit access only to the Internet.
Figure 8 MAB and Guest VLAN After IEEE 802.1X Timeout
Authentication Failure VLAN
After an IEEE 802.1X authentication failure, the switch can be configured to either deploy the Authentication Failure (AuthFail) VLAN or proceed to the next authentication method, MAB or WebAuth. Figure 9 shows this process.
Figure 9 AuthFail VLAN or MAB after IEEE 802.1X Failure
In this sense, AuthFail VLAN and MAB are mutually exclusive when IEEE 802.1X fails. However, you can configure the AuthFail VLAN for IEEE 802.1X failures such as the client with a supplicant but presenting an invalid credential, as shown in Figure 9; and still retain MAB for IEEE 802.1X timeouts, such as the client with no supplicant, as shown in Figure 7 and Figure 8.
Dynamic Guest and Authentication Failure VLAN
Instead of using the locally configured Guest VLAN or AuthFail VLAN, another option is to use dynamic Guest and AuthFail VLANs, which rely on the RADIUS server to assign a VLAN when an unknown MAC address attempts to access the port after IEEE 802.1X times out or fails. In this scenario, the RADIUS server is configured to send an Access-Accept message with a dynamic VLAN assignment for unknown MAC addresses. The dynamically assigned VLAN would be one for which restricted access can be enforced. From the perspective of the switch, MAB passes even though the MAC address is unknown. The advantage of this approach over the local Guest VLAN and AuthFail VLAN is that the RADIUS server is aware of and in control of unknown endpoints. Centralized visibility and control make this approach preferable if your RADIUS server supports it.
Inaccessible RADIUS Server
When the RADIUS server is unavailable, MAB fails and, by default, all endpoints are denied access. In a highly available enterprise campus environment, it is reasonable to expect that a switch can always communicate with the RADIUS server, so the default behavior may be acceptable. However, there may be some use cases, such as a branch office with occasional WAN outages, in which the switch cannot reach the RADIUS server, but endpoints should be allowed access to the network.
If the switch already knows that the RADIUS server has failed, either through periodic probes or as the result of a previous authentication attempt, a port can be deployed in a configurable VLAN (sometimes called the critical VLAN) as soon as the link comes up. Because the switch has multiple mechanisms for learning that the RADIUS server has failed, this outcome is the most likely. If the switch determines that the RADIUS server has failed during a MAB authentication attempt, such as the first endpoint to connect to the switch after connectivity to the RADIUS server has been lost, the port is moved to the critical VLAN after the authentication times out. Previously authenticated endpoints are not affected in any way; if a reauthentication timer expires when the RADIUS server is down, the reauthentication is deferred until the switch determines that the RADIUS server has returned.
When the RADIUS server returns, the switch can be configured to reinitialize any endpoints in the critical VLAN. This behavior poses a potential problem for a MAB endpoint. When the MAB endpoint originally plugged in and the RADIUS server was unavailable, the endpoint received an IP address in the critical VLAN. Because the MAB endpoint is agentless, it has no knowledge of when the RADIUS server has returned or when it has been reinitialized. If the device is assigned a different VLAN as a result of the reinitialization, it continues to use the old IP address, which is now invalid on the new VLAN.
There are several ways to work around the reinitialization problem. You can disable reinitialization, in which case, critical authorized endpoints stay in the critical VLAN until they unplug and plug back in. You can also set the critical VLAN to the data VLAN (essentially a fail-open operation) so that the MAB endpoints maintain a valid IP address across reinitialization. If neither of these options is feasible, consider setting the DHCP lease time in the critical VLAN scope to a short time, such as five minutes, so that a MAB endpoint has an invalid address for a relatively short amount of time.
Dynamic ACL Assignment
MAB is compatible with ACLs that are dynamically assigned by the RADIUS server as the result of successful authentication.
Dynamic VLAN Assignment
MAB is compatible with VLANs that are dynamically assigned by the RADIUS server as the result of successful authentication. Be aware that MAB endpoints cannot recognize when a VLAN changes. Therefore, if a MAB endpoint initially has an IP address in VLAN A and is later assigned to VLAN B without an intervening link-down or link-up event (for example, as the result of reauthentication), the unsuspecting MAB endpoint continues to use the IP address from the old VLAN and is thus unable to get access on the new VLAN.
Wake on LAN
Wake on LAN (WoL) is an industry-standard power management feature that allows you to remotely wake up a hibernating endpoint by sending a magic packet over the network. Most WoL endpoints flap the link when going into hibernation or standby mode, thus clearing any existing MAB-authenticated sessions. By default, traffic through the unauthorized port is blocked in both directions, and the magic packet never gets to the sleeping endpoint.
To support WoL in a MAB environment, you can configure a Cisco Catalyst switch to modify the control direction of the port, allowing traffic to the endpoint while still controlling traffic from the endpoint. This approach allows the hibernating endpoint to receive the WoL packet while still preventing the unauthorized endpoint from sending any traffic to the network. After it is awakened, the endpoint can authenticate and gain full access to the network. Control direction works the same with MAB as it does with IEEE 802.1X.
Additionally, when a port is configured for open access mode, magic packets are not blocked, even on unauthorized ports, so no special configuration for WoL endpoints is necessary.
Open Access
By default, the port drops all traffic prior to successful MAB (or IEEE 802.1X) authentication. This approach is sometimes referred to as closed mode. Cisco switches can also be configured for open access, which allows all traffic while still enabling MAB.
TipOpen access has many applications, including increasing network visibility as part of a monitor mode deployment scenario. It can be combined with other features to provide incremental access control as part of a low impact mode deployment scenario. For more information about these deployment scenarios, see the "References" section.
Multiple Endpoints per Port
By default, a MAB-enabled port allows only a single endpoint per port. Any additional MAC addresses seen on the port cause a security violation.
Frequently, the limitation of a single endpoint per port does not meet all the requirements of real-world networks. Cisco Catalyst switches allow you to address multiple use cases by modifying the default behavior. The host mode on a port determines the number and type of endpoints allowed on a port. The following host modes and their applications are discussed in this section:
•
•
TipSingle-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 endpoint has authenticated with MAB, a security violation is triggered on the port. This is the default behavior.
Multidomain Authentication Host Mode
Multidomain authentication was specifically designed to address the requirements of IP telephony. When multidomain authentication is configured, two endpoints are allowed on the port: one in the voice VLAN and one in the data VLAN. Either, both, or none of the endpoints can be authenticated with MAB. Additional MAC addresses trigger a security violation.
Multi-Authentication Host Mode
If the port is configured for multi-authentication (multi-auth) host mode, multiple endpoints can be authenticated in the data VLAN. Each new MAC address that appears on the port is separately authenticated. Any, all, or none of the endpoints can be authenticated with MAB. Multi-auth host mode can be used for bridged virtual environments or to support hubs.
Multihost Mode
Unlike multi-auth host mode, which authenticates every MAC address, multihost mode authenticates the first MAC address and then allows an unlimited number of other MAC addresses. Because of the security implications of multihost mode, multi-auth host mode typically is a better choice than multihost mode.
IP Telephony
Cisco Catalyst switches are fully compatible with IP telephony and MAB. For a full description of features and a detailed configuration guide, see the following URL: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6638/config_guide_c17-605524.html.
Cisco Catalyst Integrated Security Features
This section describes the compatibility of Cisco Catalyst integrated security features with MAB.
Port Security
In general, Cisco does not recommend enabling port security when MAB is also enabled. Because MAB enforces a single MAC address per port, or per VLAN when multidomain authentication is configured for IP telephony, port security is largely redundant and may in some cases interfere with the expected operation of MAB.
DHCP Snooping
DHCP snooping is fully compatible with MAB and should be enabled as a best practice.
Dynamic Address Resolution Protocol Inspection
Dynamic Address Resolution Protocol (ARP) Inspection (DAI) is fully compatible with MAB and should be enabled as a best practice.
IP Source Guard
IP Source Guard is compatible with MAB and should be enabled as a best practice.
RADIUS Accounting
RADIUS accounting is fully compatible with MAB and should be enabled as a best practice. RADIUS accounting provides detailed information about the authenticated session and enables you to correlate MAC address, IP address, switch, port, and use statistics.
Deployment Scenarios
When deploying MAB as part of a larger access control solution, Cisco recommends a phased deployment model that gradually deploys identity-based access control to the network. The three scenarios for phased deployment are monitor mode, low impact mode, and high security mode. Each scenario identifies combinations of authentication and authorization techniques that work well together to address a particular set of use cases. The interaction of MAB with each scenario is described in the following sections:
For more information about scenario-based deployments, see the following URL: http://www.cisco.com/go/ibns.
Monitor Mode
MAB is fully supported and 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 endpoints in any way.
By enabling MAB in monitor mode, you get the highest level of visibility into devices that do not support IEEE 802.1X. In addition, by parsing authentication and accounting records for MAB in monitor mode, you can rapidly compile a list of existing MAC addresses on your network and use this list as a starting point for developing your MAC address database, as described in the "MAC Address Discovery" section.
Low Impact Mode
MAB is fully supported in low impact mode.
Low impact mode builds on the ideas of monitor mode, gradually introducing access control in a completely configurable way. Instead of denying all access before authentication, as required by a traditional IEEE 802.1X or MAB deployment, low impact mode allows you to use ACLs to selectively allow traffic before authentication. This approach is particularly useful for devices that rely on MAB to get access to the network. Waiting until IEEE 802.1X times out and falls back to MAB can have a negative effect on the boot process of these devices. Low impact mode enables you to permit time-sensitive traffic before MAB, enabling these devices to function effectively in an IEEE 802.1X-enabled environment.
High Security Mode
MAB is fully supported in high security mode.
High security mode is a more traditional deployment model for port-based access control, which denies all access before authentication. It also facilitates VLAN assignment for the data and voice domains. The primary design consideration for MAB endpoints in high security mode is the lack of immediate network access if IEEE 802.1X is also configured. MAB endpoints that are not capable of IEEE 802.1X authentication must wait for IEEE 802.1X to time out and fall back to MAB before they get access to the network. To help ensure that MAB endpoints get network access in a timely way, you need to adjust the default timeout value, as described in the 2.4.1.1. Alternatively, you can use Flexible Authentication to perform MAB before IEEE 802.1X authentication as described in the "Using MAB in IEEE 802.1X Environments" section.
Deployment Summary for MAB
Table 3 summarizes the major design decisions that need to be addressed before deploying MAB.
Sample Configuration for Standalone MAB
This section includes a sample configuration for standalone MAB. For configuration examples of MAB as a fallback to IEEE 802.1X, see the IEEE 802.1X Deployment Scenarios Configuration Guide in the "References" section.
MAB requires both global and interface configuration commands. Note that even though IEEE 802.1X is not enabled on the port, the global authentication, authorization, and accounting (AAA) configuration still uses the dot1x keyword.
aaa new-modelaaa authentication dot1x default group radius aaa authorization network default group radiusaaa accounting dot1x default start-stop group radius!interface FastEthernet2/48 switchport access vlan 40 switchport mode access authentication port-control auto mabspanning-tree portfastspanning-tree bpduguard enable!radius-server host 10.200.1.52 key cisco123References
TrustSec 1.99 Documents
•
•
•
•
•
•
•
•
Related Documents
•
•
•
•
•
•
•
•
•
•
•
•
•
Feedback