Question

NetSight NAC - rule not working

  • 14 August 2019
  • 9 replies
  • 188 views

Userlevel 1
We had NAC installed and fully configured for us. We tested on a few machines and everything was fine- in every test scenario the device being tested matched on the expected rule. Vendor is gone and now I'm rolling it out to all of my switches. Most of my computers are registering just fine, however I have a few that are not matching on rules that I expect them to.

When we created the rules, I wanted to ensure no device got blocked so we created a temporary/failsafe "Wired catchall" rule near the bottom of our rules. This rule is configured to accept anything that wasn't caught in the rules above should we experience any 802.1x authentication issues. Which is why I'm here today, I have computers that are failing authentication and are only being allowed by this catchall rule. The goal is to get all devices to match on a rule and delete the catchall, after all the catchall essentially negates the reason for buying NAC. Let me explain our environment/rules.

I like to think our NAC is a pretty typical setup. All computers will match on "Allow Domain Computers" and will show up in NAC as "host/%hostname%". When the user logs in it will match on "Allow Domain Users & Computers" and show up in NAC as "DOMAIN\username". See attachment "NAC-Rules.png".

Below is a screenshot of expected behavior:



Now I have computers that fail to match on my desired rules and make it all the way down to my "Wired Catchall" rule. One computer I've been experimenting with will not ever match on my aforementioned domain rules and instead goes all the way down to the wired catch all rule.

Then I have a computer that is consistently bouncing between different rules- the 3rd screenshot below. Most of the activity occurred in about 11 seconds.

I've noticed all computers that show an authentication type of MAC (PAP) get dropped in the Wired Catchall, and that computers with the authentication type of 802.1x (PEAP) match successfully. While this makes sense to me, I can't figure out why a computer would default to MAC (PAP).



Working with the computer from the middle screenshot above I've checked the following:
  • Ran netsh lan int sh - results show "Connected. Network does not support authentication."
  • Updated NIC drivers (Realtek RTL8167) - I have other similar computers that work with the driver used from imaging
  • Confirmed NIC has 802.1x enabled, no cert validation, fast reconnect, and authentication mode for user or computer. These settings are being pushed via Group Policy so they're the same on every computer.
  • Event Log reports the following:
  • - 802.1x = Enabled
  • - 802.1x = Not Enforced
  • - EAP Type = Microsoft Protected EAP
  • - Then "authentication succeeded" but reports it does not support authentication
I'm positive this is an issue on my client side, but I'm not sure how to fix it from here.

Anyone out there willing to take a stab before I take a hammer to these computers? 😈

Edit: Switches are Summit X460-G2- all ports are configured identical.

9 replies

Userlevel 3
A few questions:

1) What version of NAC/XMC is this?
2) The computers that are failing - are location groups involved in the rule you expect them to hit?

We have a configuration/evaluation tool which will tell you WHY we think the authorization is failing.

In the WEB ui, right click on the end system in question in the End System table, choose "Configuration Evaluation Tool" and then run it. On the Authorization tab of the results, you will see why we think it is failing. You can expand the rule section you THINK it should be hitting, and the reason(s) will be outlined as to why it fell through to the next rule.

That should give us an idea of what's going on and why.
Userlevel 1
Rodney,

  1. I'm running 8.1.5.22
  2. No location groups
Here is probably more than you asked for. One particular evaluation result reports that the host doesn't exist in the LDAP database. I'm sure this is why it thinks its failing to match, but I can confirm this computer is truly there.

Here is an expected behavior:
  • PASSED: The Authentication Type of: 802.1X (PEAP) passes the any criteria evaluation.
  • PASSED: The Device Type of: MAC Address: XX:XX:XX:7B:03:57, IP Address: 172.xxx.xxx.83, Host Name: %hostname%.%domain% passes the any criteria evaluation.
  • PASSED: The User: host/%hostname%.%domain% has LDAP attributes that match the ones defined in LDAP User Group: Domain Computers.
  • PASSED: The User: host/%hostname%.%domain% exists in the LDAP database.
  • PASSED: The Location of: Switch IP: xxx.xxx.xxx.51, Port Name: 2:26, SSID: null passes the any criteria evaluation.
  • PASSED: The Time of: Wednesday, August 14, 2019 1:57:00 PM EDT passes the any criteria evaluation.
  • PASSED: The Operating System Name of: Windows 7 SP1 passes the any criteria evaluation.
On the one that failed- I expect it to hit on at least "Allow Domain Computers". Here are the results for that failure:

  • PASSED: The Authentication Type of: MAC (PAP) passes the any criteria evaluation.
  • PASSED: The Device Type of: MAC Address: XXX:XXX:XXX:7B:04:75, IP Address: 172.xxx.xxx.129, Host Name: %hostname%.%domain% passes the any criteria evaluation.
  • FAILED: The User: null does not have LDAP attributes that match the ones defined in LDAP User Group: Domain Computers.
