Greetings, fellow disciples of NAP!

Here is a summary of the different system health agents (SHAs) that are currently available from Microsoft.

Note: The following text was shamelessly “leveraged” from our own Greg Lindsay’s upcoming Network Access Protection Design Guide. Thanks Greg!

Microsoft provides the following SHAs for the NAP platform:

·         Windows Security Health Agent (WSHA)

·         System Center Configuration Manager SHA (SCCM SHA)

·         Forefront Client Security SHA (FCS SHA)

This list does not include the SHAs available from our NAP partners, which I will describe in a future blog post. Let’s talk about each one.

Windows Security Health Agent (WSHA)

The WSHA is included with Windows Vista and Windows XP with Service Pack 3 and monitors the operational status of the Windows Security Center (WSC) on NAP client computers. The WSHA monitors the following:

·         Firewall: If required, the NAP client must have a firewall enabled for all network connections.

·         Virus Protection: If required, the NAP client computer must have an antivirus application installed, registered with WSC, and turned on. The NAP client can also be required to have an up-to-date antivirus signature file installed.

·         Spyware Protection: If required, the NAP client must have an antispyware application installed, registered with WSC, and turned on. The NAP client can also be required to have an up-to-date antispyware signature file installed. Spyware protection only applies to NAP clients running Windows Vista.

·         Automatic Updating: If required, the NAP client must be configured to check for updates from Windows Update. You can also require the NAP client to automatically download and install updates.

·         Security Update Protection: If required, the NAP client must have security updates installed based on one of four possible values that match security severity ratings from the Microsoft Security Response Center (MSRC). You can also specify the use of Windows Server Update Services (WSUS) or Windows Update to obtain security updates.

Common point of confusion: The capability of the NAP platform is sometimes equated to the capability of the WSHA and if there is a system health check that is not supported by WSHA, then the NAP platform cannot support it. This is, of course, not correct, and is most likely based on an oversimplification of NAP functionality that is included with Windows. However, just like Windows includes basic functionality for drawing (the Paint program) and supports much more capable drawing programs (such as Adobe Illustrator), NAP is a platform that allows any kind of system health check through the installation of additional SHAs, which can be developed using the NAP APIs. Additional SHAs can verify all kinds of things, from contacting an intrusion detection system (IDS) to ensure that your computer is not performing an address scan on the intranet (an IDS SHA) to automatically calling your Aunt Brenda to make sure that she is wearing her sweaters around the house because it is starting to get cold (the AB SHA :>).

System Center Configuration Manager SHA (SCCM SHA)

The SCCM SHA monitors a NAP client computer for compliance with required software updates that you specify. When a computer connects to the network, the SCCM SHA provides the current state of compliance, a site code, and a health state reference. The health state reference and site code are used to check whether or not a client computer has received the latest software update requirements from a Microsoft Systems Management Server (SMS) management point. If the health state is determined to be out of date, the client computer downloads a new set of requirements and health is evaluated again.

When you deploy a software update with SCCM, you can select the update for NAP evaluation and specify a date and time when the policy will become effective. Only those updates that have been enabled for NAP evaluation in the Configuration Manager console are required to be installed on compliant NAP clients.

For more information about SCCM and NAP, see Network Access Protection in Configuration Manager.

Forefront Client Security SHA (FCS SHA)

The FCS SHA monitors the operational health of FCS on the client computer. The administrator-defined health policy on the SHV determines whether the client computer is compliant before it is allowed to access the network. To monitor and report on FCS-related aspects of computer health, the FCS SHA queries NAP client registry settings, checks the status of system services, and verifies that the NAP client has the latest patches and malware signature definitions. The FCS SHA also sends data to the FCS server management system, which provides manageability, data collection, and reporting services.

The FCS SHA monitors the NAP client’s level of Forefront protection. Noncompliance with the FCS SHA does not necessarily mean that the computer has a virus or some other active threat, but that the FCS configuration is either incorrect or not up-to-date as defined in the health policy. The FCS SHA can restart services on noncompliant NAP clients, automatically update configuration settings, and install software updates if required.

For more information about the FCS SHA, see the Microsoft Forefront Integration Kit for Network Access Protection.

Joe Davies
Senior Program Manager

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

Greetings NAP fans!

Back from vacation and thought I would share this with you...

What are the available Network Access Protection (NAP) training solutions from Microsoft?

The first place to look is the Microsoft Learning Web site. This page lists all of the resources available from Microsoft Learning related to NAP, including E-Learning courses, classroom training courses, training plans, and a link to the Windows Server 2008 Networking and Network Access Protection (NAP) Microsoft Press book (highly recommended! :>).

Here are E-Learning courses for NAP:

·         Course 6170: Designing Network Access Protection in Windows Server 2008

·         Course 6533: Configuring Network Access Protection in Windows Server® 2008

·         Course 6534: Configuring Network Access Protection by Using IPsec in Windows Server® 2008

Check out the Windows Server 2008 Learning Portal for additional courses about networking technologies in Windows Server 2008.

