Network Access Protection (NAP) : FAQ

Selecting PEAP-TLS and other PEAP methods in Windows Vista and Windows Server 2008

MS NAP Team — Tue, 30 Sep 2008 02:52:00 GMT

Windows Vista and Windows Server 2008 support the Protected Extensible Authentication Protocol (PEAP) and the Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) and Transport Layer Security (TLS) authentication methods for PEAP. PEAP can be used in Windows Vista and Windows Server 2008 for remote access VPN connections, 802.1X-authenticated wired connections, and for wireless connections that use the 802.1X, WPA-Enterprise, or WPA2-Enterprise security types. By default, PEAP uses PEAP-MS-CHAP v2. The use of PEAP and a PEAP authentication method is required for the 802.1X and VPN NAP enforcement methods.

For VPN and wireless connections in the Network Connections folder, the list of installed PEAP methods is displayed as a normal drop-down list box from the properties of the Microsoft: Protected EAP (PEAP) network authentication method. There is a different procedure when selecting PEAP types from the following locations:

· The Authentication tab of a wired network connection in the Network Connections folder.

· The Security tab of a Wired Network (IEEE 802.3) Policies policy in Group Policy.

· The Security tab of a Wireless Network (IEEE 802.11) Policies policy in Group Policy.

To select PEAP-TLS or additional PEAP authentication methods from these locations, you must first obtain the properties of the Microsoft: Protected EAP (PEAP) network authentication method. In the Protected EAP Properties dialog box, you must click the down arrow for Select Authentication Method, and then click the small up and down arrows just below the larger down arrow to display the installed PEAP authentication methods. Here is an example.

After the desired PEAP authentication type is displayed, click on its name to select it.

For example, the following procedure selects the PEAP-TLS authentication method:

1. In Select Authentication Method, click the down arrow.

2. For PEAP-TLS, in the drop down list, directly below the down arrow, click the small down arrow to display Smart Card or other certificate, and then click Smart Card or other certificate.

Joe Davies
Senior Program Manager

My review of Information Week’s “Rolling Review: Microsoft NAP”

MS NAP Team — Fri, 26 Sep 2008 21:56:00 GMT

Greetings, keepers of the NAP flame!

On August 2, Information Week published an article titled “Rolling Review: Microsoft NAP.” I would like to comment on it on behalf of the NAP product team and add technical clarity where I can.

1. Opening paragraph:

“it's to Microsoft (NSDQ: MSFT)'s credit that early on the company moved away from trying to develop a proprietary system. Instead, it built a framework; developed a set of APIs for third-party integration; and, most important, aligned itself with the most widely accepted standards body in the NAC space, the Trusted Computing Group.”

We heartily agree with this statement. We decided to create NAP as a platform in conjunction with industry standards, rather than provide a proprietary solution that attempts to address every kind of system health check and every kind of enforcement method.

2. 4^th paragraph

“the Cisco NAC agent provides the administrator with the ability to scan for specific registry keys or other system values, and make policy decisions based on those values. The NAP agent does not.”

The built-in Windows Security Health Agent (WSHA) does not provide these abilities. The NAP Agent service running on a NAP client can host multiple system health agents (SHAs) and third-party vendors can supply additional SHAs to extend the set of health checks. The more accurate statement for the last sentence in this quote is: “The NAP agent with the built-in WSHA does not.”

3. Explanation of DHCP enforcement

“Clients that fail a health check are provided with an IP address and subnet mask, but no default gateway. However, these clients are provided with host routes to remediation servers, where updates can be downloaded and installed automatically or manually.”

Clients that fail system health evaluation are allocated an IPv4 address with a subnet mask of 255.255.255.255, which means that they will not be able to reach other locations on their subnet.

Whether updates are downloaded and installed automatically or manually is a function of the SHAs and related system software that is running on the NAP client. With the correct logic within the SHA and access to remediation servers, SHAs can automatically install and configure components and updates.

4. Explanation of IPsec enforcement

“If a system that lacks a valid health certificate tries to connect to a network that requires one for access, the connection will be dropped.”

