Kaanosh Forums: Network Access Protection (Part 2)

Message

   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 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 network 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. Health criteria varies so much from one company to another that Microsoft left the system health validator policy empty (at least in the current beta). As such, it will be up to you to configure the system health validator.
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 hosting the Network Policy Server on this box is just asking for trouble. There is nothing in Windows that prevents you from using the same server for both the VPN components and the Network Policy Server, so for demonstration purposes (and because of a lack of hardware) I will be using the same box to host both components.
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 Validators 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, keep the A Firewall is Enabled for all Network Connections check box selected, and 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
Now that you have configured the System Health Validators, you must configure a System Health Validator template. System health Validator templates 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 templates, right click on the System Health Validator Template container and select the New command from the resulting shortcut menu. When you do, Windows will display the Create New SHV Template dialog box that’s shown in Figure D.

Figure D: You must create a new system health validator template
As you can see in the figure, the dialog box prompts you to enter a name for the new template. Enter the word Compliant into the Name field. Now, make sure that the Template Type 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 template that defines what it means to be compliant. We must now create a second template that defines what it means for a system to be out of compliance. To do so, right click on the System Health Validator Templates 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 template NonCompliant. Set the Template Type to Client Fails one or More SHV Checks. 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 System health Validator Templates container, you should see both the Compliant and the NonCompliant template 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 System health Validator Templates container, you should see both the Compliant and the NonCompliant template displayed in the console’s center pane.

In the previous article in this series, I showed 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 system health validator templates that define what it means to be in and out of compliance with the network health policy.
In this article, I will continue the discussion by showing 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.
Begin the process by opening the Network Policy Server console if it isn’t already open and selecting the console’s Authorization Policies container. Upon doing so, take a look at the Details pane to see if any authorization policies currently exist. On my test system, there are four previously existing authorization policies, but who knows whether or not those policies will exist in the final version of Longhorn Server. If any policies do exist, delete them by right clicking on them and selecting the Delete command from the resulting shortcut menu.
Now that you have cleared out the previously existing policies, you can create a new authorization policy. To do so, right click on the Authorization Policy container and select the New | Custom commands from the resulting shortcut menus. Windows will now display the New Authorization Policy Properties sheet. 
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 properties sheet’s Overview tab. Now, set the policy type option to Grant Access, as shown in Figure A. Setting the policy type 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.

Figure A: Set the Policy Type to Grant Access
Now, select the properties sheet’s Conditions tab. As the name implies, the Conditions tab allows you to set the conditions that a client computer must meet in order for the policy to be applied. Scroll through the list of available conditions to Network Access Protection, and then select the SHV Templates option located beneath it. When you do, the details pane will display the Existing Templates drop down list. Choose Compliant from the drop down list and click the Add button. The Conditions used in this Policy window will now indicate that Computer Health matches “Compliant”, as shown in Figure B. This means that in order to be considered compliant, client computers must match the criteria defined in the Compliant policy that you created in a previous part of this article series. More specifically, it means that client computers must have the Windows firewall enabled.

Figure B: In order to be compliant, client computers must meet the requirements defined in the Compliant policy that you created in a previous part of this article series
Now, select the properties sheet’s Settings tab. The Settings tab contains a variety of settings that can be applied to computers meeting the conditions that you defined earlier. Since this is a policy that will be applied to computers that are compliant with the network security policy, we need to remove any restrictions from the Settings so that compliant computers can gain access to the network.
To do so, navigate through the console tree to Network Access Protection | NAP Enforcement. Now, select the Do Not Enforce radio button, as shown in Figure C. This prevents compliant computers from being restricted from accessing network resources.

