- 802.1x Vs Mab
- What Is Mab Authentication
- Mab Authentication Troubleshooting
- Mab Authentication Configuration
- Cisco Mab
Open System Preferences, Users & Groups, Login Options, Join, Open Directory Utilities, Active Directory, Click on the edit pencil in the botton left of window, Click Show advanced. You should now see the option to create a mobile account. You will need to be on your active directory network to create the account. Configuring the global MAC authentication password MAC authentication requires that only a single entry containing the username and password is placed in the user database with the device's MAC address. This creates an opportunity for malicious device spoofing.
Overview
MAC Authentication Bypass or MAB, does exactly what the name implies. This is a method of fallback for bypassing 802.1x access control, using the MAC address of an endpoint. The main thing to note about MAB, is that there is no standard for implementing this. How 802.1x authentication works A common network access, three-component architecture features a supplicant, access device (switch, access point) and authentication server (RADIUS). We use Cisco ISE for authentication off all our devices in the network. We also uses VOIP phones with MAB authentication. After authentication the phone must be switched to the voice-vlan-40 (also using LLDP/CDP) I need the special AP-pairs from Cisco ISE to set this VLAN. Does anyone can help m.
This article includes general troubleshooting for 802.1X wireless and wired clients. While troubleshooting 802.1X and wireless, it's important to know how the flow of authentication works, and then figure out where it's breaking. It involves a lot of third-party devices and software. Most of the time, we have to identify where the problem is, and another vendor has to fix it. We don't make access points or switches, so it's not an end-to-end Microsoft solution.
Scenarios
This troubleshooting technique applies to any scenario in which wireless or wired connections with 802.1X authentication is attempted and then fails to establish. The workflow covers Windows 7 through Windows 10 for clients, and Windows Server 2008 R2 through Windows Server 2012 R2 for NPS.
Known issues
None
Data collection
See Advanced troubleshooting 802.1X authentication data collection.
Troubleshooting
Viewing NPS authentication status events in the Windows Security event log is one of the most useful troubleshooting methods to obtain information about failed authentications.
NPS event log entries contain information about the connection attempt, including the name of the connection request policy that matched the connection attempt and the network policy that accepted or rejected the connection attempt. If you don't see both success and failure events, see the NPS audit policy section later in this article.
Check Windows Security Event log on the NPS Server for NPS events that correspond to rejected (event ID 6273) or accepted (event ID 6272) connection attempts.
Pokemon emerald codebreaker codes no gba gameshark. In the event message, scroll to the very bottom, and then check the Reason Code field and the text that's associated with it.
Example: event ID 6273 (Audit Failure)
Example: event ID 6272 (Audit Success)
The WLAN AutoConfig operational log lists information and error events based on conditions detected by or reported to the WLAN AutoConfig service. The operational log contains information about the wireless network adapter, the properties of the wireless connection profile, the specified network authentication, and, in the event of connectivity problems, the reason for the failure. For wired network access, the Wired AutoConfig operational log is an equivalent one.
On the client side, go to Event Viewer (Local)Applications and Services LogsMicrosoftWindowsWLAN-AutoConfig/Operational for wireless issues. For wired network access issues, go to .Wired-AutoConfig/Operational. See the following example:
Most 802.1X authentication issues are because of problems with the certificate that's used for client or server authentication. Examples include invalid certificate, expiration, chain verification failure, and revocation check failure.
First, validate the type of EAP method that's used:
If a certificate is used for its authentication method, check whether the certificate is valid. For the server (NPS) side, you can confirm what certificate is being used from the EAP property menu. In NPS snap-in, go to Policies > Network Policies. Select and hold (or right-click) the policy, and then select Properties. In the pop-up window, go to the Constraints tab, and then select the Authentication Methods section.
The CAPI2 event log is useful for troubleshooting certificate-related issues.By default, this log isn't enabled. To enable this log, expand Event Viewer (Local)Applications and Services LogsMicrosoftWindowsCAPI2, select and hold (or right-click) Operational, and then select Enable Log.
For information about how to analyze CAPI2 event logs, seeTroubleshooting PKI Problems on Windows Vista.
When troubleshooting complex 802.1X authentication issues, it's important to understand the 802.1X authentication process. Here's an example of wireless connection process with 802.1X authentication:
If you collect a network packet capture on both the client and the server (NPS) side, you can see a flow like the one below. Type EAPOL in the Display Filter for a client-side capture, and EAP for an NPS-side capture. See the following examples:
Client-side packet capture data
NPS-side packet capture data
Note
802.1x Vs Mab
If you have a wireless trace, you can also view ETL files with network monitor and apply the ONEX_MicrosoftWindowsOneX and WLAN_MicrosoftWindowsWLANAutoConfig Network Monitor filters. If you need to load the required parser, see the instructions under the Help menu in Network Monitor. Here's an example:
Audit policy
By default, NPS audit policy (event logging) for connection success and failure is enabled. If you find that one or both types of logging are disabled, use the following steps to troubleshoot.
What Is Mab Authentication
View the current audit policy settings by running the following command on the NPS server:
If both success and failure events are enabled, the output should be:
If it says, 'No auditing,' you can run this command to enable it:
Even if audit policy appears to be fully enabled, it sometimes helps to disable and then re-enable this setting. You can also enable Network Policy Server logon/logoff auditing by using Group Policy. To get to the success/failure setting, select Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff > Audit Network Policy Server.
Additional references
Troubleshooting Windows Vista 802.11 Wireless Connections
Troubleshooting Windows Vista Secure 802.3 Wired Connections
With a number of different terms floating around it is easy to get confused by them all. This post will explore some of the differences, dig into some of the details and review how different components are combined to make a coherent solution. Hopefully by the end of this post you will understand 802.1x and MAB in a bit more detail.
This post follows on from one of my previous ones – The Importance of Network Access Control. If you haven’t already I’d recommend reviewing that first.
Is 802.1X the same as NAC?
No. You may hear the two terms used interchangeably but they are not the same. Let’s review what they are at a high-level.
- 802.1x – 802.1x is a standards-based framework that defines a model to provide network-based authentication. On its own it is nothing really more than a method of providing authentication (proof of identity)
- NAC – NAC tends to refer to an overall solution and encompasses more than just authentication alone. NAC solutions often (but not always) utilise 802.1x in order to authenticate users or devices, but typically provide a lot more services on top of this
What about MAB?
MAB stands for MAC Address Bypass and is another way a network device, such as a switch, can “authenticate” (though it’s not really authentication) a device to a NAC solution. Not all devices can support 802.1x and where this is the case, MAB is often used as a fallback method. Think of it as simply being a method of letting the NAC solution know about a connecting device without the use of 802.1x authentication.
So all NAC solutions use 802.1x and MAB?
Not quite! There are NAC solutions on the market that don’t utilise 802.1x or MAB and typically achieve similar results using a combination of endpoint agents, SNMP and NETCONF configuration. I have no experience of these products personally so will not be focussing on them in this article. If you have used, or currently use such a solution I’d be keen to hear more on how you find it so get in touch!
A closer look at 802.1x
As I touched on before, 802.1x isn’t really a protocol in its own right, but an authentication framework. As part of the 802.1x framework there are a number of different roles and protocols in use – the main ones you’ll come across are:
Roles
Mab Authentication Troubleshooting
- Supplicant – The supplicant is the 802.1x software that runs on the endpoint. This software is responsible for handling communication with the authenticator and sending authentication credentials to the authentication server. Lots of devices support 802.1x nowadays including PCs, laptops, phones, printers and video conference units. Supplicant software more often than not comes built into the operating system, but additional third-party software is also available (and sometimes required for certain features)
- Authenticator – The authenticator is the network device that is acting as a “gatekeeper” to the network – typically a switch or Wireless LAN Controller (WLC). It prevents access to the network (if configured to do so) until the authentication server tells it otherwise. The authenticator is responsible for taking the messages from the supplicant, encapsulating them in RADIUS and sending them to the authentication server for processing
- Authentication Server – The brains of the operation! The authentication server is the component that ultimately decides if clients can access the network or not, as well as any restrictions that must be applied to the session
Protocols
- EAP – Stands for Extensible Authentication Protocol and it provides a number of different “methods” for authentication. I review some of these a bit further on in this post. The actual EAP conversation ultimately takes place between the supplicant and the authentication server, with the authenticator just acting as a middle man and tunnelling the messages in RADIUS. This allows the two parties to communicate before the supplicant has an IP address
- EAPOL – Stands for EAP Over LAN. It is a network layer protocol that encapsulates EAP messages between the supplicant and the authenticator. Don’t get too hung up on the details of this – it is just how the messages are encapsulated between the supplicant and the authenticator
- RADIUS – Stands for Remote Authentication Dial-In User Service. It is a standards-based network protocol that can provide authentication, authorisation and accounting. RADIUS is used by the authenticator to tunnel EAP messages from the supplicant to the authentication server. When the authentication server has made an access decision it communicates this to the authenticator by way of RADIUS Access-Accept or Access-Reject messages. RADIUS also provides extensible Attribute Value Pairs (AVPs) which allows the authentication server to dictate certain dynamic actions such as “put the device in VLAN x” or “apply a downloadable access-control list to the port”
The authentication process
The diagram and points below give you a simplified overview of the 802.1x authentication process.
- This first message may or may not occur. If the switch sends the request/identity message first you won’t see it
- The switch sends a request message prompting the endpoint to send its identity
- The endpoint sends its identity. What this identity value is will vary based on a) the type of authentication in use and b) the configured security settings. The identity could be the hostname of the PC, a person’s username or could be a dummy/anonymous value if identity privacy is in use. Why might you want to use identity privacy? There is no TLS tunnel protecting data yet and vanilla RADIUS doesn’t encrypt the username field
- The authenticator relays the user identity as a RADIUS message to the authentication server. The EAP protocol is packaged up as RADIUS AVPs
- Based on its configuration, the authentication server will pick an EAP method and respond. Note, it is possible more than one method will be allowed and as such there may be some additional message exchanges as the client/authentication server negotiate what they are going to use
- The message is relayed to the supplicant and for most EAP methods this will also include the authentication server’s EAP certificate. This is used to setup a secure end-to-end TLS tunnel between the supplicant and authentication server. Which certificates are trusted will depend on the supplicant settings. As highlighted above, this is a simplified overview and there may be more back and forth between the supplicant and authentication server depending on configuration and EAP method used
- Once a secure tunnel is established (for most EAP methods anyway) the supplicant sends its authentication credentials. What the credentials are will depend on the EAP method in use but are typically MSCHAPv2 credentials or a signed certificate
- Credentials are relayed to the authentication server by the authenticator. It is worth noting that for most EAP methods these will be secured inside TLS and will not visible even if sniffing traffic
- Dependant on the authentication server’s policies it will decide to send an accept or reject message. As highlighted earlier NAC offers a lot of features, so the decision to allow or deny is likely not based solely on whether the authentication passed or failed
- The EAP success/failure message is sent to the supplicant and dependant on a number of factors, such as supplicant and authenticator configuration, a session will begin, or it won’t. Any restrictions being applied by the authentication server would be applied to the session by the authenticator
- Optionally, and dependant on device support, you may also see EAP logoff messages when devices are disconnecting from the network. You may also see a variant of this known as an EAP proxy logoff message – this is commonly seen when PCs or laptops connect behind an IP phone and disconnect. If the phone supports proxy logoff then it can notify the upstream switch that the device has disconnected and the session has been cleared. Without this notification the switch would have to rely on timers to clear the session as it would have no way of knowing the device had disconnected (as the link state remained up on the switchport due to the phone)
EAP Methods
There are a number of EAP methods that can be used to authenticate supplicants. Most of the commonly used ones offer mutual authentication whereby the client also authenticates the server (i.e. by checking its certificate). The EAP method you choose will depend on the environment you are deploying NAC to and what you are looking to achieve. The most commonly used methods in real world deployments, along with some pros and cons are shown below.
PEAP
Stands for Protected EAP and it requires a server-side certificate on the authentication server. Before any authentication credentials are passed from the supplicant a TLS tunnel is setup. This allows the client to first authenticate the server and then pass credentials in an encrypted tunnel. PEAP is known as a tunnel method, whereby the actual authentication is carried out using a separate inner method that could be a number of different things such as MSCHAPv2 or Generic Token Card. Most commonly PEAP is used with MSCHAPv2 to tunnel user or machine credentials.
- Pros – One of the simplest EAP methods to setup and manage. It does not require client-side certificates allowing easier deployment and management in the future
- Cons – PEAP with MSCHAPv2 is more susceptible to Man in The Middle attacks if the supplicant has not been configured correctly. It also requires server-side certificates (is that really a con nowadays though?!). For machine-based authentication this really only works in a scalable manner when using an Active Directory environment
EAP-TLS
Uses both server-side and client-side certificates to carry out strong mutual authentication. Again, this can be based on user or machine certificates.
- Pros – Probably the strongest EAP method available and resistant to Man in the Middle attacks by design. Allows support for multiple device types (phones, Windows AD devices, non-AD devices such as Macs etc.)
- Cons – Requires that every supplicant device has a valid certificate installed. This can be additional management overhead if you don’t already have this setup in your environment and often puts organisations off
EAP-FAST
Another tunnel method like PEAP that was originally developed by Cisco. Unlike PEAP this one has some more complexity and isn’t as widely used. EAP-FAST uses something known as Protected Access Credentials (PACs) that are a bit like TLS session tickets. I only tend to see this used for one of two reasons – 1) The need to authenticate Cisco wireless access points to the wired network and 2) To support EAP-Chaining where both the user and computer authentication is taken into account – EAP-FAST is the only method that can currently handle both and tie them together.
- Pros – Provides more features such as the ability to do EAP-Chaining. It doesn’t strictly require a server-side certificate, though this would still be recommended and preferred
- Cons – Not supported on a lot of operating systems and typically requires third party supplicant software (though I believe this is changing in Windows 10 – but not by default). Understanding the additional complexity can be a little challenging
EAP-MD5
I didn’t really want to mention this one as it is legacy and insecure, however there have been some older devices that only supported this and in many ways it is still better than MAB alone (though still requires restrictions – more on that in the next section).
- Pros – None really, other than some old devices support it and if it is all you can do it is still better than nothing – though it shouldn’t be relied on for strong security and its use should be minimal
- Cons – Everything! It is insecure, doesn’t perform server-side authentication, is easily subject to Man in The Middle attacks and is just basically a bit rubbish
Bappi lahiri telugu naa songs. The list above is by no means exhaustive – there are a lot more EAP methods than this, however these tend to be the ones you come across in most real-world deployments.
Mab Authentication Configuration
A quick note on EAP-Chaining
I’ve touched on EAP-Chaining a couple of times – what do I really mean by this? Most EAP methods were only designed to do a single authentication – either the machine or the user, but not both. You can configure both in your NAC policies, but by default one is just going to override the other – the status of both isn’t taken into consideration. I won’t get too much into the details now, but this usually ends up in the ability for a user to connect any device they like – as long as they enter their username and password into the supplicant. But what happens if you want to restrict the type of device (machine authentication) but then apply policies based on user groups?
Cisco Mab
Depending on the NAC solution there are a number of ways to achieve this, some good, some not so good. But one of the most secure ways is EAP-Chaining. Using the “EAP-FAST” method, it allows both machine and user authentication to be tied together securely and considered in policies. Your policies would then look something like:
- If only the machine is authenticated – do “x”
- If machine and user are authenticated – do “y”
- If user only authenticated – do “z”
A closer look at MAB
MAB is a fallback option for devices that don’t support 802.1x. It is virtually always used in deployments in some way shape or form. MAB works by having the authenticator take the connecting device’s MAC address and send it to the authentication server as its username and password. The authentication server will check its policies and send back an Access-Accept or Access-Reject just like it would with 802.1x. It doesn’t take a genius to work out that MAB is not a secure authentication method.
Now, MAB is not always used in isolation – you will often find that the authentication server is taking other attributes into account when making its decision (such as profiling information that helps to identify what the device may be – e.g. printer, phone etc.) however it is still susceptible to trivial spoofing. For this reason, all sessions authorised by way of MAB should be restricted in what they can do. For example, if you provide access to a printer based on MAB it should be restricted with something such as a downloadable ACL so that it can only talk to the required resources (i.e. print servers). If an attacker does come along and spoof the device’s MAC address they are going to be limited in what they can access – they will not have full unrestricted access.
This isn’t to say you shouldn’t apply restrictions to 802.1x authenticated sessions as well – it is good practice to do so. The principle of providing least privilege is a good one to follow regardless of the authentication mechanism. You should however definitely be restricting any sessions allowed on the network by MAB.
Summary
Hopefully this post has given you a better understanding of 802.1x and MAB. Importantly as well, how they are both used together to form a coherent NAC solution.
Questions? Comments? Please get in touch!