Components of Network Access Protection (NAP)

Components of a NAP-Enabled Infrastructure.

The components of a NAP-enabled network infrastructure consist of the following:
2

NAP clients - Computers that support the NAP platform and include computers running Windows Server 2008, Windows Vista, or Windows XP SP3.

NAP enforcement points - Computers or network access devices that use NAP or can be used with NAP to require the evaluation of a NAP client’s health state and provide restricted network access or communication. NAP enforcement points use a Network Policy Server (NPS) that is acting as a NAP health policy server to evaluate the health state of NAP clients, whether network access or communication is allowed, and the set of remediation actions that a noncompliant NAP client must perform. Examples of NAP enforcement points are the following:

* Health Registration Authority (HRA) -A computer running Windows Server 2008 and Internet Information Services (IIS) that obtains health certificates from a certification authority (CA) for compliant NAP clients
* Network access devices -Ethernet switches or wireless access points (APs) that support IEEE 802.1X authentication
* VPN server -A computer running Windows Server 2008 and Routing and Remote Access that allows remote access VPN connections to an intranet
* DHCP server -A computer running Windows Server 2008 and the Dynamic Host Configuration Protocol (DHCP) Server service that provides automatic Internet Protocol version 4 (IPv4) address configuration to intranet clients

NAP health policy servers -Computers running Windows Server 2008 and the NPS service that store health requirement policies and provide health state validation for NAP. NPS is the replacement for the Internet Authentication Service (IAS), the Remote Authentication Dial-In User Service (RADIUS) server and proxy provided with Windows Server 2003. NPS can also act as an authentication, authorization, and accounting (AAA) server for network access. When acting as a AAA server or NAP health policy server, NPS is typically run on a separate server for centralized configuration of network access and health requirement policies, as Figure 1 shows. The NPS service is also run on Windows Server 2008–based NAP enforcement points, such as an HRA or DHCP server. However, in these configurations, the NPS service is acting as a RADIUS proxy to exchange RADIUS messages with a NAP health policy server.

Health requirement servers -Computers that provide current system health state for NAP health policy servers. For example, a health requirement server for an antivirus program tracks the latest version of the antivirus signature file.

Active Directory Domain Services -The Windows directory service that stores account credentials and properties and Group Policy settings. Although not required for health state validation, Active Directory is 3 required for Internet Protocol Security (IPsec)–protected communications, 802.1X-authenticated connections, and remote access VPN connections.

Restricted network -A separate logical or physical network that contains:

* Remediation servers -Network infrastructure servers and health update servers that NAP clients can access to remediate their noncompliant state. Examples of network infrastructure servers include Domain Name System (DNS) servers and Active Directory domain controllers. Examples of health update servers include antivirus signature distribution servers and software update servers.
* NAP clients with limited access -Computers that are placed on the restricted network when they do not comply with health requirement policies.
* Non-NAP-capable computers -Optionally, computers that do not support NAP can be placed on the restricted network (not shown in Figure 1).

System Health Agents and System Health Validators

Components of the NAP infrastructure known as system health agents (SHAs) on NAP clients and system health validators (SHVs) on NAP health policy servers provide health state tracking and validation for attributes of system health. Windows Vista and Windows XP SP3 include a Windows Security Health Validator SHV that monitors the settings of the Windows Security Center. Windows Server 2008 includes the corresponding Windows Security Health Validator SHV. NAP is designed to be flexible and extensible. It can interoperate with any vendor who provides SHAs and SHVs that use the NAP API.

An SHA creates a statement of health (SoH) that contains the current status information about the attribute of health being monitored by the SHA. For example, an SHA for an antivirus program might contain the state of the program (installed and running) and the version of the current antivirus signature file. Whenever an SHA updates its status, it creates a new SoH. To indicate its overall health state, a NAP client uses a System Statement of Health (SSoH), which includes version information for the NAP client and the set of SoHs for the installed SHAs.

