Network Access Protection, Revisited

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Network-Access-Protection-Revisited-Part1.html

PART-1

What is Network Access Protection

Network Access Protection, or NAP as it is sometimes called, was created to address one of the major frustrations that network administrators often experience. As a network administrator, I'm sure that you have probably put a lot of time and effort into making your network is secure as possible. The problem is that some of the machines on your network are outside of your direct control, and have previously been difficult or impossible to secure.
I am talking, of course, about remote users. It is easy to secure desktop workstations that reside on premise, and you can probably even get away with securing user's laptops, so long as those laptops are company property. However, in many organizations, users like to logon from their home computer using a VPN connection so that they can do some work after hours without having to travel to the office. Because the company does not own these machines, the administrator staff has no direct control over them.
Prior to the creation of Network Access Protection, I have always fought to keep machines outside of the direct control of the administrative staff from connecting to the network. My reason for this is that over the years I have run into some really scary home machines. It is not at all uncommon to find home machines that are completely infested with viruses and spyware, or that are still running outdated operating systems. From time to time, I still have people asking me about problems that they are having with Windows 98.
Network Access Protection is designed to alleviate these concerns. When a user connects to your network, the user's machine can be compared against a health policy that you have established. The actual contents of this health policy will likely vary from one organization to another, that you can require that the user's operating system have the latest security patches, and that the machine be running up-to-date antivirus software, and things like that. If the machine meets the criteria that you have established in the policy that the machine is free to connect to the network in the usual manner. If the machine does not comply with your policy, then you can choose to deny network access to the user, fix the problem on the spot, or go ahead and let the user have access but make a note of the state of the user's machine.
Some Terminology to Know

Before I can really get started in explaining how Network Access Protection works, you need to be familiar with the terminology that Microsoft uses in regard to Network Access Protection.
The first-term that you need to be familiar with is Enforcement Client, sometimes abbreviated as EC. An Enforcement Client is nothing more than the client machine that is attempting to connect to your network. Keep in mind that not all workstations are compatible with Network Access Protection. In order to be considered an Enforcement Client, the workstation must be able to run the System Health Agent component, which I will talk about a little bit later on. Only Windows Vista and Windows XP SP3 are capable of running the System Health Agent, and therefore these are the only workstation operating systems that are compatible with Network Access Protection.
The next term that you need to be familiar with is System Health Agent, or SHA. The System Health Agent is an agent that runs as a service on the workstation, and monitors the Windows Security Center. The agent is responsible for reporting system health information to the Enforcement Server upon connection.
As you might have guessed, the next term that I want to talk about is Enforcement Server. The Enforcement Server is a server that enforces the policies that are defined by Network Access Protection.
Another term to know is System Health Validator, or SHV. The System Health Validator takes the information that has received from the System Health Agent, and compares that information against the health policy that has been defined.
The last term that I want to talk about is Remediation Server. A remediation server is a server that is made accessible to enforcement clients that are found not to comply with the network access policies that have been established. Typically, a remediation server will contain all the mechanisms that are necessary for making the enforcement client compliant with the policies. For example, a remediation server might apply security patches to the enforcement client.
Network Access Protection’s Limitations

One last thing I want to be sure to mention about Network Access Protection is that Network Access Protection offers you a way of enhancing your organization's security, but it does not replace the other security mechanisms that you are already using. Network Access Protection does a great job of ensuring that remote clients comply with your network security policy. In fact, it will probably do an even better job of enforcing this policy as time goes on, because the policy is based on open standards. This means that third-party software vendors will be able to write their own policy modules, which will allow you to create security policies that apply to third party software running on the enforcement client.
What Network Access Protection does not do is that it will not keep intruders off of your network. Network Access Protection only ensures that workstations being used for remote access to the network meets certain criteria. Therefore, Network Access Protection will only stop a hacker if their machine does not comply with your security policy. If a hacker's machine is compliant, then it will be up to your other security mechanisms to make sure that the hacker is denied access.
Conclusion

In this article, I have explained that Network Access Protection provides you with a way of ensuring that any workstation that establishes a connection to your network conforms to your network’s security policy. In the next article in this series, I will continue the discussion by showing you how to implement the Network Access Protection feature

---

موضوعات مشابه:

• Network Access Protection
• NAP (Network Access Protection)
• Network Access Protection
• Network Access Protection, Revisited

---

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Network-Access-Protection-Revisited-Part2.html

PART-2

The Network Access Protection Infrastructure

Implementing Network Access Protection requires the use of several servers, each performing a specific role. As you can see in the figure below, we are going to be using a Routing and Remote Access Server, a domain controller, and a Network Policy Server.

Figure A: Implementing Network Access Protection requires several servers to be used
As you can see in the diagram, the Windows Vista client is connecting to a Windows 2008 Server that’s running the Remote Access (RRAS) service. This server acts as the VPN server for the network. The Windows Vista client establishes a connection to this VPN server in the usual way.
When the remote user connects to the VPN server, the user’s credentials are validated using the RADIUS protocol. .The network policy server then determines which health policies are in effect, and what should happen if the remote client is out of compliance.
In a lab environment, a single physical server could be used to host both the Routing and Remote Access Service role and the Network Policy Server role. In the real world VPN servers exist at the network perimeter, and it would completely undermine your network’s security if you hosted the network policy server on a perimeter server.
The Domain Controller

If you look at the diagram shown in Figure A, you will see that one of the required servers is a domain controller. Don’t think of this as a single server, but rather as an entire Active Directory infrastructure. As I’m sure you know, the Active Directory cannot function without a DNS server. That being the case, if this diagram were a literal representation of an actual network, then the domain controller would be hosting the DNS services. Of course, in the real world organizations typically use multiple domain controllers and a dedicated DNS servers.
An additional infrastructure requirement that is not shown on the diagram is an Enterprise Certificate Authority. Fortunately, Windows can be configured to act in such a capacity. In this article series, I will be configuring the domain controller to also function as our enterprise certificate authority. If this were a real world deployment you would want to use a dedicated server as the enterprise certificate authority because of the sensitive nature of digital certificates.
Installing an Enterprise Certificate Authority

