We’re happy to announce that Exam Ref 70-417: Upgrading Your Skills to MCSA Windows Server 2012 by JC Mackin, is now available for purchase.
Please refer to the table of contents from this previous post.
A sample from Chapter 7:
Configure a network policy server infrastructure
Network Access Protection (NAP), as you know, is a Windows Server feature that
enforces health requirements on client computers as they attempt to connect to a
company network. These health requirements can relate to the status of software updates,
of antivirus protection, of host firewall status, or of spyware protection. NAP was first introduced
in Windows Server 2008.
Although NAP doesn’t include any significant new features in Windows Server 2012, one
important new feature, System Health Validator (SHV) Multi-configuration, appeared in
Windows Server 2008 R2. This new feature falls within the one NAP objective listed for the
70-417 exam, Configure Network Access Protection.
Objectives in this chapter: Objective 7.1: Configure Network Access Protection
Objective 7.1: Configure Network Access Protection
NAP can be deployed in many different configurations, depending on whether it is enforced
through DHCP, VPNs, IPsec, or Remote Desktop Services Gateway, or 802.1x. If your knowledge
of NAP has become rusty since you earned your last certification, it’s important to
review how NAP enforcement is configured.
Most of NAP has remained the same since Windows Server 2008, but there is one new
feature in NAP that falls within the Configure Network Access Protection objective: SHV
Multi-configuration. For the 70-417 exam, you definitely need to know about this new
feature, but one small feature might not be sufficient to represent the entire Configure
Network Access Protection objective on the exam. For this reason, you might encounter one
or more questions about NAP configuration that are similar to the ones you saw when you
earned your Windows Server 2008 certification.
How NAP works
First, let’s review some basic NAP concepts. When a client computer first attempts to connect
to a network, its first point of contact could be a DHCP server, a VPN server, or another type
of device. In a NAP infrastructure, this first point of contact is configured as a NAP enforcement
point, and the NAP client is configured to report its system status (called a statement of
health or SoH) to this NAP enforcement point.
The NAP enforcement point uses the RADIUS protocol to forward the SoH and connection
request to a Network Policy Server (NPS). The NPS server uses connection request policies to
determine whether the client connection request will be processed by NAP. If evaluated by
NAP, the client request is next processed by network policies, which provide potential instructions
about whether to allow the connection, block the connection, or allow restricted access
only to a remediation server or set of servers. The instructions of only the first network policy
that matches the conditions of the connection request are followed.
Figure 7-1 shows an example of a simple NAP infrastructure.
Network policies usually include health policies as matching conditions. Health policies
determine whether a NAP client matches an indicated state of failing or passing a health
check according to an SHV. Windows Server includes one built-in SHV, Windows Security
Besides the network policies that assess the health compliance of NAP clients, an additional
network policy is normally included to match clients that are not NAP-capable. These
network policies include a condition named “NAP-Capable” whose value is configured as
“Computer is non NAP-capable.” (NAP-capable computers are ones that send an SoH.)
Network policies created to match non-NAP-capable clients may be configured either to
allow or block the connection request.
The following list further describes these components involved in NAP processing:
■ Connection request policies Rules that determine whether a connection request
will be processed by network policies
■ Network policies Rules that compare the health of connection requests to health
policy statements and accordingly allow access, block access, or allow remediated
access to those requests. Network policies include conditions and condition values
configured to match different types of clients. The Health Policy condition uses a
health policy check to match a client. The NAP-Capable condition matches clients
based on whether they have sent an SoH. The MS-Service class condition is used to
match particular DHCP scopes.
■ Health policy A statement of health compliance or noncompliance according to a
■ SHV A software component that performs a particular set of tests about the safety of
a client connection
■ Windows SHV The default SHV and only SHV built into Windows Server 2012
Figure 7-2 illustrates how these components could work together in a particular example
of NAP processing.
The procedures for configuring the various NAP enforcement types all differ from each
other, but they do share common steps. In general, you first configure the NAP server by
using the NAP Configuration Wizard. You use this wizard to specify the NAP enforcement
type you want to implement and to create the required connection request policies, network
policies, and health policies. After running the wizard, you create security groups for NAP and
configure Group Policy. For more information about implementing the various NAP enforcement
types, visit http://technet.microsoft.com/en-us/library/dd314175(v=ws.10).aspx.
Windows Server 2008 allowed you to configure just one set of health tests for each SHV.
As a result, an NPS server couldn’t typically adjust its health checks to suit different NAP
This limitation could sometimes present a problem. In some scenarios, you might prefer
to apply different health checks to different enforcement methods, computers, or users. For
example, you might want to require all VPN-connected computers to have their antivirus
software both enabled and up to date but require local DHCP-based connections to have
their antivirus software enabled only. To meet such a requirement in Windows Server 2008,
you usually needed to use two NPS servers.
In Windows Server 2008 R2 and Windows Server 2012, however, you can create multiple
configurations for each SHV. After you create configurations in addition to the default configuration,
you can specify which SHV configuration you want to use for a particular health
policy. Figure 7-3 shows an example of multiple configurations created for the built-in SHV,
Windows Security Health Validator.
In Windows Server 2008 R2 and Windows Server 2012, a Settings node appears in the
Network Policy Server console beneath the default Windows Security Health Validator (and
beneath any additional SHVs you have installed that are also compatible with multiple configurations).
When you select the Settings node, only the Default Configuration appears by
default. This configuration can’t be deleted or renamed.
Creating additional SHV configurations
To create an additional confi guration for an SHV, perform the following steps. (These steps
demonstrate the procedure using the built-in Windows Security Health Validator as the SHV.)
1. In the Network Policy Server console tree, navigate to Network Access Protection
\System Health Validators\Windows Security Health Validator\Settings.
2. Right-click Settings and then click New, as shown in Figure 7-4.
3. In the Configuration Friendly Name dialog box, type a name for the new configuration,
and then click OK.
4. In the Windows Security Health Validator window, shown in Figure 7-5, specify the
desired system health requirements for the configuration.
You can enable any of the following health checks:
■ A Firewall Is Enabled For All Network Connections If this check box is selected,
the client computer must have a firewall that is registered with Windows Security
Center and enabled for all network connections.
■ An Antivirus Application Is On If this check box is selected, the client computer
must have an antivirus application installed, registered with Windows Security
Center, and turned on.
■ Antivirus Is Up To Date If this check box is selected, the client computer can also
be checked to ensure that the antivirus signature fi le is up to date.
■ An Antispyware Application Is On If this check box is selected, the client
computer must have an antispyware application installed, registered with Windows
Security Center, and turned on.
■ Antispyware Is Up To Date If this check box is selected, the client computer can
also be checked to ensure that the antispyware signature fi le is up to date.
■ Automatic Updating Is Enabled If this check box is selected, the client computer
must be configured to check for updates from Windows Update. You can choose
whether to download and install them.
■ Security Update Settings Use this section to define health checks related to
security updates. If you select the option to restrict access for clients that do not
have all available security updates installed, clients will be designated as noncompliant
if they do not meet this requirement according to the criteria you specify. You
can specify the minimum severity level required for the updates and the minimum
number of hours allowed since the client has checked for security updates. You
can also require clients to use Windows Server Update Services (WSUS), Windows
Update, or both sources.