When the NAP client validates its system health, it passes its SSoH to the NAP health policy server for evaluation through a NAP enforcement point. The NAP health policy server uses the SSoH, its installed SHVs, and its health requirement policies to determine whether the NAP client is compliant with system health requirements, and if it is not, the remediation actions that must be taken to achieve compliance. Each SHV produces a statement of health response (SoHR), which can contain remediation instructions. For example, the SoHR for an antivirus program might contain the current version number of the antivirus signature file and the name or IP address of the antivirus signature file server on the intranet.

Based on the SoHRs from the SHVs and the configured health requirement policies, the NAP health policy server creates a System Statement of Health Response (SSoHR), 4 which indicates whether the NAP client is compliant or noncompliant and includes the set of SoHRs from the SHVs. The NAP health policy server passes the SSoHR back to the NAP client through a NAP enforcement point. The NAP client passes the SoHRs to its SHAs. The noncompliant SHAs automatically remediate their health state and create updated SoHs, and the health validation process begins again.
Enforcement Clients and Servers

A NAP Enforcement Client (EC) is a component on a NAP client that requests some level of access to a network, passes the computer’s health status to a NAP enforcement point that is providing the network access, and indicates health evaluation information to other components of the NAP client architecture. The NAP ECs for the NAP platform supplied in Windows Vista, Windows XP SP3, and Windows Server 2008 are the following:

* An IPsec EC for IPsec-protected communications
* An EAPHost EC for 802.1X-authenticated connections
* A VPN EC for remote access VPN connections
* A DHCP EC for DHCP-based IPv4 address configuration
* A TS Gateway EC for connections to a TS Gateway server

A NAP Enforcement Server (ES) is a component on a NAP enforcement point running Windows Server 2008 that allows some level of network access or communication, can pass a NAP client’s health status to NPS for evaluation, and, based on the response from NPS, can provide the enforcement of limited network access. The NAP ESs included with Windows Server 2008 are the following:

* An IPsec ES for IPsec-protected communications
* A DHCP ES for DHCP-based IPv4 address configuration
* A TS Gateway ES for TS Gateway server connections

For 802.1X-authenticated and remote access VPN connections, there is no separate ES component running on the 802.1X switch or wireless AP or VPN server.

Together, ECs and ESs require health state validation and enforce limited network access for noncompliant computers for specific types of network access or communication.
NPS

NPS is a RADIUS server and proxy in Windows Server 2008. As a RADIUS server, NPS provides AAA services for various types of network access. For authentication and authorization, NPS uses Active Directory to verify user or computer credentials and obtain user or computer account properties when a computer attempts an 802.1Xauthenticated connection or a VPN connection.

NPS also acts as a NAP health policy server. Administrators set system health requirements in the form of health requirement policies on the NAP health policy server.
5

NAP health policy servers evaluate health state information provided by NAP clients to determine health compliance, and for noncompliance, the set of remediation actions that must be taken by the NAP client to become compliant.

The role of NPS as an AAA server is independent from its role as a NAP health policy server. These roles can be used separately or combined as needed. For example:

* NPS can be an AAA server on an intranet that has not yet deployed NAP.
* NPS can be a combination of AAA server and health policy server for 802.1Xauthenticated connections on an intranet that has deployed NAP for 802.1Xauthenticated connections.
* NPS can be a health policy server for DHCP configuration on an intranet that has deployed NAP for DHCP configuration.

Read More

Exchange Server 2010 Beta available

Microsoft Exchange Server 2010 brings a new and rich set of technologies, features, and services to the Exchange Server product line. This topic lists many of the new features and functionality that are included in Exchange 2010. The list isn't comprehensive; however, it provides important information to use when you're planning, deploying, and administering your Exchange 2010 organization:

