Network Access Protection (NAP) : NPS

See NAP at TechEd 2009

MS NAP Team — Tue, 12 May 2009 03:53:00 GMT

Hey NAP Fans!

If you are attending TechEd 2009 in Los Angeles this week, be sure to stop by the NAP booth in the Microsoft Technical Learning Center (TLC). It is a great opportunity to meet and speak with NAP team members and learn about some of the enhancements and new scenarios in Windows® 7 and Windows® Server 2008 R2.

Also there are at least two breakout sessions that would be useful for anyone interested in learning more about NAP deployments. Both are on Friday May 15th:

WSV206 Windows Clients and Windows Server 2008 NAP: Why They Are Better Together

Presenter: Jay Ferron

Fri 5/15 | 9:00 AM-10:15 AM | Room 502A

WSV305 Deploying NAP: Best Practices and Lessons Learned

Presenters: Venkatesh Gopalakrishnan, Lambert Green

Fri 5/15 | 2:45 PM-4:00 PM | Room 403B

Hope to see you there,

The NAP Team

Example of using the new NPS templates feature in Windows Server 2008 R2

MS NAP Team — Thu, 26 Feb 2009 23:16:00 GMT

In a previous NAP blog entry, we described the new NPS templates feature in Windows Server 2008 R2. In this blog entry, we show an example of using a template for a RADIUS shared secret.

Templates for RADIUS shared secrets allow users to specify a shared secret that can be reused when configuring RADIUS clients and remote RADIUS servers in the Network Policy Server snap-in. To create and use a RADIUS shared secret template, do the following:

1. From the Network Policy Server snap-in, open the Templates Management node.

2. In the console tree, right-click Shared Secrets, and then click New.

3. In Template Name, type a name for the shared secret template, and then either manually specify the shared secret or have NPS automatically generate one.

4. Click OK to save changes.

To use the RADIUS shared secret template, configure a RADIUS client, a remote RADIUS server, or a remote RADIUS server template and specify the template name for the shared secret, rather than manually configuring a shared secret or having NPS generate one. The following figure shows an example.

To view which RADIUS clients, remote RADIUS servers, and remote RADIUS server templates use a specific RADIUS shared secret template, right click the name of the RADIUS shared secret template, and then click View Usage.

NAP Product Team

NPS templates in Windows Server 2008 R2

MS NAP Team — Tue, 17 Feb 2009 21:45:00 GMT

NPS templates, the flagship feature of NPS in Windows Server 2008 R2, provides a huge reduction in cost of ownership and deployment for all NPS environments. NPS templates separate common RADIUS configuration elements such as RADIUS shared secrets and RADIUS clients from the configuration running on the server. When referenced, the NPS setting inherits the values configured in the specified template. A change in the template changes the corresponding value in all of the places in which the template is referenced. For example, a single RADIUS shared secret template can be referenced for multiple RADIUS clients and remote RADIUS servers. When you change the RADIUS shared secret template, the change is inherited by all of the RADIUS clients and remote RADIUS servers in which that RADIUS shared secret template is referenced.

You can also use NPS templates to assist in configuration with referencing them. For example, you can create a RADIUS client template that contains common settings (such as the vendor type or shared secret) for a specific group of RADIUS clients (such as all wireless APs from a specific vendor). When you create a new RADIUS client, you can select the RADIUS client template to obtain the common settings. When you unselect the template, the inherited settings remain and you can configure individual settings, such as the RADIUS client’s IP address.

Note Template settings are not supported by commands in the netsh nps context. Using netsh nps commands will remove the reference to the template and change the configuration element specified in the command.

NPS template settings can also be easily migrated and synchronized across multiple NPS servers.

The following types of configuration elements use templates:

· RADIUS shared secret

· RADIUS clients

· Remote RADIUS servers

· IP filters

· Health policies

· Remediation server groups

You can configure templates for these configuration elements from the Templates Management node of the Network Policy Server snap-in. The following figure shows an example.

For a larger version of this figure, click here.

Individual templates can be added, edited, duplicated, or deleted. After they are configured, they can be referenced and de-referenced in the appropriate dialog boxes in the Network Policy Server snap-in.

The following table lists the different types of templates and where they are used in the Network Policy Server snap-in.

Template	Where it is used
RADIUS shared secret	When creating or configuring RADIUS clients, remote RADIUS server group members, RADIUS client templates, or remote RADIUS server templates
RADIUS clients	When creating or configuring RADIUS clients
Remote RADIUS servers	When creating or configuring remote RADIUS server group members
IP filters	When configuring IP Filters settings for a network policy
Health policies	When creating or configuring health policies
Remediation server groups	When creating or configuring remediation server groups

NAP Product Team

Tool for migrating IAS configuration settings to NPS is now available!

MS NAP Team — Thu, 15 Jan 2009 21:57:00 GMT

Configuration settings for the Internet Authentication Service (IAS) in Windows Server 2003 are stored in .MDB files. Configuration settings for Network Policy Server (NPS) in Windows Server 2008 are stored in .XML files. If you install Windows Server 2008 on a computer already running Windows Server 2003 (known as an in-place upgrade), the configuration settings are automatically migrated from the .MDB to the .XML format.

When Windows Server 2008 shipped, there was no capability to export the configuration settings of an IAS server to a format that can be imported on a different NPS server. For example, if you wanted to replace an IAS server with an NPS server running on different computer, there was no direct way to migrate the settings of the IAS server to the new NPS server. IAS supports the export of its settings with the netsh aaaa show config > path\file.txt command. However, the format of the exported text file could not be used by the netsh nps import path\file.txt command on an NPS server.

To address this migration issue, the NPS product team is proud to announce the availability of a Windows Server 2008 hotfix that contains Iasmigreader.exe, a command-line tool that exports the configuration settings of IAS on a computer running Windows Server 2003 to an Ias.txt file. Ias.txt is in a format that can be imported on an NPS server running Windows Server 2008 with the netsh nps import path\ias.txt command.

See Microsoft Knowledge Base article 955995 for the hotfix and more information.

Download, export, import, and enjoy!

Joe Davies
Senior Program Manager

NPS/NAP Logging - BSU.EDU style!

JeffSigman — Tue, 08 Jul 2008 17:41:00 GMT

Hey NAP fans, I’m Alex Chalmers from Ball State University with a guest post about NPS logging.

If you made it to one of Jeff’s TechEd IT Pro presentations, you’ll remember me discussing our NAP implementation and some of the challenges that we’ve faced along the way. Gathering accounting data across the NPS implementation for reporting is one of the largest we’ve faced so far. With multiple NPS servers around our campus for redundancy, trying to trace a session from login to logout can be tough without some type of centralization. There are a few possible solutions, but there are several gotchas to be aware of.

A natural reaction to the challenge might be to point to using SQL logging using a single, central data source for all of the NPS servers. It isn’t a bad solution for a small/medium sized site and is relatively simple to manage. But there is a pretty large problem with using this scenario when using RADIUS authentication (like with NAP)… if logging the event fails during authentication, the authentication will fail (refer to the Deploying SQL Server Logging with Windows Server 2003 IAS Guide, as it is still relevant). This means that if the central database server is ever down or otherwise unreachable, end users can no longer authenticate (or re-authenticate) to the network. At my site where we use 802.1X enforcement with session timeouts it would probably cause a flurry of helpdesk calls, depending on the length of the outage, and guarantee persona non grata status for me with my client services staff for a few days.

In trying to work out an alternative solution, other options were rejected for various reasons. Logging to a flat file didn’t solve any problems; it has the same problems of the current design with the added issue of trying to get the data into a reporting format. Trying to use SQL replication was out as we would have had to license SQL Server Standard or Enterprise for all of our NPS servers, as SQL Server Express can’t act as a publisher. Running independent SQL Server Express instances on each NPS system on its own could have worked, but you are limited to a 4GB database and still have to manually centralize the logging. Luckily, as we were looking at this last option some very knowledgeable people suggested we look at using SQL Service Broker.

Service Broker is a communications framework built into SQL Server 2005, and unlike replication in this case it could be used to send data from a SQL Server Express instance to a central data warehouse. The framework design is nearly tailor-made to be used in this situation. In its most basic sense, it enables two entities to send messages to each other while ensuring the messages are reliably received only once and in the same order they were sent. Reliable delivery, even across system restarts and network outages, and delivery without repetition are the two keys for this particular implementation.

I’ve created a set of SQL scripts that will help you to create the necessary objects for a basic, but functional, solution. But before we can get to implementing anything, we need some prerequisites. You will need to download and install SQL Server Express and Management Studio Express on each of your NPS servers. You will also need to have a server capable of storing your aggregate logging data running SQL Server 2005 Standard or Enterprise edition. Unfortunately, Service Broker will not communicate between to Express edition server instances. Each server must be addressable by DNS name. Configuring Service Broker on an instance will open a TCP port for communication, which will need access through any firewalls if present. The de facto default port is 4022, but it can be changed if needed. You will also need to have some paths pre-created for each server’s database and transaction logs, as well as a working directory to store certificate and key backups for disaster recovery purposes. Once you have these prerequisites complete, you can move on to running the scripts.

These scripts are sample code and assume that objects do not exist. Please take the time to analyze what is going on in each of them, and run through the scenario at least once in a test environment to be certain that the configuration is exactly what you want before moving into production. The script files use the Template Parameter feature of Management Studio Express to allow you to tune certain items in the scripts to fit your environment. Before running the scripts, please fill in the template information by selecting Query->Specify Values for Template Parameters… from the menu bar. Inside the script zip file, I have included a worksheet with the parameters used in each script to help you prepare.

