Network Access Protection (NAP) : Deployments

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

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

The no enforcement design for NAP

MS NAP Team — Tue, 23 Dec 2008 02:20:00 GMT

Although NAP can be used to enforce restricted access for noncompliant NAP clients and non-NAP-capable clients, NAP can also be used to provide you with information about the overall level of health compliance on your network and correct system health problems automatically without notifying the user or restricting their access. This latter configuration of a NAP deployment is known as the no enforcement design and consists of deploying NAP in reporting mode with autoremediation enabled.

The value of the no enforcement design was echoed to me by attendees at a recent McAfee regional security event, where I helped present an overview of NAP and McAfee Network Access Control 3.0 integration to IT staff and security architects (this is the same presentation that I gave at McAfee’s FOCUS 08 event). Some attendees said that they were very interested in the no enforcement design of NAP because they did not want their users notified of noncompliance (via the NAP notification message) and definitely did not want their users’ access to be restricted. They would rather determine and fix any system health issues in the background without disturbing their users. One of the benefits of the no enforcement design is that you do not have to set up a restricted network with remediation servers.

To configure a no enforcement design, use the Configure NAP wizard in the Network Policy Server snap-in for the appropriate NAP enforcement method. On the Define NAP Health Policy page, select the Enable Auto-Remediation of Client Computers check box and specify that NAP ineligible computers are allowed full access. After the Configure NAP wizard is complete, modify the network policy for noncompliant NAP clients by selecting Allow Full Network Access for the NAP Enforcement settings.

Note For the 802.1X enforcement method, specify the same VLAN or ACL settings for both full access and restricted access on the Configure Virtual LANs (VLANs) page of the Configure NAP wizard.

For more information, see the No Enforcement Design topic in Greg Lindsay’s excellent NAP Design Guide.

Joe Davies

Resources for using certificates with NPS and NAP

MS NAP Team — Fri, 19 Dec 2008 18:59:00 GMT

An interesting but also somewhat complicated element of deploying a network access method with or without a NAP health evaluation is the use of digital certificates. Digital certificates can be used to provide strong authentication for remote access VPN connections, IEEE 802.1X-authenticated wired and wireless connections, and IPsec-protected traffic.

Additionally, the following NAP enforcement methods use certificates:

· IPsec enforcement uses health certificates

· The 802.1X and VPN enforcement methods use the Protected Extensible Authentication Protocol (PEAP) method, which requires a computer certificate on the NPS server and a corresponding root certificate on the NAP client

Here are the key resources for learning about certificates and access methods with NPS:

· Certificates and NPS

· Certificate Requirements for PEAP and EAP

Additionally, here are two Foundation Network Companion Guides that describe certificate deployment for EAP and PEAP:

· The “Foundation Network Companion Guide: Deploying Server Certificates” available in HTML and Word document format

· The “Foundation Network Companion Guide: Deploying Computer and User Certificates” available in HTML and Word document format

Consume, assimilate, deploy, and enjoy!

Joe Davies

"How Microsoft does IT: Managing Network Access Protection" TechNet WebCast now available

MS NAP Team — Fri, 14 Nov 2008 21:32:00 GMT

The "How Microsoft does IT: Managing Network Access Protection" TechNet WebCast, recorded on Tuesday, November 11 by Brent Scallan, Senior Systems Engineer with Microsoft IT, and Pat Fetty, Principal Program Manager with the Windows Customer Advisory Team, is now available at:

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032391121&CountryCode=US

To view it, you will need to use your Windows Live ID.

I strongly recommend viewing this Webcast (or downloading it and listening to the WMA file in your car!).

It contains a wealth of information about the Microsoft NAP deployment experience, describes NAP on the Internet, provides a summary of lessons learned, shows a demonstration of IPsec enforcement on the Microsoft network, and includes a Q&A session that answers commonly asked questions about NAP deployment.

Thanks Brent and Pat!

Joe Davies
Senior Program Manager

“How Microsoft does IT: Managing Network Access Protection” TechNet WebCast on Tuesday

MS NAP Team — Thu, 06 Nov 2008 22:31:00 GMT

Heads up, NAP-meisters!

On Tuesday, November 11, at 9:30 AM Pacific Time (US & Canada), our very own Brent Scallan, Senior Systems Engineer with Microsoft IT, and Pat Fetty, Principal Program Manager with the Windows Customer Advisory Team, will present the TechNet WebCast titled “How Microsoft does IT: Managing Network Access Protection.” Both of these distinguished gentlemen are NAP heros of the highest order (their medals are being designed as we speak :>).

Here is the link to register:

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032391120&EventCategory=4&culture=en-US&CountryCode=US

Learn how Microsoft IT deployed NAP at Microsoft, including custom infrastructure elements and lessons learned, and about a cool new scenario known as NAP on the Internet.

Put this one on your calendars!

Joe Davies
Senior Program Manager

Microsoft Assessment and Planning Toolkit 3.2 Beta Released

MS NAP Team — Thu, 16 Oct 2008 19:13:00 GMT

The Microsoft Assessment and Planning (MAP) Toolkit is an integrated platform with tools and guidance that make it easier for you to assess your current IT infrastructure and determine the right Microsoft technologies for your IT needs.

The existing MAP Toolkit 3.1 is located here and includes desktop Windows Security Center assessment, which is instrumental in analyzing your network prior to a NAP deployment. Click here for the NAP blog post that describes this in detail.

The MAP Toolkit 3.2 beta includes a new feature to perform readiness assessment for a deployment of NAP with Microsoft Forefront.

Click here to get on the MAP 3.2 beta and try it out!

Joe Davies
Senior Program Manager

Detailed Ball State University case study published!

MS NAP Team — Wed, 01 Oct 2008 22:53:00 GMT

http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000002748

