Troubleshooting NPS for basic MAC Authentication

  • 2
  • Question
  • Updated 3 years ago
  • (Edited)
We are in the process of implementing an Aerohive infrastructure in our district (from Cisco) and have a small issue we are trying to work out with one particular SSID.  I understand that the solution we are troubleshooting isn't in any way a secure solution, but rather a matter of making access to a particular SSID smoother in certain applications (Chromebooks, device carts for young children).  We just want basic MAC authentication on this SSID.

Anyway...  I set up a spare server as an AD server running NPS.   I've gone through the guide here:  https://technet.microsoft.com/en-us/library/dd197535(WS.10).aspx and other sources for the basics of setting up NPS (connection request policies, network policies, etc) to handle MAC address authentication.  The policy I created is set to just use PAP.   I've created a user account on the AD server with the username and password both the MAC address of the device I am testing.

For example: aabbcc112233

On HMOL I have created an experimental network policy  and applied it to a single AP here in my office.  I have AAA Client Settings pointing to the AD/NPS server with the correct secret and an SSID set up as "Open" with "Enable MAC authentication" checked and "PAP" set as the authentication protocol.  All this has been set to the AP via update.

So I grab my device and attempt to connect to this new SSID and it fails.  I see the following in Event Viewer on the AD server under Security:

Audit Failure- Event ID 6273:
Network Policy Server denied access to a user.
Contact the Network Policy Server administrator for more information.
User:
Security ID: NULL SID
Account Name: aabbcc112233
Account Domain: DOMAINNAME
Fully Qualified Account Name: DOMAINNAME\AA-BB-CC-11-22-33
Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
OS-Version: -
Called Station Identifier: 9C-5D-12-7F-43-A4:Test_SSID
Calling Station Identifier: AA-BB-CC-11-22-33
NAS:
NAS IPv4 Address: 10.19.107.1
NAS IPv6 Address: -
NAS Identifier: AH-7f4380
NAS Port-Type: Wireless - IEEE 802.11
NAS Port: 0
RADIUS Client:
Client Friendly Name: Test AP
Client IP Address: 10.19.107.1
Authentication Details:
Connection Request Policy Name: MAC Authentication Aerohive
Network Policy Name: -
Authentication Provider: Windows
Authentication Server: WIN-06HKOI2O79H.DOMAINNAME.net
Authentication Type: PAP
EAP Type: -
Account Session Identifier: -
Logging Results: Accounting information was written to the local log file.
Reason Code: 16
Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

So it appears that the AP is passing along the request, but the NPS server is not liking what it is getting in terms of user credentials.  Again, in this instance both the username and password are "aabbcc112233" ... no hyphens, no colons, etc.

Ideas?
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes

Posted 3 years ago

  • 2
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Are you sure your RADIUS shared secret matches on both sides?
(Edited)
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
Just verified.   They match.  Still get the same errors in Event Viewer.
Photo of @TheWiFiJedi

@TheWiFiJedi

  • 1 Post
  • 0 Reply Likes
NULL SID might be the issue. Try running newsid and check again.
Photo of Dianne Dunlap

Dianne Dunlap

  • 75 Posts
  • 15 Reply Likes
I believe the RFC says the radius-server must silently discard the packet if the key is bad.  I believe the issue is the password (or the username).  If one sets up a spare radius-capable router or switch for admin authentication to radius & try the same credentials with that, does it work?  
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2477 Posts
  • 447 Reply Likes
It does. Others online however say in some numbers that a bad shared secret was the cause of this specific issue for them, in some cases. There's always what the spec says vs. what actually happens in failure conditions.
(Edited)
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
What is bugging me on the NPS Accounting Log is the Fully Qualified User Name and SAM Account Name have dashes... the user is set up without the dashes in the username and password.

<Event><Timestamp data_type="4">10/07/2015 08:28:24.670</Timestamp><Computer-Name data_type="1">WIN-06HKOI2O79H</Computer-Name><Event-Source data_type="1">IAS</Event-Source><Class data_type="1">311 1 10.2.0.111 10/07/2015 13:27:53 2</Class><Authentication-Type data_type="0">1</Authentication-Type><Fully-Qualifed-User-Name data_type="1">DOMAIN\AA-BB-CC-11-22-33</Fully-Qualifed-User-Name><SAM-Account-Name data_type="1">DOMAIN\AA-BB-CC-11-22-33</SAM-Account-Name><Provider-Type data_type="0">1</Provider-Type><Proxy-Policy-Name data_type="1">MAC Authentication Aerohive</Proxy-Policy-Name><Client-IP-Address data_type="3">10.19.107.1</Client-IP-Address>
<Client-Vendor data_type="0">0</Client-Vendor><Client-Friendly-Name data_type="1">Test AP</Client-Friendly-Name><Packet-Type data_type="0">3</Packet-Type><Reason-Code data_type="0">16</Reason-Code></Event>
Photo of Dianne Dunlap

Dianne Dunlap

  • 75 Posts
  • 15 Reply Likes
Check on sniffer trace - the username is cleartext there. 
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
Will do.   Just going by the Technet guide it seems a requirement that the username and password be the MAC address without any dashes, colons, etc.   Are there circumstances under which a client would pass that information any other way?
Photo of Dianne Dunlap

