Microsoft Windows Vista: Network Access Protection (NAP)

Microsoft's Network Access Protection (NAP) is built into the Windows Longhorn Server and Windows Vista client operating systems and expands upon the functionality of the Network Access Quarantine Control feature in Windows Server 2003. NAP allows you to monitor the health status of all computers that attempt to connect to your network--not just remote access clients--and ensure that they're compliant with your health policies. Noncompliant computers can be given access to a restricted network where you can place resources they can use to gain compliance. Here are 10 basic facts you need to know before deploying NAP on your network.

NAP is a supplemental feature:

NAP does not take the place of other network security mechanisms, such as firewalls, anti-malware programs, and intrusion detection systems. It does not in any way prevent unauthorized access to your network. Instead, it helps protect your network from attacks and malicious software that can be introduced by authorized users who connect to your network via unpatched, misconfigured, or unprotected computers.

NAP can be deployed in two modes-monitoring mode or isolation mode:

If you configure a monitoring policy, authorized users are given access to the network even if their computers are found noncompliant, but the noncompliant status is logged so that administrators can instruct the users to bring the computers into compliance. In isolation mode, noncompliant computers are given access only to the restricted network, where they can find resources to gain compliance.

You can select compliance criteria for the computers that connect to your network:

Compliance criteria include requirements for service packs and security updates, antivirus software, anti-spyware protection, firewalls, and Windows Automatic Updates. The criteria are configured on the System Health Validator (SHV) on the NAP server.

The NAP server must run Windows Longhorn Server:

The NAP server is a Network Policy Server (NPS). NPS is Longhorn's replacement for Internet Authentication? Service (IAS) in Windows Server 2003 and provides authentication and authorization. NAP services include the NAP Administration Server and the NAP Enforcement Server. The System Health Validator (SHV) runs on the server.

NAP requires that the client computers have NAP client software installed:

The NAP client is built into Windows Vista, and a NAP client for Windows XP is expected to be made available with the release of Windows Longhorn Server. The System Health Agent (SHA) runs on the client. If you have computers on the network running operating systems that don't support NAP, you can exempt them from the health status requirements by creating exceptions, so that those computers can still access the network. If no exceptions are made for them, non-NAP capable computers will have access to the restricted network only.

The SHA prepares a Statement of Health (SoH) based on the health status of the client computer:

The NAP software submits the SoH to the SHV. The SHV communicates with the Policy Server and determines whether the health status provided in the SoH meets the requirements of your health policy. If it does, the computer is allowed full access to the network. If not (in isolation mode), the computer is given access to the restricted network where it can download the updates or software needed to come into compliance. The computers on the restricted network that contain these resources are called remediation servers.

You can use health certificates to prove compliance:

In this case, you need a Longhorn server running Internet Information Services (IIS) and Certificate Services to act as a CA and issue the health certificates. This server is called the Health Registration Authority (HRA). The NAP client sends the SoH to the HRA, which sends it to the NPS server. The NPS server communicates with the Policy Server to find out if the SoH is valid. If it is, the HRA obtains a health certificate for the client, which can be used to initiate IPSec-based communications.

There are four types of NAP enforcement:

IPSec enforcement relies on the HRA and X.509 certificates. 802.1x enforcement relies on an EAPHost NAP enforcement client and is used for clients connecting through an 802.1x access point. (This can be a wireless access point or an Ethernet switch.) Restricted access profiles are placed on noncompliant clients using packet filters or VLAN identifiers to restrict them to the restricted network. VPN enforcement relies on VPN servers to enforce the health policy when a computer attempts to make a VPN connection to the network. DHCP enforcement relies on the DHCP servers to enforce the health policy when a computer leases or renews its IP address. You can use one, some, or all of the enforcement methods on a given network.

Only computers that connect to the network via one of the four enforcement methods will have their access restricted if they're noncompliant:

DHCP enforcement is the easiest to deploy and most comprehensive because most computers will need to lease IP addresses (all except those assigned static addresses), but IPSec enforcement is the strongest enforcement method. When a computer's access is restricted, it will still have access to the DNS and DHCP servers, as well as the remediation servers. You can, however, place secondary DNS servers or forwarding servers on the restricted network, rather than primary DNS servers.

NAP is different from Network Access Quarantine Control in Windows Server 2003:

NAP can be applied to all the systems on the network, not just remote access clients. With NAP, you can also monitor and control the health status of visiting laptops and even on-site desktop computers. It's also easier to deploy because it doesn't require the creation of custom scripts and manual configuration with command-line tools, as does NAQC. In addition, third-party software vendors can use the NAP APIs to create NAP-compatible health status validation and network access limitation components. NAP and NAQC can be used simultaneously, but generally NAP will serve as a replacement for NAQC.

User Account Control in Microsoft Windows Vista

Vista's User Account Control (UAC) protects against malware elevation of privileges, even when someone is logged on with an administrative account.
UAC is at the heart of Windows Vista's focus on security, but it is also one of Vista's most misunderstood new features. Love it or hate it, you'll need to learn more about it to balance security and user-friendliness in your Vista deployment. Let's take a look at 10 things you need to know about UAC before you roll out Vista, whether on an individual machine or throughout an organization.

UAC cuts the risk of logging on as an administrator:

It's a common problem: Users who have administrative accounts tend to log on with those accounts, even if they also have regular user accounts and realize that using a standard user account for routine tasks is a better security practice. It's just more convenient, and human nature puts a high priority on convenience.

With User Account Control, some of the risk of logging on as an admin is ameliorated because Vista performs most tasks with regular user privileges even when someone is logged on as an administrator.

The logon process has changed:

Although it appears the same to the user--you still enter your account name and password in the same way--the Vista logon process has changed under the hood. Now when you log on with an administrative account, you not only get an access token for that account, but you also get a standard user access token. The standard token is used to launch Explorer.exe, so all child processes will run with that token's privileges unless privileges are elevated by responding to a UAC prompt.

It's easier to tell which tasks require admin privileges:

Vista makes it easier to know which actions will require elevated privileges. Options in dialog boxes for which you must have administrative privileges are marked with a shield-shaped icon to indicate that if you select that option, you'll need to respond to the UAC prompt (or, if Group Policy is so configured, you may not be able to perform the operation at all when logged on as a standard user).

Administrator Approval Mode is the default:

By default, Vista runs with standard user privileges, even when you're logged on as an administrator. If a task requires administrative privileges, a dialog box asks for your permission to continue the action. This prevents malware from elevating privileges without your knowledge.

You can make it more secure:

You can change the behavior of UAC by editing Group Policy (the local security policy or domain policy). You can increase security by requiring that a user enter administrative credentials to elevate privileges, rather than just clicking the Continue button, even when already logged on as an administrator. Users logged on with standard user accounts will, by default, be prompted to enter administrative credentials when they try to perform a task that requires elevated privileges. In a domain environment, the default is to disallow the elevation of privileges. You can change these behaviors by editing Group Policy, too.

You can increase security even more:

By default, both signed and unsigned executable files will run with elevated privileges when you respond to the prompt. However, in a high security environment, this behavior can be changed by editing Group Policy so that Vista will elevate only executables that are signed and valid. When you enable this policy, Vista will check the executable's digital certificate whenever that application requests elevation of privileges.

You can make it less secure (but more convenient):

It's not recommended, but if you're in an environment that you're absolutely certain is free of malware, you can edit Group Policy to allow those logged on as administrators to perform tasks with elevated privileges without being required to respond to the UAC prompt. This essentially negates the extra security provided by UAC when logged on as an administrator and exposes the system to the same security threats that exist when you log on with an admin account in pre-Vista versions of Windows. However, it does do away with the sometimes annoying dialog boxes and makes it more convenient for admins who are, for example, installing a lot of software.

You can turn off UAC or the Secure Desktop:

When UAC prompts for permission to elevate privileges, the desktop is locked so that it can receive messages only from Windows processes. No other software can interact with the desktop at this time, and it goes dark to indicate this. By editing Group Policy, you can disable the Secure Desktop. The prompt will still pop up but will be displayed on the interactive desktop.

It's also possible (although not recommended) to turn off UAC completely. This is done by disabling the policy to Run All Administrators In Administrator Approval Mode.

Legacy applications may need to be marked:

Pre-Vista applications that were not written to be aware of UAC may have to be specially configured to work with Vista. If the programs need to perform tasks that require administrative privileges, you need to mark them with a requested execution level to prompt users for approval. This can be done with the Application Compatibility Toolkit, available as a free download from Microsoft. For more details, see TechNet's Windows Application Compatibility page.

UAC is not a substitute for other security measures:

UAC provides extra protection; for example, it makes it more difficult for malicious software to do harm. However, it's not a substitute for antivirus and anti-spyware programs, and you should still use a good, properly configured firewall. To be effective, security must be multi-layered, and UAC is only one element of a good client security plan.