System Health
Those
clients subject to the policies of the NPS will report to the NPS using
their built-in NPS client. The NPS Client agent retrieves policies from
the NPS and evaluates the health of a system against the checks defined
in the policy encapsulating the results, known as a Statement of Health
(SoH). The SoH contains results from all the checks performed on the
system, and the NPS Client agent submits the SoH to the NPS. The NPS
receives the SoH and compares it against the NPS policies:
If the system appears compliant with the policies, it is allowed on the network.
If
deemed noncompliant, the system can be granted limited access to the
network, allowing for correction of any issues that caused it to be
considered noncompliant.
NPS policies, known as health policies,
are based on server-side components called System Health Validators.
These SHVs plug in to the NPS server and enable performing specific
checks on a client to validate its health. As an example, the built-in
Windows Security SHV defines checks for the status of the Windows
Firewall, existence of antivirus software, and other settings typically
associated with the Windows Security Center. Each check results in one
of two states: Pass or Fail. The status of a client as a whole may also
be reported in one of three different states:
Transitional—
This state indicates that the client is not ready to report its status.
In the ConfigMgr context, this could mean the client agent is not yet
enabled on the system.
Infected— This state is primarily used by antivirus SHVs and is not used by the ConfigMgr client.
Unknown— This is a catchall state often used to indicate client credential issues.
The
health policies define which SHVs to use and what conditions must be
met for a system to match a health policy. The following conditions are
possible in a health policy:
Client passes all SHV checks
Client fails all SHV checks
Client passes one or more SHV checks
Client fails one or more SHV checks
Client reported as transitional by one or more SHVs
Client reported as infected by one or more SHVs
Client reported as unknown by one or more SHVs
The
ConfigMgr SHV point implements the SHV that plugs in to an NPS. The
policies produced by this SHV instruct the NPS Client agent to compare
the exact patch status of a system against the applicable mandatory
updates configured in the NAP policies in the ConfigMgr console (Site
Database -> Computer Management -> Network Access Protection
-> Policies).
A
System Health Agent (SHA) is a component that plugs in to the NPS agent
on the client; each server-side SHV has a corresponding client-side
SHA. SHAs perform the actual checks on a system and produce the
Pass/Fail results that go into the client’s SoH.
The
ConfigMgr client implements the ConfigMgr SHA. This SHA performs the
actual comparison of the current update status on the client with the
mandatory deployments applicable to the system, adding the results to
the SoH for that system.
Client Compliance
The
ConfigMgr SHA first performs a series of nonconfigurable checks to
determine the compliance state of the client. These checks include the
following:
Is this a new client? If a new client has not downloaded the policies yet, the client is marked as compliant.
Are the site code and site ID invalid? If yes, the client is marked as Unknown.
Is the NAP Client agent disabled? If yes, the client is marked as compliant.
Is the SoH older than the “Date created must be after” date? If yes, mark the client as noncompliant.
If
any of these checks succeed, the status updates in the SoH and the
series of checks ceases. If the client makes it through these checks,
the SHA compares the configured NAP polices against the client. Each
NAP policy must define two things:
Updates—
This is the set of updates that, if applicable to a client system, must
be installed on that system for it to be marked as compliant. As an
example, if an update is not applicable to a client system because it
is for a different version of Windows, it is not considered. Update
status is based on the last successful software updates scan of the
system.
Effective Date—
This is the date when the updates defined in an NAP policy are
considered mandatory. If the updates in the policy are not installed on
a client system after this date, the system is considered noncompliant.
You
can configure multiple NAP policies, allowing for multiple sets of
updates and effective dates. These policies are not targeted in any way
and are applied to all systems equally. You can create an NAP policy in
one of two ways:
- Right-click
the Policies node (Site Database -> Computer Management ->
Network Access Protection -> Policies) in the ConfigMgr console and
select New. This action opens the New Policies Wizard displayed in Figure 2,
with two primary pages—one to choose updates, and one to set the
effective date for the policy. You can only choose updates from
Deployment Packages.
- Right-click
any single update or multiselected updates in the Update Repository, an
Update List, Deployment, or Deployment Package and then select
Properties from the context menu. This launches a Properties dialog box
with an NAP Evaluation tab, displayed in Figure 3.
Here, you can enable NAP evaluation and configure an effective date by
the selected updates. This creates a new NAP policy under the Policies
node, which you can later modify or delete.
Remediation
If
the ConfigMgr SHV deems a client system noncompliant, the system may be
placed in a quarantine status based on the Network Policy configuration
on the NPS server. In this quarantine status, the client system has
limited access to network resources. This limited network connectivity,
known as remediation, allows the client to correct conditions that caused it to be noncompliant.
With
ConfigMgr 2007, the remediation process is automatic—the client
automatically requests updates from ConfigMgr and installs them based
on the NAP policies. The only required configuration is to add specific
infrastructure servers to a remediation server group in the NPS. This
group identifies which servers are accessible by systems placed into
the quarantine status. You should add the following types of servers
that host critical network services into this group:
DNS servers for name resolution
Domain controllers for authentication and group policy
A global catalog server for locating Configuration Manager 2007 services
Do
not place Configuration Manager servers in the remediation server
group, because access to these systems is dynamically granted.
Tip: Utilizing Remediation to Protect Against Zero-Day Exploits
Although
the obvious purpose for remediation is to prevent systems from
accessing the network that are not patched up to a defined level, a
not-so-obvious purpose is to deploy updates for zero-day exploits. In
this case, you can use NAP to deploy updates by configuring a specific
NAP policy for the update and making it effective immediately. As
clients check in with your NPS infrastructure, they will immediately be
out of compliance and fall into remediation, and automatically install
the update. You must also ensure that the patch is available in a
deployment package in this scenario.
Although
it comes with some overhead in the form of the Windows Server 2008 NPS
role, NAP increases the security posture of your network greatly by
interrogating systems as they try to connect to the network and
enforcing a minimum patch level. It can also help you deploy updates
for those annoying (and upper-management attention-getting) zero-day
exploits.
