cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 

NetSight NAC - rule not working

NetSight NAC - rule not working

T_Pitch
New Contributor III
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:

30d3016c57d74e6f93eee340c63f0adf_86ac91ee-a010-43e4-9111-69497ae8917c.png



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).

30d3016c57d74e6f93eee340c63f0adf_d2f3fe32-1b9e-4fc6-ad6a-a249f8193d0d.png

30d3016c57d74e6f93eee340c63f0adf_89033d83-6c76-48da-926a-ea181f1445b5.png


30d3016c57d74e6f93eee340c63f0adf_1a3641b0-3ec9-4cdb-9812-e65253ab4f18.png


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.
1 ACCEPTED SOLUTION

Brian_Anderson1
Contributor
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.

View solution in original post

9 REPLIES 9

Brian_Anderson1
Contributor
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.

T_Pitch
New Contributor III
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

Brian_Anderson1
Contributor
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.

T_Pitch
New Contributor III
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. ļ™‚
GTM-P2G8KFN