Figure C: NAP enforcement should not be applied to compliant computers
After you select the Do Not Enforce option, navigate through the console tree to Constraints | Authentication Method. The details pane should now display a series of check boxes, each corresponding to a different authentication method. Go ahead and uncheck all of the check boxes, but check the EAP check box. Click the EAP Methods check box and then click the Add button. Select the Secured Password (EAP-MSCHAP v2) option and click OK twice to close the various dialog boxes that have opened. Click OK once more to save the template that you have created.
So far we have created a template for compliant computers, now we have to create a similar template for computers that are not compliant. To do so, right click on the console tree’s Authorization Policies container and select the New | Custom commands from the resulting shortcut menus. This will cause Windows to reveal the now familiar New Authorization Policy Properties sheet. 
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. 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.
Now, select the Conditions tab. When we created the authorization policy for compliant computers, we created a condition which required the computer to comply with the compliant template 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 template. Specifically, this means checking to make sure that the Windows firewall is not enabled.
Scroll through the list of available conditions to Network Access Protection and then select the SHV Templates container. Select the NonCompliant option from the list of existing templates, and then click the Add button.
Next, select the Settings tab and navigate through the console tree to Constraints | Authentication Method. The details pane should now display a series of check boxes, each corresponding to a different authentication method. Go ahead and uncheck all of the check boxes, but check the EAP check box. Click the EAP Methods check box and then click the Add button. Select the Secured Password (EAP-MSCHAP v2) option and click OK twice to close the various dialog boxes that have open. 
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 SHV template. 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 Available Settings. When you do, the Details pane will display various enforcement options. Select the Enforce option, and then select the Update Non Compliant Computers Automatically check box, as shown in Figure D. Click OK to save the policy that you have created.

Figure D: You must enforce NAP protection for non compliant computers
Conclusion
In this article, I have shown you how to create authorization policies for both compliant and for non compliant computers. In the next article in the series, we will conclude the server configuration.

In the previous article in this series, I showed you how to create authorization policies for both compliant and for non compliant computers. In this article, we will complete the server configuration procedure. The first step in doing so is to create a default authentication policy that can be applied to any machine that authenticates through the RRAS server.
Begin the process by opening the Network Policy Server console and navigating through the console tree to NPS (Local) | Authentication Processing | Authentication Policies. At this point, the details pane should display any previously existing authentication policies. Delete the existing policies by right clicking on them and selecting the Delete command from the resulting shortcut menu.
Now it’s time to create a default authentication policy. To do so, click the New link found in the Actions pane and then choose the Custom option. Windows will now display the New Authentication Policy properties sheet, shown in Figure A.

Figure A: Enter RRAS as the policy name and then verify that the policy is enabled
Enter RRAS as the policy name, and then verify that the Policy Enabled check box is selected. Next, make sure that the Available Sources radio button is selected, and then select the Remote Access Server (VPN-Dialup) option from the Available Sources drop down list.
Now, switch to the Settings tab and select the Authentication container from the console tree. Now, select the Override Authentication Settings from Authorization Policy check box. When you do, the details pane will display a variety of authentication methods, as shown in Figure B. Select the EAP check box, and then click the EAP Methods button.

Figure B: Select the EAP check box and then click the EAP Methods button
Windows will now display the Select EAP Providers dialog box. Click the Add button to reveal a list of EAP authentication methods. Choose EAP-MSCHAPv2 and Protected EAP (PEAP) from the list and click OK. The selected EAP authentication methods should now be displayed in the Select EAP Providers dialog box, as shown in Figure C. Click OK to continue.

Figure C: You must enable MSCHAPv2 and PEAP authentication
Now go to the Conditions tab. You must select at least one condition that must be met in order for the policy to be enforced. You can set any condition that you want, I recommend navigating through the console tree to Connection Properties | Tunnel Type and then selecting the Point to Point Tunneling Protocol and the Layer Two Tunneling Protocol check boxes and clicking the Add button. That way the new authentication policy will apply to VPN connections. Click OK to save the new authentication policy that you have created.
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. Since the RRAS services are running on the same physical server as the Network Policy Services, you will simply use the server’s IP address.
To create a RADIUS Client Configuration Policy, navigate through the Network Policy Server console tree to NPS (Local) | RADIUS Clients. Now, click the New RADIUS Client link found in the Actions pane. Windows will now launch the New RADIUS Client Wizard. 
On the wizard’s initial screen, you will be prompted 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 IP address into the space provided and click Next.
At this point, the wizard will display the Additional Information screen. This screen asks you for a client vendor and for a shared secret. Select RADIUS Standard as the Client Vendor. For the purposes of this article, enter RRASS as the shared secret. Select the Client is NAP Capable check box, as shown in Figure D, and click Finish. You are finally done configuring the Network Policy Server!

