NAC deployments often require more integration than seen at first blush. Especially when the NAC products don't meet with expectations. Take user login/log-offs that were a problem I mentioned in my review of ConSentry's product. There are ways to mitigate problems or bolster your NAC deployments using features you already have.
The issue is that the LANShield Controller, their in-line NAC appliance, didn't detect log-offs properly and that means its simple for one user to impersonate another because the attacker is already local to the network and can easily pull a cable from a wall or PC to jack-in. ConSentry did say it is addressing this issue in a future release, but what can you do in the meantime?
First off, if you're using Windows in an Active Directory environment, and who isn't, the first thing you can do is disable login caching in AD???s Group Policy Object. By default, the workstation will cache the last 10 logins. The benefit is if a workstation can't access the Directory, the user can still login to the workstation and be productive. Or an attacker could just pull the network cable, login using AD account that had been cached, re-connect the cable, and get access to the network as the previous user. If you disable login caching by setting cached logins to zero and don't allow logins using local accounts, then if the Directory isn't available, the user can't login over the network. The downside is if the user can't login, they can't work, so you need to ensure you have a fault tolerant AD deployment or just bite the bullet. At any rate, doing so at least stops one avenue of attack.
Setting cached logins to zero on laptops won't work, however. Windows simply doesn't handle multiple user accounts gracefully (or at least I haven't found a way that it does), so if your laptops are set to zero login caches, users won't be mobile. Besides, another way to by-pass ConSentry's solution is to simply yank the cable from the workstation and replace the MAC and IP address in another workstation. We may be able to look to the network for a potential solution using features in switches that generally called IP locking which maps an IP address and MAC to a switch port and defeat moving addresses arbitrarily. Now, I haven't tested this yet, but I plan to ferret the efficacy of this proposed solution and the gotchas.
DHCP is an easy one to handle. Switches from Cisco, Extreme, and HP, to name a few, support DHCP assignment enforcement. The switches snoop on the DHCP handshake and map the offered IP address to a MAC address and a port. If the IP address shows up on another switch port, all traffic should be rejected from it. Also, when the switch port becomes inactive from a host being pulled from it, the IP address mapping is removed. Those two functions promise to thwart physical impersonation. In some cursory testing, I found that at least Windows hosts, when they lose the physical connection, will re-run DHCP when it is reconnected. I haven't explored all the various situations or other OS's. If you have experience with these features, I would love to hear about them. E-mail or post a response.
That's great for DHCP, but what about hosts with static IP addresses? Yeah, this is where IP address management gets a bit more difficult. You could statically map IP addresses to ports, but if you're in an organization of any size, static mapping becomes an awful lot of work. I don't have an answer there (do you?) except to suggest moving your workstations to DHCP or just deploy 802.1X. Generally speaking, with DJCP, hosts will continue to receive the same IP address over and over and you can statically map IP addresses to MAC addresses. That will reduce some of the management overhead once you get the static mapping rolled out.