* New Rights-Protected E-Mail Functionality with Active Directory RMS
* New Transport and Routing Functionality
* New Permissions Functionality
* New High Availability Functionality
* New Messaging Policy and Compliance Features
* New Outlook Web Access Features
* New Unified Messaging Features
* Web Management Interface
* New Exchange Core Store Functionality
* New Administration Functionality in the Exchange Management Console
* New Administration Functionality in the Exchange Management Shell

The first Beta version of Exchange Server 2010 is now available for download. Go ahead, download now!!

Read More

Happy Father’s Day to all of you techie dads out there

Read More

Free Windows 7 IT Pro beta class offered

Microsoft Learning has recently completed the beta version of a Windows 7 Instructor-led training course for IT Professionals entitled “Installing and Configuring Windows® 7 Client”

In an attempt to attain feedback on the course prior to the RTM release of Windows 7 we are offering the three-day course to IT Pros who would like to attend and give feedback on the course.

· When: July 7th to 9th (9:00AM to 5:00PM)

· Where: Microsoft Campus, Redmond WA

This beta class is being offered for free only once and class size is limited. If you are interested in attending the course send an email to trblog@microsoft.com. In the email explain your interest in the course as an IT Professional. Students will be chosen based on how well they match the audience profile listed in the syllabus link above. You will receive an email response within 48 hours if you have been selected to attend the course.

Read More

Microsoft’s Virtual Lab Exams: Going Inside the Black Box

Microsoft recently announced the release of virtual labs in 83-640. Virtual labs allow you to perform tasks using the software technology rather than performing them in a simulated environment or answering multiple choices questions about how you would solve the specified problem. With virtual labs, you solve the problem by doing something. I found this totally cool video that shows off the virtual lab technology and item type and thought it would be great to share it with you.

Read More

Implementing Roaming User Profiles in Windows Vista

To implement roaming user profiles for users of Windows Vista computers in an Active Directory environment, follow these steps:

1. 1. Prepare the file server where you want to store roaming user profiles for users by creating a shared folder on the server. (This server is sometimes 2called the profile server; a typical sharename for this shared folder is Profiles.)
2. 2. Assign the permissions shown in Tables 1 and 2 to the underlying folder being shared and to the share itself. Also confirm that the permissions in Table 3 are automatically applied to each roaming user profile folder.

Table 1 NTFS Permissions for Roaming Profile Parent Folder

User account


Minimum permissions required

Creator/Owner


Full Control -Subfolders and Files Only

Administrator


None

Security group of


List Folder/Read Data, Create Folders/Append

users needing to


Data -This Folder Only

put data on share




Everyone


No Permissions

Local System


Full Control -This Folder, Subfolders, and Files

Table 2 Share-Level (SMB) Permissions for Roaming Profile Share

User account


Default permissions


Minimum permissions required

Everyone


Full Control


No Permissions

Security group of users needing to


N/A


Full Control

put data on share







Table 3 NTFS Permissions for Each User’s Roaming Profile Folder

User account


Default permissions


Minimum permissions required

%Username%


Full Control, Owner Of Folder


Full Control, Owner Of Folder

Local System


Full Control


Full Control

Administrators


No Permissions1


No Permissions

Everyone


No Permissions


No Permissions

1This is true unless you set the “Add the Administrator security group to the roaming user profile share” policy, in which case the Administrators group has Full Control (requires Windows 2000 Service Pack 2 or later).

3. 3. Create a default network profile for users and copy it to the NETLOGON share on a domain controller. Let it replicate to other domain controllers in the domain.
This step is optional and is typically necessary only if you want to preconfigure a roaming user profile for your users so that they will all have the same desktop experience when they first log on. If you do not create a default network profile, Windows Vista will use the local %SystemRoot%\Users\Default profile instead.
4. 4. Open Active Directory Users and Computers and configure the profile path on the Profile tab for each user who will roam.

3

Additional, optional steps include configuring roaming profiles as mandatory profiles or as super mandatory profiles if desired.
Creating a Default Network Profile

When a user logs on to a Windows Vista computer for the first time, Windows Vista tries to find a profile named Default User.v2 in the NETLOGON share on the domain controller authenticating the user. If Windows Vista finds such a profile, this profile is copied to the user’s computer to form the user’s local profile on the computer. If Windows Vista does not find such a profile, the Default profile under %SystemDrive%\Users on the user’s computer is copied instead as the user’s local profile.

To create a default network profile, follow these steps:

1. 1. Log on to any computer running Windows Vista, using any domain user account.
2. 2. Configure the desktop settings, Start menu, and other aspects of your computer’s environment as you want users who log on to Windows for the first time to experience them.
3. 3. Log off and then log on using an account that belongs to the Domain Admins group.
4. 4. Click Start, right-click Computer, and then select Properties.
5. 5. Click Advanced System Settings. In the System Properties dialog box, click the Advanced Settings tab and then click Settings under User Profiles. The User Profiles dialog box opens.
6. 6. Select the user profile you previously configured in step 2 and click Copy To.The Copy To dialog box opens.
7. 7. Type \\domain_controller\NETLOGON\Default User.v2 in the Copy To dialog box.
8. 8. Click Change, type Everyone and then click OK twice to copy the local user profile you previously configured to the NETLOGON share as the default network profile Default User v.2.
9. 9. Type \\domain_controller\NETLOGON in the Quick Search box and press ENTER to open the NETLOGON share on your domain controller in a Windows Explorer window. Verify that the profile has been copied.

Note You may already have a Default User profile in NETLOGON that you created previously as a default network profile for users of computers running earlier versions of Windows. This network profile is not compatible with Windows Vista. See the section “Considerations for Mixed Environments” later in this chapter for more information.
Configuring a User Account to Use a Roaming Profile

Once you have created a Profiles share and configured it with suitable permissions on a file server, you can configure new user accounts to use roaming user profiles. To do this, 4 follow these steps (a Windows Server 2003 domain is used in this example):

1. 1. Log on to a domain controller as a member of the Domain Admins group (or any administrator workstation running an earlier version of Windows on which adminpak.msi has been installed).
2. 2. Open Active Directory Users and Computers and select the organizational unit containing the new user accounts you want to enable roaming for.
3. 3. Select each user account in the OU that you want configure. Right-click each account and select Properties.
4. 4. Click the Profile tab, select the check box labeled Profile Path, type \\profile_server\Profiles\%username% in the Profile Path text box, and then click OK.

The selected new user accounts are now ready for using roaming profiles. To complete this procedure, have each user log on to a Windows Vista computer using his or her user credentials. When the user logs on to Windows Vista for the first time, the Default User.v2 profile is copied from NETLOGON to the user’s local profile and then copied as user_name.v2 to the Profiles share on the profile server. For example, a user named Jacky Chen (jchen@contoso.com) who logs on to a Windows Vista computer for the first time will receive the roaming user profile \\profile_server\Profiles\jchen.v2. The .v2 suffix identifies this profile as compatible only with Windows Vista or later.
Implementing Mandatory Profiles

The procedure for implementing mandatory user profiles is similar to the procedure for implementing roaming user profiles described earlier in the article, with the following differences:

* Instead ofassigning the Authenticated Users built-in group Full Control of the Profiles folder on the profile server, assign this group Read permission and the Administrators group Full Control instead.
* Follow the steps in the section “Creating a Default Network Profile,” but instead of copying the domain user profile you configured to \\domain_controller\NETLOGON\Default User.v2, copy the profile to \\profile_server\Profiles\Mandatory.v2.
* Browse to locate the super-hidden \\profile_server\Profiles\Mandatory.v2\ntuser.dat file and change its name to ntuser.man. (Super-hidden files have the hidden and system attributes set.)
* Follow the steps in the section “Configuring a User Account to Use a Roaming Profile,” but instead of typing \\profile_server\Profiles\%username% in the Profile Path text box, type \\profile_server\Profiles\Mandatory.

