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"
Today I have been troubleshooting a Citrix NetScaler configuration, where some clients received the Protocol Driver Error message when executing a published application. This error message is mostly related to a wrong configuration of the Security Ticket Authorities (STA’s). I spent a lot of time troubleshooting this issue and focused on the STA configuration. I have been deleting, adding and modifying multiple STA’s to the configuration of the NetScaler without any luck. I checked the configuration of the firewall, but this wasn’t the problem either.
I decided to go back to basic and just added one STA to the Virtual Server and the STA service group used by the Web Interface. I was able to login with that STA server, but after a while I wasn’t able to login and received the Protocol Driver Error again.
While browsing through the NetScaler I noticed one thing. Every time I wasn’t able to login, there were 5 concurrent users already connected with the NetScaler. I did some more research on the internet and found the following article.
Reading the article, tells me that, by default, only 5 concurrent ICA sessions are possible through the NetScaler. I checked the license and the customer has a license for 50 SSL VPN connections, like shown below:
> show license
Web Logging: YES
Surge Protection: NO
Load Balancing: YES
Content Switching: YES
Cache Redirection: NO
Sure Connect: NO
Compression Control: NO
Delta Compression: NO
Priority Queuing: NO
SSL Offloading: YES
Global Server Load Balancing: NO
GSLB Proximity: NO
Http DoS Protection: NO
Dynamic Routing: YES
Content Filtering: YES
Integrated Caching: NO
SSL VPN: YES (Maximum users = 50)
OSPF Routing: NO
RIP Routing: NO
BGP Routing: NO
IPv6 protocol translation: YES
Application Firewall: NO
HTML Injection: NO
NetScaler Push: NO
I increased the default value to 50 with the following command:
> set aaa parameter -maxAAAUsers 50
From that point on I was able to start another ICA connection, while there were already 5 concurrent users connected. Now I have to wait and see if this actually solved the problem, but I guess it has.
I tried to increase the –maxAAAUsers value to a value higher than 50, but that isn’t possible as you can see.
> set aaa parameter -maxAAAUsers 100
ERROR: MaxAAAUsers value not allowed by license