Starting on the central SQL server, the first script to run is the ConfigureConsolidationServer.sql script. This will configure the Service Broker endpoints, create the consolidated accounting database, and create the basic broker service that each NPS server will connect to. While you should be able to execute the whole script in one batch after configuring the template parameters, I would suggest running it one section of code at a time to see the steps in action. When the script completes, you should have several files in the working directory you specified as a parameter. While you should store each of the files securely for disaster recovery purposes, you will need to copy the two certificates to each NPS server before running the next script.

Once the central server is configured, we can move to each NPS server. Open ConfigureNPSServer.sql in Management Studio Express and configure the necessary parameters. The certificates that you copied over in the previous step should reside in the working directory specified here. Those certificates will be used to identify and secure the remote broker service to the NPS system. This script will generate two similar certificates used to identify the NPS server to the central SQL server. You will need to copy them over before proceeding.

Now that servers have a baseline configuration, running the ConnectNPSServer.sql script on the central SQL server will authorize the NPS server to communicate on the Service Broker service. In a multi-server NPS configuration, you will need to run a version of ConnectNPSServer.sql for each NPS server in the environment. Once the scripts have run successfully, you should configure your NPS logging to log to the local SQL server instance. You will know if the scripts work by examining the RADIUS_Events_XML table on the central SQL server. If events are being stored, the configuration is successful. If you are getting data stored locally, but not to the central server, check that the addresses you’ve used in the scripts are valid and that all the ports are listening as expected. The majority of issues that I've run into with this configuration have been caused by either a bad address or a firewall blocking the Service Broker port that was configured for each server.

The magic of this configuration happens in two stored procedures: Report_Event on the NPS server and Collect_Events on the central SQL server. Report_Event is called whenever NPS logs an event. NPS sends an XML fragment to the stored procedure, which is then assigned a timestamp and GUID and stored in a local table. Additionally, the stored procedure transmits the data, including the additional timestamp and GUID, via Service Broker to the central SQL server. Collect_Events is called whenever data is logged to the central SQL server's Service Broker queue. It contains the logic to receive messages via the Broker service. The raw XML data is then stored in the RADIUS_Events_XML table, along with the previously assigned GUID and event timestamp. All of the remaining script code is used to create the infrastructure to allow these two procedures to work effectively.

Since I've said that these scripts are sample code, what could be improved upon for your environment? The first item I would look at is managing the local logs stored on the NPS server. These are stored there only as a safeguard until you can be certain that the data is accessible on the central system. You could deal with this issue in many ways, including not bothering with the local cache. The second major thing to look at is the data format on the central server. While centralizing the data is the main goal of this post, working directly with the XML data for reporting isn't necessarily the most elegant of solutions. You will probably want to either extend the Collect_Events procedure or create a scheduled job that will process the RADIUS_Events_XML table and transform the data into table form. Depending on the data that you're most interested in, you may find that a given event will have multiple entries for a given attribute (SHA SoH data is one) so you might need multiple tables with relationships. Key them off the event GUID assigned in the Report_Event procedure so that you can track an event's data where ever it may reside. The last item that I would look at directly is whether there is any organizational data that you might need to store at or near the time of the event. If your user population has somewhat frequent name changes, as an example, you may want to extend the data to include not only the username of the account used to login but the user object's AD GUID, SID, or some other unique identifier so that you can track a user's activities over a period of time without needing a list of usernames.

As you can see, this solution provides quite a bit of flexibility to design a system that will work for your needs. The downside to the solution is it does require a fair amount of knowledge about SQL Server to pull data from the logs and design queries that can later be used in a reporting solution, using Reporting Services or some other mechanism. The scripts I've implemented are really only the backbone of the solution, providing the necessary infrastructure and "glue" to allow the servers to communicate effectively.

I know that you will most likely have questions about our deployment or how these scripts function beyond the small novel of a post I have here. I'll happily answer any question in the comments of this post, or you are most welcome to send me email. If you have ideas, suggestions, or tips on how you've implemented something please share them as well!

- Alex B Chalmers

NAP 802.1X Configuration Walkthrough – Part 2

JeffSigman — Fri, 20 Jun 2008 19:59:00 GMT

NAP 802.1X Configuration Walkthrough – Part 2

This is a continuation from Part 1.

Step 2 – Windows Server 2008 NPS, the heart of NAP

I am going to take a slightly different approach than the 802.1X step-by-step guide. Feel free to follow either method, whatever gets it done for you!

My configuration assumes a “WORKGROUP”, not domain joined. Again, for simplicity of building a demonstration, I prefer to remove the AD component.

· Open “Server Manager”, just in case it didn’t open for you on logon. :->

· Add our NAP role – “Network Policy and Access Services”.

· Add our role service – “Network Policy Server (NPS)”.

*Tip* - if you also install the “Health Registration Authority (HRA)”, this is used only if you are doing NAP + IPsec, it may save you a bit of pain getting 802.1X to work. It has an option to create a “self-signed certificate” for the server. NPS / EAP require a server certificate to do 802.1X NAP.

· This is an important step, in case you are skipping the previous steps on installing the stuff. You should clear ALL EXISTING CONFIGURATION. Even on a default install, I clear it all out for my own sanity. Clean slate baby; easier to debug.

The four nodes to clear are 1.) RADIUS Clients 2.) Connection Request Policies 3.) Network Policies 4.) Health Policies.

· Now that we have a clean configuration, let’s run the spiffy wizard. Click on the top “NPS” node within the tree-view. You should then see a “Configure NAP” link on the “Getting Started” page.

· The first page of the wizard is figuring out which scenario of NAP enforcement you want to configure. For this walkthrough, I am discussing “IEEE 802.1X (Wired)”.

· Time to configure a RADIUS client (i.e. 802.1X switch). You will have to remember the IP address and shared secret that you configured on the switch itself in Part 1. Click the “Add” button. Fill in a nice friendly name for the switch (maybe a model# and physical location and such – it will be displayed in the logs later), the IP address of the switch (use the management VLAN 1 IP interface) and the shared secret.

· Since this is a workgroup, the next page can be skipped. This is where you can specify what machines and users should be included in your NAP deployment. This is pretty cool in that you can roll out NAP at your own pace throughout a domain.

· As I mentioned in the *tip* above, NAP + 802.1X needs a certificate on the server-side to function. A self-signed cert is a quick and easy way to get this going for a workgroup.

I am going to be discussing user-based NAP 802.1X – thus you only need to enable PEAP-MS-CHAPv2. If you were in an AD, you could deploy auto-enrolled machine certificates and get 802.1X machine authentication working. It is pretty slick.

·         Alrighty then, this is the fun bit – configuring the VLANs. It is relatively painless. This can sometimes vary depending on the switch. I will say that all seven of the switches I configured for RSA needed the same exact settings in here.

The “Organization network VLAN” is what I am calling the Compliant VLAN. Obviously the “Restricted network VLAN” is the Non-Compliant VLAN.

Compliant VLAN settings:
Tunnel-Type             = Virtual LANs (VLAN)
Tunnel-Medium-Type = 802 (includes all 802 media ...)
Tunnel-Pvt-Group   = 2

Non-Compliant VLAN settings:
Tunnel-Type             = Virtual LANs (VLAN)
Tunnel-Medium-Type = 802 (includes all 802 media ...)
Tunnel-Pvt-Group   = 3

· The “Health” settings that are available to you without any additional software are around the Windows Security Center. In NAP, this component is called on the NAP client “Windows Security System Health Agent” – and on the NAP server “Windows Security System Health Validator”.

You will notice in my screenshot that I have other stuff in there. These are plug-ins to NAP I was showing off at TechEd 2008 Orlando. You should be able to accept the defaults on this page and party on.

· The wizard is done!

· You should verify that the wizard added the configuration in the following nodes - 1.) RADIUS Clients 2.) Connection Request Policies 3.) Network Policies 4.) Health Policies.

· Navigate to the “System Health Validators” node in the tree and double-click the “Windows Security Health Validator”. Click the “Configure” button. I recommend starting small and just check for the Windows Firewall at first.

Nicely done! On to the client in the next installment!

Jeff

NAP 802.1X Configuration Walkthrough – Part 1

JeffSigman — Thu, 19 Jun 2008 20:08:00 GMT

I just got back from TechEd 2008 North America (Orlando) where I presented two “breakout” sessions on NAP. It went off with a bang and most people really loved the sessions / demos. I have blogged a couple times in the past that I would document exactly how I made it all work and now I want to come through on that promise.

Back in April of this year I created a cool 802.1X NAP Interoperability Showcase for the RSA show – it was two mobile racks (guitar racks actually) full of vendor 802.1X wired gear. I had devices from Cisco, D-Link, Enterasys, Extreme, Foundry, HP ProCurve and Nortel. I got it all working flawlessly with NAP / NPS / Server 2008! It was quite a thing to get working being a guy who deals chiefly in Windows OS’s (and not much networking hardware). After getting it all working I felt some serious love for the scenario – it is definitely my favorite flavor of the 6 NAP enforcement methods we support (DHCP, IPsec, 802.1X, VPN, TSG and Cisco NAC).

Before I head to Windows configuration, we need to talk GEAR. Here are the devices I got working in the showcase rack. I included links to my configuration files from the first five (I need to dig up the other guys too):