The procedure for deploying an enterprise certificate authority varies a little bit depending on whether you are installing the services on a Windows 2003 server or on a Windows 2008 server. Because one of my purpose is in writing this article series is to familiarize you with Windows 2008 Server, the following procedure is intended for installing the certificate services on a Windows 2008 Server.
Before a show you how to install the certificate services, you need to keep in mind that in a real world deployment, you would want to take extreme measures to make sure that your enterprise certificate authority is secure. After all, if someone were to compromise your enterprise certificate authority, they own your network. Because this article focuses on Network Access Protection and not on the certificate services per se, I am going to show you just enough to get the certificate services up and running. In a real world deployment, you would want to put a whole lot more thought into the server’s configuration.
Begin the deployment process by opening Windows 2008 Server’s Server Manager and select the Roles option from the console tree. Next, click the Add Roles link found in the Roles Summary section of the console. This will cause Windows to launch the Add Roles Wizard. Click Next to bypass the wizard’s Welcome screen. You will now see a list of all of the available roles, as shown in Figure B. Select the Active Directory Certificate Server option from the list. Click Next to continue.

Figure B: Windows lists all of the roles that are available to you
At this point, you will see a screen that introduces you to the certificate services and provides you with some words of caution. Click Next to ignore this screen and you will see another screen that asks you which components you want to install. Select the Certification Authority and the Certificate Authority Web Enrollment check boxes.
You will now see a screen similar to the one that’s shown in Figure C, telling you that some additional roles must be installed prior to installing the Certificate Authority Web Enrollment Role. Click the Add Required Role Service button, and then click Next.

Figure C: The Certificate Services Web Enrollment Role cannot function without IIS
You will now see a screen that asks you if you would like to create an enterprise certificate authority or a standalone certificate authority. Choose the Enterprise Certificate Authority option and click Next. You will now be prompted as to whether this server should act as a Root CA or as a Subordinate CA. Since this is the first (and only) certificate authority in your lab, you should choose the Root CA option. Click Next to continue.
The Wizard will now ask you if you want to create a new private key or if you want to use an existing private key. Again, this is a lab setup, so choose the option to create a new private key and click Next to continue.
The next screen that you will encounter asks you to either create a new private key or to use an existing private key. Since no private key exists yet, choose the option to create a new private key, and click Next.
You should now see a screen that’s similar to the one shown in Figure D, asking you to select a cryptographic service provider, a key length, and a hash algorithm. In a real world deployment these are all things that you would want to carefully consider. Since we are setting this certificate authority up solely for demonstration purposes just go with the defaults and click Next.

Figure D: Choosing the correct cryptographic options would be critical in a real world deployment for security reasons
The next screen that you will see gives you a chance to define a common name and a distinguished name suffix for the certificate authority. Again, just go with the defaults and click Next.
You should now see a screen asking how long the certificates should be valid for. The default time period is 5 years, which is fine for our purposes, so just click Next. The next screen that you will see asks you where the certificate databases and the corresponding transaction logs should be located. In a production environment, choosing an appropriate location is critical to fault tolerance and security. Since this is a lab just go with the defaults and click Next.
As you will recall, we had to add an additional role midstream in order to support the Certificate Services Web Enrollment role. Therefore, the next screen that you will see is an introduction to IIS. Click Next to bypass this screen, and you will see a screen asking you which Web Server components you want to install. It is important to understand that Windows has already made the appropriate choices for you, so just click Next.
You will now see a screen detailing the options that you have selected. Click the Install button and Windows will copy the necessary files and configure the underlying services. When the process completes, the results screen should show you that the roles have been installed successfully, as shown in Figure E. Click Close to complete the process.

Figure E: When the installation process completes, click the Close button
Conclusion

Now that I have shown you how to configure the enterprise certificate authority, it is time to begin configuration of the VPN server. I will show you how in Part 3

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Network-Access-Protection-Revisited-Part3.html

PART-3

In Part 2 of this article series, I showed you how to install an Enterprise Certificate Authority, and how to prepare the rest of the network infrastructure that would be required for facilitating Network Access Protection. In this article, I will continue the discussion by showing you how to configure the necessary VPN Server. For the purposes of this article series, I will be installing the Network Policy Server onto the same physical computer as will be used for the VPN Server. In a real world deployment, you would usually want to use two separate computers to host these roles for security reasons. Hosting both roles on the same computer should only be done in a lab environment.
Basic Configuration Tasks

Before I show you how to configure this server to act as a VPN server, you must perform some basic configuration tasks. Essentially, this means that you must install Windows Server 2008, and configure it to use a static IP address. The IP address must fall into the same range as the domain controller that you configured previously. Additionally, the server’s Preferred DNS Server setting in its TCP/IP configuration should point to the domain controller that you set up earlier in this series, since it is also acting as a DNS server. After you finish performing the VPN server’s initial configuration, you should use the PING command to verify that the VPN server can communicate with the domain controller.
Joining a Domain

Now that you have specified the machine’s TCP/IP configuration and tested its connectivity, it’s time to get started with the real configuration tasks. The first thing that you will have to do is to join the server to the domain that you created earlier in this series. The process of joining a domain works very similarly in Windows Server 2008 to the way that it works in Windows Server 2003.
To join a domain, right click on the Computer command found on the server’s Start menu, and choose the Properties command from the resulting shortcut menu. Upon doing so, Windows will open the Control Panel’s System applet. Now, click the Change Settings button found in the Computer Name, Domain, and Workgroup Settings section of this screen. Doing so will reveal the System Properties sheet. The System Properties sheet is nearly identical to the one found in Windows Server 2003, as shown in Figure A. Click the Change button to reveal the Computer Name Changes dialog box. In Figure A, the Change button is grayed out because the server has already been joined to a domain. Now, select the Domain radio button found in the dialog box’s Member of section. Enter the name of your domain into the Domain field and click OK.

Figure A: The System Properties sheet is nearly identical to the one found in Windows Server 2003
You should now see a dialog box prompting you for a set of credentials. Enter the username and password your domain administrator account, and click the Submit button. After a brief delay you should see a dialog box welcoming you to the domain. Click OK, and you’ll see another dialog box telling you that you must restart your computer. Click OK one more time, followed by the Close button. When you restart the computer, it should be a member of the domain that you specified.
Installing Routing and Remote Access

Now it’s time to install the Routing and Remote Access service. As a part of the installation process, we will configure this service to act as a VPN server. Begin the process by opening the Server Manager. You can find a shortcut to the Server Manager on the Administrative Tools menu. When the Server Manager opens, scroll to the Roles Summary section found in the details pane. Now, click the Add Roles link to launch the Add Roles Wizard.
When the wizard opens, click Next to bypass the Welcome screen. You should now see a screen prompting you as to which roles you want to install on the server. Click the checkbox corresponding to the Network Policy and Access Services option. Click the Next button and you will be taken to a screen that presents you with an introduction to the Network Policy and Access Services. Click Next one more time and you will see a screen prompting you to select the Network Policy and Access Services components that you want to install. Select the check boxes corresponding to Network Policy Server, and Routing and Remote Access Services, as shown in Figure B.

Figure B: Choose the Network Policy Server and the Routing and Remote Access Services options
When you select the Routing and Remote Access Services check box, the Remote Access Service, and the Routing check boxes will be selected automatically. You must leave these check boxes selected because they will install the components that will be necessary for the server to act as a VPN.
Click the Next button and you will be taken to a screen that displays a summary of the services that are about to be installed. Assuming that everything looks good, click the Install button to begin the installation process. This is a good time to go take a break, because the installation process can take several minutes to complete, depending on your hardware. When the installation process completes, click the Close button.
After the Network Access Services have been installed, it is time to configure the Routing and Remote Access Services to accept VPN connections. Begin by opening the Server Manager, and navigating through the console tree to Server Manager | Roles | Network Policy and Access Service | Routing and Remote Access. Now, right click on the Routing and Remote Access container and select the Configure and Enable Routing and Remote Access command from the resulting shortcut menu. This will cause Windows to open the Routing and Remote Access Server Set up Wizard.
Click Next to bypass the wizard’s welcome screen. You should now see a screen asking you which configuration you want to use. Choose the Remote Access (dial-up or VPN) option, as shown in Figure C, and click Next. The following screen will give you a choice between configuring dial-up or VPN access. Choose the VPN check box and click Next.

Figure C: Choose the Remote Access (Dial-Up or VPN) option, and click Next
The wizard will now take you to the VPN connection page. Now, choose the network interface that will be used by clients to connect to the VPN server and deselect the Enable Security on the Selected Interface by Setting up Static Packet Filters check box, as shown in Figure D.

Figure D: Choose the network adapter that you want to use for inbound VPN requests
Click Next and you will see a screen asking you if you want to assign IP addresses to clients automatically, or if you would rather get the addresses from a specified address range. Choose the From a Specified Range of Addresses option, and click Next.
At this point, you’ll see a screen asks you to enter an IP address range that can be assigned to VPN clients. Click the New button and enter a beginning and an ending address for the IP address range, as shown in Figure E. When you are done, click OK, followed by Next. Windows will now open the Managing Multiple Remote Access Server’s page.

Figure E: You must enter a range of IP addresses to be assigned to clients
The wizard will now ask you if you want the RRAS server to authenticate connection requests, or if you would rather use a RADIUS server. RRAS is fully capable of performing the necessary authentication, but large organizations often have multiple RRAS servers, and it is therefore easier from a management prospective to use a centralized RADIUS server for authentication.
Go ahead and choose the Yes option to configure the server to work with a Radius server. You will now be prompted to enter the IP address for your Radius server. We haven’t actually set up a RADIUS server yet, but later on, we will install RADIUS on our VPN server. Again though, in the real world, you would want to install RADIUS on a separate server. For our purposes, just enter the server’s own IP address as the primary and secondary Radius server address. You will also be prompted to enter a shared secret. For demonstration purposes, just enter rras as the shared secret. When you’re done, Click Next followed by Finish. You will now see a couple of warning messages. Just click OK to close each message.
The last step in the RRAS configuration process is to set up the authentication scheme. To do so, go back to the Server manager, and right click on the Routing and Remote Access container, and choose the Properties command from the resulting shortcut menu. When you do, you’ll see in the server’s properties sheet. Go to the Security tab and click the Authentication Methods button. Verify that the MSCHAPv2 and EAP check boxes are selected, as shown in Figure F, and click OK.

Figure F: Verify that the MSCHAPv2 and EAP options are selected
Conclusion

In this article, I have shown you how to install and configure the Routing and Remote Access Services in a way that will allow the server to act as a VPN server. In the next part of this article series, I will continue the discussion by showing you how to configure the Network Policy Server component

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Network-Access-Protection-Revisited-Part4.html

PART-4

In the previous article in this series, I showed you how to configure the VPN component that will be used to allow external users to gain access to our network. In this article, I will continue the discussion by showing you how to configure the Network Policy Server component.
As I have explained earlier in the series, the Network Policy Server’s job is to compare the statements of health that it will receive from PCs that are requesting access to the network against the system health policy. The system health policy dictates what is required of PCs in order for them to be considered healthy.
In the real world, a system health policy would likely require workstations to be running a current Windows operating system, and to have all of the latest security patches. Regardless of what criteria you use to decide whether or not a workstation is healthy, you are going to have to do some work.
For demonstration purposes, we will create a very simple system health validator that simply checks to see if the Windows firewall is enabled. If the firewall is enabled, then we will consider the workstation to be healthy.
As I mentioned earlier in this article series, in the real world you should not host the Network Policy Server on the same box as your VPN server. The VPN server is exposed to the outside world, and if you host the Network Policy Server on this box, then you run a high risk of the Network Policy Server being compromised. There is nothing in Windows that prevents you from using the same server for both the VPN components and the Network Policy Server though, so for demonstration purposes (and because of a lack of hardware) I will be using the same box to host both components.
Configuring a Network Policy Server

Begin the configuration process by entering the MMC command at the Run prompt to open an empty Microsoft Management Console. When the console opens, select the Add / Remove Snap-in command from the console’s File menu. This will cause Windows to display the Add or Remove Snap-Ins dialog box. Select the Network Policy Server option from the list of available snap-ins, and click the Add button. You should now see a prompt asking you if you would like to manage the local computer or another computer. Make sure that the Local Computer option is selected and then click OK. Click OK one more time and the Network Policy Server component will be opened.
At this point, you must navigate through the console tree to NPS (Local) | Network Access Protection | System Health Validators, as shown in Figure A. Now, right click on the Windows System Health Validator object found in the center pane of the console, and select the Properties command from the resulting shortcut menu. This will cause Windows to display the Windows Security Health Validator Properties dialog box, shown in Figure B.

