Tuesday, June 11, 2013

Windows 2012 NAP (NPS) with DHCP

After my
last article on DHCP I decided to flesh out the Microsoft offerings
and expand into Network Policy Server.
NPS is actually a set of different features from Microsoft including RADIUS
and what the rest of the industry knows as NAC,
(Network Access Control) which Microsoft calls NAP
(Network Access Protection). This allows you to grant or deny network access
to clients based on criteria such as:

Domain/Group Membership

Client source network

Time of day

Client health (as determined by an SHV, see below for more)

3 out of 4 Doctors
are very serious about Microsoft NAP.

These rules must be introduced to the clients at an insertion point (think
of it as an entry gate). The supported insertion points include:

IPSec

802.1X

VPN

DHCP

RDGateway

I'll be covering integration with DHCP since it is by far the most cost
effective method considering the required role of Microsoft based services
in the environment. For information on the others, see Technet:
NAP Enforcement Points.First, let's set up NAP:

Assumptions

At least one Windows 2012 server ready to go. Note that NPS is not
supported on server core. Most of these instructions are
applicable to 2008/r2 as well.

I assume you'll be installing NAP on the DHCP server itself. You can
have these roles on separate servers should you desire, but you'll need
to install the NAP piece on the DHCP server as a RADIUS proxy. I won't
be covering that piece here. For more on that, see this
Technet article.

Installing NAP

Using server manager, select "Manage"->"Add Roles or
Features"

Navigate through the Add Roles and Features Wizard, selecting the
target server and "Network Policy and Access Services".

When prompted to select role services, you need keep only the default
"Network Policy Server" selected and continue through the wizard.

Repeat this step for the DHCP server as well if it's a different server
than the one you installed NAP on.

Configuring NAP

The NAC portion of NAP is actually a collection of several different
elements. The following elements make up a NAP policy that can be used by
DHCP; numbers in front represent the default number of that item for one
overall policy:

Connection Request Policy (Created by Wizard)

(3) Network Policies (Created by Wizard)

(2) Health Policies (Created by Wizard)

Windows Security Health Validator

At least one Remediation Server Group

There is a (seemingly hidden) wizard to guide you through the process of
creating most of these elements, but we're going to create the unguided
ones first and then circle back and use the Wizard since we'll want to
point to those during the Wizard portion. For all these sections save the
DHCP and client sections we'll be working in the Network Policy Server
management tool.

Windows Security Health Validator

The Security Health Validator is the policy for defining what a healthy
windows client is. The built-in Windows SHV gives the NAP server the
capability to interact with the Network Access Protection Agent service on
Windows clients (XP SP3 and newer) to determine the health status of that
given client. The Security Health Validator determines what criteria the
client must pass for the client to be considered healthy. There is a
default configuration that can be utilized but for the sake of experience
we'll configure the Windows SHV. To do so:

Give the SHV a name; make it something meaningful to describe the
target client base, i.e. "Standard Client Set"

Set your settings as desired; they're split into settings for Windows
XP and Vista or higher. The settings are quite straightforward though it
should be noted that if you would like to utilize WSUS to update out of
compliance clients (assuming you select being out of date makes for a
failed check) you'll need to check the box on the very bottom of the
options dialog. Click "OK" when complete.

Click on the "Error Codes" under "Settings" and take note of
the Error Code Configurations. Generally the default state of
"Noncompliant" for each setting is desirable, but depending on your
clients and equipment there may be situations where you would want to
change some of these SHV check failures to compliant.

Note that third parties can also create SHVs to plugin to the NAP
architecture for use with other products. (Old list of some others here)

Remediation Server Groups

The remediation server groups are the servers that will be made
accessible to non-compliant clients if you choose to do so. These servers
can be used to patch clients to a compliant status. Note that any services
needed to contact the remediation services (WSUS, Antivir FTP, etc.) need
to be available for the clients to update properly. (DNS, etc.) Under the
DHCP enforcement model, these servers are made available via static
routes. Also note that you can provide a help URL to a website instructing
access-limited clients on how to repair their machines. The server that
hosts this URL and all resources required to resolve it must be part of
the remediation server group as well. For more information about RSGs, see
Technet:
Planning the Placement of a NAP Remediation Server. Assuming you
have determined which servers need be part of the remediation group, let's
set them up:

Expand "Network Access Protection"->"Remediation
Server Groups"

Right Click->"New" (Note that these can be stored as
templates for use elsewhere as well)

Give the group a meaningful name; note that each health policy can use
only one group, so everything for that client base will need be in that
group. Something like "Sitename Remediation Group"

Click the "Add" button to add a server.

Enter a friendly name for this server, i.e. "Minneapolis WSUS 01"
or just the server name and then enter the DNS name and click "Resolve".
Hit "OK" when complete.

Repeat steps 4 and 5 for each server in this group. Then hit "OK"
on the "New Remediation Server Group" page.

Select "Dynamic Host Configuration Protocol(DHCP)"
under "Network Connection Method". Note this is where you would select a
different option should you want to use a different insertion point. If
you wish to enable this policy on only specific scopes then
give the policy a name, I.E. "Minneapolis NAP DHCP". If
you wish this policy to be effective on all scopes do not
change it from the default name. Click "Next".