1. HP ProCurve 2626

2. Cisco Catalyst 3550

3. D-Link xStack DES-3828

4. Extreme Summit X450-24t

5. Foundry FastIron Edge 4802-POE

6. Enterasys 2G4072-52

7. Nortel BayStack 5520-24T-PWR

I also saved off a copy of the Network Policy Server (NPS) XML configuration file if you want to refer to it. Use caution when using these files. I don’t want you to frakk your switch! For the purposes of this walkthrough, I am going to discuss the specifics of the HP ProCurve 2626. It is a switch that is near and dear to my heart as it is the first one I ever got working. :-> Some things may vary on your brand / model.

Step 1 – Configure that switch baby

This step caused me some serious pain for a number of reasons. I was handed 7 switches with NO power cables, NO terminal cables NOR any instruction manuals. Whoa ho! “Good luck” was something I was thinking at the time. I hope you aren’t in the same boat here. :->

The ProCurve wasn’t bad at all once I found a female-to-female DB9 cable (i.e. Radio Shack). Being a Microsoft guy, I felt obligated to use Hyper Terminal (some Linux guys later informed me about PuTTY, which is pretty cool). Since Hypertrm disappeared from Vista (huh?!?), I went to my XP SP3 box and copied the required files to my memory stick (hypertrm.chm, hypertrm.dll, hypertrm.exe, hypertrm.hlp).

To get connected to the ProCurve I used 8-N-1 @ 115,200 with Xon/Xoff and VT100 emulation. Boy, this brought me back to my modem days. After hitting “connect” and enter a couple times, you should be presented with this.

By the way, you can use HP’s web based configuration interface for some stuff, like configuring VLANs, but it isn’t able to handle RADIUS configuration – which made me move right over to terminal for everything.

Here is a simple diagram of what every switch looked like. 3 VLANs total:

· VLAN 1: Management VLAN. Each of the seven switches had an IP address on the 10.x network. This is so they could do two things – authenticate to the NPS via RADIUS + relay the DHCP/BOOTP traffic to the DHCP server running on Windows Server 2008.

· VLAN 2: Compliant VLAN. AKA – the “healthy network”. Clients on this network are compliant with your policy.

· VLAN 3: Non-Compliant VLAN – AKA – the “unhealthy network”. Clients on this network are not compliant with your policy. They should not be able to contact clients in Compliant VLAN. It is also advisable to restrict what they can reach on the Management VLAN – only resources required to get them fixed up as well as infrastructure (e.g. AD).

Let’s take a look at the ProCurve configuration I am using:

Startup configuration:

; J4900B Configuration Editor; Created on release #H.10.45

hostname "HP ProCurve 2626"

ip routing

vlan 1

name "Management"

untagged 2,4,6,8-26

ip address 10.0.0.2 255.0.0.0

no untagged 1,3,5,7

exit

vlan 2

name "Compliant"

ip address 20.0.0.1 255.255.0.0

ip helper-address 10.0.0.1

exit

vlan 3

name "NonCompliant"

untagged 1,3,5,7

ip address 30.0.0.1 255.255.0.0

ip helper-address 10.0.0.1

exit

aaa authentication port-access eap-radius authorized

radius-server host 10.0.0.1 key secret

primary-vlan 3

aaa port-access authenticator 1,3,5,7

aaa port-access authenticator active

aaa port-access 1,3,5,7

Since I have multiple IP segments, I needed to enable IP Routing on the switch. This line makes that happen:

ip routing

Here are the VLANs. The names are self-evident. I only wanted 4 ports available for clients to authenticate with 802.1X (ports 1,3,5,7). I am not using 802.1X’s notion of port tagging the Ethernet frames, which I won’t go into here. I was going for simplicity, so I treated all seven of the switches like a completely separate network (non-routable between each switch).

vlan 1

name "Management"

untagged 2,4,6,8-26

ip address 10.0.0.2 255.0.0.0

no untagged 1,3,5,7

exit

vlan 2

name "Compliant"

ip address 20.0.0.1 255.255.0.0

ip helper-address 10.0.0.1

exit

vlan 3

name "NonCompliant"

untagged 1,3,5,7

ip address 30.0.0.1 255.255.0.0

ip helper-address 10.0.0.1

exit

We need to enable 802.1X on a port by port basis, as well as tell the switch how we intend to authenticate these ports. This is where we point the switch at the Windows Server 2008 machine running Network Policy Server (NPS). The shared secret I am using in this example is complex – it is “secret”. :->

aaa authentication port-access eap-radius authorized

radius-server host 10.0.0.1 key secret

primary-vlan 3

aaa port-access authenticator 1,3,5,7

aaa port-access authenticator active

aaa port-access 1,3,5,7

Make sure you commit the configuration to memory!

HP ProCurve 2626# write memory

Got more coming at you tomorrow! Stay tuned.

Jeff

NAP @ TechEd Podcast

JeffSigman — Wed, 11 Jun 2008 23:14:00 GMT

NAP - with Jeff Sigman and Others

Jeff Sigman – Microsoft
Chris Boscolo - Napera Networks, Inc.
Alex Chalmers - Ball State University
Pattabhi Attaluri - Avenda Systems

In this podcast from Tech·Ed NA 2008 IT Pro, Jeff Sigman talks about Network Access Protection (NAP). Alex Chalmers of Ball State University shares his experiences rolling out a large NAP deployment. Chris Boscolo (Napera Networks, Inc.) and Pattabhi Attaluri (Avenda Systems) talk about products their companies provide to add value to a NAP environment.

PowerPoint from the session.

Special thanks to Kevin Remde for making this podcast happen!

The World on {NAP}

JeffSigman — Mon, 05 May 2008 21:31:00 GMT

In case you haven’t noticed, {NAP} is being deployed across the globe! It is an exciting time with Windows Server 2008, Vista and XP SP3 NAP released and available to the world. Check out the great things 13 of our customers are saying below.

The full details of these customer deployments are in this word document. Check it out!!

City of Uppsala

Size
6,000 employees

Vertical
Government – Local

Country/Region
Sweden

PCL Constructors

Size
3,000 employees

Vertical
Building and Construction

Country/Region
Canada

Continental Airlines

Size:
44,000 employees

Vertical:
Aviation

Country/Region
United States

Rijksmuseum Amsterdam

Size:
420 employees

Vertical:
Museums

Country/Region
Netherlands, The

Fulton County

Size:
5,000 employees

Vertical:
Government - Central IT

Country/Region
United States

Microsoft Corporation

Size:
77,000 employees

Vertical:
Software Engineering

Country/Region
United States

La Trobe University

Size:
3,000 employees

Vertical:
Higher Education Institutions

Country/Region
Australia

KoçSistem

Size:
900 employees

Vertical:
IT Services

Country/Region
Turkey

Petron Corporation

Size:
1,300 employees

Vertical:
Oil & Gas

Country/Region
Philippines

University of Hradec Králové

Size:
800 employees

Vertical:
Universities

Country/Region
Czech Republic

City of Helsinki

Size:
40,000 employees

Vertical:
Government - Local

Country/Region
Finland

Government of Alberta

Size:
30,000 employees

Vertical:
Government - Regional / State

Country/Region
Canada

“With Windows Server 2008 Network Access Protection, all of our users will be able to access whatever network resources they need, regardless of their physical location or the state of their computers.”

Maurice Moes

Senior Architect and Project Manager, BRAIN FORCE

BRAIN FORCE

Size:
1,400 employees

Vertical:
Information Technology

Country/Region
Netherlands, The

{Jeff Sigman}{Senior Program Manager & NAP Hero}{Enterprise Security Group}

{NAP Blog, FAQ, Forum, MSDN, Site and my bloÿg}

NAP FAQ: Enforcing Security Updates (out-of-the-box)

MS NAP Team — Fri, 25 Apr 2008 01:54:00 GMT

Hey! My name is Mike Burk. I am a Program Manager on the Windows Security team. My team is responsible for the out-of-the-box NAP experience in Windows XP SP3, Vista and Server 2008. It is called the Windows Security Health Agent (client-side) and Validator (server-side). You will see it abbreviated as WSHA/WSHV in a lot of our documentation and on the web.

We’ve been getting a lot of questions about how update enforcement using the WSHA/WSHV actually works. The first thing to keep in mind is that the WSHA/WSHV only enforces security updates.

The easiest way to discuss update enforcement is to step through each part of the “Security Update Protection” section of the WSHV user interface. This is the dialog that appears within the Network Policy Server (NPS) console on Windows Server 2008:

1. “Restrict access…” checkbox

This activates the “Security Updates Protection” checks within the WSHA/WSHV (as well as the other controls in the section).

2. Severity rating pull-down menu

This is the severity level assigned by the MSRC for the update. If a client is missing security updates of the specified severity or higher, it will be deemed non-compliant and given restricted network access. The default is “Important and above.”

Note: “Low and above” and “All” actually mean the same thing. We are fixing this in future versions.

3. Number of hours since last scanned

This is the number of hours since the last time the client synched with its appropriate update server. This is only assessed when joining the network. If the time since last online scan exceeds this value, then the client will be deemed non-complaint. The default for this value is 22 hours, though it can be configured from 1 to 72 hours. Also, if automatic remediation is selected in the NAP policy, the WSHV will instruct the WSHA to do an online scan to ensure all new security updates are accounted for.

4. Update sources