IPsec enforcement is combination of health certificates and IPsec policy that requires protected communication with health certificates for authentication. The enforcement is done end-to-end between two communicating nodes, rather than at a connection point to the network.

5. Explanation of VPN enforcement

“VPN enforcement is most easily achieved through the use of Microsoft's Routing and Remote Access server, but third-party VPNs can be made to work with NAP.”

The exact details and requirements for using a third-party VPN server or concentrator with NAP and the VPN enforcement method is something that I am investigating. I will publish the results in a future NAP blog post.

6. Explanation of 802.1X enforcement

“When a system attempts to log on, the NAP client packages its Statement of Health and logon credentials into an EAP authentication request.”

Actually, there are separate EAP authentication methods and message exchanges for authentication and the passing of system health information.

7. Factors for system health

“Out of the box, you can check for the status of Windows firewall and antivirus/anti-spyware software, as well as Windows Updates and the update policy.”

The built-in WSHA monitors the services and components of the Windows Security Center (WSC), which provides system health checks for the following:

· Whether a host-based firewall that is registered with the WSC is enabled. This includes the built-in Windows Firewall and third-party firewall products.

· Whether an antivirus application that is registered with WSC is enabled and up to date. This includes third-party antivirus products.

· Whether an antispyware application that is registered with WSC is enabled and up to date. This includes the built-in Windows Defender for Windows Vista and third-party antispyware products.

· Whether automatic updating is enabled.

· Whether security updates of a specified level have been installed, the time interval within which the client must check for new security updates, and the sources of the updates (Windows Update or Windows Server Update Services).

8. How strict your policies are

“Microsoft recommends a phased implementation where NAP is initially deployed in a reporting-only mode. Once you're comfortable that enforcing health standards won't grind business to a halt, you can move gradually to an auto-remediated enforcement policy.”

NAP can be used to determine the overall system health compliance of your network (reporting mode) and to enforce system health requirements by restricting the access of noncompliant computers (full enforcement mode). Depending on the needs of your organization, either of these modes are acceptable destinations for a NAP deployment. Additionally, autoremediation can be enabled for either deployment mode.

9. The “Two Microsoft NAP Deployment Scenarios” figure

Two points of technical clarification:

· For DHCP enforcement, the NAP client requests an IPv4 address, not access. Therefore, the labels on the arrows between the NAP client and the DHCP server should be “Address requested” and “Address granted.”

· The interaction between NPS and Active Directory for DHCP enforcement is only to verify security group membership. For 802.1X enforcement, NPS uses Active Directory to also validate the credentials of the 802.1X client.

10. “Out for a Spin” section

A. “That's because DHCP in Windows 2008 is NAP-aware and includes the additional user classes and scope options necessary to dynamically black-hole clients that fail health checks.”

I would replace the term “black hole” with “restrict the access of”. The term “black hole” in my mind implies no access, whereas typical NAP deployments contain remediation servers that noncompliant clients must access to correct their system health.

B. “Only Windows XP SP3 and Vista have built-in NAP clients”

Windows Server 2008 also has a built-in NAP client, although it does not include the WSHA.

C. “we had to configure a group policy to get clients to start up the service automatically and participate in DHCP enforcement.”

The location of the Group Policy setting to automatically start the NAP Agent service is Computer Configuration\Policies\Windows Settings\Security Settings\System Services\Network Access Protection Agent.

D. “To our surprise, these non-NAP-capable PCs were quarantined, as though they had failed a health check.”

This behavior is based on the default settings of the Define NAP Health Policy page of the Configure NAP wizard. To prevent non-NAP capable computers from having their access limited, select Allow full network access to NAP-ineligible client computers on the Define NAP Health Policy page.

11. Bottom line paragraph

A. “NAP is a great value for organizations that have yet to invest in NAC”

We agree! :> NAP deployments require NAP infrastructure servers that are running Windows Server 2008 and client computers running a version of Windows that includes a NAP client. For most organizations, this means upgrading your user computers to Windows Vista or Windows XP with Service Pack 3.

B. “Microsoft Network Access Protection is difficult to configure, even for simple enforcement methods.”

The areas of configuration for NAP consist of the following:

· NAP clients: Specific NAP enforcement clients must be enabled and, in the case of Windows XP with SP3, the NAP Agent service must be configured to start automatically. Both of these elements of configuration can be done with Group Policy or a script.

· NAP enforcement points: Depending on the NAP enforcement method, you must enable and configure NAP or restricted access functionality.

· NAP health policy servers: The set of policies for a given enforcement method can be automatically created with the Configure NAP wizard in the Network Policy Server snap-in.

Although we respectfully disagree with their blanket statement about NAP configuration, especially relative to other NAC solutions in the marketplace, we agree that there is room for improvement to investigate in future updates for NAP.

C. “We'd like to see a more intuitive auto-install process for an antivirus or anti-spyware client as part of the auto-remediation process”

As described previously, automatic installation of system health software is a function of the SHA, not the NAP platform. The WSHA does not perform this function, but third-party SHAs can.

Joe Davies
Senior Program Manager

What is the NAP client doing?

MS NAP Team — Sat, 06 Sep 2008 02:13:00 GMT

Greetings, Guardians of NAPness!

Here is an interesting question about NAP client behavior that was posed by a fellow NAP fan:

How does a NAP client communicate a change in health state and get reevaluated and what sort of ongoing traffic is there between the NAP client and the NAP health policy server?

If you have seen a typical demonstration of NAP autoremediation, the demonstrator intentionally turns off the Windows Firewall on a compliant NAP client. Within seconds, a Network Access Protection message appears in the notification area of the desktop indicating that the computer no longer meets the system health requirements of the network, and then another message appears stating that the computer now meets the system health requirements of the network.

The natural questions that arise from seeing this demo are the following:

1. How does the NAP client know that the firewall was turned off?

2. How does the NAP client indicate its new health state to the rest of the NAP infrastructure, get re-evaluated, and receive remediation instructions to turn on the firewall?

3. After turning on the firewall, how does the NAP client get re-evaluated and gain full access to the network?

4. Does the demonstrator realize that he has a tuft of hair towards the back of his head that is sticking straight out, acting for all intents and purposes like a rooftop radio antenna?

I will answer questions 1 through 3 below. As for question 4, I am afraid this issue is beyond the capabilities of the NAP platform at this time and can only suggest a stiff hair gel for a short-term workaround, scissors for a longer term solution, or laser-based hair removal for a permanent solution (or, in my case, a laser is not required; only a few more years are needed!). :>

The summary answer to questions 1 through 3 is that System Health Agents (SHAs) monitor the configuration state of their associated components and system services for changes that affect system health. When a change occurs, the SHA indicates an updated Statement of Health (SoH) to the NAP Client service, which creates a new System SoH (SSoH) and uses its NAP enforcement clients (ECs) to send the new SSoH to their corresponding NAP enforcement points. The NAP enforcement points then send the SSoH to the NAP health policy server for evaluation. At this point, the process for remediation and reevaluation occurs in the same way as if a noncompliant NAP client started up on the network.

Note that the NAP client sends the new SSoH to the NAP health policy server when the configuration change occurs. There is no ongoing, interval-based polling or connection-based data flowing between the NAP client and the NAP health policy server. When indicating a change in health state, the amount of traffic on the wire is the same as the NAP-based traffic when the computer starts up on the network. The traffic on the wire between the NAP enforcement point and the NAP health policy server is typically a handful of RADIUS messages; two messages for each round trip to the NAP health policy server.

Let’s apply this explanation to the demonstration: When the Windows Firewall is turned off, the Windows Security Health Agent (WSHA) notices the configuration change, creates a new SoH (with the Windows Firewall state set to disabled), and indicates it to the NAP Client service. The NAP Client service creates and sends a new SSoH containing the updated WSHA SoH to its enforcement point, who forwards it on the NAP health policy server.

The next question that arises from this explanation is the following: OK, smart guy, how exactly does the NAP client indicate the new SSoH to the NAP enforcement point, who forwards it to the NAP health policy server?

I am glad that you asked…

The exact method of indicating the new SSoH depends on the NAP enforcement method. Here is how it is done:

· For IPsec enforcement, the NAP client computer deletes its current health certificate and contacts its HRA to obtain a new health certificate. In the ensuing process, the NAP client sends the SSoH to the HRA over HTTP or HTTPS.

