Security

I have looked at this article but it doesn't seem to fit my needs exactly. 

https://community.arubanetworks.com/t5/Controller-Based-WLANs/How-do-I-use-the-user-derivation-rule-to-set-the-role-using-a/ta-p/182426

I'm relatively new to Aruba and this is my first controller-based enterprise installation.

We have a pair of 7030s running 6.5.4.13.  We have one AP group with 3 SSIDs.  On one of those SSIDs we are having to run WEP due to some legacy equipment that is getting replaced and to support a migration to WPA2-PSK.  We aren't looking to do MAC authentication.  But we need to allow only certain MAC addresses to connect to that SSID.  Some of those MAC addresses we need to define by OUI only since there may be several dozen of them.  There are a few MAC addresses we will need to define by the full MAC address.  We want whatever method would work best to do this.

Currently the SSID works but unwanted devices can connect.  We in essence want a "permit only" for those defined MACs and a "deny all" for any that don't match.  We have some Aerohive networks (yes, sorry) where this was pretty easy to implement and actually denies even the attempt to associate to the AP except for the allowed MACs.

If possible I would like guidance for the GUI vs the CLI but will take whatever I can get.  Any help is appreciated!!  Thanks!!!

- Create a role called "Deny" that has a single line to deny everything

- In the same AAA profile that has the user derivation rule, make the initial role "Deny"

Thanks.  So to clarify, use the article I linked to as a base for what I’m doing but use your modifications for the role and AAA profile.

It also seems that all of my options in AAA Profile under the Virtual AP for that SSID are grayed out.  I’m not sure why.  I’m on the master controller and using an admin user.

Your link is correct, but to do this through the GUI you need to go to configuration> security> AAA profile.

Ahhh!  Because what I see under the virtual AP is inherited from there.  ;)

I will try this and, if it works, will happily mark this as a solution.  Thank you so much!!

The previous suggestions are correct. I just wanted to explain a little about the process. When the user first connects to the WLAN, the user will be assigned the LOGON role (this happens to all users no matter what), which will immediately be replaced by the initial role. Per the suggestion, the initial role will by DENY, so every connection will be given DENY. At that point, the next step is the User Rule is processed. The User Rule can be made up of one or more conditions. These conditions are processed in order, so put the most likely ones to be hit at the top of the list, or if there is logic in one rule that should supercede another, make sure you have the order correct. The first condition that matches will set the role, and no other conditions will be processed. So if there is a User rule assigned to the AAA profile, and one of the conditions matches, and the role that the condition is assigning exists, then that will be the new role, replacing the DENY role.

As long as you do not enable MAC authentication, 802.1X/EAP authentication, or captive portal authenticaiton, then no more role derivation is processed, and the only way the user will receive a role is through one of the methods mentioned above.

I hope this helps,

Thank you for the explanation.  That's sort of what I thought was going on but I absolutely appreciate the confirmation.

First, thank you both for your help.  I know I have to be real close on this but something is still missing.  I"m not sure where I'm missing it.  Here is what I have done.

Under Security>Authentication>User Rules I created a user rule called MAC-FILTER.  In that filter I placed two entries.  One is a macaddr starts-with where I specify an OUI that belongs to several of the wireless picking devices.  I also put in another entry as an equals that has the full MAC address of another chosen device.  Remember I'm just testing here.  When we figure this out there will be a few more.

Under Security>Authentication>Profiles>AAA Profiles I chose the AAA profile that belongs to the VAP in question.  I changed the initial role to "denyall" and then changed the user derivation rules to "MAC-FILTER" and applied.

I went back to check my clients and nothing happened initially.  I don't know if I needed to force it but, to force a reassociation, I rebooted a couple of the APs the clients were associated to.  They immediately changed APs and the client role then showed as "denyall".

However, I can still ping the clients that are showing denyall.  The default denyall role doesn't actually have a policy associated with it which I thought would mean it would hit the implicit deny.  Of course in reading it only talks about a firewall policy with no rules having an implicit deny so I added a firewall policy to denyall with no rules.  I reapplied and bounced again and it is still pinging.  So then I tried a policy with explicit denies with the same result.  So I'm missing something here in how this is working.  I at least have the role getting assigned properly.  That seems to be working perfectly.  But the result is that the role is not accomplishing what we desire and that is a denial of access to any clients not defined in MAC-FILTER.

I would appreciate any further help.

I do have to make one further comment, though, unrelated to this thread.  I am THRILLED with this system.  When I went through my training I was thoroughly impressed.  But when the rubber hit the road it did not disappoint.  This is the first major wireless change we have made for this customer that we actually flipped from one system to another with zero problems.  Distribution centers are challenging environments.  Distribution centers with a mix of different RF clients, some old, some new, are even more challenging.  We have had good experiences where we have only had a few minor problems and had to troubleshoot various things.  Did I say this is the FIRST time we have moved them to a new system with ZERO problems.  Everything just worked.  My hat is off to Aruba.

To kick users off, use "aaa user delete mac <mac address of device>" or "aaa user delete all" to kick everyone off.  Test again, after you did that.

That was it!!!  Worked perfectly.  Kicked off both clients that should be allowed and those that should be denied and only the ones that should be allowed came back.  Awesome!!

The method you used before might have just shifted users to another access point, AND when you change the roles of devices, existing flows continue.  Removing users entirely stops the flows...