There are three sources for getting updates: Windows Server Update Services (WSUS), Windows Update (WU), or Microsoft Update (MU). The WSHV is configurable to allow an administrator to accept updates from each of these on Vista SP1 and XP SP3. What this means is that a client reports its status with respect to the updates it knows about, and also where it gets its updates. If this is an acceptable source for updates, as configured in the WSHV, then the WSHV will accept that update status. Microsoft Update is accepted by default since it contains all updates. If an administrator wants to control which updates are approved for his network, then he should configure the clients for WSUS and check the WSUS box in the WSHV user interface.

Note: WSHA on Vista RTM (not SP1 or later) is only compatible with WSUS for update enforcement. This is the default on the WSHV for configuring policies for Vista clients.

Remediation

If the NAP policy is set for "Automatic Remediation", then the WSHA will automatically download and install the missing updates. The WSHA on the client will query the Windows Update Agent on the client for updates upon boot or upon joining the network, and every hour thereafter. If the Windows Update Agent reports that an update is missing, then the WSHA will generate a NAP message and the WSHV will enforce compliance per the NAP policy.

Note: The periodic scan interval is configurable via the ScanInterval value in the registry key HKLM\Software\Microsoft\MSSHA\.

I hope this clarifies how the WSHA/WSHV helps to keep your clients updated with the latest security updates!

Mike Burk

miburk@microsoft.com

Debugging NAP Errors (part 1)

MS NAP Team — Wed, 20 Feb 2008 09:15:00 GMT

I’ve heard from a lot of folks who set up NAP in a lab who would love to have more information on all the great data that Network Policy Server (NPS) writes into the audit log. If you haven’t checked out our auditing, go to Server Manager and click on the main node for our role (Network Policy and Access Services). You will see all related NAP server events at the top of the right hand pane. This will be part 1 in a series of “Debugging NAP” posts. I decided to kick it off by examining the messages / errors which come from our Windows Security Center NAP integration piece (included in XP SP3, Vista and Server 2008). It is called the Windows System Health Agent on the client (or WSHA) and the Windows System Health Validator on the server (or WSHV). ......(read more)

Network Access Protection (NAP) Deployment Planning

MS NAP Team — Sat, 28 Jul 2007 23:38:00 GMT

The following blog post has been extracted from the "Network Access Protection Deployment Planning Guide", by Susie Bernard (March 2007).

Introduction

Whether your organization is small, medium, or large, deploying an enterprise software solution like Network Access Protection (NAP) requires careful planning. Deploying NAP involves network infrastructure design evaluation, how clients connect to that network, and what criteria those clients need to meet to be considered compliant. Detailed planning increases the probability that your NAP deployment will be a success.

Deploying NAP involves configuring NAP settings on both the servers and the client computers. The server components are responsible for validating the health of client computers and specifying which network resources are available to them.

NAP client components are responsible for compiling health status statements on NAP client computers, maintaining client computers' health state, and communicating that health state to the server components.

Phases of deployment

The stages of any enterprise software deployment project are generally categorized according to phases, as follows:

Planning
Lab testing
Pilot deployment
Production deployment

Planning

This deployment planning guide can help administrators with the planning deployment phase of a NAP implementation.

Lab testing

For assistance with the lab testing phase of a NAP implementation, consult the step-by-step guides that are available for download on the NAP home page on TechNet.

Pilot deployment

Follow up your lab testing with a pilot deployment. For the pilot, deploy NAP to a select group of computers and/or users. Begin by enabling NAP in reporting mode only. In other words, configure NAP to implement Network Policy Validation where the health state of computers that request network access is validated against the network access policies you've defined, but network access is not restricted -- regardless of the client's state of health. This allows administrators to assess and analyze the health of the computers attaching to the network prior to enabling any enforcement methods that can potentially restrict network access.

As you gather data and determine the level of compliance in your pilot group, phase in an enforced health policy to computers in the pilot group by restricting network access to noncompliant client computers. While running NAP in reporting mode, ensure that you take the necessary actions to bring noncompliant NAP clients into compliance before enabling enforcement.

Production deployment

Carefully planning your deployment, performing lab testing, and completing a pilot deployment can help ensure a successful production deployment.

Decision Areas

Planning a NAP deployment requires making decisions surrounding health policy, enforcement, and remediation. This guide contains the following topics to aid you in planning your NAP implementation:

Defining NAP Policy
Choosing Enforcement Methods
Choosing Remediation Techniques

In order to proceed with these decisions, administrators should be familiar with how users and computers are grouped and managed within the network. This can help define how to control network health evaluation and enforcement. Administrators should also understand the requirements and components of NAP. Decisions must be made regarding the system health agents (SHAs) that are installed on the client computers and system health validators (SHVs) that are installed on the server running Network Policy Service (NPS[1]). Administrators will have to deploy these NAP components before they can configure and enable a network policy that enforces a client health policy. Therefore, a good understanding of these concepts is necessary to the planning process. Although NAP concepts are not described in this deployment planning guide, more information about NAP requirements can be found in the Windows Server 2008 online Help and in various articles linked to on the NAP home page on TechNet.

[1] The acronym NPS is used interchangeably in this document to refer to both the Network Policy Service and the computer running Network Policy Service (informally, Network Policy Server).

Defining NAP Policy

NAP policies are made up of Network Policy Server (NPS) authorization settings and define how NPS enforces client computer compliance with network health requirements.

In order to define a NAP policy, an administrator must answer the question, "What is compliant and what is noncompliant?" The answer to this question is based on a number of factors, most importantly your IT organization's security policies and other computer requirements dictated by IT management.

This section helps administrators address the most common NAP policy decisions surrounding the following computer health concerns:

Virus protection
Windows updates
Firewall protection
Spyware protection

Note: Although there might be other concerns, these four decisions are addressed here because they are the most common and because each of these areas is addressed by a system health agent (and its corresponding system health validator) in the first release of NAP in Windows Server 2008 and Windows Vista^TM.

Anti-virus Protection

Health policies surrounding anti-virus solutions can vary from one organization to the next. There are a number of questions to be addressed in defining anti-virus health policy. For example, your organization's IT security team requires an anti-virus solution in the environment. Essentially, this would mean that computers connecting to the network must have some type of anti-virus software installed. The NAP administrator must then answer the questions:

Is a particular manufacturer of anti-virus software required by security policy?
If so, is specific versioning of the product required at all times?
Or, is the requirement simply that the most updated version of the anti-virus software is necessary?
Does policy require that the most recent anti-virus updates are installed on each computer?
If so, how does your organization define "most recent" for health policy? Should the computer have all updates that are more than ten days old? Seven days? Two days?
Does policy require that full anti-virus computer scans are performed on a specified schedule?
If so, what is the maximum allowable timeframe for the most recent scan? Should the scan have occurred in the past two weeks in order for the computer to be deemed compliant? The past seven days?

The NAP administrator can build an anti-virus health policy based on the answers to these questions. Many of the features needed to do this are built into NAP already. It operates in conjunction with the Windows Security Health Agent included in Windows Vista (and available for download for Windows^® XP Service Pack 3) and in the Windows Security Health Validator included in Windows Server 2008. Other capabilities might be provided by NAP anti-virus partners. For a current list of partners and descriptions of how their products integrate with NAP, see Network Access Protection Partners.

Windows Updates

Another common security requirement is that computers have the latest Windows updates installed. Questions surrounding this type of health policy might include:

Are important updates which can improve Windows security and reliability required by computers connecting to the network?
If so, with what frequency should the client computer check for updates? Should the client have checked within the past week? Within the last 24 hours?
Should Windows Updates be enabled on the client and if so, with what frequency should update checks be performed in order for the computer to be considered compliant? Should updates be installed automatically or at the user's discretion?
Are recommended updates which address non-critical system problems required?
Are optional updates such as updated device drivers required?

Generally the NAP administrator should coordinate Windows Update policy with the IT staff members who are responsible for patch management on the secure network. This might include an SMS administrator, a Windows Server Update Services (WSUS) administrator, Active Directory group policy administrator, or other patch management solution administrator.

Firewall protection

Decisions regarding firewall policies are generally straightforward. Windows Firewall is a component of the Windows client operating systems that are supported by NAP. In defining Windows firewall health policy, the administrator should ask the following questions:

Does health policy dictate that a firewall is turned on?
If so is Microsoft Windows Firewall required, or are other third-party firewall solutions sufficient?
Is it necessary to configure the firewall to block all unsolicited attempts to connect to the computer?

Spyware Protection

Another health policy decision for administrators to address is whether or not to define a health policy for spyware protection and if so, whether or not to require a specific anti-spyware software solution for compliance. For example, a spyware protection health policy might require that Windows Defender is installed and enabled for real-time protection. Windows Defender is included in the Windows Vista operating system and can be downloaded from Microsoft.com for installation on the Windows XP platform.

Other Configuration Settings

Your organization might have health policy needs beyond those provided out-of-the-box with NAP as described here. In that case, plan to evaluate what these additional needs are and consult the Network Access Protection Partners to determine which NAP partners can provide an SHA and an SHV that fits your organization's additional needs.

Other NAP Policy Decisions

As you create a checklist of the health policies that are required for your organization, you must make decisions about which system health agents to deploy, what to do with noncompliant computers, and what to do with computers connecting to your network that are not NAP-capable--such as computers running a UNIX operating system.