· For 802.1X enforcement, the NAP client computer initiates 802.1X reauthentication on its existing wired or wireless connection. In the ensuing authentication process, the NAP client sends the SSoH in a PEAP-TLV message.

· For VPN enforcement, the NAP client computer restarts PPP-based authentication on its existing remote access VPN connection. In the ensuing authentication process, the NAP client sends the SSoH in a PEAP-TLV message.

· For DHCP enforcement, the NAP client computer attempts to renew its current DHCP-based IPv4 address configuration. The NAP client sends the SSoH in the DHCPRequest message.

Are there any more questions? It’s Friday. Can I go home now? :>

Joe Davies
Senior Program Manager

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

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 Infrastructure Planning and Design (IPD) Guide Now Available!

JeffSigman — Sat, 28 Jun 2008 04:19:00 GMT

Would you like help selecting the best NAP enforcement method to accomplish your goals? Well, you’re in luck. The fine folks on the Solution Accelerators team have created guidance on just that topic!

The document is entitled “Selecting the Right NAP Architecture”. Here is the main page which lists the available Infrastructure Planning and Design Guides.

Solution Accelerators are free, scenario-based guides and automations designed to help IT professionals who are proactively planning, deploying, and operating IT systems using Microsoft products and technologies. Solution Accelerator scenarios focus on security and compliance, management and infrastructure, and communication and collaboration.

NAP the WORLD baby,

Jeff

NAP 802.1X Configuration Walkthrough – Part 3

JeffSigman — Sun, 22 Jun 2008 21:02:00 GMT

This is a continuation from Part 1 and Part 2.

Step 3 – NAP Clients, it’s just too easy

NAP can be configured from the command-line, the MMC (except on XP SP3) and of course Group Policy (GP). Since this is a workgroup scenario, I am going to skip GP – but the principles below are the same.

· Start the services snap-in and locate these two services – “Network Access Protection Agent” (NAPAgent) and “Wired AutoConfig” (dot3svc).

· Start NAPAgent and Dot3svc; set both to “Automatic” startup.

sc config NAPAgent start= auto
net start NAPAgent
sc config Dot3Svc start= auto
net start Dot3Svc

· Start the NAP Client Configuration snap-in; click on the “Enforcement Clients” link.

· Enable the “EAP Quarantine Enforcement Client” by double-clicking on it and selecting “Enable this enforcement client”.

netsh NAP client set enforcement ID = "79623" ADMIN = "ENABLE"

· Click on the “User Interface Settings” link; double-click on the “User Interface Settings” entry to configure text to be displayed to users when NAP is unable to (or in progress of) auto-remediate a problem on the computer.

netsh NAP client set userinterface TITLE = "I regret to inform you that you have been NAP'd!!" TEXT = "Please logoff and go home, do not collect $200"

· You may export / import these settings if you wish.

netsh NAP client export FILENAME = "c:\NapCfg.xml"
netsh NAP client import FILENAME = "c:\NapCfg.xml"

· Start the Network Connections folder; right-click on your network interface and select “Properties”.

· Since you started the “Dot3Svc”, you will now see the “Authentication” tab; Enable 802.1X and caching; Make sure PEAP is selected; Clicks “Settings”.

· In the “Protected EAP Properties” dialog, un-check “Validate server certificate”; Select MS-CHAPv2; Check “Enable Quarantine checks”; Click “Configure”.

· In the “EAP MSCHAPv2 Properties” dialog, un-check the auto-use credentials setting – this is because we are in a workgroup – if you were in a domain you would want to leave this enabled so the domain user would automatically use his domain credentials.

· After you “OK” all of those dialogs, the 802.1X client should now attempt to authenticate to the switch port; if not, simply enable/disable or unplug/plug the NIC; you should get prompted for credentials; type the user / password.

· If everything works you should see something like this; any failures usually show “authentication failed”.

· Thankfully, you can also use the command-line to export/import these settings too.

netsh lan export profile FOLDER = "c:\\"
netsh lan add profile FILENAME = "c:\LANProfile.xml"