Dianne Dunlap

  • 75 Posts
  • 15 Reply Likes
The end-device would never send it different ways but Aerohive might convert from colons to dashes to null prior to sending.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Tony,

I've finally had the time to write a more substantive response that will, hopefully, help you.

An easy way to achieve what you want it to not bother checking the username and password at all.

If it's a MAC address in both of those, you've not achieved anything at all from a security perspective.

The client's MAC address is also contained in the Calling-Station-Id.

After having conditional checks for the MAC addresses that you wish to permit against the Calling-Station-Id (it's a regular expression so use a pipe: | ), you can permit the connection by checking for a Service-Type of Call-Check, a NAS-Port-Type of Wireless/802.11 and for the SSID of your network against the Called-Station-Id attribute with a regular expression.

With NPS, you would need to configure a CRP to "Accept users without validating credentials" with the right conditions.

(Ignore the MAC Address Deny in the title, I'm reusing a screenshot I already had.)


(Note: I have HiveOS configured to send client MAC addresses delimited with hyphens, this isn't the default so you will need to adjust as necessary. There may be a limit to the length of the Calling-Station-Id condition in which case you would need another CRP.)

(You will want to Accept users without validating credentials, again reusing an earlier screenshot.)



Remember to configure the RADIUS attributes you want to go in the Access-Accept under Standard.
(Edited)
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
Thank you for taking the time to craft this response.  So for Calling Station ID I would create a piped list of all MAC addresses that should be allowed to connect.   Does this require a Network Policy as well?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
That's correct.

Just a Connection Request Policy, no Network Policy needed/used.
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
I'm obviously missing something.   Let's go with a concrete example.  I have an iPhone here.   My SSID is "ISD31_DistrictDevices" and the MAC address of the iPhone is d8cf9ceae2b0 ... So I created the following Connection Policy:



Note:  I tried this with and without the hyphens in the MAC address.

All Network policies are disabled.  I am still unable to connect on that SSID from this device.  All I see in event viewer now is multiple Special Logon, Logon and Logoff events, none of which seem to be connected to this connection attempt.

Should something be configured differently for the SSID in HMOL?
(Edited)
Photo of Dianne Dunlap

Dianne Dunlap

  • 75 Posts
  • 15 Reply Likes
I've got an example of this at:
https://docs.google.com/document/d/1xzJhWafRZWWqzIaTGaF3xt5a7ECGzGsrdpRzRGSTm_8/edit?usp=sharing
Chromebooks should have unique ouis but you will not be able to tell an ipad from an iphone using ouis.  If you have carts of ipads, you would probably need to do what you were originally doing.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Dianne,

It is regular expression, not wildcard semantics. Your use of * is not behaving as you expect it to therefore.
(As * matches 0 or more, you will get away with it though.)

See: https://technet.microsoft.com/en-us/library/dd197583(v=ws.10).aspx

You also need a ^ before the start of each partial MAC address or you could match starting from the wrong place, so could auth unintended MAC addresses.

You also ought to check for the Service-Type which will limit to MAC address authentication only.

(A Service-Type of Framed is typically used for 802.1X)

I asked for Service-Type to be added to HiveOS a while back. It was added in HiveOS 6.1r3:

https://community.aerohive.com/aerohive/topics/add_the_service_type_radius_avp_to_properly_distingui...

Cheers,

Nick
(Edited)
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
OK...  Found the error of my ways.

In NPS:

1. Radius Clients - for some reason I had the test AP configured here with the "Access-Request messages must contain the Message-Authenticator attribute" option checked.  Must have tinkered with it during the AD integration testing.

2.  In the CRP - The MAC address has to be hyphenated in the Calling Station ID.  I added in caps as well.

Also... Under Authentication I switched to "Accept users without validating credentials."

I appreciate the advice given here... but unfortunately I'm not certain that this is a workable solution.   The Calling Station ID field will accept about 16 MAC addresses in a piped list.  We are talking about a few hundred devices (Chromebooks, ChromeBases, iPads, Laptop Carts).  Unless there is a way to reference a list of some kind I don't think this will be very efficient.

So I may have to continue testing against Active Directory with MAC address as username/password.  Not secure, I know, but perhaps a way to make it more painful for the craftier cherubs to figure out how to surf anonymously.
Photo of Dianne Dunlap

Dianne Dunlap

  • 75 Posts
  • 15 Reply Likes
agreed that there could be limitations (I only tried with 2 in the "or"). Since you would encounter issues with ipad/iphone differentiation besides this, you might want to do a Powershell mac address import into AD.
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
So I am back to my original question.  Back to the drawing board!
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
Final setup for those who are looking for the same solution:

This is for basic MAC address authentication.  The device connects to the specified SSID, the AP pushes the MAC address to NPS for authentication and if the MAC address is in AD, the device is allowed to join the network.

Assumptions...

1. You have a functioning Win 2008 or greater AD server.
2. The NPS service is installed.
3. NPS is registered in Active Directory

For this example my AD/NPS server is at 10.2.0.111.

My APs are all on the 10.19.0.0/16 subnet

NPS Setup

In NPS, under Templates Management right click on "Shared Secrets" and create a new shared secret template.  I called this one "Aerohive".  Type in the Shared Secret that will be used between NPS and RADIUS clients.



Under RADIUS Clients and Servers right click on RADIUS Clients.  You are defining the clients that are allowed to communicate with NPS.  In this example I gave it a friendly name and then specified an entire subnet because all of my APs are on 10.19.0.0/16. You can, if you wish, create multiple clients for each AP that will be sending RADUIS requests to this server.   Be sure to select the Shared Secret template you created above.



Note:  On the Advanced tab, be sure that RADIUS Standard is selected and that "Access-Request messages must contain the Message-Authenticator attribute" is NOT checked.

Under Policies right click on Connection Request Policies to create a new CRP.  In this case I called mine Aerohive CRP.  Be sure the policy is Enabled.  Type of network access server can be left as Unspecified.



For Conditions, all you need to add is NAS Port Type and choose Wireless - IEEE 802.11



Under Settings just be sure that "Authenticate requests on this server" is selected.



Again, under Policies, right click on Network Policies and add a new Network Policy.  In this case mine is called MAC Authentication Aerohive.  Be sure the policy is enabled, Grant Access is the Access Permission chosen and the type of network access server can be Unspecified.



For Conditions you will want to specify two conditions.  Add NAS Port Type and choose "Wireless - IEEE 802.11" and in this example I also checked Wireless Other.   In addition, you want to add a User Groups condition.  In my example I simply used "Domain Users" because the only users on this server will be the MAC addresses of each device that will be allowed to connect.  If you are putting your MAC address users into a particular group, then you will want to specify this group here.



On the Contstraints tab be sure the only option checked is "Unencrypted authentication (PAP,SPAP)". 



Nas Port Type should again be "Wireless - IEEE 802.11" and "Wireless - Other"



Regarding the "Settings" tab.  Some examples I read or videos I watched describe adding several Standard RADIUS attributes on the Settings tab.   This is only necessary if you need NPS to return unique information, for example if one set of MAC addresses go to vlan 249 and another set goes to vlan 256.  In my example, as you will see below, the SSID I set up is already in a predetermined vlan.  So all I require is that the user be authenticated and access be granted.  So no RADIUS attributes required.

That is all I configured for NPS settings.   The next step is to add users either via Active Directory Users and Computers or via script.   The requirement here is that the username and password must both be the MAC address of the device you want to allow.  The default format in HMOL is to send the MAC all lowercase with no hypens or colons (Configuration-> Management Services-> Management Options, choose your organization's options and the MAC format options are at the bottom).  So if you have it at the default, then the username and password in AD must follow the same format.

Note:  In my reading here  the advice is to add a couple of registry entries for Remote Access Policy.  In the many failed setup variants I tested I had added these registry entries.  After removing them, and adjusting other options I have a functioning NPS setup.  I have no idea if there was a direct correlation or not, but MAC authentication is working on my 2008R2 server without the registry values added.

HMOL

The setup in HMOL is pretty straightforward after NPS setup.  Go to Configuration-> Advanced Configuration-> Security-> AAA Client Settings and add a new setting:



Not much to it.  Add a new Server, indicate the IP address of your NPS server and make sure the Shared Secret matches the Shared Secret you created in NPS above.  If you have redundant servers set up, add them here as secondary servers.

Create your SSID.  Configuration-> SSIDs add a new SSID.  Name it and set your parameters.  In this case I left it open... although we may add PSK on top of this.  We will also hide it.  

Check "Enable MAC Authentication" and choose PAP (to match the authentication setting in your NPS Network Policy).



The final step is to set up your Network Policy.  Here you choose (or add) your SSID, choose the AAA Client Settings you created under Authentication, add your User Profile and you are done.  In this case the user profile is specifically set up so that devices that connect to this SSID are dropped into a specific VLAN.

Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
I welcome any critique of the above.  I will make changes if necessary.  Hopefully this helps someone who is searching for a similar solution.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Thanks, Tony.

You don't need Wireless other as this is 802.11.

You should have a check for a Service-Type of Call-Check on the Connection Request Policy. (Otherwise, how do you ensure that it's MAC address authentication that is taking place?)

I would probably use CHAPv2 rather than PAP personally.

Your conditions on the Network Policy should just be to a Windows security group that you use for MAC address authentication and the user accounts for the MAC address should be a member of that group.

Nick
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
Well, for some reason I can't edit my response above, so suffice it to say that I have applied Nick's suggestion.  In the Connection Request Policy... "Add..." Service-Type and check "Call-Check".  

I will experiment with the CHAPv2 vs PAP settings.

Regarding the User Groups condition in the Network Policy.  Nick is absolutely right, and I commented on it briefly.  In my setup, the only thing this server is used for is MAC address authentication.  It is not part of our "production" Active Directory domain.  So I simply used "Domain Users".  If you make this a part of your existing AD Domain, you will want to create a security group and make all of your "MAC address Users" part of that group, then specify only that group in the User Groups condition.

Thanks Nick.