Securing Wireless Networks with Windows Server 2008 and NPS

In this post I’m going to go through the process of securing your wireless network using Windows Server 2008 and the NPS (Network Policy Services) role from start to finish.

Previously, I was using Windows Server 2003 with IAS (Internet Authentication Services) to secure my wireless network, until I recently upgraded all of my servers to Windows Server 2008 – By the way, NPS is the new version and name for IAS.

Here is the TechNet guide which I followed – http://technet.microsoft.com/en-us/library/cc771455.aspx – I will be applying these guidelines to the following environment…

  • A Windows Server 2008 machine running AD DS (Active Directory Domain Services)
  • A Windows Server 2008 machine running NPS (Network Protection Services) and AD CS (Active Directory Certificate Services)
  • A Linksys WAP54G (an entry level wireless access point – you can use any wireless access point that supports RADIUS)

You can run NPS, AD DS and AD CS on the same machine if you want to, but I wouldn’t recommend it (personally, I prefer to keep my domain controllers running only AD DS).

I’m not going to go through the process of installing AD DS as it’s a little out of scope for this post, so we’ll start from having an established domain, and a clean install of Windows Server 2008 on which we will install AD CS and NPS.

The first step is installing AD CS and NPS on your clean Windows Server 2008 install…

  1. First, you’ll need to join the server to your existing domain and then restart;
  2. After the server restarts, open Server Manager;
  3. Click on the Roles node;
  4. Click on the Add Roles;
  5. On the Server Roles screen, select Active Directory Certificate Services and Network Policy and Access Services;
  6. Follow the wizard, selecting Network Policy Server when configuring the Network Policy and Access Services role and leaving the default Certification Authority role service selected for AD CS;
  7. Select Enterprise for the setup type for AD CS;
  8. Choose Root CA for the CA Type (remember we’re assuming that this is the first Certification Authority in your environment, so if it’s not you either don’t need to install this role, or if you choose you can configure this server as a Subordinate CA instead);
  9. Run through the rest of the wizard, making any changes you may wish to, otherwise just leave the defaults as they are appropriate (I changed the CA Common Name to the name of the server, as I think it’s cleaner) – Note that there is a warning at the end of the wizard, stating that the name of this server cannot be changed after installing the AD CS role.

Now that you have a Root CA and an NPS server on your domain, we can start configuring it…

  1. Open an MMC console, and go to File -> Add/Remove Snap-in…
  2. Add the Certificates snap-in, selecting Computer account for the local computer;
  3. Expand Certificates (Local Computers) -> Personal, right click on Certificates and choose Request new certificate;
  4. Follow the wizard, choosing Computer for the certificate type and then click the Enroll button, then close MMC;
  5. Open the Network Policy Server administrative console from Administrative Tools;
  6. Right click on the parent node, NPS (Local) and click Register server in Active Directory – Click OK on the two informational popups;
  7. With the NPS (Local) node still selected, choose RADIUS server for 802.1X Wireless or Wired Connections and then click on the Configure 802.1X button;
  8. Under Type of 802.1X connections, select Secure Wireless Connections and provide an appropriate name for the policies which will be created as part of this wizard;
  9. In the next step, you’ll need to configure a RADIUS client (by the way, RADIUS stands for Remote Authentication Dial In User Service), so click on the Add button;
  10. The RADIUS client will be your wireless access point, so for the friendly name type in something to identify the access point (for example, AP01), then provide the IP address or DNS entry for the access point;
  11. Click on the Generate radio button, and then click on the Generate button to generate a shared secret – Copy the shared secret to a notepad document, and click OK – Note that on my particular access point, a character limit of 22 characters exists for shared secrets so I had to cut the string down to the acceptable limit, so I would suggest checking for this limitation on your own hardware;
  12. Click Next, and then choose Microsoft: Protected EAP (PEAP) and then click on the Configure button (if you get an error message, you probably didn’t follow steps 1 -> 4 correctly);
  13. Ensure that the Certificate issued drop down box has the certificate you enrolled in step 4;
  14. Click Next, and then click on the Add button to use an Active Directory group to secure your wireless (you should add both the machine accounts and user accounts to this group to allow the machine to authenticate on the wireless before the user logs in);
  15. On the next step of the wizard, you can configure VLAN information, otherwise just accept defaults to complete;
  16. Restart the Network Policy Server service.

If you expand the Policies node now, you’ll see that the wizard has created a Connection Request Policy and a Network Policy containing the appropriate settings to authenticate your wireless connection – These individual policies can obviously be created manually, but the wizard is an easier method.

You can also remove the less secure authentication method options, and increase the encryption methods in the network policy if you wish (I have configured mine this way)…

  1. Under the Network Policies node, bring up the properties of the newly created policy;
  2. On the Constraints tab, uncheck all of the checkboxes under Less secure authentication methods;
  3. On the Settings tab, click on Encryption and uncheck all boxes except Strongest encryption (MPPE 128-bit);
  4. Save the policy and then restart the Network Policy Server service.

With the NPS server configured to accept requests from your wireless access point, you’ll now need to configure the access point to communicate with the NPS servers – These instructions are for my Linksys WAP54G, but will be similar to most access points which support RADIUS…

  1. In the web interface for the access point, click on the Wireless tab and assign an appropriate SSID;
  2. Click on the Security sub-tab, and set the Security Mode to WPA-Enterprise (if your access point supports WPA2-Enterprise, use this instead);
  3. Set the Encryption to AES, and then provide the NPS server IP as the RADIUS Server and the Shared Secret that you saved in step 11 above;
  4. Save your settings and restart the access point.