Then I expect it to hit on "Allow Domain Users & Computers". Here are the results for that failure:
  • PASSED: The Authentication Type of: MAC (PAP) passes the any criteria evaluation.
  • FAILED: The Host: %hostname%.%domain% does not exist in the LDAP database.
Here is that catchall rule. :
  • PASSED: The Authentication Type of: MAC (PAP) passes the any criteria evaluation.
  • PASSED: The Device Type of: MAC Address: XX:XX:XX:7B:04:75, IP Address: 172.xxx.xxx.129, Host Name: %hostname%.%domain% passes the any criteria evaluation.
  • PASSED: The User Name of: null passes the any criteria evaluation.
  • PASSED: The Location of: Switch IP: xxx.xxx.xxx.51, Port Name: 1:42, SSID: null passes the any criteria evaluation.
  • PASSED: The Time of: Wednesday, August 14, 2019 9:33:52 AM EDT passes the any criteria evaluation.
  • PASSED: The Operating System Name of: Windows 7 SP1 passes the any criteria evaluation.
Userlevel 2
I'd look and see if your DNS server has updated info on the computer in question. There are settings in DHCP server options to update DNS when it hands out an IP address. I'd start looking there.

Here is a good article to start looking at. https://gtacknowledge.extremenetworks.com/articles/Solution/NAC-LDAP-Host-Rule-Not-Working-End-System-Not-Matching-Correct-Rule-in-NAC-s-Rule-Logic?q=reverse+dns&c=Extreme_Software%3ANAC_Manager&l=en_US&fs=Search&pn=1

There are others in GTAC, look for reverse dns lookup in the NAC category.

Hope this helps.
Userlevel 1
Brian,

Thanks for the suggestion- DHCP is updating DNS.

I'm actually glad to see your name popup. I believe you're the one that set this up for us back on December. If so, I'm just now getting around to deploying company-wide.
Userlevel 2
I always wonder, when somebody says "vendor is gone" if it's me 🙂.

Does it always fail on the same computers, or is it random? If you do a ldap lookup on the computer, does NAC pull the attributes in? Under the AAA config, ldap config has a test button, from there you can search for that computer, I believe $ should pull it up. Sometimes * will do the trick too.
Userlevel 1
Brian,

Please don't take that as a complaint. Everything you did and we tested was successful.

I ran the tests as you suggested, it reported computer values as expected.

Before I created the original post I went to a test computer and bypassed the phone (computers connected through phone). When I did that the computer registered just fine. I put the phone back inline and the computer still was registered fine. I gave it a few days and it showed back up on my catchall rule.

I decided to swap the phone out- so I took the phone connected to my computer and swapped them with one another. I expected my computer to eventually hit the catchall rule but it didn't. Nor did the other computer.

This morning I went to one of my users to bypass their phone and their computer is now matching on the expected rules. If history holds true, in the next couple of days it will fall back to matching on the catchall rule. I've attached the end system events from me bypassing the phone. Before the user logged in, I had put the phone back. You can see where I disconnected it, connected it, then the user authenticated.

All of my phones are the same model, and firmware version. I doubt my phones are the issue but for some reason messing with the connectivity seems to generate a different end result. I have 185 devices registering with the expected group (nearly all of them go through their phones). Maybe 14 computers that are not working as expected.

Side note- I have some computers that are matching on the "Wired catchall" but are on wireless. They show disconnected. I suspect maybe they were connected via the wire and wireless before they went offline and NAC got confused. I'll worry about those later. 🙂
Userlevel 2
For the wireless users hitting the catchall rule, probably an undocumented feature in the switch firmware, where clients with bridged at AP topologies, and you have wired policy with access points getting a AP-Aware role, they get authenticated on the wired ports too. I know this is fixed in 22.5.1.7, not sure about any other fork of firmware.

As for the computers getting reauthed with a different rule, the devices should stay authenticated unless something triggers a reauth. Are the ports configured to reauth after a certain amount of time? Are the computers going to sleep and then reauthenticating when awakened?
To me, it still sounds like dns type of issue. Do you have reverse dns lookup zones setup for your networks?

When the computer drops in the catchall rule after being authenticated, check dns and dhcp to see if all the information matches up before restarting or reconnecting the computer back.
Userlevel 1
I figured the wireless/wired issue was something like that. I'll ignore it for now.

The above screenshot that includes 17 events started at 6:59:33 AM and finished at 7:15:22 AM. The only reason 7:15 showed up is because that's when the user logged in.

I have reverse DNS defined for that subnet and that computer is reporting correctly.


C:\>nslookup
Server:
Address:

Name: .
Address: 172.xxx.xxx.77


C:\>nslookup 172.xxx.xxx.77
Server:
Address:

Name: .
Address: 172.xxx.xxx.77
Userlevel 2
Ok. On that screen shot, looks like you are seeing MAC and .1x auth, I don't see timestamps on the screenshot so it is hard to tell the sequence. The device will do both mac and .1x while authenticating, however .1x will take precedence and have final say on the device authentication. MAC is a just a bit faster to auth, so you will see that hit the catch all rule first then .1x will authenticate.

Reply