For example, you might choose to provide exceptions to certain computers in your organization that are not NAP-capable, or you might choose to restrict network access to all clients that are not NAP-capable. The decisions will depend upon the needs of your organization and its security policy. For more information, see Unsupported platforms later in this section.

System health agents and system health validators

Administrators must decide which system health validator (or combination thereof) will be part of the health check. When you define a network health policy on the NPS server, you must decide which system health validators will apply to that particular policy. Each system health validator that is enabled on the NPS as part of a health policy requires that a corresponding system health agent is installed on the client computers that are being evaluated against that policy when they attempt to connect to the secure network. An important factor to note is that your network might have more than one type of system health validator. If so, the NPS must coordinate the output from all of the SHVs and determine whether (and how) to limit the access of a noncompliant computer. This requires careful planning when defining health policies and evaluating how different SHVs interact.

Example: You are applying three different SHVs: A, B, and C. In this example scenario, SHV "A" deems the client computer to be compliant with its policy; SHV "B" also determines the same result; however, SHV "C" deems the computer to be noncompliant. It is the administrator's responsibility to configure NPS to react appropriately based on those mixed results. The administrator needs to define whether a compliant machine is required to pass one, all, or a specific combination of the SHV checks.

Windows Security Health Agent and Windows Security Health Validator

Administrators might choose to use the built-in system health validator and system health agent that ship with Windows Server 2008 and Windows Vista. Windows Vista includes a system health agent as part of the operating system called the Windows Security Health Agent. It can provide health statements based on Windows Security Center reporting features including the status of firewall software, antivirus software, anti-spyware software, and Automatic Updates. Windows Server 2008 includes the Windows Security Health Validator that corresponds to the Vista health agent.

Note: At the time of this guide's publication, Microsoft is developing the Network Access Protection Client for Windows XP (now in beta testing) that will be released at the same time as Windows Server 2008. For more information, see Down-level OS Support on the NAP Blog.

The Windows Security Health Agent and Windows Security Health Validator provide the following functionality for NAP-capable computers:

The client computer has firewall software installed and enabled.
The client computer has antivirus software installed and running.
The client computer has current antivirus updates installed.
The client computer has anti-spyware software installed and running.
The client computer has current anti-spyware updates installed.
Microsoft Update Services are enabled on the client computer.
In addition, if NAP-capable client computers are running Windows Update Agent and are registered with a Windows Server Update Service (WSUS) server, NAP can verify that the most recent software security updates are installed based on one of four possible values that match security severity ratings from the Microsoft Security Response Center (MSRC). Note that with the release of Windows VistaSP1 and Windows Server 2008, patch management will also be able to validate against Windows Update and Microsoft Update (WU/MU), in addition to WSUS.

Note: Windows Security Center depends on status notification from the anti-virus software, firewall software, and anti-spyware software in order to recognize it. For example, if the anti-virus software in use does not have the ability to report to Windows Security Center that it is up-to-date, then the Windows Security Center might not report that. So, keep in mind that there is some dependency on the anti-virus software, anti-spyware software, and firewall software to integrate with Windows Security Center.

Noncompliant computers

For noncompliant computers, you must decide what level of network access (if any) you are going to allow those computers. The type of restricted access that can be enforced on noncompliant computers is dependent upon which enforcement method is applied when the computer attempts a network connection. For more information about making this decision, see Choosing Enforcement Methods later in this guide.

Unsupported platforms

Administrators must also decide how to deal with non-supported platforms and network traffic that may attempt network access. These types of devices cannot submit a statement of health and therefore cannot participate in the NAP health evaluation. The network administrator must decide how to deal with these devices.

The administrator might decide that any device that cannot be evaluated for health using NAP will be kept on a restricted access network, then configure that restricted access so it provides the necessary support for those devices. On the other hand, the administrator might choose to allow all devices not capable of doing NAP to be given full access to the secure network. There are obvious risks involved in doing this. One risk is that a computer that is capable of doing NAP (i.e., a computer running Windows Vista) could appear as being not NAP-capable by disabling the NAP client software. If the number of devices that are not NAP-capable is manageably small, the administrator might consider managing their access by exception. For example, if you know the MAC address of the device that is not NAP-capable, you can explicitly grant full access to that device without allowing all non-NAP capable devices full access. Another option is using a third-party offering for doing health evaluations of these devices.

Choosing Enforcement Methods

After outlining health policy, administrators need to determine how (or if) the organization should enforce Network Access Protection (NAP) in the organization. Read this section to determine which questions to ask when choosing enforcement methods during the deployment planning phase and to understand the advantages of choosing one enforcement method over another.

Note: After creating an initial list of health policies, it's a good idea to determine the extent to which the computers connecting to your network are compliant. This is easily done with NAP by enabling NAP in reporting mode only. In reporting mode the NAP client's health is evaluated but access restrictions are not imposed on computers that do not pass the health check. All computers, regardless of health compliance, are given full access to the secured network. However, because the health evaluation results are recorded in the logs on the NPS, the administrator can generate reports regarding the overall health status of the network. Doing this gives administrators an idea of the percentage of computers that are noncompliant, which can also help in determining which enforcement method(s), if any, to use.

Ensure that you understand the enforcement methods that are available in NAP. NAP enforcement methods are any-of-four network access technologies that work in conjunction with NAP to enforce health policies. Table 1 briefly describes the four built-in NAP enforcement methods (known as "enforcement clients") and their corresponding network access mechanisms.

Keep in mind that NAP enforcement methods are not mutually exclusive. Administrators might choose to use multiple-supported enforcement methods in different combinations.

Table 1. NAP enforcement clients

Enforcement client	Description
Dynamic Host Configuration Protocol (DHCP)	Enforces health policies when a client computer attempts to obtain an IP address from a DHCP server.
Extensible Authentication Protocol (EAP) for IEEE 802.1X connections	Enforces health policies when a client computer attempts to access a network using EAP through an 802.1X wireless connection or an authenticating switch connection.
Remote access for VPN connections	Enforces health policies when a client computer attempts to gain access to the network through a virtual private network (VPN) connection.
Internet Protocol security (IPsec) communications	Enforces health policies when a client computer attempts to communicate with another computer using IPsec.

In addition to the built-in enforcement clients, administrators might use additional third-party enforcement clients. For more information about these, see Network Access Protection Partners and consult with the appropriate vendor.

Questions to Help Administrators Choose Enforcement Methods

This section describes some fundamental questions that administrators need to ask when determining which enforcement methods to use with NAP.

Are any computers connecting to the network remotely?

The most fundamental question is whether or not client computers are connecting to the protected network remotely. If clients are connecting from locations that are outside of the protected network by way of a virtual private network (VPN) and you need to check them for health policy compliance before allowing them unrestricted network access, then administrators should consider using the VPN enforcement method.

VPN enforcement works by using a set of remote access IP packet filters to limit the traffic of the VPN client so that it can only reach the resources on the restricted network. The VPN server applies the IP packet filters to the IP traffic that is received from the VPN client and silently discards all packets that do not correspond to a configured packet filter. If the VPN client is noncompliant, the VPN connection has the packet filters applied and the VPN client can only reach resources on the restricted network.

Essentially with VPN enforcement, you can restrict the client to a logical network that can only access remediation servers. These client computers would remain restricted from broader connectivity to resources in the protected network until they are brought into a compliant state.

Note: The VPN server component must be NAP-enabled. At this time, only the Microsoft Routing and Remote Access service in Windows Server 2008 support NAP, although NAP partners might provide integrated NAP-enabled VPN server software at a later time.

Are computers using DHCP to obtain an IP address on your network?

The second most fundamental question surrounds the IP addressing scheme your organization uses. If your organization uses Dynamic Host Configuration Protocol (DHCP) to distribute IP addresses to computers connecting to the network, consider using DHCP enforcement to provide network access protection.

DHCP enforcement works by limiting network access for the DHCP client through its IP routing table. DHCP enforcement sets the DHCP Router option value to 0.0.0.0 so that the noncompliant computer is not configured to use a default gateway. DHCP enforcement also sets the subnet mask for the allocated IP address to 255.255.255.255 so that there is no route to the attached subnet.

As with VPN enforcement, using DHCP enforcement can restrict the client to a logical network that can only access remediation servers.

To allow noncompliant computers to access the remediation servers on the restricted network, the DHCP server assigns the Classless Static Routes DHCP option which contains a set of host routes to the computers on the restricted network, such as the DNS and remediation servers. The end result of DHCP limited network access is a configuration and routing table that allows connectivity only to specific destination addresses. Therefore, when an application attempts to send to a unicast IPv4 address other than those supplied via the Classless Static Routes option, the TCP/IP protocol returns a routing error.

Note: At this time, DHCP enforcement is for IP version 4 (IPv4) and does not support IP version 6 (IPv6)-based DHCP clients. However, IPv6 support might come at a later date either for Microsoft DHCP for IPv6, or for a third-party DHCP provider. DHCP enforcement requires a NAP-enabled DHCP server, which at the present time is only supported by the Microsoft DHCP Server component that is included in the Windows Server 2008.

Do network users have administrative privileges on their computers?

If you are considering using DHCP enforcement, keep in mind that one of the weaknesses of DHCP enforcement is that it can be overridden by assigning a static IP address to the client computer. Because DHCP enforcement is based on entries in the IPv4 routing table, it cannot prevent a malicious user who is a local administrator from manually changing the IPv4 routing table and gaining access to the protected network, thus bypassing NAP policy enforcement.

Are you using Microsoft's DHCP Service?

