cancel
Showing results for 
Search instead for 
Did you mean: 

Trying to setup the most basic MAC based Access Control but need help

Trying to setup the most basic MAC based Access Control but need help

Stephen_Stormon
Contributor
We know that XMC and NAC can do a whole lot, but initially all we want to do is this:

1) A system will be plugged into a port and will show up in the end-systems tab
2) An administrator will then add that to the "Allowed Devices" group which we have created (for simplicity, this group uses the "Default NAC Profile" which uses the "Enterprise User" Accept Policy)
3) All other systems that have not been added to the "Allowed Devices" group are blocked from accessing the network.

I have an isolated non-production switch that I want to test this on, but I have a question about the config and the rules.
1) We have one Configuration (IMS) that is currently in use on all switches. I have made a secondary Configuration (IMS - MAC Auth) which I wanted to use for MAC auth testing, but I can't figure out how to apply that to just the one switch I want to test on (it has been a while since we first deployed XMC/NAC and I don't know if I am just forgetting where the option is or if a whole new Policy Domain is needed to make this happen)?
2) If the other configuration can be assigned to just a switch for testing, will the attached rules accomplish what we want?
  • Quarantine anything in the Blacklist group
  • Send a notification for anything in the Assessment Warning group
  • Allow anyone if the omni\XOS Administrators group to login to the switches (this currently works)
  • Quarantine any system from which a user attempts to login to a switch but they are not in the omni\XOS administrators group
  • Allow any system that is in the "Allowed Devices" group onto the network
  • Block all other devices
I know that this means that we will have enable identity management on all ports and add all systems to the "Allowed Devices" group before enforcing those rules.

I'm new to the NAC side of things and know that it can cause issues when configured incorrectly, so all the help (and clarification to ideas that I am not understanding correctly) you can provide is welcome.

6a5595c2cbe34599ac32cafbc141d742_4db75318-81f3-4189-90e5-3183dd8a15fc.png

15 REPLIES 15

Zdeněk_Pala
Extreme Employee
You can use NAC Manager to change the config:

a78b023c328c44bdb4e50978b7e2694a_fe94ea1b-1032-4e1d-b860-23f41abe1b66.png

a78b023c328c44bdb4e50978b7e2694a_fe94ea1b-1032-4e1d-b860-23f41abe1b66.png

Regards Zdeněk Pala

Stephen_Stormon
Contributor
Where is the option to change which configuration is assigned to the engine? I can see that the "IMS" configuration is applied to this engine, but I can't remember where to go to change that setting.

c6ab4197e52b4f60b193f1b2d637d46b_06ac882c-534d-40b2-9e88-7351db6f48a5.png

Zdeněk_Pala
Extreme Employee
There is one access control configuration for group of engines. You can have more groups and each group can have own access control configuration.

there is always maximum one configuration for engine.
Regards Zdeněk Pala

Stephen_Stormon
Contributor
@Ronald Dvorak , so you are saying that there can only be one "Access Control Configuration" for all of NAC? I guess the only reason we haven't run into any issues yet is because the "Default" and "IMS" configurations are basically the same (shown below). It sounds like we should disable all the rules in the "Default" configuration (if we want to leave it around for reference), delete it and stick with our "IMS" one, or just use the "Default" one and delete our "IMS" one.

7daf08545974483f977dde2a4578d593_b6ad29ee-8317-449d-8d5b-a623563f0423.png

7daf08545974483f977dde2a4578d593_5150a665-e0b1-46c7-93a2-2010895dab13.png

Zdeněk_Pala
Extreme Employee
two options how you can accomplish what I understand you want (May be I do not understand it)...

Option 1 = more scalable more "human error resilient":
  • Create new configuration
  • Create new engine group
  • Assign your new configuration to new engine group
  • Deploy new Access Control Engine and assign it to your new engine group
  • connect your testing switch to the new Engine
now you can play with the switch and rules without affecting your production.

Option 2 = does need less resources
  • Create new location based on your testing switch
  • All your testing rules must have your new location in conditions
  • Rules are processed from top to the bottom = your testing rules must be on the top
your scenario seems to be quite easy.
Rule #1 = if location and end-system is in Allowed Devices then apply the proper profile with policy
Rule #2 = if location then apply Deny profile with deny policy or Reject profile (needs to be created). by default deny profile does assign deny policy what does allow DHCP, DNS, ARP = so fingerprinting will work for you for non-approved devices
Regards Zdeněk Pala
GTM-P2G8KFN