Now your access point should be configured to talk to your NPS server, so all that is left is to configure your clients to connect – The recommended way of doing this, would be to use Group Policy, but the instructions below are for configuring a Windows Vista client – You can easily replicate these actions in a Group Policy under the Security node.

To configure a Windows Vista client which is joined to the domain…

  1. Open up the Network and Sharing Center;
  2. Click on Connect to a network;
  3. Locate the network you have just secured (it should say Security-enabled network next to it) and click the Connect button;
  4. It will take a short while to set up the profile and then connect successfully.

You can also configure a few extra settings to speed up the time it takes to connect (it won’t improve the overall speed, only the time it takes to initially connect to the wireless network)…

  1. In the Network and Sharing Center, click on Manage wireless networks and then double click the network you set up above;
  2. Click the Security tab, and then the Settings button below;
  3. The Validate server certificate checkbox should already be selected by default, but you should also select the CA that you set up earlier under the Trusted Root Certification Authorities to speed up the certificate verification process;
  4. You can also check the box Do not prompt user to authorize new servers or trusted certification authorities in order to improve the user’s experience.

Some suggestions recommendations…

  • Use a security group with the appropriate machine and user accounts as members to secure your network;
  • Group Policy is by far the best way to deploy the client side settings, but will obviously require an established domain connection in order to push these settings down to the clients;
  • While disabling the SSID of your access point sounds like an increased security measure, it can be a security risk if you are configuring your workstations to actively look for the SSID name – Potential session hijackers could intercept this traffic and set up an SSID for the requested name, unknowingly to the user which would then connect to a potentially malicious network;
  • You can vary the encryption type from AES to TKIP if your devices don’t all support AES, although AES is the preferred encryption algorithm;
  • If you’re having trouble with your connection, there are a few places you can look to troubleshoot, namely – Local client event logs, the NPS log file which lives in C:WindowsSystem32logfiles and most importantly the Security event logs of the NPS server which contains detailed information about access successes and failures.

Error Installing Printers on Windows Server Core 2008

If you’ve ever tried installing a printer on Server Core 2008, chances are you’ve probably come across an error when using Print Management (printmanagement.msc) to remotely manage your Server Core install and add your printer. It looks like it’s going to work fine, but then just before it finishes, you get this…

Unable to install <printer name>, Type 3 – User Mode, <architecture> driver. Operation could not be completed (error 0x800f0247).

And then you might also get this…

Failed to add driver. Operation could not be completed (error 0x00000578).

When you try installing this same printer and driver on a GUI machine, it installs without any problems, so you can safely say it’s a Server Core issue.

As you’d expect, the first step would be to lookup the error code… So we have errors 0x800f0247 and 0x00000578.

Converting these codes from hexidecimal to decimal gives us errors 2148467271 and 1400 respectively. The first one is bogus, as it’s out of range, however error code 1400 translates as ERROR_INVALID_WINDOW_HANDLE.

The issue is the fact that Server Core isn’t handling the unsigned drivers by giving the Print Management console information to prompt the user to confirm the installation of the driver, hence the driver fails to install.

To get around this issue, we can pre-install the required drivers from the command line of the Server Core machine, by passing a call to the PrintUI.dll (which luckily is still used for the Server Core printing engine) – You could also theoretically use the prndrvr.vbs file which can be found in %SYSTEMROOT%\System32\Printing_Admin_Scripts\en-us however it seems that it also cannot handle the prompting of the unsigned driver installation either, and because it only passes calls through to PrintUI.dll anyway, we may as well use it directly.

So create a directory called C:\Temp and copy your printer driver folder to this location on your Server Core machine.

Then, from the command prompt of your Server Core machine, use the following syntax…

start /w rundll32 PrintUI.dll,PrintUIEntry /ia /K /m “<driver name>” /h “<architecture>” /v 3 /f “<driver inf file>”

Here is a breakdown of the above command…

  • The start /w command will hold the command prompt until the command has finished;
  • rundll32 is the process we use to invoke PrintUI.dll;
  • ,PrintUIEntry tells rundll32 that we want to use this entry point in PrintUI.dll;
  • /ia tells the PrintUI.dll that we want to install a printer driver using an inf file;
  • /K (must be capital!) allows us to specificy a numerical value for /v;
  • /m is where you provide the name of the driver (in my case “Samsung CLX-3160 Series”) – You can get this by looking inside the inf file for your driver;
  • /h is where you provide the architecture for the driver, as “Windows NT x86” for 32-bit architecture, “x64” for 64-bit architecture and “IA64” for Itanium architecture;
  • /v specifies that the driver is used for Windows XP or later
  • /f is the location to the driver .inf file (which you should have copied to C:\Temp)

So for example, my command looked like this…

start /w rundll32 PrintUI.dll,PrintUIEntry /ia /K /m “Samsung CLX-3160 Series” /h “Windows NT x86” /v 3 /f “C:\Temp\Samsung CLX-3160 Series\driver\sugi1.inf”

After running this command, you get a red unsigned driver warning screen, which you can now accept to install the driver.

When you refresh the Drivers node in Print Management on your GUI machine, you’ll see your new driver listed. You can now go ahead and deploy your printer, however note that if you are running x64 of Server Core 2008 you’ll need to install the x64 driver before you can add the printer (otherwise you won’t be able to select your installed driver during the printer add process).

You can also delete the folders you copied in to C:\Temp now, because the drivers have been copied to their permanent location.