Microsoft's DHCP Service is currently the only DHCP provider that is NAP-enabled. If you are using a third-party DCHP provider, check with your DHCP software vendor to determine if that vendor has plans to support NAP. You may consider implementing a different NAP enforcement method in the meantime.

The next section summarizes the differences between VPN and DHCP enforcement methods.

VPN vs. DHCP

VPN enforcement limits the access of noncompliant VPN clients that are attempting to access the protected network through a VPN connection by restricting their IP connections through a packet filtering technique. DHCP enforcement limits the access of noncompliant DHCP clients that are attempting to obtain a valid IP address configuration by granting an IP address to the client, yet removing routing capability from it. In both of these cases the access to a restricted network is based on a client-server relationship and implemented at the server through which the client is requesting network access or configuration.

Keep in mind that you can configure NAP to employ more than one enforcement method. The NAP administrator can configure NAP to perform health checks only on clients connecting via VPN, or only on computers connecting directly via DHCP, or on both.

Does your wired network employ the IEEE 802.1X protocol?

If your wired or wireless network currently uses the IEEE 802.1X standard, which defines port-based user authentication methods used when accessing the network, then you should consider using 802.1X enforcement. It is a more secure way of providing network access protection for your intranet than DHCP or VPN enforcement. If you are not currently using wire 802.1X for network connectivity, you should investigate the expense and complexity of implementing 802.1X authentication on your network prior to choosing it as a NAP enforcement method. It is not uncommon for a wired 802.1X implementation to require a fairly hefty hardware investment. Wireless 802.1X implementations are typically less cost-intensive than wired 802.1X implementations.

IEEE 802.1X enforcement works by instructing the 802.1X-capable access point (for wireless) or the 802.1X-capable switch (wired) to use a limited-access profile--either a set of IP packet filters or a virtual LAN identifier (VLAN ID)--to limit the traffic of the 802.1X-based noncompliant client, so it can only reach resources on the restricted network. For IP packet filtering, the 802.1X-capable access point applies the IP packet filters to the IP traffic that is exchanged with the 802.1X client and silently discards all packets that do not correspond to a configured packet filter. For VLAN IDs, the 802.1X-capable access point applies the VLAN ID to all of the packets exchanged with the 802.1X client and the traffic does not leave the VLAN corresponding to the restricted network.

Have you implemented or are you considering implementing a Public Key Infrastructure (PKI) in your organization?

If you are already using a Certification Authority (CA) and digital certificates in your environment for authentication, then you already have the infrastructure in place to use IPsec as a NAP enforcement method. Like 802.1X enforcement, IPsec enforcement provides better security than DHCP enforcement.

Unlike VPN and DHCP enforcement, IPsec is enforced at each individual computer rather than at the point of entry into the network. The determination of client health is performed by way of a health registration authority (HRA). The NAP client submits a request to the HRA asking for a health certificate. This health certificate is an X.509 certificate containing a specific object identifier (OID) identifying it as a health certificate. If the requesting client is compliant, the HRA responds to the request by obtaining a health certificate from the Certification Authority (CA) and giving it to the client. That client is then able to present the health certificate to prove that it has passed a health check.

IPsec enforcement in NAP works by limiting the access of noncompliant clients that are attempting to communicate to servers in the secured network. When a noncompliant client attempts to connect to a protected resource, the resource requests that the client present its health certificate to prove that it has passed a health check. Because the noncompliant client does not have a health certificate, IPsec enforcement limits the client's network connectivity by causing the server to drop connection attempts coming from it (and from any computers without health certificates).

Administrators should configure the CA to distribute health certificates that are only valid for a short period of time, e.g. 24 or 48 hours. This forces the client to request a new health certificate when the current certificate expires. That client must then undergo another health check. The validity period for the health certificates is configured at the HRA and is a decision that the administrator must make.

The following are some of the benefits of IPsec enforcement.

Tamper-resistant. IPsec enforcement cannot be bypassed by reconfiguring a NAP client. A NAP client cannot receive a health certificate or initiate communication with a compliant computer without a health certificate by manipulating settings on their local computer, even for a user with local administrator privileges. Additionally, IPsec enforcement cannot be bypassed through the use of hubs or virtual computer technologies.

No infrastructure upgrade needed. IPsec enforcement works at the network layer of the Open System Interconnection (OSI) model rather than the data link layer; therefore, it is independent of physical network infrastructure components such as hubs, switches, and routers.

Flexible limitations. With IPsec enforcement, administrators can configure IPsec enforcement so that compliant computers can initiate communications with noncompliant computers, but noncompliant computers cannot initiate communications with compliant computers. The administrator defines the type of traffic that must be authenticated with a health certificate and protected with IPsec through IPsec policy settings. IPsec policy allows for the creation of IP filters that can define traffic by source IP address, destination IP address, IP protocol number, source and destination TCP port, and source and destination UDP port. With IPsec policy and IP filter definition, it is possible to limit network access on a per-computer or per-application basis.

Compared to other NAP enforcement mechanisms (IEEE 802.1X, VPN, and DHCP), IPsec provides the strongest and most flexible form of NAP enforcement. IPsec enforcement is strong because it confines the communication with protected resources to compliant clients. IPsec enforcement helps protect the communication that occurs between two computers, regardless of their role.

By using IPsec as a NAP enforcement mechanism, administrators can help protect network traffic end-to-end and not just at the point of network access.

802.1X vs. IPsec

When determining how to protect your intranet and its assets, you do not have to choose between 802.1X for wired networks and IPsec. Because they operate at different layers and perform different functions, the use of one does not exclude the use of the other. From a security standpoint, it is better to deploy security technologies that create a series of barriers against an attacker. Deploying 802.1X for wired networks helps prevent unknown hosts from gaining access to your intranet. Deploying IPsec helps prevent unknown hosts from communicating with IPsec-protected hosts on your intranet.

An 802.1X communication requires network hardware that can be expensive if your organization has not already invested in it. However, a benefit of providing 802.1X NAP enforcement is that you are enforcing protection at the network port. If the computer is not compliant, you can restrict its access so that it can only send IP packets on a predefined VLAN, that is separate from the full-access VLAN, where compliant clients and servers are accessible to compliant clients.

IPsec, on the other hand, does not require additional hardware. One of the differences of IPsec NAP enforcement is that the enforcement occurs at the host. The client can connect and send IP packets wherever it wants. Health policy decides which computers can receive packets from the noncompliant client.

Example: A client computer that is attempting a network connection does not have antivirus software installed. If NAP is configured with 802.1X enforcement, the port can be shut down entirely for that client--or you can restrict the client computer to a virtual network that restricts its impact to the rest of the nodes on the protected network. IPsec enforcement on the other hand, determines through a health check that the client computer is not compliant, but the client still has the ability to connect to the protected network. IPsec policy instructs the protected nodes not to receive packets from the noncompliant computer. Thus, the noncompliant computer can in effect remain isolated from other computers on the protected network, but it is still connected to the network and can consume network bandwidth.

Security-wise, IPsec offers the option of end-to-end encryption. If encryption is a security requirement in your organization, by optionally specifying IPsec policy settings you can encrypt IP traffic between IPsec peers for highly sensitive traffic. Unlike IEEE 802.1X wireless LANs which only encrypt frames from the wireless client to the wireless access point, IPsec encryption is between IPsec peer computers.

Table 2 provides a high-level summary of the security provided by 802.1X and IPsec for wired networks.

Table 2. IPsec vs. 802.1X (for wired networks) security overview

Security property	802.1X for wired networks	IPsec
Authentication	X	X
Tampering and spoofing protection	X	X
Encryption		X
Protection for roaming clients		X

Table 3 provides a more granular comparison of 802.1X for wired networks and IPsec based on the 802.1X and IPsec standards.

Table 3. IPsec vs. 802.1X (for wired networks) in greater detail

