NAC up your Alley! – NAC Appliance
Tags: Network Admission Control (NAC)
To refresh everyone’s memory, my last few posts have been discussing the Network Admission Control (NAC) Appliance and Framework. So where does this thing called NAC Appliance fit in? Is this technology right for you? Are you ready for NAC? Here is an introduction to the Cisco NAC Appliance and how it differs from the NAC Framework we discussed in those earlier posts.
In October of 2004, Cisco acquired a company called Perfigo. Perfigo was originally responsible for creating the now-known-as NAC Appliances that we’ve grown to love (or hate). Back then, they were known as Clean Access Appliances. When Cisco got a hold of the product they rightfully re-named the product Network Admission Control (NAC) Appliance.
The product has grown over time. If you have been following Cisco for a while you kind of get a feel for how acquisitions turn out. They seem to first acquire an organization, then remove the acquired companies’ label and replace it with their own. After that, they seem to sit on the product for a little while making minor modifications until finally one day, it becomes “Cisco-ized”. This means the product is truly enhanced to meet the expectations that Cisco seems to have met time after time again. We’ll get into that later, but for now we’ll keep our discussion focused on the technology.
Think about the acronym I mentioned earlier, NAC, and you’re probably thinking about virus or worm mitigation as a lot of people do. Many organizations pursue NAC as a method to mitigate viral attacks on their networks. The thing that a lot of people don’t realize is that we are not really looking for viruses or worms with Cisco NAC Appliance. What can be done are two basic requirements before entering into a network fitted with NAC Appliance: Authentication and Authorization (aka Compliance). I’ll on focus in here on the authentication piece, and we’ll move onto compliance checking in my next entry.
Authentication not only provides us with a means to determine who is on the network, it also provides us with a means to determine ones’ access once on the network. Now don’t get your hopes up, there are limitations that I’ll get back to later in our discussion. With authentication we are basically intercepting any network packets sourced from hosts and forcing that source to go through authentication. This helps prevent rogue devices from getting on the network.
Some people wonder how the authentication takes place. Basically, when a host is added to the network it will get its’ DHCP address from the server it currently does. After that, a packet is sent from the host to the internal network. This can be in terms of someone opening Outlook or just the operating system trying to contact the internet for updates. Once the packets are intercepted by the NAC Appliance, a trigger process begins. The Appliance tries to communicate with the host by means of an agent loaded locally on the host called the NAA (NAC Appliance Agent). If the NAA is present, then the Appliance will validate the users’ credentials that they logged onto their PC with.
(When I teach, some of my students from very large organizations come to class wondering how to get devices that cannot possess the NAA to have VLANs and traffic policies assigned to them as well. The easy answer for now is that it can be done by use of device filters — but more on that later.)
If the NAA is not present, the user will be redirected to the NAC Appliance when they open their browser. This redirection brings up a completely customizable webpage that will authenticate the user to whatever backend server you wish, including Windows NT (straight active directory), LDAP, RADIUS and a few others, but these seem to be the most popular. And so there it begins. Everything the user does from here is tied to their credentials; including the NAC Role, VLAN assignment, traffic ACL policies, and the almighty posture validation requirements.
Author: Jim Thomas