Enjoy.

Joe Davies
Senior Program Manager

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

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

Hey NAP fans!

Check out this blog post from Blue Ridge Networks: Data Leak Prevention and Network Access Protection (NAP)

This blog post was written by Eirik Iverson, Product Manager at Blue Ridge and recent guest NAP blogger.

Eirik's post describes a painful data leak and how NAP can be used for defense-in-depth to prevent rogue computers from attaching to networks and accessing network resources. Thanks Eirik!

Enjoy.

Joe Davies
Senior Program Manager

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

When you create a new RADIUS client or modify the settings of an existing RADIUS client from the RADIUS Clients node of the Network Policy Server snap-in, there is a RADIUS client is NAP-capable check box. Here is an example.

What is this check box all about?

As I state in the Windows Server 2008 Networking and Network Access Protection (NAP) book, you should select this box if the RADIUS client is a NAP enforcement point that is running Windows Server 2008. That is, if the NAP enforcement point is one or more of the following:

·         A Health Registration Authority (HRA) for IPsec enforcement

·         A virtual private network (VPN) server for VPN enforcement

·         A Dynamic Host Configuration Protocol (DHCP) server for DHCP enforcement

·         A Terminal Server (TS) Gateway server for TS Gateway enforcement

When this check box is selected, the NPS service sends NAP-specific RADIUS vendor-specific attributes (VSAs) in the Access-Accept message. When this check box is not selected, the NPS service does not send NAP-specific RADIUS VSAs in the RADIUS Access-Accept message.

When configuring RADIUS clients for a NAP deployment, do the following:

·         For RADIUS clients corresponding to Windows Server 2008-based NAP enforcement points, select the RADIUS client is NAP-capable check box. Windows Server 2008-based NAP enforcement points use the information in the NAP-specific VSAs to determine the state of the NAP client and how to limit the access of a noncompliant NAP client. Also included in these VSAs is the System Statement of Health Response (SSoHR), which the enforcement point passes to the NAP client. For a complete listing of these VSAs, click here.

·         For RADIUS clients corresponding to IEEE 802.1X-capable switches and wireless access points for 802.1X enforcement, clear the RADIUS client is NAP-capable check box. Some IEEE 802.1X-capable devices automatically deny connections when the Access-Accept message contains attributes that the device is not expecting. In the case of 802.1X enforcement, the IEEE 802.1X-capable devices are instructed to limit the access of noncompliant NAP clients through standard RADIUS attributes such as Filter-ID and Tunnel-Type. With 802.1X enforcement, the NAP health policy server sends the SSoHR and other NAP-specific information directly to the NAP client using a Protected Extensible Authentication Protocol (PEAP) message.

When you create RADIUS clients from within the Configure NAP wizard, you do not have the ability to configure this check box. You must modify the RADIUS client configuration from the RADIUS Clients node of the Network Policy Server snap-in after completing the Configure NAP wizard.

Joe Davies
Senior Program Manager

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

Greetings NAP fans!

I just found out about this and had to share it with the NAP community. The Enterprise Networking Customer Support team here at Microsoft has a blog at http://blogs.technet.com/networking/default.aspx. This blog has been around since April of 2007 (I may have been living in a cave since then…).

In this blog, the Microsoft engineers that support enterprise networking technologies in Windows share tips and tricks, technical information about support issues, lists of new Microsoft Knowledgebase articles, and much more.

If you deploy or support Windows enterprise networking technologies, take a look at this valuable resource and add it to your RSS feeds.

Joe Davies
Senior Program Manager

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

Greetings NAP fans!

As Jeff Sigman described in his last NAP blog post, I have taken over his role on the NAP product team and will be managing the NAP blog going forward. Thanks Jeff for your years of hard work and dedication in making NAP a great product and building a NAP community!

As many of you know, I have been a technical writer at Microsoft for years and wrote the TechNet column The Cable Guy from 2000 to 2008. For more information, see my Cable Guy bio and Wikipedia article. My latest and greatest accomplishment as a technical writer is the Windows Server 2008 Networking Suite, a set of 4 books that take the reader from the basics, to deployment and troubleshooting, to protocols and packet structure for networking services in Windows Server 2008 and Windows Vista. The Windows Server 2008 Networking Suite includes the Windows Server 2008 Networking and Network Access Protection (NAP) title from Microsoft Press.

I am very excited about my new role on the NAP product team and doing whatever I can to help you realize the potential of NAP on your networks.

My goals for the NAP blog are the following:

·         Describe the improvements that the NAP product team and other product teams at Microsoft are making to NAP and associated Windows networking and security services
·         Share technical information about NAP and how it works
·         Share NAP deployment tips and tricks
·         Provide information about NAP presentations at industry conferences
·         Interact with you, the NAP technical community, to determine how we can improve your experience with NAP

I look forward to serving you with great content on the NAP blog and meeting you in the future.

Onward and upward!

Joe Davies
Senior Program Manager
josephd@windows.microsoft.com