802.1X for wired networks	IPsec
Authenticates and authorizes connections to a network. With 802.1X, the enforcement of the requirement of valid credentials is performed at the network edge by the switch. Wired 802.1X is a Data Link layer security barrier. A computer cannot plug into an available network port and begin communicating on the network.	Authenticates communications between endpoints. With IPsec, each end of the communication performs the enforcement of IPsec authentication. IPsec is a Network-layer security barrier. A computer cannot initiate communications with IPsec-protected intranet resources after obtaining a connection to the network.
Enforces security protection at the switch. IEEE 802.1X for wired networks is only applied at the switch port. Other methods of accessing the intranet might not be protected with 802.1X.	Enforces security protection at the host. IPsec policies are enforced by the host and apply regardless of the way that the host connects to the intranet or whether the host is connected to the intranet.
Does not provide cryptographic protection of traffic between the supplicant and the switch. After authentication and authorization, there are no facilities within the 802.1X standard that protect the traffic on the 802.1X-authenticated link.	Optionally provides cryptographic protection of traffic between endpoints. After authentication and negotiation of security options, IPsec protects packets with tamper-proofing and optional encryption.
Does not provide protection against attackers with physical access to a switch port. After obtaining physical access to a switch port, an attacker that spoofs the MAC address of a valid host can gain access to the intranet.	Provides protection against unknown hosts. An IPsec-protected host will discard spoofed packets sent by an unknown host.
Can provide protection against denial of service attacks that consume bandwidth. Protection against denial of service (DoS) attacks, in which an attacker tries to overwhelm the network with packets, is not an inherent function of 802.1X, but a capability of many switches that support 802.1X authentication.	Can provide protection against denial of service (DoS) attacks launched against hosts. IPsec is not designed to prevent a malicious host from transmitting packets. However, IPsec can prevent received packets from being processed. IPsec can silently discard unprotected packets upon receipt.
Works for all networking protocols. IEEE 802.1X operates at the Data Link layer before a connecting host sends any network protocol frames or packets.	Works only for IP-based traffic. IPsec can only protect packets that have an IP (IPv4 or IPv6) header.
Requires that your switches support 802.1X. The switches in your switching fabric must support 802.1X authentication and the use of RADIUS tunnel attributes to control VLAN ID or IP filtering.	Requires no additional support from the network infrastructure. IPsec operates at the network layer and works over any IP-based network.
Requires that your network hosts support 802.1X. The connecting network hosts must support 802.1X authentication for LAN connections and the EAP methods required by the RADIUS server.	Requires that your network hosts support IPsec. The network hosts must support IPsec, common authentication methods, and common cryptographic algorithms for key determination, Hash-based Message Authentication Codes (HMACs), and encryption (optional).
Requires an authentication infrastructure consisting of RADIUS servers and account databases. To perform authentication and authorization you must deploy account databases to store computer and user accounts and their credentials, and RADIUS servers to evaluate the connection attempt.	Requires an authentication infrastructure (depends on the IPsec authentication method). To perform IPsec authentication, you must deploy an authentication infrastructure that can authenticate the credentials of IPsec peers.
Simple or group-based network access. IEEE 802.1X provides a simple allowed/denied access to intranets. Whether the access is simple or group-based, 802.1X allows all traffic from an authenticated host. Many switches also support the use of virtual LANs (VLANs) to group ports together or to specify the types of traffic allowed on the switch port.	Isolated or granular network access. You can use IPsec policy and authentication methods to isolate portions of your network. IPsec settings can specify different levels of protection for network traffic to the granularity of IP addresses and TCP or UDP ports.
Requires no changes to applications. Because it operates at the Data Link layer, 802.1X does not require application support.	Requires no changes to applications. Because it operates at the Network layer, IPsec does not require application support.
Cannot protect against a trusted attacker. If a host has the proper credentials for 802.1X authentication, the switch cannot prevent the host from attacking the network.	Cannot protect against a trusted attacker. If a host has the proper credentials for IPsec authentication and the correct policy settings for IPsec protection of traffic, IPsec cannot prevent the host from attacking other hosts.

802.1X for wired networks

IPsec

Authenticates and authorizes connections to a network.

With 802.1X, the enforcement of the requirement of valid credentials is performed at the network edge by the switch. Wired 802.1X is a Data Link layer security barrier. A computer cannot plug into an available network port and begin communicating on the network.

Authenticates communications between endpoints.

With IPsec, each end of the communication performs the enforcement of IPsec authentication. IPsec is a Network-layer security barrier. A computer cannot initiate communications with IPsec-protected intranet resources after obtaining a connection to the network.

Enforces security protection at the switch.

IEEE 802.1X for wired networks is only applied at the switch port. Other methods of accessing the intranet might not be protected with 802.1X.

Enforces security protection at the host.

IPsec policies are enforced by the host and apply regardless of the way that the host connects to the intranet or whether the host is connected to the intranet.

Does not provide cryptographic protection of traffic between the supplicant and the switch.

After authentication and authorization, there are no facilities within the 802.1X standard that protect the traffic on the 802.1X-authenticated link.

Optionally provides cryptographic protection of traffic between endpoints.

After authentication and negotiation of security options, IPsec protects packets with tamper-proofing and optional encryption.

Does not provide protection against attackers with physical access to a switch port.

After obtaining physical access to a switch port, an attacker that spoofs the MAC address of a valid host can gain access to the intranet.

Provides protection against unknown hosts.

An IPsec-protected host will discard spoofed packets sent by an unknown host.

Can provide protection against denial of service attacks that consume bandwidth.

Protection against denial of service (DoS) attacks, in which an attacker tries to overwhelm the network with packets, is not an inherent function of 802.1X, but a capability of many switches that support 802.1X authentication.

Can provide protection against denial of service (DoS) attacks launched against hosts.

IPsec is not designed to prevent a malicious host from transmitting packets. However, IPsec can prevent received packets from being processed. IPsec can silently discard unprotected packets upon receipt.

Works for all networking protocols.

IEEE 802.1X operates at the Data Link layer before a connecting host sends any network protocol frames or packets.

Works only for IP-based traffic.

IPsec can only protect packets that have an IP (IPv4 or IPv6) header.

Requires that your switches support 802.1X.

The switches in your switching fabric must support 802.1X authentication and the use of RADIUS tunnel attributes to control VLAN ID or IP filtering.

Requires no additional support from the network infrastructure.

IPsec operates at the network layer and works over any IP-based network.

Requires that your network hosts support 802.1X.

The connecting network hosts must support 802.1X authentication for LAN connections and the EAP methods required by the RADIUS server.

Requires that your network hosts support IPsec.

The network hosts must support IPsec, common authentication methods, and common cryptographic algorithms for key determination, Hash-based Message Authentication Codes (HMACs), and encryption (optional).

Requires an authentication infrastructure consisting of RADIUS servers and account databases.

To perform authentication and authorization you must deploy account databases to store computer and user accounts and their credentials, and RADIUS servers to evaluate the connection attempt.

Requires an authentication infrastructure (depends on the IPsec authentication method).

To perform IPsec authentication, you must deploy an authentication infrastructure that can authenticate the credentials of IPsec peers.

Simple or group-based network access.

IEEE 802.1X provides a simple allowed/denied access to intranets. Whether the access is simple or group-based, 802.1X allows all traffic from an authenticated host. Many switches also support the use of virtual LANs (VLANs) to group ports together or to specify the types of traffic allowed on the switch port.

Isolated or granular network access.

You can use IPsec policy and authentication methods to isolate portions of your network. IPsec settings can specify different levels of protection for network traffic to the granularity of IP addresses and TCP or UDP ports.

Requires no changes to applications.

Because it operates at the Data Link layer, 802.1X does not require application support.

Requires no changes to applications.

Because it operates at the Network layer, IPsec does not require application support.

Cannot protect against a trusted attacker.

If a host has the proper credentials for 802.1X authentication, the switch cannot prevent the host from attacking the network.

Cannot protect against a trusted attacker.

If a host has the proper credentials for IPsec authentication and the correct policy settings for IPsec protection of traffic, IPsec cannot prevent the host from attacking other hosts.

In summary, this section presents fundamental questions to consider when choosing an enforcement method. Consider the following:

VPN enforcement is relatively straightforward. Organizations that have an existing virtual private network for remote access can use VPN enforcement in NAP. For more information, see the VPN Connections section in Network Access Protection Platform Architecture.
DHCP enforcement is fairly easy to implement, but it can be bypassed with static IP addressing. For more information see the DHCP IP Address Configuration section in Network Access Protection Platform Architecture.
802.1X enforcement requires 802.1X-enabled network hardware (possibly requiring an initial investment in purchasing and deploying that hardware), yet it provides broad coverage. For more information, see IEEE 802.1X for Wired Networks and Internet Protocol Security with Microsoft Windows.
IPsec moves enforcement up from the network layer of the OSI model, but IPsec enforcement does not prevent noncompliant clients from sending packets on the network. For more information, see Internet Protocol Security Enforcement in the Network Access Protection Platform.

After determining the enforcement methods to use with NAP, you should whether or not there will be exceptions to the enforcement rules--for example, computers in your organization that are running Linux. Devise a plan for dealing with those and other computers that are not NAP-capable. Essentially, if NAP asks a client computer for a statement of health but the client does not provide it, that computer is not a NAP-capable computer and administrators must determine whether to restrict network access for that computer or grant it full access to the secured network. When granting limited access, the administrator must understand which network resources the computer must be able to access in order to perform day-to-day operations and make these resources available in the restricted network.

Choosing Remediation Techniques

The remediation techniques that your organization uses to bring noncompliant computers into compliance with network health policy are dependent upon the health policies that are in effect. Many organizations are already running server applications in their environment that provide ongoing updates to computer nodes that are connected to the network, some of which are NAP-aware. If the remediation technique in use provides the ability for clients to receive notification from NAP health agents and to pull updates from the remediation server, then most organizations will continue to use their existing patch management system for remediation in a NAP environment.

Basically these remediation servers contain health update resources such as the necessary security updates, configurations, and applications that client computers can access to remediate their noncompliant state. Examples include antivirus signature distribution servers, computer management servers (e.g. Microsoft Systems Management Server), and software update servers (such as Microsoft Windows Software Update Services). Various remediation methods exist. Some remediation servers push content out to client computers, other remediation techniques are configured to allow the client to pull content from the remediation servers.

If you already have remediation servers on your network, part of the NAP deployment planning process is determining if your existing remediation techniques are NAP-aware and how to use them in conjunction with NAP network access restrictions being enforced on noncompliant computers. If you have not yet deployed remediation servers on your network, you should begin planning the type of remediation servers that you will need (based on health policies), and the locations of these servers on your network (based on enforcement methods). For example, administrators might choose to put some of their remediation servers in a restricted network to which the noncompliant NAP clients can connect. The NAP clients can then communicate with remediation servers to become compliant, based on instructions from the NPS server.

Example deployment of a network policy that enforces NAP