Figure A: Navigate through the console tree to NPS (Local) | Network Access Protection | System Health Validators

Figure B: The Windows Security Health Validator Properties dialog box is used to configure the system health validator
Click the dialog box’s Configure button and Windows will display the Windows Security Health Validator dialog box, shown in Figure C. As you can see in the figure, this dialog box allows you to define your system health validator policy. By default the dialog box is configured to require the Windows firewall to be enabled, Windows update to be enabled, and anti virus and anti spyware protection to be installed and up to date. Since we are only interested in making sure that the Windows firewall is enabled, leave the A Firewall is Enabled for all Network Connections check box selected, but deselect all of the other check boxes. Click OK twice to continue.

Figure C: Select the 'A Firewall is Enabled for all Network Connections' check box and deselect all of the other check boxes
Creating a System Health Policy

Now that you have configured the System Health Validators, you must configure a System Health Policy. System health policies define the system health validation results. Essentially, this means defining what constitutes a pass or fail when the system health validation is performed on a client.
To configure the Network Policy Server’s health policy, navigate though the console tree to NPS (Local) | Policies | Health Policies. Now, right click on the Health Policies container, and select the New command from the resulting shortcut menu. When you do, Windows will display the Create New Health Policy dialog box that’s shown in Figure D.

Figure D: You must create a new system health policy
As you can see in the figure, the dialog box prompts you to enter a name for the new policy. Enter the word Compliant into the Name field. Now, make sure that the Client SHV Checks drop down list is set to Client Passes all SHV Checks. Select the Windows System Health Validator check box and click OK.
We have now created a policy that defines what it means to be compliant. We must now create a second policy that defines what it means for a system to be out of compliance. To do so, right click on the Health Policies container and select the New command from the resulting shortcut menu. You should now see the same screen that you were working with a moment ago.
This time, name the new policy NonCompliant. Set the Client SHV Checks drop down list to use the Client Fails one or More SHV Checks option. Now, select the Windows Security Health Validator check box and click OK. If you return to the Network Policy Server console’s main screen and select the Health Policies container, you should see both the Compliant and the NonCompliant policies displayed in the console’s center pane, as shown in Figure E.

Figure E: If you return to the Network Policy Server console’s main screen and select the Health Policies container, you should see both the Compliant and the NonCompliant template displayed in the console’s center pane
Conclusion

In this article, I have shown you how to configure a system health validator so that Windows will check to see if clients requesting access to the network have the Windows firewall enabled. I then showed you how to create a system health policy that defines what it means to be in and out of compliance with the network health policy.
In the next part of this article series, I will show you how to create health authorization policies. Health authorization policies are the policies that control what happens if a client is compliant with the network health policy, or what will happen if the system that is requesting network access is found to be non compliant. It is these policies that determine what level of access, if any, the client will receive to the network. As this series progresses, I will also be discussing automatic remediation. Remediation refers to fixing health problems on the fly, prior to granting clients network access

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Network-Access-Protection-Revisited-Part5.html

PART-5

In the previous article in this series, I showed you how to configure a system health validator that checks to see if clients requesting access to the network have the Windows firewall enabled. I then showed you how to create system health policies that define what it means for clients to be healthy or unhealthy.
In this article, I will continue the discussion by showing you how to create network policies. Network policies are the policies that control what happens if a client is compliant with the health policy, or what will happen if the system that is requesting network access is found to be non compliant. It is these policies that determine what level of access, if any, the client will receive to the network.
Creating Network Policies

Begin the process by opening the Network Policy Server console and selecting the console’s Network Policies container. Upon doing so, take a look at the Details pane to see if any network policies currently exist. On my test system, there are two default network policies, both of which are enabled by default. One policy is the Connections to Microsoft Routing and Remote Access Server policy, and the other is the Connections to Other Access Servers policy. I recommend disabling these policies by right clicking on them, and choosing the Disable command from the resulting shortcut menu.
Now that you have cleared out the previously existing policies, you can create a new network policy. To do so, right click on the Network Policy container and select the New command from the resulting shortcut menu. When you do, Windows will launch the New Network Policy Wizard.
The first thing that you will have to do is to assign a name to the policy. Let’s call this policy Compliant-Full-Access. You can enter the policy’s name into the Policy Name field, found on the wizard’s initial screen. Leave the Type of Network Access Server drop down list set to Unspecified, as shown in Figure A, and click Next.

Figure A: Assign a name to the new policy and click Next
The next screen that you will encounter asks you to specify the conditions that are to be used by the new network policy. You can click the Add button to open the Specify Conditions dialog box. Scroll through the dialog box’s various options until you locate the Health Policies option. Select the Health Policies option, and click the Add button. When you do, you will be prompted to select the health policy that you want to enforce. Choose the Compliant option from the drop down list, as shown in Figure B.

Figure B: Choose the Compliant option from the list of health policies
Click OK to close the Select Conditions dialog box, and then click Next. When you do, Windows will display the wizard’s Specify Access Permission screen. Choose the Grant Access option, and click Next. Setting the access permission to Grant Access does not grant users full access to the network. All it means is that requests coming into this policy are approved for further processing.
At this point, you will see the wizard’s Configure Authentication Methods screen. This screen displays a series of check boxes, each corresponding to a different authentication method. Go ahead and accept the defaults, as shown in Figure C, and click Next.

Figure C: Accept the default authentication methods, and click Next
Click Next, and you will see the Configure Constraints screen. We don’t want to add any constraints to this policy, so just click Next.
You will now see the wizard’s Configure Settings screen. This screen allows you to specify the settings that should be applied if a computer is granted access. In some of the earlier builds of Windows Server 2008, you were required to disable NAP enforcement so that client computers could gain access to the network. In the RTM release though, the NAP Enforcement setting is configured by default to allow full access to the network. That being the case, we can just click Next.
You should now see a screen displaying a summary of the configuration options that you have chosen for the policy. Assuming that everything looks correct, click Finish to create the policy.
Non-Compliant Computers