Greetings NAP fans! Guest NAP team blogger Joe Davies here with a somewhat self-serving blog entry.

I just wanted to remind all of you that the Windows Server 2008 Networking and Network Access Protection (NAP) book from Microsoft Press, written by yours truly and Tony Northrup (a Microsoft MVP and highly prolific and experienced author), is now bundled in the Windows Server 2008 Resource Kit from Microsoft Press. Obviously, if you purchase the Windows Server 2008 Resource Kit, you do not also need to separately purchase the Windows Server 2008 Networking and Network Access Protection book.

You can get the Windows Server 2008 Resource Kit from the following online book sellers:

·         Amazon.com

·         Barnes and Noble

·         Quantum Books

Although I wrote a lot of networking content for the Windows 2000 Server Resource Kit and several books for Microsoft Press, this is the first time that one of my print books has made it into a Windows Server Resource Kit (…and there was much rejoicing.)

By the way, the Networking and NAP book is not the thickest book in the Resource Kit set. The Windows Server 2008 Active Directory title is 827 pages, while the Networking and NAP book is only 817 pages. [Note to self: In the next version, add at least 11 pages with the text “This page intentionally left blank.” :> ]

Enjoy.

Joe Davies

P.S. The updates described in the July 29 NAP Team blog entry apply to the version of the Networking and NAP book included in the current Windows Server 2008 Resource Kit.

P.P.S. The Amazon.com listing for the Windows Server 2008 Resource Kit refers to NAP as “network aspect projection.” I am not sure what network aspect projection is, but it sounds pretty cool. Meanwhile, we are working with Amazon.com to get this corrected.

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.

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

Hello NAP fans! Joe Davies here, also known as The Cable Guy for TechNet, reporting on some updates to the Windows Server 2008 Networking and Network Access Protection (NAP) book from Microsoft Press.

Although we made every attempt to verify the information in the book, here are some updates based on last minute product changes and for stuff that we did not catch. Future printings of this book will reflect these changes.

1. On page 642, the text for the "Creating the Certificate Template for Health Certificates" section at the bottom of the page:

Should be changed to the following:

2. On page 643, the following block of text:

 1. Click Start, click Run, type certtmpl.msc, and then press ENTER.

2. In the details pane, right-click Workstation Authentication, and then click Duplicate Template. This template is used because it is already configured with the client authentication EKU.

3. On the General tab, under Template Display Name, type System Health Authentication.

4. Select the Publish Certificate In Active Directory check box.

5. Click the Extensions tab, and then click double-click Application Policies.

6. Click Add, and then click New.

7. In the New Application Policy dialog box, under Name, type System Health Authentication, and under Object Identifier, type 1.3.6.1.4.1.311.47.1.1. The Client Authentication application policy will already be present.

8. Click OK three times, and then click the Security tab. Because the WorkStation Authentication template was duplicated, this template should have two application policies: Client Authentication and System Health Authentication.

9. Click Add, type the name of your IPsec NAP exemption group (such as IPsec NAP Exemption), and then click OK.

10. On the Security tab, in the Groups Or User Names list, select the name of your IPsec NAP exemption group, and then select the Allow check box next to Autoenroll. Click OK.

For a Windows Server 2008–based NAP CA, you must ensure that the System Health Authentication certificate template has the appropriate permissions for autoenrollment in the IPsec NAP exemption group.

To Configure the Permissions on the System Health Authentication Certificate Template

1. Click Start, click Run, type certtmpl.msc, and then press ENTER.

2. In the details pane, right-click System Health Authentication.

3. On the Security tab, click Add, type the name of your IPsec NAP exemption group, and then click OK.

Should be changed to the following:

1. Click Start, click Run, type certtmpl.msc, and then press ENTER.

2. In the details pane, right-click Workstation Authentication, and then click Duplicate Template. This template is used because it is already configured with the client authentication EKU.

3. For a Windows Server 2008-based NAP CA, click Windows Server 2008, Enterprise Edition in the Duplicate Template dialog box, and then click OK.

4. On the General tab, under Template Display Name, type System Health Authentication.

5. Select the Publish Certificate In Active Directory check box.

6. Click the Extensions tab, and then double-click Application Policies.

7. For a Windows Server 2008-based NAP CA, click Add, double-click System Health Authentication, and then click OK.

8. For a Windows Server 2003-based NAP CA, click Add, and then click New. In the New Application Policy dialog box, under Name, type System Health Authentication, and under Object Identifier, type 1.3.6.1.4.1.311.47.1.1. The Client Authentication application policy will already be present. Click OK three times.

9. Click the Security tab.

10. Click Add, type the name of your IPsec NAP exemption group (such as IPsec NAP Exemption), and then click OK.

11. On the Security tab, in the Groups Or User Names list, select the name of your IPsec NAP exemption group, and then select the Allow check box next to Enroll and Autoenroll.

Please feel free to print these updates and tape or staple them to pages 642 and 643 of your printed book so that your copy has the correct information.

Thanks!

Joe Davies

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

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!