Figure D: Enter a shared secret and select the Client is NAP Capable check box
Client Configuration
Now that we have finished configuring the Network Policy Server, it’s time to configure a client to connect to the server. Keep in mind that the technique that I am about to show you will only work on clients that are running Windows Vista.
For the purposes of this article, I am assuming that the client machine is running Windows Vista, and that it is configured with a static IP address. As you may know, Windows Vista is designed to run IPv6 by default. Network Access Protection should eventually support IPv6, but being that Windows Longhorn Server is still in beta testing, it seems that IPv6 is currently unsupported when it comes to Network access protection. That being the case, you should disable IPv6 on the machine’s network configuration. When Longhorn Server is eventually released, I intend to write an update to this article series that addresses the use of IPv6, as well is anything that has changed since the beta.
The client computer should also be configured as a member of the domain that contains the Network Policy Server. In addition, the domain should contain a user account that you can use to log in to the Routing and Remote Access Server that you have created.
Now let’s create a Virtual Private Network connection that you will eventually be able to use to test the Network Access Protection server. To do so, open the Control Panel and click on the Network and Internet link, followed by the Network Center link. When the Network Center opens, click the Set up a Connection or Network link. You should now see a screen asking you what type of connection you want to create. Click the Connect to a Workplace option and then click Next. 
Choose the option to connect through a VPN, and you’ll be prompted to enter a Internet address and a destination name. You should enter the IP address of the RRAS server into the Internet Address field. You can enter anything that you want into the Destination Name field. Select the Allow Other People to use this Connection check box, and click Next. You must now enter a user name and password for a user who has permission to logon to the RRAS server, as well as the name of the domain that you will be logging onto.
Click the Connect button and Vista will attempt to connect to your RRAS server. More than likely, the connection will fail. When you receive the message stating that the wizard cannot connect to your workplace, click the Setup a Connection Anyway icon. This will save your settings so that we can finish customizing them in the next part of this series.
Conclusion
In this article, we have completed the configuration of the Network Policy Server, and begun configuring a network client. In the next article I will conclude the series by showing you how to complete the client configuration.

