We’ve talked about security in previous posts. We’ve also talked about SMB, Large File Copies and a number of other networking-related issues. Today we’re going to talk about Network Access Protection (NAP) and its role in the enterprise. Now, I know you’re probably asking yourself why we’re going on Networking safari, instead of sticking to topics that seem to be Performance related. The simple answer is that you need to understand NAP and its role as it relates to Terminal Server Gateway …
So what exactly is NAP? NAP provides components and an API to help enforce health compliance for systems connected to the network. Most IT administrators have been exposed to managed anti-virus solutions where a central server pushes out new anti-virus signatures. Or perhaps you’ve been exposed to SUS / WSUS or another hot fix management system that allows you to deploy patches from a central location via the Automatic Updates service built into the operating system. You might have some experience managing the Windows Firewall through group policy and ensuring that the firewall is correctly configured to prevent wide open access to the system or the network. The problem in the past is that these are all disparate systems with their own back-end servers, management tools and reporting. Enter NAP. Using NAP, you can create solutions to validate that systems connected to your corporate network comply with your IT policies. With a NAP infrastructure, the following benefits are available:
- Configure system health requirements for NAP-capable systems
- Specify access enforcement behaviors, including monitoring of the access and communications attempts and recording them for ongoing / forensic analysis
- NAP-capable systems can update themselves to become compliant (when they initially connect to the network) and then they can download updates / change settings to remain compliant
If you’re an IT Administrator who is responsible for environment and system health, and you haven’t heard about NAP then I daresay you’re probably turning cartwheels! A quick caveat though – NAP isn’t designed to protect the network from malicious users. In other words, if a system connecting to the network is completely up to date with the correct patches and configuration settings based on the NAP policy settings then the machine will be granted the appropriate access to the network. NAP also will not prevent an authorized user using a NAP-compliant system from uploading a malicious program or engaging in inappropriate behavior. NAP is not an Anti-virus or Anti-Spyware product. It is used to ensure that systems connecting to the network meet the criteria for systems allowed to connect to the network – and if they do not meet the criteria then they are placed in a limited access mode (or possibly even denied access) until they are compliant.
So before wrapping up, let’s quickly recap the key aspects of NAP and a couple of typical NAP scenarios, beginning with Health State Validation. When a computer connects to the network its health state is checked against the health requirement policies. Administrators can not only configure the policy to grant access if the system is compliant, they can define what actions to take if a system is not compliant. Those actions could include mandating updated patches and settings, limiting access by placing the machine in a remediation group where the client has enough access to get to the resources needed to get the system compliant – or even denying access to the network completely until the system is updated. Administrators can help ensure compliance by configuring settings to automatically update non-compliant systems using management products such as Microsoft Systems Management Server (SMS) or Microsoft System Center Configuration Manager (SCCM) 2007.
So what might some common NAP scenarios be? Obviously if you have users with laptops, when they are on the road, their systems might not get updated as frequently as a desktop system in the office that is "always" connected to the corporate network. You want to ensure that whenever they connect in to the corporate network, either when they are in the office or connecting remotely via VPN, that their systems meet corporate compliance standards. Using NAP, you can configure the policy to conduct an anti-virus scan when the systems connect to guard against the risk of the system having gotten infected when connected to unprotected networks (such as the Internet!) I already mentioned desktop systems – even though they generally tend to be static in terms of location, they must still pass compliance checks when connecting to the local network – for example after a reboot. Patches and configuration settings still have to be applied to these systems. Going back to laptops for a second – think about whenever you have visitors to your environment who want to fire up their laptops and connect to your corporate network to get connected to the Internet and then back to their company. These laptops might not be compliant with your corporate security standards, and you could configure NAP for visitor machines to only have Internet access. Obviously since these systems do not belong to your company it would be inappropriate to "force" patches and configuration changes to be applied on these systems. Finally – think about those users who use their own personal machines to connect to your company’s network via VPN. These systems do not belong to your Active Directory environment, the administrators have no physical access to the machine and it can sometimes be difficult to enforce compliance in terms of keeping Anti-virus software up to date, ensuring patches are installed etc – after all, you don’t own the machine! However, using NAP, you can enforce compliance by limiting the access of these systems to a restricted network until they meet the system health requirements! They may not be your systems, but it is your network!
With that, it’s time to wrap up this post. In the next post, I’ll briefly cover the different components of NAP. Until next time …