This detailed case study provides details on the solution, hardware, and the key benefits of deploying NAP with 802.1X enforcement at Ball State University in Muncie, Indiana.

Thanks to Alex Chalmers of Ball State University (all-around NAP champion and fellow NAP guest blogger) and the NAP team's Pat Fetty for making it happen!

Note that this case study is an expanded version of the case study previously published at http://www.microsoft.com/industry/publicsector/partnersolutionmarketplace/CaseStudyDetail.aspx?casestudyid=201245.

Joe Davies
Senior Program Manager

WinCAT blog post on NAP and 802.1X Enforcement

MS NAP Team — Mon, 25 Aug 2008 20:35:00 GMT

Check out the Windows Server Customer Advisory Team (WinCAT) post Network Access Protection Using 802.1x VLAN’s or Port ACLs – Which is right for you?

Our very own Pat Fetty, whom many of you have seen presenting NAP talks at industry conferences, discusses the two ways that you can configure IEEE 802.1X-based switches and wireless access points for NAP using virtual LANs (VLANs) and access control lists (ACLs). Pat then compares the two approaches with their respective pros and cons.

This is very valuable information to review prior to beginning your 802.1X enforcement deployment.

Thanks Pat!

Joe Davies
Senior Program Manager

This posting is provided "AS IS" with no warranties, and confers no rights.

Combining NAP enforcement methods

MS NAP Team — Thu, 31 Jul 2008 20:40:00 GMT

Which NAP enforcement methods provided with Windows can you use together? Here is a section from the upcoming Network Access Protection Design Guide from our technical writer Greg Lindsay:

Combining NAP Methods

While the steps presented in this guide may imply that each enforcement method will be implemented alone it is possible to use more than one enforcement method simultaneously. An organization might invest additional resources into combining these enforcement methods because they have complementary strengths and weaknesses. NAP with VPN enforcement can be used to enforce organizational compliance policies on remote clients, while IPsec could be used for local clients. 802.1X and IPsec offer a particularly robust combination because together they can restrict network connectivity at multiple layers of the network protocol stack. The following table illustrates potential ways to combine enforcement methods. Keep in mind that the complexity of your NAP deployment can increase when you combine enforcement methods.

	IPsec	802.1X	VPN	DHCP
IPsec		ü	ü	ü
802.1X	ü		X	ü
VPN	ü	X		X
DHCP	ü	ü	X

Table 1: NAP enforcement method combinations.

This information is also published in the "Selecting the Right NAP Architecture" Infrastructure Planning and Design (IPD) guide.

These combinations are from the NAP client’s perspective. A NAP deployment can be configured to support all four NAP enforcement methods. However, a NAP client can only use a subset of them, depending on the nature of its connectivity to the intranet.

For example, a NAP client can obtain an authenticated Layer 2 connection to the network using 802.1X (wired or wireless) or a remote access VPN connection. It does not use both. Therefore, from the NAP client’s perspective, it will not use both the 802.1X and VPN enforcement methods when attempting to access an intranet.

Similarly, a remote access VPN client connection does not use DHCP to obtain an IP address. It uses the IP Control Protocol (IPCP) as part of the Point-to-Point Protocol (PPP) connection setup. Therefore, a NAP client does not use both VPN and DHCP enforcement methods.

Another combination of NAP enforcement methods is 802.1X, DHCP, and IPsec.

NAP Guest Blogger: Joe Davies

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 and the Microsoft Assessment and Planning Toolkit 3.1

JeffSigman — Tue, 01 Jul 2008 02:30:00 GMT

The latest version of the Microsoft Assessment and Planning Toolkit 3.1 (aka MAP) was released today from the Solution Accelerators team which contains a cool new feature that just might assist you in your NAP deployment planning.

If you’ve never heard of MAP, it is quite cool. I installed it and played around with it for the first time today. It was quite simple to use, once I overcame the installation pre-requisite hurdles (you need Word + Excel + two shared components of Office installed). Here is Baldwin Ng’s summary of what the tool is all about:

... in a nutshell, MAP is basically a network-wide agent-less tool that can help you quickly find out where your desktops and servers are and then it would auto-generate upgrade recommendations for multiple products and technologies including server, desktop and virtualization migration scenarios covering:

· Windows Vista hardware and device compatibility assessment

· Office 2007 hardware compatibility assessment

· Windows Server 2008 hardware and device compatibility assessment

· Microsoft Application Virtualization hardware compatibility assessment

· SNMP inventory reporting

[... and new to version 3.1]

· Hyper-V virtualization candidates assessment (+ improved virtual machines inventory)

· SQL server discovery and assessment

· 64-bit installation support

· Desktop Windows Security Center assessment

The last one in red is where NAP comes in. NAP out of the box in XP SP3, Vista and Server 2008 tracks compliance around the Windows Security Center. As you probably know, NAP can be extended by 3^rd parties quite easily to extend the compliance checking, but the items in Security Center are a great place to start! MAP is able to inventory your entire network and actually give you a glimpse of you NAP “compliance” without having to deploy it first to find out! Pretty cool!

I ran a short wizard to tell MAP to enumerate all the computers in my AD and to scan them for “Vista compatibility”. It found my only domain-joined computer:

The cool thing about the results is that they are available right through Excel. It showed me that if I enabled NAP today, this machine would probably need some remediation! :->

I encourage you to play around with this awesome update to a very rich tool!

Main download page –or- directly from x86 / x64

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!

FCS + NAP Update

JeffSigman — Tue, 06 May 2008 22:40:00 GMT

The fine folks over at the Solution Accelerators team are making GREAT progress on the Forefront Client Security 1.0 NAP integration (FCS NAP). Check out their latest here. This product extension to FCS/NAP should be shipping publicly very soon! Very cool.

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

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

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}