So far we have created a policy for compliant computers, now we have to create a similar policy for computers that are not compliant. To do so, right click on the console tree’s Network Policies container and select the New command from the resulting shortcut menus. This will cause Windows to launch the now familiar New Network Policy wizard.
As was the case before, the first thing that you must do is to enter a name for the new policy that you are creating. Let’s call this policy Noncompliant-Restricted. Once again, set the Type of Network Access Server option to Unspecified, and click Next.
You will now be taken to the wizard’s Conditions screen. When we created the network policy for compliant computers, we created a condition which required the computer to comply with the compliant policy that we had created in a previous part of this article series. Since this policy is for non compliant computers though, you must check to see if the client computer’s configuration matches the conditions defined in the NonCompliant policy. Specifically, this means checking to make sure that the Windows firewall is not enabled.
To do so, click the Add button, and Windows will display the Select Conditions dialog box. Choose the Health Policies option from the list, and click the Add button. Now, choose the NonCompliant option from the list of health policies, and click OK, followed by Next.
Windows will now display the wizard’s Specify Access Permission screen. Even though we are creating a restricted policy, you must still set the policy type to Grant Access. Remember that this does not grant access to the network, but rather allows further processing of the policy.
Click Next, and you will be taken to the wizard’s Configure Authentication Methods screen. Once again, just accept the default settings, and click Next.
At this point, you will see the Configure Constraints screen. We don’t need to configure any constraints, so just click Next.
You will now be taken to the wizard’s Configure Settings screen. So far everything that we have done to the policy for non compliant computers has been identical to what we did to the policy for compliant computers aside from specifying a different policy. If we left this policy the way that it is, then non compliant computers could end up gaining network access. Since we don’t want for that to happen, we need to use NAP enforcement to prevent network access.
To do so, select the NAP Enforcement container found in the list of settings. When you do, the Details pane will display various enforcement options. Select the Allow Limited Access option, and then click the Enable Auto Remediation of Client Computers check box. Enforce option, and then select the Update Non Compliant Computers Automatically check box. Click Next, followed by Finish to create the new policy.
Conclusion

In this article, I have shown you how to create network policies for both compliant and for non compliant computers. In the next article in the series, we will conclude the server configuration

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Network-Access-Protection-Revisited-Part6.html

PART-6

In the previous article in this series, I showed you how to create authorization policies for both compliant and for noncompliant computers. In this article, we will complete the server configuration procedure. The first step in doing so is to create a network policy that can be applied to any machine that authenticates through the VPN server.
Creating a Network Policy

Begin the process by opening the Network Policy Server console and navigating through the console tree to NPS (Local) | Policies | Network Policies. At this point, the details pane should display any previously existing network policies. Take a moment to verify that the Compliant – Full Access and the Noncompliant – Restricted policies are enabled, and that the Connections to Microsoft Routing and Remote Access Server policy is disabled, as shown in Figure A.

Figure A: Make sure that the Compliant – Full Access and the Noncompliant – Restricted policies are enabled
Now it is time to create a network policy. To do so, right click on the Network Policies container and choose the New command from the resulting shortcut menu. When you do, Windows will launch the New Network Policy Wizard.
The first thing that you must do is to enter a name for the new policy that we are creating. For our purposes, let’s call the policy RRAS. After entering RRAS in the Policy Name field, select the Remote Access Server (VPN-Dial up) option from the Type of Network Access Server drop down list, as shown in Figure B.

Figure B: Set the Type of Network Access Server to Remote Access Server (VPN-Dial up)
Click Next, and the wizard will take you to the Specify Conditions screen. The wizard will not even allow you to continue until you specify at least one condition that must be met. I like to configure the policy to look at the inbound connection type. That way, I can set the policy to apply to any VPN connection that is established with the server.
To set the conditions, click the Add button, and then scroll through the Select Conditions dialog box until you find the Tunnel Type option. Select the Tunnel Type option, and click Add. You will now see a screen that asks you to specify the types of tunnels required to match the policy. You can really choose anything that you want here, but I recommend choosing the Layer Two Tunneling Protocol (L2TP) and the Point to Point Tunneling Protocol (PPTP) options, as shown in Figure C.

Figure C: Choose the PPTP and the L2TP options, and click OK
Click OK, and then click Next. The wizard will now display the Specify Access Permission screen. Choose the Access Granted radio button, and then select the Access is Determined by User Dial In Properties check box, as shown in Figure D.

Figure D: Choose the Access Granted radio button, and then select the Access is Determined by User Dial In Properties check box
The next screen that you will be taken to asks you which EAP types you want to use for authentication. You can use any EAP types that you want, but I recommend using Microsoft Protected EAP and EAP-MSCHAP-V2. To specify these types of EAP, click the Add button, and then select the Microsoft: Protected EAP (PEAP) option, and click OK. Next, click the Add button again, select the Microsoft: Secured Password (EAP-MSCHAP-V2) option, and click OK. When the wizard returns you to the Configure Authentication Methods screen, deselect the Microsoft Encrypted Authentication (MS-CHAP) check box. The screen should now look like the one that is shown in Figure E.

Figure E: Your Configure Authentication Methods screen should look like this
Click Next, and the wizard will display the Configure Constraints screen. As you can see in Figure F, this screen allows you to set things like the session timeout period or any day or time restrictions that you want to impose. Given the complexity of deploying NAP, I recommend not initially imposing any constraints. I tend to think that it is better to initially focus on getting NAP working, and then to go back later on and specify any desired constraints.

Figure F: I recommend waiting until later to impose any constraints
Click next, followed by Finish to complete the configuration process.
RADIUS Client Configuration Policy

