Denying Wifi access with valid username password on non corporate device

[RobertD1]

Hello,

Have a rule in Control called DenyWifi with Deny profile called DenyWifi and even though the device hits the rule the device gets on the network, obtains an IP and can access the internet. I want to stop someone logging in using a non-corporate PC but the username and password is correct.

The AP is a cloud IQ device. I tried adding a User Profile called DenyWifi with filter-id DenyWifi thinking this would be the answer but did not make a difference. It is second in the list after a User Profile called Enterprise User which allows access. 

I'm confused where this is falling down, and any guidance appreciated.

Thanks

Rob

[RobertD1]

Hi Rob, I retested and managed to get the DenyWifi to work using Control. I made sure there was a User Profile that matched the filter-id and could see by tracing with tcpdump on the EAC engine the correct policy was sent to the AP. Thanks for your response which made me look again in more detail and good to know it works and that the AP can get a permit or deny from Control and the User Policy also needs to match the corner case.

[RobertD1]

The only way I found worked was to block the MAC address of the device is using MAC filters and denying the MAC address in the Network Policy Additional Settings (Optional Settings) but this is moving the configuration to away from NAC and makes it more manual overhead having to add MAC addresses in XIQ. Even though I can add the MAC to an End Systems group and create a rule where it is used it does not prevent a valid user from logging in on a PC I want to block. Customer wants to prevent BYOD to work where employees have a valid username and password.

[Robert_Haynes]

It sounds like the policy enforcement side in XIQ is not working as expected. If you're hitting the appropriate rule in Control and Control is returning the filter ID for "DenyWiFi" then a policy on XIQ for "DenyWiFi" should have ACLs that provide no access. Your policy on Control should also be set "Reject". I can't see how if set up correctly that hitting your rule, getting a Reject sent would result in a client still being able to DHCP lease and have presence on the network.