Network Access Protection, Revisited (Part 6)

If you would like to read other parts to the article series please read:

Network Access Protection, Revisited (Part 1)

  • Network Access Protection, Revisited (Part 2)
  • Network Access Protection, Revisited (Part 3)
  • Network Access Protection, Revisited (Part 4)
  • Network Access Protection, Revisited (Part 5)
  • Network Access Protection, Revisited (Part 7)
  • Network Access Protection, Revisited (Part 8)
  • Network Access Protection, Revisited (Part 9)
  • 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.

    If you would like to read other parts to the article series please read:

    Network Access Protection, Revisited (Part 1)

  • Network Access Protection, Revisited (Part 2)
  • Network Access Protection, Revisited (Part 3)
  • Network Access Protection, Revisited (Part 4)
  • Network Access Protection, Revisited (Part 5)
  • Network Access Protection, Revisited (Part 7)
  • Network Access Protection, Revisited (Part 8)
  • Network Access Protection, Revisited (Part 9)
  • About The Author

    Leave a Comment

    Your email address will not be published. Required fields are marked *

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

    Scroll to Top