The following scenario included in the NAP Components topic in the online Help for Network Policy Service, is an example of creating a network policy that enforces NAP. At the end of the example is a high-level summary of the steps required to create the policy.

In this example, a network administrator creates a network policy that is enabled, grants access, and enforces NAP for NAP-capable 802.1X wireless client computers running either Microsoft^®Windows XP with Service Pack 3 or Windows Vista.

In this example "A. Datum" and "A. Datum Antivirus" are the fictional names used. Configuration of the A. Datum Antivirus SHV shows how third-party SHVs can be incorporated into a NAP deployment. A. Datum has designed A. Datum Antivirus to be compatible with NAP, and provides its customers with the A. Datum Antivirus SHA and SHV components to allow them to implement a NAP solution with A. Datum Antivirus.

For this example, the following assumptions exist:

1. The administrator has already configured Group Policy configuration for NAP clients, and all NAP clients are domain member computers.
2. The administrator has already installed NAP upgrades for client computers running Microsoft Windows XP with Service Pack 3.
3. The administrator has already deployed NAP remediation servers that can provide client computers with antivirus signature updates. In NPS, the administrator has created a Remediation Server Group named A. Datum Antivirus Remediation Servers.
4. The administrator has already deployed wireless access points that support 802.1X and RADIUS, and the wireless infrastructure is functioning properly before NAP is configured and enforced by NPS.
5. The administrator has already deployed a Web server on the remediation network that contains help for NAP users at the Uniform Resource Locator (URL) address http://naphelp.
6. The administrator has already created a group in Active Directory named WirelessNAPUsers and has added user accounts to the group for users that have NAP-capable client computers. In addition, the administrator has already created a group in Active Directory named WirelessUsers for users that do not have NAP-capable client computers.
7. The NPS server is configured as a RADIUS server and wireless access points are configured in NPS as RADIUS clients.
8. The example third party SHV and SHA are not installed yet. The network administrator uses antivirus software created by a company named A. Datum, and the product is named A. Datum Antivirus.

Network administrator goals for NAP

In this example, the network administrator has the following goals for NAP:

1. Using the A. Datum Antivirus SHV and SHA, the administrator wants to ensure that client health checks include verification that A. Datum Antivirus with the most recent antivirus signatures are installed on client computers. The administrator also wants to configure NAP autoremediation so that the most recent signatures are automatically downloaded and installed on client computers.
2. Using the Windows Security SHV and SHA, which are included in the WindowsServer 2008 and WindowsVista operating systems respectively, the administrator wants to ensure that client health checks include verification that Windows Firewall is enabled and that Microsoft Update is enabled so that client computers have all of the most recent Windows security updates installed. The administrator also wants to configure NAP autoremediation so that the most recent security updates are automatically downloaded and installed on client computers if they do not already have the most recent security updates.

Example deployment steps

For this example deployment the following steps are required:

Install NAP SHA components on NAP clients.
Install SHVs on NPS server.
Configure SHVs for the desired health policy.
Run the New Network Policy Wizard to create NAP health policies. Configure the policy such that it is not restricting network access and is operating in reporting mode.
Enable the network policy and set the policy to grant access.
Monitor the NAP health of the clients and address any problems to reduce the number of noncompliant clients to the desired level.
In the network policy, enable network restriction using a desired grace time to allow clients time to attain compliance before being restricted (probation mode).
Monitor the NAP health of the network running in probation mode for a period of time until satisfied that operations are performing as expected.
In the network policy, eliminate the grace period and implement enforcement mode--where noncompliant clients are given restricted access at the time of health check until they undergo remediation and are returned to a compliant state.

Enabling NAP Monitoring and Reporting

It is a good idea to be familiar with how to enable NAP reporting so that you can troubleshoot issues and monitor status during the lab testing and pilot deployment phases of your NAP implementation. This section provides an overview of the Network Policy Service logs.

Plan to enable the two types of logging in Network Policy Service (NPS) during lab testing and your pilot deployment.

Event logging for NPS: Records NPS events in the system event log. This is used primarily for auditing and troubleshooting connection attempts.
Logging user authentication and accounting requests: Logs user authentication and accounting requests to log files in text or database format, or in a stored procedure in a SQL Server 2000 or SQL Server2005 database. Request logging is used primarily for connection analysis and billing purposes. It is also useful as a security investigation tool, providing a method of tracking down the activity an attacker.

To make the most effective use of NPS logging, you should turn on logging (initially) for both authentication and accounting records. After you've successfully deployed and configured NAP in your production environment, you can modify these selections based on what is appropriate for the environment. You should plan to have a log-file backup system in place, because the logs cannot be recreated when they are damaged or deleted. Also, ensure that event logging is configured with a capacity that is sufficient to maintain the logs. If you choose to store the logs in a database, plan to provide failover and redundancy. With SQL Server logging, place two computers running SQL Server on different subnets. Use the SQL Server Create Publication Wizard to set up database replication between the two servers. For more information, see the SQL Server documentation.

NAP Resources

See the following links for more information about NAP:

Introduction to Network Access Protection

Overview of NAP scenarios and NAP components and a brief description of how NAP works for Internet Protocol security (IPsec)-based communication, 802.1X authenticated connections, virtual private network (VPN) connections, and Dynamic Host Configuration Protocol (DHCP) configuration.

Frequently Asked Questions about Network Access Protection

Frequently asked questions about NAP.

Network Access Protection Platform Architecture

Detailed description of the components of the NAP architecture, how NAP works, and how NAP allows third-party software vendors and system integrators to create complete solutions for system health validated network access.

Internet Protocol Security Enforcement in the Network Access Protection Platform

Detailed description of how IPsec enforcement in the Network Access Protection platform works to provide system health validation and enforcement for IPsec-secured communication.

Configuring Network Access Protection Policies in Windows Server 2008

Description of how to configure NAP health requirements and enforcement behavior using the Network Policy Service (NPS) in Windows Server 2008.

Summary

This guide describes the decisions that an administrator must make when planning a Network Access Protection (NAP) deployment. NAP is a network access control technology included in Microsoft Windows Vista, Windows XP Professional Service Pack 3, and Windows Server 2008. This guide does not describe NAP concepts or the components of NAP. Rather, it provides a brief overview of the following phases of a NAP deployment and describes running NAP in reporting mode before fully enabling its enforcement and network restriction capabilities:

Planning
Lab testing
Pilot deployment
Production deployment

The main topics of this guide are defining health policy, comparing and choosing NAP enforcement methods, and defining network restrictions for noncompliant client computers undergoing any of these enforcement methods:

Virtual private network (VPN) connections
Dynamic Host Configuration Protocol (DHCP) address configuration
Internet Protocol security (IPsec)-based communication
IEEE802.1X-authenticated connections

Remediation techniques used to bring computers into compliance are also discussed, as is the recommendation that administrators enable reporting for NAP in order to troubleshoot issues during the phases of deployment and monitor progress. Also included in this deployment guide is a sample deployment scenario.

NPS pattern matching heaven in Windows Server 2008

MS NAP Team — Wed, 04 Jul 2007 00:35:00 GMT

Greetings! Sam Salhi here from the Network Policy Server (NPS) team. One of NPS’s most powerful features is Pattern Matching. What makes it so powerful is the use of regular expressions when dealing with it.

Here’s a little example. Suppose that you want to proxy users from domain "foo.com" to a remote NPS server. You’re not interested in authenticating them locally. So what do you do?

You create a Connection Request Processing (CRP) Policy that will match, based on username and forward to the remote servers. How would that matching look like? Simple, a regular expression. So just enter: Foo.com.

But what about users that come in NT4 style domain names? You have two options. Either create a new policy or … Use the same policy matching field to enter the value now it will look like this

Foo.com|foo\\

This all looks good. Since you’re only forwarding to a remote NPS, that will do some authentication as well. If there is no security associated with it. This would be fine. But what if security is an issue (as in, anyone from foo.com will be allowed access without authentication?)

In these cases, the rule must be tightened and made as strict as possible. So something like:

.*@foo\.com$|^foo\\

The stricter, the better. But remember you only need to do this when you’re allowing extra security. If you’re just using it to match while authentication/authorization will take care of security. Then you don’t need to make it too strict.

Remember that, "." matches with anything. So 192.168.1.1 in regular expression world means *192?168?1?1* so something like: 192.168.121.221 would match it. If you want it to be strict, you must have the "." Escaped and the beginning and end delimited. So ^192\.168\.1\.1$ this means that only 192.168.1.1 will match this policy.

Pattern matching is the core of the Attribute Manipulation features in NPS, but we’ll talk about these next time.

Happy Matching!

Sam.Salhi@online.microsoft.com

IAS/EAP/NPS team

PS - More on Pattern matching Syntax with a quick refresher on Regular expressions here.

The heart of NAP now has its own site...

MS NAP Team — Fri, 29 Jun 2007 23:58:00 GMT

Network Policy Server (NPS) in Windows Server 2008 (formally known as Internet Authentication Server - IAS) has a new home on the web:

http://www.microsoft.com/nps

-or-

http://www.microsoft.com/technet/network/nps/default.mspx

Party on and NAP the WORLD!

Jeff Sigman
NAP Release Manager
Jeff.Sigman@online.microsoft.com *
- http://blogs.technet.com/nap
- http://microsoft.com/nap
- http://forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=576&SiteID=17

* Remove the "online" to actually email me.
** This posting is provided "AS IS" with no warranties, and confers no rights.