PACUG‘s 2nd meeting. (Well, probably not their second meeting *ever*, but the second meeting since they started back up recently.) Phillip James gave a talk about Network Access Control, which I expected to be about things like 802.1x. Turns out I wasn’t reading the mail list closely enough – his talk was specifically about Cisco’s NAC appliance, including very detailed instructions on how to deploy it. He’s going to sanitize his slides a bit and pass them by the appropriate authorities & they should be publicly available next week.
Cisco’s NAC appliance (which is made up of several parts: a manager, a server, agents) sits in-line (usually; there are OOB options coming up) at various points on your network and controls who’s allowed to access which corporate resources. You can allow the same user different access permissions based on what type of system they’re on (eg Mac/Windows, *nix), who owns it (e.g., user’s personal equipment vs corporate), how they’re connecting (e.g., LAN, VPN), and the status of various applications on the machine (e.g., is their AV up-to-date). Licensing, of course, is dependent on the number of users & sites.
Four actions the NAC performs:
1. Identify the device & user
2. Enforce policies in a consistent manner (HR departments probably require consistent enforcement across all users in order for necessary disciplinary action to be taken)
3. Quarantine & Remediate non-compliant equipment
4. Configure & manage access policies
Steps to deployment (this is actually a useful checklist for *any* application deployment, IMO):
– gather your list of contacts. Phillip included an exhaustive list of all the contacts you need to have within the organization
– technical requirements analysis
– ops requirements analysis (eg, training, how many licenses)
– design phase
– lab testing (you have a lab, right?)
– field testing at select sites; rule of thumb is 10-15% of your final deployment
– production deployment
A good test plan:
– deploy it first as audit only. This gives you a baseline of compliance before you start enforcement. (And allows you to troubleshoot piece-by-piece instead of just dropping it all in there at once.)
– next: checks without enforcement. User is given a popup notification that they are out of compliance with whatever policy, and they have the option to correct the issue now or bypass it.
– once compliance is at an agreed-upon level (say, 85-90%), enable checks with enforcement. From my experience, if you wait for a level of compliance from users (esp if they’re given the option to bypass it), you’ll be waiting a loooooooong time. My preference would be to give them a cutoff date instead.
– make sure the test plan has an explicit definition of a “successful” test.
Phillip finished up with my favorite part of any presentation: War Stories. (He called them “Tips from the Field”.) One gotcha to consider is that tcpdump will only show traffic destined to the NAC appliance, not through it.
I would have liked to have heard a bit more about how the NAC actually operates – it sounds like the connection gets transferred around between different VLANS – one for authentication, then to a different one depending on the permissions granted to the user, which is pretty intriguing.
After the presentation, we had a short “general networking Q&A”. I should have come prepared with questions. (Maybe about monitoring Metro Ethernet connections.) A few Cisco SEs were present to answer questions.
Some items of interest to me:
Apparently there is a bug/feature in IPv6 reflexive ACLs. Good to know in advance.
VPN Tunnel issues: sometimes the tunnel will show as up, but is not passing traffic, and you have to bounce it (“clear crypto sa” IIRC). It would be nice to have a warning about this situation. Supposedly the interface should be flapping if this is going on, which should generate an SNMP trap. I need to look into that.