Any user who now logs on with this mandatory user profile will be able to configure the desktop environment while logged on to the network, but when the user logs off any changes made to the environment will not be saved.
5

Caution Do not add .v2 to the profile path of the user object in Active Directory Users and Computers. Doing so may prevent Windows Vista from locating the roaming or mandatory profile. You should only apply the .v2 suffix to the name of the user folder on the central file server.

Caution It is acceptable to use the existing server and file share where you store your current roaming user profiles. If you do so, however, each user will have two roaming profile folders: one for Windows Vista and one for Windows XP. The added folder also means additional storage requirements for the server. Ensure that the drive hosting the share has adequate free space, and adjust any disk-quota policies accordingly.
Implementing Super Mandatory Profiles

The procedure for implementing super mandatory profiles is similar to the procedure for implementing mandatory user profiles described earlier, with the following differences:

* Instead of copying the domain user profile you configured to \\domain_controller\NETLOGON\Default User.v2, copy the profile to \\profile_server\Profiles\Mandatory.man.v2.
* Instead of typing \\profile_server\Profiles\%username% in the Profile Path text box, type \\profile_server\Profiles\Mandatory.man.

Once you have implemented these profiles, users will be able to configure their desktop environments while logged on to the network, but when they log off any changes they made to their environments will not be saved. In addition, if the profile server is unavailable when the user tries to log on to the network (or if the super mandatory profile does not load for any other reason), Windows Vista will not allow the user to log on to the computer.
Using Roaming User Profiles Together with Folder Redirection

If you configure both Folder Redirection and roaming user profiles, do not store redirected folders within the user’s roaming profiles, but instead store them on the network share where Folder Redirection is targeted. This reduces the size of a user’s roaming profile, speeds up its download time, and improves the user’s logon experience.

In general, best practice is to configure Folder Redirection first, make sure it applies successfully, and then deploy roaming user profiles. Also, users should log off all computers and follow these steps on one computer first (with all their main data).
Considerations for Mixed Environments

The following considerations apply when implementing roaming user profiles in mixed environments that consist of both Windows Vista and Windows XP or Windows 2000 client computers:

* Default network profiles created for computer running an earlier version of Windows are not compatible with default network profiles created for Windows Vista computers because the profile namespace of Windows Vista 6 is incompatible with the profile namespace of Windows XP. Because of this incompatibility, users who log on to a computer running an earlier version of Windows cannot roam their profiles to Windows Vista computers and vice versa. If users must use both Windows Vista computers and earlier versions of Windows, they will need separate roaming profiles for each computer and must manage the profiles separately. If Folder Redirection is implemented, however, part of the user profiles (the redirected folders) can be shared between the two desktop environments.
* If users need to roam across both Windows Vista computers and computers running earlier versions of Windows, you will need twice the usual space to store their roaming profiles. For example, if user Jacky Chen roams across both Windows Vista and computer running an earlier version of Windows, he will have two roaming profiles on the profile server:
o \\profile_server\Profiles\jchen, which is his roaming profile on earlier versions of Windows
o \\profile_server\Profiles\jchen.v2, which is his roaming profile on Windows Vista computers

These two user profiles are incompatible and will not share any data unless you have also implemented Folder Redirection for the user. Specifically, if you implement all available Folder Redirection policies for this user (including those that apply to earlier versions of Windows), only the HKCU settings will be unavailable between platforms.

In Windows Vista, disk quotas configured on roaming profiles no longer prevent users from logging off as disk quotas did on earlier versions of Windows. However, disk quotas will prevent roaming profiles from being uploaded to the profile server when the user logs off. No user data is lost, however, since the data still remains in the user’s local user profile on the computer.

Read More

Free E-Book on Terminal Services

For 25 years, Microsoft Press books have focused on helping you take your skills and knowledge to the next level. Celebrate our 25th Anniversary with a "Free e-book of the Month" offer! Simply sign up for the Microsoft Press Book Connection Newsletter for notification of offers, register, and download the selection of the month.

Read More