Can I configure a list of MAC addresses in 1 MAC objects config?

  • 1
  • Question
  • Updated 5 years ago
  • Answered
Hi I am trying to create a "MAC Objects" list of MAC addresses. There are 2 reasons I am trying to do this.

1. I have currently 15 MACBook's and have configured Client Classification reassignment based on a "MAC objects" configuration.

I have configured the first a "MAC address" "MAC Objects" and configured a MAC address and it is labelled Global and the client classification reassignment moves the computer with that MAC address to the correct VLAN. When I try to add a second MAC address to the same MAC Object I do not get the global option. I get option of: Device Tags, Device Name, and Topology Node. Only the first MAC address is reassigned, all others do not reassign.

I have also tried using "MAC Address Range" and set the start and end MAC address as the same MAC address. This will allow me to add multiple MAC addresses under a single "MAC Objects" config. But the client classification rule does not move the computers to the correct VLAN. I experimented and adjusted the range to be the actual MAC address I want in the start of the range and the end MAC address I incremented the MAC address by 1. This will allow all client machines in this list to be reassigned using the client classification rule. But the only problem with that setup is if there is another MacBook that a student brings in that just happens to have the mac address I have configured as the end of the range, then a BYOD device is then assigned to our college machines VLAN. (I know a very unlikely scenario).

2. If I can get a solution to this I can also then use the client classification rules to block unwanted users, or users that have abused their privilege from a single MAC object. Rather than creating another MAC Object and then another client classification rule to deny them access. This is where a MAC Address Range configuration may have a larger chance of 2 people bringing in consecutive MAC addresses on their devices and hence blocking someone that has not done anything wrong.
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes

Posted 5 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Have you considered using 802.1X and/or PPSKs to get the granularity you need instead?

What you are trying to do is terribly insecure and is definitely not recommended.
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes
OK. Big picture.

I have 802.1x auth on 1 SSID.

I am VLAN steering college owned laptops using computer authentication. Staff laptops to 1 VLAN, Student laptops to another.

I am also steering BYOD devices based on username. Staff BYOD to a 3rd VLAN and Student BYOD to a 4th.

I have been trying to setup computer authentication for MAC's so that college owned MAC's are all on their own VLAN. They do not behave the same at this point as a PC. I am trying to minimise MAC chatter on our network. There are a couple of ways I can see to achieve this. If I use a system profile on the MAC I can get them to authenticate and steer to the correct VLAN. But the machine name is not suitable for our aerohive/AD setup . I have been advised to crack the MAC keychain and get the mac computer password. When I do this our netboxblue does not recognise the user when the user logs on. So our accounting traffic shows the MacBook machine name so then relies on who was using this MAC at this time. To overcome this I can allow the 802.1x to authenticate the user who logs on and push these MAC addresses for these very few MacBooks via client classification rules.
This does allow our netboxblue accounting traffic to show the correct username of the person using these MacBook's.

Is there another way you can suggest to achieve this?
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes
A clarification.

We are also trying to use 802.1x pass through authentication on our netboxblue.

When 802.1x pass through is not selected the MacBook does account correctly by username using a system profile.

Now that we have changed to use the 802.1x pass through we are getting the above behaviour. So unsure weather aerohive forum is the best place for this question.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Snooping on the outer identity via pass through/proxy is highly and trivially security vulnerable as you usually can claim to be whoever you want. Just type in another user's user name and off you go. It's caused by identity privacy / anonymous outer identity with TLS-based EAP types.

Is that really what you want!?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
At the EAP terminating RADIUS server you authenticate either via user name/password or a device certificate. These map either to a user or a device, either of which can also be a member of one or more security groups.

Based on user, device or membership of a security group you can return via the EAP terminating RADIUS server:

1) The VLAN (Tunnel-Private-Group-Id) you wish the connection to be in.
2) The Profile (Filter-Id) that you wish the connection to have.

You can make this as granular as you wish, albeit you cannot bind device and user credentials together - auth. cannot be chained in EAP-PEAP or EAP-TLS or EAP-TTLS.

The EAP terminating RADIUS server is privy to who logged on initially as well as the subsequent accounting that is performed by switches/APs. It can then, in abstract, inform the firewall/filter as to who is logged on as needs be - identity and IP address.

This has nothing to do with MAC addresses or device names, nor PCs or Apple Macs.

I think your Netbox Blue is a large part of the problem here as you cannot act as a 'snooping' intermediary and do this correctly.
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes
Nick,

I have been asked by my boss to make it work and check if there are security vulnerabilities. If it is as you say and this leaves a large security breach possibility and it doesn't even behave as expected, then we will probably have to go back to disabling 802.1x pass through.

We were trying to avoid the enterprising student from logging on as one user to aerohive and using another account to connect through netbox. This would leave mismatching records which would be a pain to see what is really happening.

But if 802.1x pass through creates larger security problems then we need to rethink what we are trying to do.

Without reading more about it, I feel that the same security hole you suggest is there using 802.1x pass through is still there anyway with our current setup.

More reading needed.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Michael,

I have been endeavouring to achieve this type of SSO via 802.1X properly via an Network Policy Sever extension that I have written. Nothing commercial that I am aware of does so today.

For the moment, it just works with Palo Alto firewalls (and general deployability is pending a hotfix form Microsoft) but could be extended for other systems.

The introduction to the blog post I wrote about a bug in NPS that I want squashing highlights the trivial identity spoofing issue that underpins most solutions in this space as they work using the User-Name AVP.

(If you find any aspect of the concepts unclear, let me know and I'll try and explain better here.)

http://www.nicklowe.org/2013/08/nps-class-attribute-bug/

Once I have hotfixes from Microsoft, I would be happy to look at extending it to other systems, where a documented API is available.

Nick
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes
Nick,

I have just read the whitepaper from Netbox about their 802.1x pass through:

http://netboxblue.com/sites/2012.netb...

I thought you might be interested in it. It sounds like it is only accounting information that is used for their 802.1x pass through rather than it being the username/password. It also runs a service on the domain controller to verify who the user is.

We do not use an NPS, we are using all AeroHive's inbuilt features for RADIUS and user attributes from AD, any accounting information is being sent to Netbox.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Yup, of it is only accounting information, it will be vulnerable in most deployments.

If you are using Aerohive's built-in RADIUS server, you should test with a client setting the anonymous outer identity to that of another user and see what you see.

If HiveOS uses the inner-identity in the accounting, you'll be ok, if not - you're vulnerable.