Hopefully you now have end-to-end NAP 802.1X working. If not, my next installment includes troubleshooting! :->

Jeff

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

How ‘bout some NAP perspective from the field

JeffSigman — Tue, 13 May 2008 08:04:00 GMT

Hello NAP Bloggers! My name is Mark Foust, a Windows Server Networking Technical Specialist working down in Tampa Florida (USA). I wanted to share a bit of my perspective on the world of {NAP}.

7 things you may not have considered about NAP:

1. NAP enforces minimum consistency levels, not maximum security

NAP should be looked at as a mechanism to enforce the minimum machine / device requirements, not maximum levels. NAP is not meant as a lockdown mechanism, rather an enabler of IT by automating minimum security levels during connection (as well as on-going compliance). NAP is not a holistic security template, nor a point of control for managing the patch levels for every device. NAP is enforced at entry points in your infrastructure DHCP, VPN, IPSEC and 802.1X entry points. As with every technology there will be some devices that need exceptions….see #6

2. NAP doesn’t care much about your user login

Assuming you are in the same forest/domain as your workstation---a somewhat safe assumption. NAP is typically device / machine based and not user based; an important distinction as it is the hardware device object, in Active Directory, that requires the Group Policy objects to be applied, not users. Note that Group Policy is applied in a L>S>D>OU fashion---Local, Site, Domain and OU. In that order and last writer wins any conflicts.

The exception to this is 802.1X + NAP – you are able to do machine AND user authentication at the hardware layer and can create user based NAP policies. Also notable is that NAP functions in a “workgroup” and doesn’t require a domain at all!

3. NAP’s greatest initial advantage is REPORTING

You may not have considered this, but enforcing something as simple as a single AV engine or update may have unintended consequences on your network. For example, what if you found out that 17% of your users were not running standard up-to-date AV signatures? NAP would/could lock out 17% of your company for failing to comply. You’d probably find a lot of lab machines, vendor laptops (guests), virtual machines and line of business (LOB) devices that may have been granted such AV exceptions in the past. Be careful. You will want to initially only report on each policy violation. This is going to give you information you’ve long needed to report on LOB compliancy, vendors and a cadre of other statistical variances that you have probably not considered.

4. NAP should not be viewed as a forklift type of upgrade or enforcement mechanism.

You must exercise caution when implementing restrictive policies on an enterprise. Reasonable preparation before enforcement should include testing, piloting, communication to your end-user community, and training of help desk to assist in remediation of issues that occur. Also, a good back-out plan should be in place should there be too restrictive a setting enforce or errors. Proper lab testing and production pilot testing involving sample groups is always a best practice. Allow for time to do administrative knowledge transfer---should the main NAP administrators be away for a couple days. In other words, don’t wait for an implementation issue to bite you before you plan.

5. NAP will highlight your weak operational issues.

This is a good thing. If you’ve not spent much time considering how you remediate the automation types of issues that NAP will remediate, you are going to get a chance. If you’ve felt like you’ve not had much executive support to enforce patching / update minimums in the past, NAP will help push that conversation. The key word here is automation to remediate patching / updating types of issues. This will help you enforce security maturity across your enterprise. With NAP, it becomes harder to exclude the guilty client workstations / device---a very different way to govern for you. Every enterprise has silos and fiefdoms. NAP helps bridge this gap with a constant, consistent, enterprise-wide, minimum enforcement mechanism. You are not the bad guy anymore. When someone comes to you mad that you patched their machine, you are able to defer patching enforcement discussions to a higher power---NAP in the cloud. :->

6. You will need to make some exceptions for NAP

NAP provides a mechanism to support your administrative needs to ensure everyone is at least on a minimum patch / security level. This may not play well with certain applications that only support a standard like n-2 or an old legacy Server 2003 SP1 machine. Realize that this constant enforcement of updating does not replace your testing needs around application compatibility testing. You may find that NAP will cause you to mature your OU structure. Application Servers may get their own OU now---which is a best practice for Active Directory Security anyway….to break your servers down into roles and possibly applications as sub-sets of those roles, then apply more/less restrictive policies on those servers.

7. NAP will become a foundational part of your infrastructure

