Configuring an SSID with WPA2 Pre-Shared key or Enterprise authentication and encryption is very common. Sometimes you would like to add an extra authentication method. Although this method isn’t very secure, MAC authentication is still used as an extra method to strengthen the level of security of a wireless or wired network.
These days I have been configuring a Aruba Networks wireless network with one master en two local controllers. The customer is using WPA2 security and wanted to add MAC authentication as extra authentication method. The configuration of MAC authentication for Aruba Mobility Controllers is very straightforward. This blog provides an example of the MAC authentication configuration. The configuration of a MAC Authentication Profile and the definition the MAC database are key in the solution.
While testing I noticed that MAC authentication only worked when I configured the parameter “Max Authentication Failures = 1” of the MAC Authentication Profile. The MAC address of the client is blacklisted if it’s unknown. When blacklisted, the client cannot associate with any SSID for at least one hour. This wasn’t exactly what I wanted to happen.
The following log contains the user-debug information during the authentication process, when the parameter is still set to 0.
Dec 14 09:01:20 :522005: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP=192.168.129.3 User entry deleted: reason=essid change
Dec 14 09:01:20 :522050: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=N/A User data downloaded to datapath, new Role=authenticated/54, bw Contract=0/0,reason=Station resetting role
Dec 14 09:01:20 :522042: <NOTI> |authmgr| User Authentication Failed: username=cc:08:e0:5e:2c:7b MAC=cc:08:e0:5e:2c:7b IP=0.0.0.0 auth method=MAC auth server=Internal
Dec 14 09:01:22 :522026: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP=192.168.129.3 User miss: ingress=0x1200, VLAN=666
Dec 14 09:01:22 :522049: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=0.0.0.0 User role updated, existing Role=WA-Test_role/none, new Role=WA-Test_role/WA-Test_role, reason=First IP user created
Dec 14 09:01:22 :522006: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP=192.168.129.3 User entry added: reason=Sibtye
Dec 14 09:01:22 :522049: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=192.168.129.3 User role updated, existing Role=WA-Test_role/WA-Test_role, new Role=WA-Test_role/WA-Test_role, reason=User not authenticated for inheriting attributes
Dec 14 09:01:22 :522050: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=192.168.129.3 User data downloaded to datapath, new Role=WA-Test_role/59, bw Contract=16385/16385,reason=New user IP processing
To me it looked like the authentication was using an OR statement instead of and AND statement. Eventually, with the help of cjoseph from Airheads Social, I noticed that after WPA2 authentication, the user gets the initial role of the AAA profile. I configured this profile as authenticated (allow all). Next MAC authentication is performed. If MAC authentication fails, the user still has the initial role from the AAA profile. If MAC authentication succeeds, the client is elevated to the MAC authentication role from the AAA profile.
I want both authentication methods to be successful before the client is granted access to the network. The only thing to change was, changing the initial role from the AAA profile to deny all.
aaa profile "WA-Test_aaa_prof"
Latest posts by René Jorissen (see all)
- ClearPass & MobileIron – Error: not well-formed (invalid token) - October 28, 2016
- FortiMail – Howto configure DLP - October 27, 2016
- FortiMail – Howto enable DLP - October 25, 2016