On the next screen, clickadd if the DHCP server is not on
the same server as the main NAP server. If that is the case, enter a
Friendly Name, Address, and Shared Secret and click "OK". If not, no
action is necessary. After this is complete, click "Next".

On the next screen, "Specify DHCP Scopes", we need only add scopes if
we want this policy to apply to a specific set of scopes. If we do not
specify any scopes it will apply to all NAP enabled scopes. Either add
the name of all specific scopes to which this policy will apply or just
click "Next" with the scopes empty to have it apply to all.

The "Configure Machine Groups" screen, like the previous DHCP Scopes
screen, is only for limiting access to a set of computers. Should you
choose, specify the group(s) of computers you would like to receive IP
addresses. In most cases you should leave this blank, but in the event
you would restrict via group click "Add" and enter the groups you would
like to have access. Click "Next" when you are done with this
screen.

On the next "Specify a NAP Remediation Server Group and URL" screen
select the server remediation group we created earlier. If you would
like the clients to have access to a web site describing how to
re-mediate their machines enter that under "Troubleshooting URL". Note
you must setup this site, it is not included with NAP since the
instructions will be different depending on your software selection.
After entering the required information, click "Next".

"Define NAP Health Policy" is the final screen. You should see
the "Windows Security Health Validator" selected and you can go ahead
and enable auto-remediation of client computers with the
applicable check box. I'll address this a bit more in closing.

As for "Network access restrictions for NAP-ineligible client
computers", select whichever you prefer. In most cases if you've
bothered to come this far you'll be selecting to deny full network
access since that's usually the point. Click "Next".

You will be presented with a summary screen; review the information
and click "Finish".

Configure Clients

We need to configure two important elements to make the clients
functional: Enable the service and configure it to enforce via DHCP. To
accomplish that, we'll use group policy. You will need to ensure your
group policy objects are targeted appropriately via something like OU
linking or security filtering. If you need more information on how to
target group policy objects, see this
link. Also note that according to some Microsoft documentation, the
Wired and/or Wireless Autoconfig services need to be set to automatic, but
in my testing they worked when set to manual. Keep that in mind if you
have issues.

Edit the group policy object you plan to use for NAP client
enforcement using the Group Policy Management tool.

Provided you're ready, take any steps necessary to apply the GPO to
the desired clients. (Link, etc.)

Enable in DHCP

You can either enable globally or on a per-scope basis. I will give the
instructions on how to enable globally. If you want to enable on a
per-scope basis substitute right-clicking on the "IPv4" below with the
scope(s) you desire instead. In that case, you'll need to specify the
custom name of the policy you created in step 3 above.

Open the DHCP Manager and point it at the server in question.

Right click "IPv4" and click "Properties"

Click "Network Access Protection"

Select what you would like to happen should the NAP server become
unavailable, then click "Enable on all scopes".

You will be notified that your NAP settings will be overridden on all
scopes. Assuming this is what you would like to do, click "Yes".

Click "OK".

If you're using a 2012 failover/loadbalance configuration the NAP
settings will replicate for each scope, but make sure communication to the
NAP server is configured correctly for each DHCP server. That connection
information is not replicated. Here is additional info should you need it:
Technet: Configure
a DHCP Server for NAP. No restart of anything is needed; you should
be using NAP now!

Usage Notes/Troubleshooting

If using a custom profile name for a specific scope, you'll need to
provide the custom profile name. This name is the name of the connection
request policy you would like to use. For more info see: Configuring
Custom NPS Policies Per DHCP scope

The event log location relevant to NPS authentication is in the
security log with the task category of "Network Policy Server". A
filtered view of this can be found under "Custom Views->Server
Roles->Network Policy and Access Server".

Know that this solution won't keep out anyone trying to infiltrate
your network; anyone with a moderate amount of savvy can take steps to
determine what IP to assign themselves should they have physical access
to your network.

You can add several other types of criteria to your policy should you
desire. Take a look at your policies under NPS->Policies->Network
Policies for more options.

If you enabled auto-remediation, clients will try to repair themselves
for simple issues. For example: if a client's firewall is off and the
policy requires it, the client will re-enable the firewall and attempt
to pass the health check again. Should this fail manual intervention
will be necessary. For more information on how to troubleshoot the
client, see "Configure
NAP Tracing" on Technet.

Make sure you monitor the load on your NPS servers; the last thing you
want is for them to get overwhelmed and prevent proper servicing of DHCP
requests. There are some performance counters that can help you with
this task; for more info see Technet:
Load Balancing with NPS Proxy. Also, be sure to read up on Technet:
Best Practices for NPS which covers performance as
well as other important info.

For some information regarding how to use Powershell to
configure/manipulate NPS, see my
post here.

Prologue

Obviously we're just scratching the surface here; there is quite a bit
more that we could dig into but I'm going to stop here in the interest of
time. NAC solutions aren't particularly popular right now in a regular office
scenario, but as issues continue to arise with malware, etc. more
companies may determine these sorts of solutions are necessary. If you
already have a Microsoft based infrastructure you probably have nearly
everything you need to implement this solution. If you have
questions/concerns/comments please feel free to comment. Thanks!