NAP is not just a simplistic feature; it is a service running on your OS [for Windows Server 2008, Vista RTM/SP1, and XP SP3]. This service will bring stability, security, maturity through automation to your enterprise. Your homework: Figure out why this is so important at a high level.

NAP the world baby!

- Mark

NAP FAQ: Logging baby, logging

JeffSigman — Sun, 27 Apr 2008 00:17:00 GMT

A colleague of mine pointed out an AMAZING blog post on the Windows Server Customer Advisory Team (WinCAT) team blog - The Definitive Guide to NAP Logging. This is a kick butt troubleshooting post! Very useful when trying to track down what is wrong between NAP Client and Server.

Much thanks Pete Rivera (the author), John Morello (the all-around cool guy) and Louis Hardy (for pointing it out to me)!

Cheers!

{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

Gotchas, FAQs, Best Practices, and Tips for Implementing NAP in Configuration Manager (SCCM + NAP)

MS NAP Team — Mon, 21 Apr 2008 23:41:00 GMT

My previous guest post walked you through what was happening in the background with Configuration Manager NAP when a noncompliant computer connected to the network, and was restricted and remediated for a software update. This post follows up with some gotchas, FAQs, best practices, and tips for implementing NAP in Configuration Manager.

I’m Carol Bailey, Senior Technical Writer for System Center Configuration Manager 2007 (formally SMS 2003), and I’m involved with many of the security-related features in Configuration Manager – including Internet-based client management, desired configuration management, ….. and Network Access Protection (NAP).

Gotchas:

The prereqs. Of particular note for NAP, you must extend the Active Directory schema for Configuration Manager 2007: Prerequisites for Network Access Protection.
Remediation in Configuration Manager does not include installing the Configuration Manager client (SCCM SHA) if it is not installed. If the policies on the NAP health policy server (NPS) include the Configuration Manager System Health Validator (SCCM SHV) and do not exclude computers that do not have the Configuration Manager client (SCCM SHA) installed, the computer will be deemed noncompliant and cannot be automatically remediated. In the Network Access Protection dialog box, you’ll see “SHA Not Present” with ID 79745. In this scenario, either configure exemption policies for computers that should not have the Configuration Manager client (SCCM SHA) installed, or provide a method of manually installing the client that works when the computer is on the restricted network.
Until you enable the Network Access Protection client agent (aka NAPAgent; not enabled by default), the Policies node under the Network Access Protection node in the Configuration Manager console does not display, and neither does the NAP Evaluation tab in the software update, or the NAP option in the Deploy Software Update Wizard.
If the NAP health policy server (NPS) allows full network access (“reporting mode”), Configuration Manager will not remediate on the unrestricted network. This facility is supported through standard Configuration Manager software updates. Additionally, if the NAP health policy server (NPS) is enforcing health policies, Configuration Manager will always remediate noncompliant computers, even if the option on the NAP health policy server Enable auto-remediation of client computers is not enabled. For more information, see About Network Access Protection Remediation and Configuring Network Policies for Configuration Manager Network Access Protection.
Unlike software update deployments, NAP policies in Configuration Manager are not targeted to collections – they are automatically targeted to all clients assigned to the site.
Like other objects that are created in a Configuration Manager hierarchy, NAP policies flow down the hierarchy. However, unlike other objects, child sites cannot create their own NAP policies. For more information: About Network Access Protection in Configuration Manager Hierarchies.
Do not expect NAP in Configuration Manager to offer real-time enforcement. While NAP helps keep computers compliant over the long run, enforcement delays might be several hours or more due to a variety of factors, including the settings of various configuration parameters. However, you can minimize these delays if you have a zero-day exploit situation (see How to Configure a Configuration Manager NAP Policy for a Zero-Day Exploit in Network Access Protection).

FAQs:

Q: Does NAP in Configuration Manager require you to be running Windows Server 2008 on the servers?

A: No, only the server with the Network Policy Server (NPS) role and configured as a NAP health policy server must be running Windows Server 2008. This is the server onto which you install the Configuration Manager System Health Validator (SCCM SHV) point.

Q: I’m using DHCP and VPN enforcement. Which servers need to be added to the Remediation Server Group on the Network Policy Server (NPS)?

A: The Configuration Manager remediation servers (management point, software update point, and distribution points) are automatically added to the Remediation Server Group – there is no need to manually add them. However, you will still need to add servers that provide infrastructure services, such as DNS servers and domain controllers. More information: Configuring Remediation Server Groups for Configuration Manager Network Access Protection.

Q: Why is the Configure button not available for the Configuration Manager System Health Validator (SCCM SHV) on the Network Policy Server (NPS)?

A: With the exception of mapping error conditions to compliant or noncompliant, configuration for the Configuration Manager System Health Validator (SCCM SHV) is done through the Configuration Manager console, by configuring the properties of the System Health Validator Point Component Properties. To help you understand these configuration options and the consequences of changing the default values, use the F1 help: System Health Validator Point Component Properties.

Q: How do you configure NAP for a cross-forest scenario?

A: See About Network Access Protection and Multiple Active Directory Forests. As with all Configuration Manager site system servers, the Configuration Manager System Health Validator (SCCM SHV) must reside on a member server; it is not supported in a workgroup environment. However, it can be installed in a different forest than the site server’s forest.

Q: Do you have a step-by-step or checklist for configuring NAP in Configuration Manager?

A: See Administrator Checklist: Configure Network Access Protection for Configuration Manager and you might also find the following useful: Example Scenarios for Implementing Network Access Protection in Configuration Manager.

Q: Why is my Configuration Manager client going into restriction when it has all the software updates that are configured for NAP?

A: The Configuration Manager System Health Validator (SCCM SHV) makes a number of checks for compliance. A client might be noncompliant because it hasn’t downloaded the latest policies; its statement of health has expired; or it’s from an unknown site. For more information, see About Compliance for Network Access Protection in Configuration Manager.

Q: I’ve heard that the Configuration Manager client might use a cached statement of health (SoH) rather than performing a fresh evaluation when it is asked for its health state – what’s going on here?

A: There are several scenarios under which the client can use a cached statement of health (SoH). Using a cached statement of health results in faster connections, but the NAP evaluation information might be out of date. For more information, see About the Statement of Health (SoH) in Network Access Protection and NAP Evaluation Conditions for Configuration Manager Clients.

Q: I’m testing NAP in Configuration Manager, and clients have full network access when they should be restricted. How can I troubleshoot this?

A: There are multiple possible reasons for this scenario. Check Computers Have Full Network Access When They Should Not Using Network Access Protection.

Q: I’m testing NAP in Configuration Manager, and clients are failing to remediate. How can I troubleshoot this?

A: There are multiple possible reasons for this scenario. Check Client Fails to Successfully Remediate with Network Access Protection.

Q: What log files are specific to Configuration Manager NAP?

A: See Log Files for Network Access Protection.

Best Practices:

For a complete list, see Best Practices for Network Access Protection and Network Access Protection Security Best Practices:

· Confirm the successful installation of software updates on the unrestricted network using the software updates feature in Configuration Manager before configuring software updates for Network Access Protection (NAP).

· Test average remediation times to set expectations.

· Educate users in advance to encourage them to install software updates before the NAP effective date.

· Do not install the WSUS system health agent on a computer that has the Configuration Manager client installed with the Network Access Protection client agent enabled.

Tips:

Factor in early the collaboration that will needed between different groups and define the processes that will be used for a smooth transfer of responsibilities. Probably more than any other feature in Configuration Manager, NAP requires careful coordination with multiple teams. For a list of the different roles and processes that might be involved, see Determine Administrator Roles and Processes for Network Access Protection.
Be prepared for the political consequences of restricting network access. In the heat of the moment it can be difficult to justify this preventative action when it impacts short term business continuity. For examples of how implementing Network Access Protection can affect users in their working environment, see Example Scenarios for Implementing Network Access Protection in Configuration Manager.
Installing software updates can result in requiring a reboot, which is enforced when remediating on the restricted network. If this is unacceptable in your working environment, consider enforcing compliance on the full network for a limited time (deferred enforcement) – in this scenario the reboot is requested but not enforced until the grace period ends. For more information, see the section “Remediation Restarts and Retries” in About Network Access Protection Remediation and the flowchart Enforced Compliance with Network Access Protection in Configuration Manager.
Download and take the Network Access Protection quiz (available as one of the Configuration Manager quizzes). It’s fun, informative, and checks that you’re in good shape to start implementing NAP in Configuration Manager. (Hint, many of the answers are in this post!).

If you have any questions or feedback about the documentation for Configuration Manager NAP, you can e-mail me (Carol.Bailey@Microsoft.com) or my documentation team (SMSDocs@Microsoft.com).

- Carol

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

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)

