802.1x and MAC Address Authentication

  • 1
  • Question
  • Updated 2 years ago
I am very new to networking and Aerohive and have a question about how to configure both the Hivemanager NG and my Radius Server to Authenticate using 802.1x while also authenticating the MAC address in the database to allow that device on the network with the user's credentials.

Here is the scenario. We are a small private school with around 400 concurrent users, so the native MAC Authentication in the Hivemanager won't work with only 256 allowed MAC Addresses. I have successfully set up 802.1x authentication using our Radius server and AD on two separate SSIDs for users to authenticate their device. What I want to control is what devices they are allowed to authenticate on our network. I want the students to authenticate for filtering and management purposes. We own and provide all of the devices that the students use and I want to be able to limit network access to only our devices and not any rogue devices like cell phones or a personal computers. I know I can control the Cell Phones through an OS assignment rule, but blocking the Cros or Windows would block our devices too.

Does anyone know of any step sheets or resources that can guide me through setting this up if it's possible? If there is a better way to achieve what I am trying to do, please let me know.
Photo of Justin Whitford

Justin Whitford

  • 6 Posts
  • 0 Reply Likes

Posted 2 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Justin,

Do not try and implement separate MAC address authentication that is subsequent to 802.1X having first completed.

The client's MAC address is present in the Calling-Station-Id attribute of the RADIUS Access-Request packets. You should use this.

Importantly, without needing to know the minutiae of what goes on, you can check the value of this attribute at a RADIUS server while 802.1X authentication is occurring to decide whether or not to allow a client to associate, and, if so, what user profile to apply to its association (VLAN, firewall, QoS etc) via the attributes sent in the RADIUS Access-Accept packet.

To integrate with a database to make appropriate policy decisions, by way of which RADIUS server to choose and use, you would want likely want to go with either FreeRADIUS or Radiator... and definitely not something like Network Policy Server (NPS) which lacks core capabilities and flexibility in this area, needed to make what you desire practical and scalable.

What you want to achieve is a concern at the RADIUS server alone, that is and to put it in another way... it is not an Aerohive specific/coupled 'thing'. You would look to configure your chosen RADIUS server appropriately based on the documentation, guidance and examples that exist for it.

If you have more specific questions after selecting a RADIUS server and a database to use, and reviewing its documentation, post back and I am sure we can help with specific, targeted advice.

Cheers,

Nick
(Edited)
Photo of Anjanesh Babu

Anjanesh Babu

  • 68 Posts
  • 7 Reply Likes
Hi Justin,
Glad that you posted this question and in a very clear fashion. The Aerohive documentation is notoriously lacking in the finer details compared to other vendors.

We have also hit the 256 number ceiling and in the process of devolving the mac addresses decision to an external radius.

Got halfway there and we could see the mac addresses being authenticated on the NPS and passed back but the profile assignment did'nt go through - the client device always dropped  into the default vlan.

I believe I may have been missing a key step and parked the setup for revisiting this later. 

I am curious to find out how this thread evolves and perhaps contribute to any testing .
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Anjanesh,

I agree that there could be improved documentation in this area.

The behaviour for the client's MAC address in the Calling-Station-Id is as per RFC 3580 in Section 3.21:

Calling-Station-Id
For IEEE 802.1X Authenticators, this attribute is used to store the Supplicant MAC address in ASCII format (upper case only), with octet values separated by a "-".  Example: "00-10-A4-23-19-C0".
https://tools.ietf.org/html/rfc3580#section-3.21

HiveOS uses a non-conforming format for the MAC address by default, but it can be configured to delimit after each octet with hyphens in uppercase where full compliance is desired/required.

As to user profile assignment via RADIUS, this feature is used extensively by many customers and does work well.

For by the book, RADIUS standards based 802.1X...

You should be returning a Service-Type attribute of Framed along with a Framed-Protocol attribute of PPP.

For VLANed environments, you can add and set:
1) Tunnel-Type attribute to VLAN
2) Tunnel-Medium-Type attribute to IEEE-802.
3) Tunnel-Private-Group-Id attribute to the desired VLAN ID in string (ASCII / UTF-8 encoded) format. (This will override any VLAN set in the user profile.)

I suggest using the Filter-Id attribute to set the user profile attribute as this is the RADIUS standards based way of doing this this unless you have a need to use Aerohive's alternative, vendor specific method.

I suggest that you take a look at Aerohive's documentation for using the Filter-Id attribute to understand how to configure this in classic HiveManager: https://mega.nz/#!mtd0UaTD!s25Kk1bZkEtMvOIqlnsTeAZx5fY67FjmQcVPQ1QljiQ

For NG, the configuration is different but, in my view, rather self explanatory and obvious.

Regards,

Nick
(Edited)
Photo of Anjanesh Babu

Anjanesh Babu

  • 68 Posts
  • 7 Reply Likes
Hi Nick,

thank you for your response. That seems familiar from another  thread research that was tried unsuccessfully. I know it doesn't  help without posting details . Will work on that.

I should say that we have used user profile assignment works great with normal AD users and not mac addresses based users.

I curious to know how Aerohive customers have radius based   vlan steering  working with  mac address as users using  the obvious documentation that getting the better of me.

A useful starting point and thank you .
Photo of Eastman Rivai

Eastman Rivai, Official Rep

  • 146 Posts
  • 17 Reply Likes
Justin,

If I understood you correctly, you want to only allow school own devices and  disallow personal devices to use the student SSID. In order to achieve your requirement, you may just allow domain computers in your radius server. This will allow only domain machines to be authenticate and prevent someone with a smart phone or tablet to connect to the SSID using their AD credentials. You can the create a domain policy for windows machine to authenticate using computer account only so the machine will only use computer account to authenticate to the SSID. Student will still use their credentials to login to the domain.

You may find the configuration details on Microsoft website. If you are unsure please let me know.

Eastman
Photo of Anjanesh Babu

Anjanesh Babu

  • 68 Posts
  • 7 Reply Likes
This document on Meraki setup has been the most helpful documentation for getting me off the ground with  Windows NPS based mac address authentication. Very handy guide.

Creating an NPS Policy for MAC-based Authentication

Depending on password policies within the Active Directory, one may have to dial down password requirements at the AD container  level  for the devices being authenticated.

Learning curve with the Windows based NPS radius server is much more easier than anything out there.

Hope this helps.
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Thanks! Just to add a note that Meraki's document should not be followed verbatim, as-is.

The instructions are in error as they do not check the value of the Service-Type attribute, which should be Call-Check for MAC-address authentication and Framed for 802.1X.

(Meraki may not be sending this attribute to differentiate the type of service, but Aerohive do and this should be checked.)

Nothing in those instructions would stop a user putting a MAC address in as the username/password when performing 802.1X-based authentication via a supplicant or CWP-based authentication via a browser.

(Permitting Wireless-Other is also incorrect, but harmless.)

I would also not personally implement MAC address authentication this way in NPS, by creating user accounts in AD, and would instead use the value of the Calling-Station-Id and the Service-Type attributes to do this in a Connection Request Policy, electing to send an Access-Accept without validating credentials. This is more a point of personal preference, however.

I would also like to see HiveOS implement the ability to do MAC address authentication using a fixed username and password that is configurable as this facilitates using a common credential and allows a Network Policy to be used.
(Edited)