In this type of deployment, the Network Policy Server acts as a RADIUS server. Rather than clients performing a direct RADIUS authentication against the Network Policy Server the RRAS server that is acting as a VPN server is going to be acting as the RADIUS client.
The last step in the server configuration process involves providing the Network Policy Server with a list of authorized RADIUS clients. Since the only RADIUS client is going to be the VPN server, you will simply enter the VPN server’s IP address. Keep in mind that the RRAS services are running on the same physical server as the Network Policy Services, so you will simply specify the server’s own IP address.
To create a RADIUS Client Configuration Policy, navigate through the Network Policy Server console tree to NPS (Local) | RADIUS Clients and Servers | RADIUS Clients. Now, right click on the RADIUS Clients container, and then choose the New RADIUS Client command from the resulting shortcut menu. This will cause Windows to open the New RADIUS Client dialog box.
The first thing that this dialog box requires you to do is to enter a friendly name and an IP address for the new RADIUS client. In a real world deployment, you would enter RRAS as the friendly name and you would enter the RRAS server’s IP address into the space provided. As you will recall, this is a lab deployment, and RRAS is running on the same server as the Network Policy Services. Therefore, enter the server’s own name and IP address into the spaces provided.
The next field on the dialog box is the Vendor Name field. To be perfectly honest, I have no idea what the Vendor Name really does, but the text on the dialog box instructs you to use the RADIUS Standard setting for most deployments. This has worked well for me in the past, so go ahead and select the RADIUS Standard option, if it is not already selected.
The next thing that the dialog box asks for is a shared secret. As with any shared secret, both the client and the server need to be aware of the shared secret. The most secure way of setting up a shared secret is to select the Generate button. When you do, Windows will automatically generate a random shared secret.
Personally, I recommend initially using a nice, simple, manual shared secret. There are two reasons for this. First, not all Windows clients support the use of really long shared secrets. Second, it is really hard to retype a long, random string made up of lots of numbers, letters, and symbols. In the interest of keeping things simple, I recommend choosing the Manual option, and then just using the word RRAS as the shared secret. Once you have gotten NAP working, you can always make it more secure by choosing a longer, more complex shared secret.
The last thing that you need to do is to select the RADIUS Client is NAP Capable check box. The NEW RADIUS Client dialog box should now look like the one that is shown in Figure G. Click OK to complete the configuration process.

Figure G: Enter a shared secret and select the Client is NAP Capable check box
Conclusion

In this article, we have completed the configuration of the Network Policy Server. In Part 7, I will show you how to perform the client configuration portion of the Setup process

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Network-Access-Protection-Revisited-Part7.html

PART-7

In the previous article in this series, we did some work on the Network Policy Server. Unfortunately, we are not quite done with the configuration process. Our Windows Vista clients are eventually going to authenticate into our VPN server using the Protected EAP (PEAP) protocol. Before we can use PEAP we have to associate a computer certificate with the VPN server. Fortunately, we have already created an enterprise certificate authority that we can use for that purpose. In this article, I will show you how to request the necessary certificate, and how to associate that certificate with the VPN server.
Requesting a Certificate

We are using Protected EAP (PEAP) as the server side authentication mechanism. In order to make that happen, we need to acquire a computer certificate from the certificate authority that we created earlier in the series. To do so, enter the MMC command at the Run prompt. When the Microsoft Management Console opens, select the Add / Remove Snap-in command from the File menu. Next, choose the Certificates option from the list of snap-ins, and click the Add button followed by the Finish button.
The console will now display the Certificate Templates snap-in. Expand the Certificate Templates container (It takes a few minutes to expand), and then locate the Computer template in the Details pane. Right click on the Computer template, and then choose the Duplicate Template command from the shortcut menu.
Windows will now ask you if you want to create a Windows Server 2003 or a Windows Server 2008 certificate. Choose the Windows Server 2008 option, and click OK. At this point, Windows will display the Properties of New Template dialog box.
The first thing that you will have to do is to enter a name for the new template. You can call the template anything that you want, so long as it is something meaningful to you. For the purposes of this article, I am going to call this certificate template VPN. Now, set the validity period for the template, and then select the Publish Certificate in Active Directory check box and the Allow Private key to be Exported Check box.
Now, go to the Request Handling tab, and make sure that the Purpose option is set to Signature and Encryption. You should also select the Add Read Permissions to Network Service check box. Finally, go to the Security tab, and click the Add button. When Windows displays the Select Users, Computers, or Groups dialog box, make sure that the From this Location field lists the name of your domain. Enter the word Administrators into the Enter the Object Names to Select field, and click the Check Names button. Assuming that Windows is able to resolve the Domain Administrators group, click OK. Finally, add the Allow Full Control option to the Administrators group, and click OK.
Now, close the Certificate Templates console, and then choose the Certification Authority command from the server’s Administrative Tools menu. When you do, Windows will open the Certification Authority console. At this point, you must expand the container that matches the name of your server, and locate the Certificate Template container beneath it.
Right click on the Certificate Template container, and then choose the New | Certificate Template to Issue command from the resulting shortcut menu. When you do, Windows will display the Enable Certificate Templates. Scroll through the list of available templates until you locate the template that you have created. Select the template, and click OK.
You should now be able to associate the certificate template with the server. To accomplish this, enter the MMC command at the Run prompt. When the Microsoft Management Console opens, choose the Add / Remove Snap-ins command from the File menu. When Windows displays the list of available snap-ins, pick the Certificates snap-in from the list, and click the Add button.
Right now, Windows will ask you if you want to manage the certificates for your user account, a service account, or a computer account. It is very important that you choose the Computer Account option. Click Next, followed by Finish and OK, and Windows will display the Certificates console.
The last part of the process involves expanding the Certificates (Local Computer) container to reveal the containers beneath it. Now, right click on the Personal container, and choose the All Tasks | Request New Certificate command from the shortcut menu. This will cause Windows to launch the Certificate Enrollment Wizard.
Click Next to bypass the Wizard’s Welcome screen and you will see a screen that displays the various templates that are available for enrollment. Select the check box that corresponds to the template that you have just created, and then click the Enroll button. The enrollment process can take a couple of minutes to complete. When the enrolment completes, click the Finish button. You can now close the Certificates console.
Now that we have associated a certificate with our server, we have to configure our connection request policy to use it. To do so, open the Network Policy Server console, and navigate through the console tree to NPS (Local) } Policies | Connection Request Policies. When you do, the details pane should display a list of connection request policies that reside on the server. You should have a policy named NAP VPN or something similar that you configured earlier in this article series.
Right click on the NAP VPN connection request policy, and choose the Properties command from the resulting shortcut menu. When you do Windows will display the NAP VPN Properties sheet. Go to the properties sheet’s Settings tab, and click on the Authentication Methods option. You should now see Microsoft: Protected EAP (PEAP) listed in the EAP Types list, as shown in Figure A. If you do not see a listing for Microsoft: Protected EAP (PEAP), then click the Add button to add it.

Figure A: Microsoft Protected EAP should be listed in the EAP Types list
Now, select the listing for Microsoft Protected EAP (PEAP), and click the Edit button. Verify that the certificate that you requested earlier is selected. You should also verify that the Enable Fast Reconnects check box and the Enable Quarantine Checks check boxes are selected. The EAP Types field at the bottom of the screen should be set to Secure Password (EAP MSCHAP V2). If it isn’t, then click the Add button and add it. When you have finished, click OK. Click OK one more time to complete this process.
Conclusion

In this article, I have shown you how to request a computer certificate, and how to associate that certificate with your VPN server. In the next article in the series, I will continue the discussion by walking you through some more of the configuration process

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Network-Access-Protection-Revisited-Part8.html

PART-8

In the previous article I showed you how to request a computer certificate and how to associate that certificate with your VPN server. In this article, I want to turn my attention towards clients who will be connecting to the VPN server. The client computers must be running Windows Vista or Windows XP with SP3 or higher, and must be domain members. Just as importantly though, they must be configured to run an enforcement client component. We will enable this component through the group policy. In this article, I will show you how.
Creating a Security Group

The thing about creating a Network Access Protection related group policy is that you probably do not want for it to apply to all of the computers on the network. Network servers for example, will probably never be connecting through the VPN, and therefore should not be configured as Network Access Protection clients. Because we need to discriminate between computers that need to act as Network Access Protection clients and those that do not, we will begin the process by creating a security group that we can apply the policy settings to.
To create the necessary security group, open the Active Directory Users and Computers console. When the console opens, right-click on your domain and then choose the New | Group commands from the resulting shortcut menus. When you do, Windows will open the New Object - Groups dialog box. Go ahead and specify NAP Clients as the name of the group. Make sure that the group's scope is set to Global, and make sure that the group type is set to Security. Click OK to create the group.
Install the Group Policy Management feature

The next thing that you will have to do is to install the Group Policy Management feature so that you can modify the various group policy settings. To do so, open Server Manager and go to the Features Summary section. Click the Add Features link, and you will be taken to a screen that shows you which features are currently installed. If it is not already installed, select the check box corresponding to the Group Policy Management feature. Finally, click Next, followed by Install. When the installation process completes, go ahead and click Close to close the wizard. You can also close the Server Manager at this point.
Creating the Group Policy Settings

Now that the necessary security group is in place, and we have installed the Group Policy Management feature, it is time to go ahead and configure the necessary group policy settings. Begin the process by entering the GPME.MSC command at the Run prompt. When you do so, Windows will display a dialog box which allows you to choose which of the existing group policies you want to edit. Rather than editing one of the existing group policies, we need to create a new group policy object.
You can accomplish this by clicking the Create New Group Policy Object button which is found just to the right of the listing for your domain. Upon clicking this button, you will be prompted to enter the name of the new group policy object that you are creating. For our purposes, let us call the new group policy object NAP Client Settings.
Now that the new group policy object has been created, select it and click OK. This will cause Windows to open the Group Policy Management Editor. You must now navigate through the console tree to Computer | Configuration | Policies | Windows Settings | Security Settings | System Services. Now, double-click on the listing for Network Access Protection Agent, found in the details pane.
Windows should now open the Network Access Protection Agent Properties dialog box. Select the Define This Policy Setting check box, and then choose the Automatic startup option. Click OK to close the dialog box.
Now, navigate through the console tree to Computer Configuration | Policies | Windows Settings | Security Settings | Network Access Protection | NAP Client Configuration | Enforcement Clients. Upon doing so, the details pane will display a list of the various enforcement clients that are available. Right-click on the Remote Access Quarantine Enforcement Client, and then choose the Enable command from the shortcut menu. Now, go back to the NAP Client Configuration container, right-click on it, and then choose Apply.
Now, go back through the console tree to Computer Configuration | Policies | Administrative Templates | Windows Components | Security Center. Double-click on the Turn on Security Center (Domain PCs Only) container shown in the details pane. When you do, Windows will display the Turn on Security Center (Domain PCs Only) Properties dialog box. Choose the Enabled option, and click OK. This will ensure that the Security Center is accessible from client PCs. This is important since we are going to be testing Network Access Protection for ability to detect whether or not the Windows firewall is currently enabled.
To complete the process, click OK and then close the Group Policy Management Editor. In some cases you may receive a prompt asking you if you want to apply the changes that you have made to the group policy object. If you receive such a prompt, then be sure to apply the changes.
Configuring Security Filters

The next thing that we have to do is to apply some security filters that will prevent Network Access Protection clients’ settings from being applied to network servers. To configure the necessary filters, enter the GPMC.MSC command at the Run prompt. This will cause Windows to open the Group Policy Management Console. Navigate through the console tree to Domain | your domain | Group Policy Objects | NAP Client Settings.
If you look at the details pane, you will notice the section labeled Security Filtering toward the bottom of the screen. By default, the policy applies to authenticated users. We need to change this so that the policy is not globally applied to anyone who is logged in. Click on the Authenticated Users listing, and then click the Remove button. Click OK when Windows asks you if you are sure.
Now, click the Add button. Windows should ask you to select a user, computer, or group that you want to use as a security filter. Enter NAP Clients into the space provided, and click the Check Names button. Assuming that the name resolves successfully, click OK.
Conclusion

Now all of the necessary group policy settings are in place. In the next article in this series, I will show you how to add your client computer to the security group that we have created in this article. From there, I will show you how to do some simple tests to make sure that the group policy settings that we have defined are being applied in the correct manner. We will then go on to test Network Access Protection, and ensure that it is able to detect whether or not the Windows firewall is enabled on the client PC

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Network-Access-Protection-Revisited-Part9.html

PART-9

Introduction

In the previous part of this article series, I showed you how to establish a security group that can be use to designate which computers will be operated using Network Access Protection. In this article, I will conclude the series by showing you how to make a client computer a member of the group that you previously created, and we will perform some tests to make sure that remote access quarantine enforcement is going to be enabled. Finally, I will show you how to connect to your remote access VPN.
Adding Computers to the Group

Our next task that we have to perform is to add some client computers to the security group that we created in the previous article. Begin the process by opening the Active Directory Users and Computers console, and then selecting the container that bears the name of your domain. The reason why we are selecting this container is because we created the security group at the domain level, rather than placing it in the Users container.
When you select the domain level container, you should see the NAP Clients group displayed in the details pane. Double click on this group and Windows will open the group’s properties sheet. Go to the properties sheet’s Members tab and click the Add button. Now, enter the name of a client PC into the space provided. Next, click the Locations button and select the Computers container, and click OK. When Windows returns you to the Select Users, Contacts, Computers, or Groups screen, click the Check Names button to verify that Windows can find your client computer successfully. Click OK twice to complete the process.
Testing Your Group Policy Settings

Now that you have added a client computer to the security group that you have created, it is time to test the client computer to make sure that the NAP related group policy settings are in effect. Before you do though, go ahead and reboot the client machine, and then log in as a standard user.
Once you log in, open a Command Prompt window and enter the following command:
NETSH NAP CLIENT SHOW GROUPPOLICY
When you do, you should see a set of results similar to the ones that are shown in Figure A.

Figure A: Enter the NETSH NAP CLIENT SHOW GROUPPOLICY command at the Command Prompt
As you can see in the figure, there are several different types of enforcement clients built into Windows. This is because there are several different ways that NAP can be deployed. Being that we are using NAP to control access to a VPN server, the only enforcement client that we are interested in is the Remote Access Quarantine Enforcement Client. Look beneath the Remote Access Quarantine Enforcement Client, and ensure that the Admin line is set to Enabled, as shown in the figure above. The other enforcement clients should remain disabled in this particular configuration.
For the next test, enter the following command:
NETSH NAP CLIENT SHOW STATE
As you can see in Figure B, the output from this command is fairly long. Scroll through the output until you locate the Remote Access Quarantine Enforcement Client section. Verify that the Remote Access Quarantine Enforcement Client is initialized.

Figure B: Verify that the Remote Access Quarantine Enforcement Client is initialized
If both of these tests are successful, then the group policy settings related to NAP are successfully being applied to the client. If that is the case, then go ahead and close the Command Prompt window. Otherwise, you will need to go back and double check your configuration.
Creating a VPN Connection

The last step in the configuration process involves setting up our VPN connection to the Remote Access Server. The process for doing so is pretty simple. In Windows Vista, open the Control Panel, and then double click on the Network and Sharing Center icon. When the Network and Sharing Center opens, click the Setup a Connection or Network link, located in the Tasks pane. At this point, you will see a screen similar to the one shown in Figure C, asking you what type of connection you want to create.

Figure C: Choose the Connect to Workplace option, and click Next
Choose the Connect to a Workplace option, and click Next. If there are already network connections present, then Windows will ask you if you want to create a new connection or if you want to use an existing connection. Choose the option to create a new connection, and click Next.
The following screen asks you if you want to use your Internet connection, or if you want to create a direct dial connection. Choose the Use My Internet Connection (VPN) option. You will now be prompted to enter the Internet Address and the destination name. Enter either the RRAS server’s IP address or its URL into the Internet Address field, and then enter a description of the connection into the Destination Name field. You can see an example of this in Figure D. You should also select the Don’t Connect Now check box.

Figure D: Enter the RRAS server’s IP address and a description of the server that you are connecting to
Click Next, and you will be taken to a screen that gives you the option of entering your authentication credentials. Whether or not you save your credentials as a part of the connection’s attributes is up to you. When you are done, click the Create button, and the new connection will be created. Click Close to close the remaining dialog box.
Now that you have created a VPN connection, we have to configure some security settings. To do so, right click on the connection that you just created, and then choose the Properties command from the resulting shortcut menu.
When Windows opens the connection’s properties sheet, go to the Security tab, and select the Advanced option. Next, click the Settings button.
Windows will now display the Advanced Security Settings dialog box, shown in Figure E. Select the Require Encryption (Disconnect if Server Declines) option from the Data Encryption drop down list. Next, select the Use Extensible Authentication Protocol (EAP) option, and then choose the Protected EAP (PEAP) (Encryption Enabled) option from the Logon Security section.

Figure E: You must configure the connection to use PEAP
At this point, you must click the Properties button. When you do, Windows will display the Protected EAP Properties dialog box, shown in Figure F. Make sure that the Validate Server Certificate and the Connect to these Servers check boxes are selected. You should also make sure that the text box beneath the Connect to These Servers option contains a listing for the correct server.

Figure F: The authentication method must be set to EAP-MSCHAP V2)
The middle section of the dialog box contains a list of various certificate authorities. For the sake of simplicity, go ahead and select the check boxes next to each listed certificate authority. In the lower section of the dialog box, you should ensure that the Select Authentication Method option is set to Secure Password (EAP-MSCHAP v2) and that the Enable Quarantine Checks check box is selected.
The next step in the process is to click the Configure button, and then select the Automatically Use My Windows Logon Name and Password (and Domain if Any) check box. Click OK four times to close the various dialog boxes.
Testing NAP

At this point, we are finally ready to put NAP to the test. As you may recall, you can require clients to meet any number of health criteria, but for demonstration purposes, we are only requiring the Windows Firewall to be enabled on the client machine. That being the case, open the Windows Security Center on the client machine, and turn the Windows Firewall off. When you are done, I recommend leaving the main Windows Security Center screen, shown in Figure G, open so that you can verify the status of the Windows Firewall.

Figure G: Ensure that the Windows Firewall is turned off
Now, open the Control Panel and double click on the Network and Sharing Center icon. When the Network and Sharing Center opens, click the Connect to a Network link. Next, Click on the VPN connection that you created earlier, and click the Connect button. When prompted, enter your authentication credentials, and click the Connect button. As Windows registers your computer on the network, the Windows Firewall should be automatically turned on, as shown in Figure H.

Figure H: NAP should automatically enable the Windows Firewall when the VPN connection is established
Conclusion

As you can see, configuring your Remote Access Server to use Network Access Protection is a rather tedious process. Even so, it is usually worth the effort, because doing so helps you to better ensure your network’s security