Looking to integrate your product with NAP?

MS NAP Team — Fri, 15 Feb 2008 00:42:00 GMT

If so, you have probably already taken a look at our MSDN area, and probably even our sample code in the Platform SDK (…\Microsoft SDKs\Windows\v6.0\Samples\NetDs\NAP). Well, I have some good news for you. We worked with an awesome guy by the name of Dan Griffin (JWSecure, Inc.) to build a better example of how to integrate with NAP.

Dan really put something cool together that is closer to a real world implementation. I welcome you to sample his nicely done “Registry” System Health Agent (SHA) / System Health Validator (SHV).

We always welcome new NAP Partners! To find out how to become a NAP partner, drop us a line.

Cheers and NAP the WORLD!

Jeff Sigman
Senior Program Manager
Network Access Protection (NAP)

Please check out the NAP Blog, FAQ, Forum, MSDN and Site.

XP NAP Rude Q and A

MS NAP Team — Fri, 09 Nov 2007 03:09:00 GMT

Since I spend nearly 1/3 of my week answering (or ignoring :->) emails about the XP NAP Client, I thought it might be smart to give a very concise Q&A. Here goes:

Questions	Jeff’s (brilliant) Answers
How do I get a copy of the BETA?	While it is on MSConnect, it is easier just to email me to get a copy. I have US-English and Language Neutral versions from the April 2007 Beta release. Remember, this is a BETA and is not officially supported (i.e. no QFEs); see XP SP3 info below.
How will this actually release officially?	ONLY via Windows XP Service Pack 3.
When will XP SP3 RTM?	1H CY2008
Will you please ship it outside of SP3?	I am sorry, no.
Why won’t you ship it outside of SP3?	In brief, the risk and cost to Windows was too high. NAP on XP changes 19+ core OS files (e.g. RAS, Wireless, EAP, etc) and we wouldn’t get the same testing coverage outside of SP3. Also, OOB releases are notoriously expensive to sustain. The code base would have to be maintained, orthogonally to XP itself, for 10+ years (i.e. MSRC’s). Wow.
How does the XP client compare with Vista?	Read my cool blog post.
Is it true that you brought all the great Vista Wired 802.1x features to XP?	Very true. Many customers have wanted Group Policy configuration for Wired 802.1x on XP. NAP gave us the needed business justification to pull it off in XP SP3.
Will the NAP Client release for any other Microsoft O/S’s?	Not at this time. No support for Windows Bob, 3.x, 9x, ME, 2000 and/or 2003.
What about Linux, Mac, etc?	Oh yeah baby, we have Linux right now. Mac is nearly here. This is the dude making it all happen.
What administration tools are available in the XP Client?	Only the command-line (netsh.exe nap). The MMC was written in managed code and isn’t available on XP. Also, our assumption is that Group Policy / script is good enough for XP.
What Active Directory schema changes are required, if any?	NAP, in general, does NOT require any AD schema updates. NAP fits in well with existing Server 2000/2003 deployments and simply requires a minimum of ONE Server 2008 computer (NAP Server / NPS). However, in order to manage Vista (and XP SP3) Wired 802.1x settings a schema update may be required. If you are using Server 2008 AD, it is included. Server 2003 AD requires an updated schema.
Will XP NAP honor my GP configuration settings just like Vista NAP (i.e. NAPAgent, QECs, etc)?	Yup!

Thanks for helping us NAP the WORLD!

Jeff Sigman
Senior Program Manager

Network Access Protection (NAP)

NAP Blog

NAP Forum

NAP Site