Author	Message
spyex2000 Newbie Joined: 07 Sep 2006 Online Status: Offline Posts: 26	Topic: Network Access Protection (Part 2) Posted: 04 May 2007 at 1:22am
	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 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 network 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. Health criteria varies so much from one company to another that Microsoft left the system health validator policy empty (at least in the current beta). As such, it will be up to you to configure the system health validator. 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 hosting the Network Policy Server on this box is just asking for trouble. There is nothing in Windows that prevents you from using the same server for both the VPN components and the Network Policy Server, so for demonstration purposes (and because of a lack of hardware) I will be using the same box to host both components. 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 Validators 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, keep the A Firewall is Enabled for all Network Connections check box selected, and 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 Now that you have configured the System Health Validators, you must configure a System Health Validator template. System health Validator templates 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 templates, right click on the System Health Validator Template container and select the New command from the resulting shortcut menu. When you do, Windows will display the Create New SHV Template dialog box that’s shown in Figure D. Figure D: You must create a new system health validator template As you can see in the figure, the dialog box prompts you to enter a name for the new template. Enter the word Compliant into the Name field. Now, make sure that the Template Type 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 template that defines what it means to be compliant. We must now create a second template that defines what it means for a system to be out of compliance. To do so, right click on the System Health Validator Templates 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 template NonCompliant. Set the Template Type to Client Fails one or More SHV Checks. 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 System health Validator Templates container, you should see both the Compliant and the NonCompliant template 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 System health Validator Templates container, you should see both the Compliant and the NonCompliant template displayed in the console’s center pane. In the previous article in this series, I showed 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 system health validator templates that define what it means to be in and out of compliance with the network health policy. In this article, I will continue the discussion by showing 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. Begin the process by opening the Network Policy Server console if it isn’t already open and selecting the console’s Authorization Policies container. Upon doing so, take a look at the Details pane to see if any authorization policies currently exist. On my test system, there are four previously existing authorization policies, but who knows whether or not those policies will exist in the final version of Longhorn Server. If any policies do exist, delete them by right clicking on them and selecting the Delete command from the resulting shortcut menu. Now that you have cleared out the previously existing policies, you can create a new authorization policy. To do so, right click on the Authorization Policy container and select the New \| Custom commands from the resulting shortcut menus. Windows will now display the New Authorization Policy Properties sheet. 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 properties sheet’s Overview tab. Now, set the policy type option to Grant Access, as shown in Figure A. Setting the policy type 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. Figure A: Set the Policy Type to Grant Access Now, select the properties sheet’s Conditions tab. As the name implies, the Conditions tab allows you to set the conditions that a client computer must meet in order for the policy to be applied. Scroll through the list of available conditions to Network Access Protection, and then select the SHV Templates option located beneath it. When you do, the details pane will display the Existing Templates drop down list. Choose Compliant from the drop down list and click the Add button. The Conditions used in this Policy window will now indicate that Computer Health matches “Compliant”, as shown in Figure B. This means that in order to be considered compliant, client computers must match the criteria defined in the Compliant policy that you created in a previous part of this article series. More specifically, it means that client computers must have the Windows firewall enabled. Figure B: In order to be compliant, client computers must meet the requirements defined in the Compliant policy that you created in a previous part of this article series Now, select the properties sheet’s Settings tab. The Settings tab contains a variety of settings that can be applied to computers meeting the conditions that you defined earlier. Since this is a policy that will be applied to computers that are compliant with the network security policy, we need to remove any restrictions from the Settings so that compliant computers can gain access to the network. To do so, navigate through the console tree to Network Access Protection \| NAP Enforcement. Now, select the Do Not Enforce radio button, as shown in Figure C. This prevents compliant computers from being restricted from accessing network resources. Figure C: NAP enforcement should not be applied to compliant computers After you select the Do Not Enforce option, navigate through the console tree to Constraints \| Authentication Method. The details pane should now display a series of check boxes, each corresponding to a different authentication method. Go ahead and uncheck all of the check boxes, but check the EAP check box. Click the EAP Methods check box and then click the Add button. Select the Secured Password (EAP-MSCHAP v2) option and click OK twice to close the various dialog boxes that have opened. Click OK once more to save the template that you have created. So far we have created a template for compliant computers, now we have to create a similar template for computers that are not compliant. To do so, right click on the console tree’s Authorization Policies container and select the New \| Custom commands from the resulting shortcut menus. This will cause Windows to reveal the now familiar New Authorization Policy Properties sheet. 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. 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. Now, select the Conditions tab. When we created the authorization policy for compliant computers, we created a condition which required the computer to comply with the compliant template 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 template. Specifically, this means checking to make sure that the Windows firewall is not enabled. Scroll through the list of available conditions to Network Access Protection and then select the SHV Templates container. Select the NonCompliant option from the list of existing templates, and then click the Add button. Next, select the Settings tab and navigate through the console tree to Constraints \| Authentication Method. The details pane should now display a series of check boxes, each corresponding to a different authentication method. Go ahead and uncheck all of the check boxes, but check the EAP check box. Click the EAP Methods check box and then click the Add button. Select the Secured Password (EAP-MSCHAP v2) option and click OK twice to close the various dialog boxes that have open. 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 SHV template. 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 Available Settings. When you do, the Details pane will display various enforcement options. Select the Enforce option, and then select the Update Non Compliant Computers Automatically check box, as shown in Figure D. Click OK to save the policy that you have created. Figure D: You must enforce NAP protection for non compliant computers Conclusion In this article, I have shown you how to create authorization policies for both compliant and for non compliant computers. In the next article in the series, we will conclude the server configuration. In the previous article in this series, I showed you how to create authorization policies for both compliant and for non compliant computers. In this article, we will complete the server configuration procedure. The first step in doing so is to create a default authentication policy that can be applied to any machine that authenticates through the RRAS server. Begin the process by opening the Network Policy Server console and navigating through the console tree to NPS (Local) \| Authentication Processing \| Authentication Policies. At this point, the details pane should display any previously existing authentication policies. Delete the existing policies by right clicking on them and selecting the Delete command from the resulting shortcut menu. Now it’s time to create a default authentication policy. To do so, click the New link found in the Actions pane and then choose the Custom option. Windows will now display the New Authentication Policy properties sheet, shown in Figure A. Figure A: Enter RRAS as the policy name and then verify that the policy is enabled Enter RRAS as the policy name, and then verify that the Policy Enabled check box is selected. Next, make sure that the Available Sources radio button is selected, and then select the Remote Access Server (VPN-Dialup) option from the Available Sources drop down list. Now, switch to the Settings tab and select the Authentication container from the console tree. Now, select the Override Authentication Settings from Authorization Policy check box. When you do, the details pane will display a variety of authentication methods, as shown in Figure B. Select the EAP check box, and then click the EAP Methods button. Figure B: Select the EAP check box and then click the EAP Methods button Windows will now display the Select EAP Providers dialog box. Click the Add button to reveal a list of EAP authentication methods. Choose EAP-MSCHAPv2 and Protected EAP (PEAP) from the list and click OK. The selected EAP authentication methods should now be displayed in the Select EAP Providers dialog box, as shown in Figure C. Click OK to continue. Figure C: You must enable MSCHAPv2 and PEAP authentication Now go to the Conditions tab. You must select at least one condition that must be met in order for the policy to be enforced. You can set any condition that you want, I recommend navigating through the console tree to Connection Properties \| Tunnel Type and then selecting the Point to Point Tunneling Protocol and the Layer Two Tunneling Protocol check boxes and clicking the Add button. That way the new authentication policy will apply to VPN connections. Click OK to save the new authentication policy that you have created. 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. Since the RRAS services are running on the same physical server as the Network Policy Services, you will simply use the server’s IP address. To create a RADIUS Client Configuration Policy, navigate through the Network Policy Server console tree to NPS (Local) \| RADIUS Clients. Now, click the New RADIUS Client link found in the Actions pane. Windows will now launch the New RADIUS Client Wizard. On the wizard’s initial screen, you will be prompted 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 IP address into the space provided and click Next. At this point, the wizard will display the Additional Information screen. This screen asks you for a client vendor and for a shared secret. Select RADIUS Standard as the Client Vendor. For the purposes of this article, enter RRASS as the shared secret. Select the Client is NAP Capable check box, as shown in Figure D, and click Finish. You are finally done configuring the Network Policy Server! Figure D: Enter a shared secret and select the Client is NAP Capable check box Client Configuration Now that we have finished configuring the Network Policy Server, it’s time to configure a client to connect to the server. Keep in mind that the technique that I am about to show you will only work on clients that are running Windows Vista. For the purposes of this article, I am assuming that the client machine is running Windows Vista, and that it is configured with a static IP address. As you may know, Windows Vista is designed to run IPv6 by default. Network Access Protection should eventually support IPv6, but being that Windows Longhorn Server is still in beta testing, it seems that IPv6 is currently unsupported when it comes to Network access protection. That being the case, you should disable IPv6 on the machine’s network configuration. When Longhorn Server is eventually released, I intend to write an update to this article series that addresses the use of IPv6, as well is anything that has changed since the beta. The client computer should also be configured as a member of the domain that contains the Network Policy Server. In addition, the domain should contain a user account that you can use to log in to the Routing and Remote Access Server that you have created. Now let’s create a Virtual Private Network connection that you will eventually be able to use to test the Network Access Protection server. To do so, open the Control Panel and click on the Network and Internet link, followed by the Network Center link. When the Network Center opens, click the Set up a Connection or Network link. You should now see a screen asking you what type of connection you want to create. Click the Connect to a Workplace option and then click Next. Choose the option to connect through a VPN, and you’ll be prompted to enter a Internet address and a destination name. You should enter the IP address of the RRAS server into the Internet Address field. You can enter anything that you want into the Destination Name field. Select the Allow Other People to use this Connection check box, and click Next. You must now enter a user name and password for a user who has permission to logon to the RRAS server, as well as the name of the domain that you will be logging onto. Click the Connect button and Vista will attempt to connect to your RRAS server. More than likely, the connection will fail. When you receive the message stating that the wizard cannot connect to your workplace, click the Setup a Connection Anyway icon. This will save your settings so that we can finish customizing them in the next part of this series. Conclusion In this article, we have completed the configuration of the Network Policy Server, and begun configuring a network client. In the next article I will conclude the series by showing you how to complete the client configuration.

	IP Logged

Networking Error !
Kaanosh Forums :Hardware Error!! :Networking Error !