In this installment of the TechRepublic series on Microsoft Network Access Protection, Rick Vanover discusses the Vista client configuration in detail. Here we will go through an example enabling a NAP configuration on a Vista client and discuss the configuration requirement considerations for using Vista in the enterprise.
The main idea behind having Network Access Protection on your network in the first place is to ensure that client workstations are properly configured from a security standpoint for your network. To make this work, you not only need to set policies on your server, but you also have to configure clients properly as well. In this article, you'll learn how to enable NAP on client workstations.
Available clients for MS-NAP
Microsoft NAP is natively available on Windows Vista and is planned to be available for Windows XP systems with the release of Service Pack 3. Service Pack 3 for Windows XP will include the NAP client. The MS-NAP documentation specifically mentions Windows XP Service Pack 3, but it is unclear when it will be made available for download. At the time of this writing, most information is pointing to the first half of 2008 for the release of XP SP3. This would continue the trend of service packs for the Windows operating system including new features and functionality.
The MS-NAP implementation can also apply to servers running Windows Server 2008. There is no mention in the materials available currently for Windows Server 2003 being able to be managed by MS-NAP like Windows XP will be with the forthcoming Service Pack 3. The Windows Server 2008 configuration elements would be the same as those for Windows XP. We'll frequently refer to a Vista client, but that client could also refer to Windows Server 2008.
Client considerations for running MS-NAP
Any NAP implementation, whether it's a Microsoft or a networking solution, has some implications. With the potential for increased security comes a possible increase in workload to a client support staff. When a system is non-compliant, it may not always be entirely intuitive for the user to determine what needs to happen for compliance to occur to enter the network.
The criteria for access are set server-side in the Security Health Validator within the Network Policy Server. Here are the basic criteria for access to be granted or denied with the MS-NAP implementation:
- Service Pack Level: Basic level of updates and service packs for the Windows operating system.
- Anti-Virus Status: Checks to see if an anti-virus program is running and can also check for it to be up-to-date.
- Antispyware Program: Checks to see if an antispyware program is running and can also check for being up-to-date. This compliance measure is only available for Vista clients.
- Automatic Updates Enabled: Checks to see if the Automatic Updates are enabled on the client.
- Update Quarantine: For environments with WSUS available, a system s health status can be determined based on the completeness of installed updates by category (Critical Only, Important And Above, Moderate And Above, Low And Above, or All Updates).
- IPSec Enforcement: IPSec policies can be applied to clients for end-to-end connections, and is applied locally on the system.
Configuration changes to Vista to enable MS-NAP
To enable MS-NAP on a Vista client, there are a number of required steps to do. This may not appeal to all environments, as the MS-NAP implementation is not entirely a server-side solution, but a combination of server roles and client configuration. Note that if there is NAP enforcement on the network from Windows, Vista clients without the correct configuration and all other systems will not be able to access the network.
To enable MS-NAP on Windows Vista, there are a few main steps which we will explain individually for this example. Be aware that different MS-NAP enforcement methods (or enforcement clients) require different configuration on the client. Here is how you enable the DHCP enforcement method:
Enable the Network Access Protection Agent Service
Default installations of Windows Vista have this service disabled by default. This is easy enough to enable, but the default domain policy if running as Windows Server 2003 for the Active Directory domain does not allow a domain or OU-based GPO to control the behavior of the service. This can be done easily enough through other mechanisms using Group Policy, but not natively in the services applet of the linked object.
Enable Security Center (domain systems only)
The Security Center will need to be enabled in the local group policy. Again, this can be done through a linked GPO through a Windows Server 2008 domain, but not natively through a Windows Server 2003 domain. Enabling Security Center is located at: Local Computer Policy | Computer Configuration | Administrative Templates | Windows Components | Security Center in the local policy on a Vista system.
Enable DHCP enforcement
Vista introduces the DHCP enforcement client, accessible from the napclcfg MMC Snap-In. This is enabled by going into the snap-in and adding the role for enforcement on the local system s DHCP configuration, as shown in Figure A.
When these three configurations are in place, the NAP client can be checked against the server s compliance policy to determine if access should be granted.
Note that if a system that is not MS-NAP enabled attempts to connect to a NAP-enabled domain, there will be no access at all granted. All DHCP requests will timeout or use automatic addressing, depending on configuration. This applies for Windows 2000, NT, and non-Windows systems that attempt to gain an address from a DHCP scope enforced with the MS-NAP implementation.
A configuration example
For the purposes of this article, let's assume we have created the following systems in a test network configuration:
OS and configuration
Windows Server 2003 Std.
Member Server, NAP roles server, DHCP Server (IPv4)
Windows Server 2008, Beta 3
Windows XP Service Pack 2
Using the client
After the configuration requirements have been met on the Vista client, you can now proceed to using the MS-NAP enabled client. From this point, the networking is transparent to the normal client operations unless the Vista client is deemed non-compliant. In this example, when the NPS policy was configure on WS2K8, the system was not provided a TCP/IP address from the DHCP server. For a client system that is not compliant, there is a log entry on the WS2K8 server stating the reason:
User <not present> was denied access.
Fully-Qualified-User-Name = <undetermined>
Machine-Name = CLIENT2
OS-Version = <not present>
NAS-IP-Address = 192.168.1.8
NAS-IPv6-Address = <not present>
NAS-Identifier = WS2K8
Called-Station-Identifier = 192.168.1.0
Calling-Station-Identifier = 000C29D7D7D7
Client-Friendly-Name = <not present>
Client-IP-Address = <not present>
Client-IPv6-Address = <not present>
NAS-Port-Type = Ethernet
NAS-Port = <not present>
Connection-Request-Policy-Name = Use Windows authentication for all users
Policy-Name = <undetermined>
Authentication-Provider = Windows
Authentication-Server = WS2K8.WS2K3DEV.LOCAL
Authentication-Type = Unauthenticated
EAP-Type = <undetermined>
Reason-Code = 48
Reason = The connection attempt did not match any remote access policy.
In this case, the system was not a supported operating system (Windows Vista, Windows Server 2008, or Windows XP Service Pack 3), was not permitted to advance onto the network based on the configuration for the NPS policy, and no addressing was assigned, not even on the remediation segment.
CLIENT1, the Vista client, is placed in the remediation configuration due to not meeting the compliance policy. The message shown in Figure B is displayed on the Vista client.
The client is placed into a limited networking configuration from our MS-NAP policy set forth in the server piece of the series. When an IPCONFIG command is run, notice the DNS naming for the client, shown in Figure C.
When in the remediation configuration for a non-compliant situation, the client based on this configuration cannot ping anything other than the remediation host. Other devices on the network are isolated locally, and the errors displayed in Figure D are given to these attempts in a ping.
The specified remediation hosts (that would have the anti-virus package available) are accessible from CLIENT1, however. From there, the user could use a self-guided update, or automated mechanisms (SMS, WSUS, Group Policy, Internet Updates, etc.) to get the system compliant for correct access to the network. This is where good planning will make the MS-NAP implementation smoother.
Look before you leap
You can see how the MS-NAP client works with the Vista client. The Windows XP client is not yet available since Windows XP Service Pack 3 is not yet available. Carefully consider your client environment when evaluating the MS-NAP implementation; having to support the clients that do not pass the policy may be a burden to system support staff. The MS-NAP implementation is complex and thorough, so be sure the client aspect is not overlooked from a support and implementation perspective.