Why most NAC deployments fail

Network Access Control.  Another somewhat ambiguous yet ubiquitous security term floating around for a decade.  The principle of NAC is legit.  The goal is to make sure only authorized users and devices connect to the network.  This should be a pretty good start at preventing someone from walking into your office and getting their own computer to start stealing stuff.  Or perhaps to prevent corporate users from connecting their personal laptops riddled with malware to the corporate network.  Sounds great on the proverbial paper.

With Bring Your Own Device smartphones and tablets and Bring Your Own Computer becoming very popular client computing models, NAC is starting to become popular again.  Because users are administrating their devices we want these users to have limited access to corporate resources.

The reason many NAC deployments fail is because rather than permitting everyone and everything into the network by default, everyone is blocked by default and privileges are elevated after some interrogation.

Classic example.  We create a policy that denies users to the network for something like they do not successfully authenticate or their anti-malware software is not present.  The C level staffer connects to the network after their password has expired or they decide to bring in their Macbook Air that doesn’t have anti-malware because they are too secure </sarcasm> that day and the project is over.

What we have found to be successful is to implement a somewhat more permissive approach.  There needs to be at least two networks configured.

  1. Full Access – This is the VLAN you probably already have configured in the network today.  When a user gets an IP address in this network they can get to the Internet, any internal servers, and also communicate with other client computers (right or wrong).
  2. Restricted Access – This network will be used to provide limited access to those users, identified through NAC, to not be up to standard.  The recommendation is to provide Internet access for TCP 80 and 443.  If a user attempts to connect to any other web services internally they should be redirected to a portal letting them know that they failed the NAC test and that they are being treated like a remote user until they remediate the issue (enable anti-malware, firewall, etc).

To get started with NAC it is recommended to give it a whirl first.  Most environments have the equipment it takes already in their environments to do this.  In this example we will configure 802.1x supplicants on our corporate provisioned laptops and authenticate them to RADIUS running on our Microsoft AD server via the switches.  

Testing a deployment like this with switch ports in a meeting room is usually acceptable.

  1. Decide who the groups of users are (FTE, Contractors, Manufacturing, Stores, Guests).  Each group may have a different level of access which will need to be defined by a new network/VLAN.  This is more of a policy conversation.
  2. Decide the levels of access.  For example if a user is authenticated they will be granted access to all services into the internal server network except for RDP and SSH, and HTTP/HTTPS and DNS out to the Internet.  Non authenticated users will only be granted the Internet access.
  3. Configure the VLANs and access control firewall rules associated with them on the firewalls.  Where this gets done in the network may vary from network to network.  Best practice would be to route all of these networks to the firewall.  This allows us to centrally control access from one network to another internally and externally.
  4. Create the VLANs on a test switch.  From here you can assign the VLAN to a specific port and make sure that the proper access controls are effective, then move on.  For example assign the full access VLAN to the port and make sure you can connect and access the specified resources.  Then apply the restricted access VLAN and make sure you can’t access any internal resources.
  5. Configure 802.1x on a test switch port.  802.1x is the protocol that allows you to authenticate users to the switch before allowing them to connect.  It is a seamless process once everything is configured and the user does not need to interact to supply their username or password.  For example if a domain user connects to the switch successfully they will be granted full access.  If a contractor or someone using their personal computer to connect they will be granted restricted access.,
  6. Enable 802.1x on the client device.  In order for your computers to connect seamlessly through 802.1x they will need to configure a supplicant on their computers or you can push this out as a GPO.  With NAC appliances this can be achieved by dropping a java or ActiveX applet on the client computer.
  7. Test authenticating with users.  With 802.1x enabled on the client device connect the computer to the network and check the switch to see that the full access VLAN is assigned to the switch port and that they can access resources normally.  Then disable 802.1x on the client so that it does not have authentication and make sure that the default restrictive VLAN is applied.  From here you can go more in depth and create users in different groups and change their access levels if required.

If you don’t get too many complaints after running meeting rooms and perhaps wireless networks like this your organization may be able to accept NAC.  From here you may want to investigate a commercial solution that will allow you to do more interrogation of the user and device they are using.  Perhaps you want to make sure that they have anti-malware running and up to date.  You may want to check that they are running a recent operating system that has less vulnerabilities than it’s legacy counterparts.  Most commercial NAC solutions allow you to check almost anything that is happening on a client computer and make decisions of how much access to give depending on what it finds.

*** This is a Security Bloggers Network syndicated blog from Insecurity authored by asdfasdfasdfasdf. Read the original post at: