Showing posts with label NPS. Show all posts
Showing posts with label NPS. Show all posts

Tuesday, June 11, 2013

Windows 2012 NAP (NPS) with DHCP

After my last article on DHCP I decided to flesh out the Microsoft offerings and expand into Network Policy Server. NPS is actually a set of different features from Microsoft including RADIUS and what the rest of the industry knows as NAC, (Network Access Control) which Microsoft calls NAP (Network Access Protection). This allows you to grant or deny network access to clients based on criteria such as:
  • Domain/Group Membership
  • Client source network
  • Time of day
  • Client health (as determined by an SHV, see below for more)

3 out of 4 Doctors are very serious about Microsoft NAP.

These rules must be introduced to the clients at an insertion point (think of it as an entry gate). The supported insertion points include:
  • IPSec
  • 802.1X
  • VPN
  • DHCP
  • RDGateway

I'll be covering integration with DHCP since it is by far the most cost effective method considering the required role of Microsoft based services in the environment. For information on the others, see Technet: NAP Enforcement Points.First, let's set up NAP:

Assumptions

  • At least one Windows 2012 server ready to go. Note that NPS is not supported on server core. Most of these instructions are applicable to 2008/r2 as well.
  • DHCP installed and ready to go.
  • Sufficient Privileges (Domain Admin generally)
  • I assume you'll be installing NAP on the DHCP server itself. You can have these roles on separate servers should you desire, but you'll need to install the NAP piece on the DHCP server as a RADIUS proxy. I won't be covering that piece here. For more on that, see this Technet article.

Installing NAP

  1. Using server manager, select "Manage"->"Add Roles or Features"
  2. Navigate through the Add Roles and Features Wizard, selecting the target server and "Network Policy and Access Services".


  3. When prompted to select role services, you need keep only the default "Network Policy Server" selected and continue through the wizard.


Repeat this step for the DHCP server as well if it's a different server than the one you installed NAP on.

Configuring NAP

The NAC portion of NAP is actually a collection of several different elements. The following elements make up a NAP policy that can be used by DHCP; numbers in front represent the default number of that item for one overall policy:

  • Connection Request Policy (Created by Wizard)
  • (3) Network Policies (Created by Wizard)
  • (2) Health Policies (Created by Wizard)
  • Windows Security Health Validator
  • At least one Remediation Server Group

There is a (seemingly hidden) wizard to guide you through the process of creating most of these elements, but we're going to create the unguided ones first and then circle back and use the Wizard since we'll want to point to those during the Wizard portion. For all these sections save the DHCP and client sections we'll be working in the Network Policy Server management tool.

Windows Security Health Validator

The Security Health Validator is the policy for defining what a healthy windows client is. The built-in Windows SHV gives the NAP server the capability to interact with the Network Access Protection Agent service on Windows clients (XP SP3 and newer) to determine the health status of that given client. The Security Health Validator determines what criteria the client must pass for the client to be considered healthy. There is a default configuration that can be utilized but for the sake of experience we'll configure the Windows SHV. To do so:

  1. First, open the NAP management tool by selecting "Tools"->"Network Policy Server" from Server Manager.
  2. Expand "Network Access Protection"->"System Health Validators"->"Windows Security Health Validator"->"Settings"
  3. Right click "Settings"->"New"
  4. Give the SHV a name; make it something meaningful to describe the target client base, i.e. "Standard Client Set"
  5. Set your settings as desired; they're split into settings for Windows XP and Vista or higher. The settings are quite straightforward though it should be noted that if you would like to utilize WSUS to update out of compliance clients (assuming you select being out of date makes for a failed check) you'll need to check the box on the very bottom of the options dialog. Click "OK" when complete.


  6. Click on the "Error Codes" under "Settings" and take note of the Error Code Configurations. Generally the default state of "Noncompliant" for each setting is desirable, but depending on your clients and equipment there may be situations where you would want to change some of these SHV check failures to compliant.

Note that third parties can also create SHVs to plugin to the NAP architecture for use with other products. (Old list of some others here)

Remediation Server Groups

The remediation server groups are the servers that will be made accessible to non-compliant clients if you choose to do so. These servers can be used to patch clients to a compliant status. Note that any services needed to contact the remediation services (WSUS, Antivir FTP, etc.) need to be available for the clients to update properly. (DNS, etc.) Under the DHCP enforcement model, these servers are made available via static routes. Also note that you can provide a help URL to a website instructing access-limited clients on how to repair their machines. The server that hosts this URL and all resources required to resolve it must be part of the remediation server group as well. For more information about RSGs, see Technet: Planning the Placement of a NAP Remediation Server. Assuming you have determined which servers need be part of the remediation group, let's set them up:

  1. Expand "Network Access Protection"->"Remediation Server Groups"
  2. Right Click->"New" (Note that these can be stored as templates for use elsewhere as well)
  3. Give the group a meaningful name; note that each health policy can use only one group, so everything for that client base will need be in that group. Something like "Sitename Remediation Group"
  4. Click the "Add" button to add a server.
  5. Enter a friendly name for this server, i.e. "Minneapolis WSUS 01" or just the server name and then enter the DNS name and click "Resolve". Hit "OK" when complete.
  6. Repeat steps 4 and 5 for each server in this group. Then hit "OK" on the "New Remediation Server Group" page.


Setup Remaining Items with The Whiz

  1. Click "NPS" on the top of the Network Policy Server management tool.
  2. Click "Configure NAP" to launch the secret hidden Wizard.


  3. Select "Dynamic Host Configuration Protocol (DHCP)" under "Network Connection Method". Note this is where you would select a different option should you want to use a different insertion point. If you wish to enable this policy on only specific scopes then give the policy a name, I.E. "Minneapolis NAP DHCP".  If you wish this policy to be effective on all scopes do not change it from the default name. Click "Next".
  4. On the next screen, click add if the DHCP server is not on the same server as the main NAP server. If that is the case, enter a Friendly Name, Address, and Shared Secret and click "OK". If not, no action is necessary. After this is complete, click "Next".
  5. On the next screen, "Specify DHCP Scopes", we need only add scopes if we want this policy to apply to a specific set of scopes. If we do not specify any scopes it will apply to all NAP enabled scopes. Either add the name of all specific scopes to which this policy will apply or just click "Next" with the scopes empty to have it apply to all.


  6. The "Configure Machine Groups" screen, like the previous DHCP Scopes screen, is only for limiting access to a set of computers. Should you choose, specify the group(s) of computers you would like to receive IP addresses. In most cases you should leave this blank, but in the event you would restrict via group click "Add" and enter the groups you would like to have access. Click "Next" when you are done with this screen.


  7. On the next "Specify a NAP Remediation Server Group and URL" screen select the server remediation group we created earlier. If you would like the clients to have access to a web site describing how to re-mediate their machines enter that under "Troubleshooting URL". Note you must setup this site, it is not included with NAP since the instructions will be different depending on your software selection. After entering the required information, click "Next".


  8.  "Define NAP Health Policy" is the final screen. You should see the "Windows Security Health Validator" selected and you can go ahead and enable auto-remediation of client computers with the applicable check box. I'll address this a bit more in closing.
  9. As for "Network access restrictions for NAP-ineligible client computers", select whichever you prefer. In most cases if you've bothered to come this far you'll be selecting to deny full network access since that's usually the point. Click "Next".


  10. You will be presented with a summary screen; review the information and click "Finish".


Configure Clients

We need to configure two important elements to make the clients functional: Enable the service and configure it to enforce via DHCP. To accomplish that, we'll use group policy. You will need to ensure your group policy objects are targeted appropriately via something like OU linking or security filtering. If you need more information on how to target group policy objects, see this link. Also note that according to some Microsoft documentation, the Wired and/or Wireless Autoconfig services need to be set to automatic, but in my testing they worked when set to manual. Keep that in mind if you have issues.

  1. Edit the group policy object you plan to use for NAP client enforcement using the Group Policy Management tool.
  2. Navigate to Computer Configuration->Policies->Windows Settings->Security Settings->System Services
  3. Double click "Network Access Protection Agent" and check "Define this policy setting" and select "Automatic". Click "OK" to save the setting.


  4. Navigate to Computer Configuration->Policies->Windows Settings->Security Settings->Network Access Protection->NAP Client Configuration->Enforcement Clients
  5. Double click "DHCP Quarantine Enforcement Client", check "Enable this enforcement client" and click "OK" to save the setting.


  6. Provided you're ready, take any steps necessary to apply the GPO to the desired clients. (Link, etc.)

Enable in DHCP

You can either enable globally or on a per-scope basis. I will give the instructions on how to enable globally. If you want to enable on a per-scope basis substitute right-clicking on the "IPv4" below with the scope(s) you desire instead. In that case, you'll need to specify the custom name of the policy you created in step 3 above.

  1. Open the DHCP Manager and point it at the server in question.
  2. Right click "IPv4" and click "Properties"
  3. Click "Network Access Protection"
  4. Select what you would like to happen should the NAP server become unavailable, then click "Enable on all scopes".


  5. You will be notified that your NAP settings will be overridden on all scopes. Assuming this is what you would like to do, click "Yes".
  6. Click "OK".

If you're using a 2012 failover/loadbalance configuration the NAP settings will replicate for each scope, but make sure communication to the NAP server is configured correctly for each DHCP server. That connection information is not replicated. Here is additional info should you need it: Technet: Configure a DHCP Server for NAP. No restart of anything is needed; you should be using NAP now!

Usage Notes/Troubleshooting

  • If using a custom profile name for a specific scope, you'll need to provide the custom profile name. This name is the name of the connection request policy you would like to use. For more info see: Configuring Custom NPS Policies Per DHCP scope


  • The event log location relevant to NPS authentication is in the security log with the task category of "Network Policy Server". A filtered view of this can be found under "Custom Views->Server Roles->Network Policy and Access Server".
  • Know that this solution won't keep out anyone trying to infiltrate your network; anyone with a moderate amount of savvy can take steps to determine what IP to assign themselves should they have physical access to your network.
  • What references what?
    • * Compliant and * Non-Compliant Network Policies reference Health Policies
    • Health Policies reference Security Health Validators
    • DHCP scopes reference Connection Request Policies
  • You can add several other types of criteria to your policy should you desire. Take a look at your policies under NPS->Policies->Network Policies for more options.


  • If you enabled auto-remediation, clients will try to repair themselves for simple issues. For example: if a client's firewall is off and the policy requires it, the client will re-enable the firewall and attempt to pass the health check again. Should this fail manual intervention will be necessary. For more information on how to troubleshoot the client, see "Configure NAP Tracing" on Technet.
  • Make sure you monitor the load on your NPS servers; the last thing you want is for them to get overwhelmed and prevent proper servicing of DHCP requests. There are some performance counters that can help you with this task; for more info see Technet: Load Balancing with NPS Proxy. Also, be sure to read up on Technet: Best Practices for NPS which covers performance as well as other important info.
  • For some information regarding how to use Powershell to configure/manipulate NPS, see my post here.

Prologue

Obviously we're just scratching the surface here; there is quite a bit more that we could dig into but I'm going to stop here in the interest of time. NAC solutions aren't particularly popular right now in a regular office scenario, but as issues continue to arise with malware, etc. more companies may determine these sorts of solutions are necessary. If you already have a Microsoft based infrastructure you probably have nearly everything you need to implement this solution. If you have questions/concerns/comments please feel free to comment. Thanks!

References

Network Policy Server

Network Policy and Access Services Overview

Network Access Protection in NPS

Checklist: Implementing a DHCP Enforcement Design

Networking and Access Technologies: Network Policy and Access Services

Planning the Placement of a NAP Health Requirement Server

NAP Client and Server-side Component Communication

Monday, March 11, 2013

New 2012 Powershell CmdLets: Role Focus on NPS (Radius) Server

This will be one in a series of posts highlighting the new Cmdlets available in Windows server 2012 that didn't previously exist. I'll be breaking them down on a role-by-role (or feature) basis for easier reading. The first we'll be focusing on is the NPS server included with Windows Server, which is often used for RADIUS authentication.



Load the module: (on a 2012 Server\Win8 machine with the NPS server role or management tools loaded)

import-module NPS

Get the commands:

get-command -module NPS

CommandType     Name                                  
-----------     ----                                            
Cmdlet          Export-NpsConfiguration
Cmdlet          Get-NpsRadiusClient
Cmdlet          Get-NpsRemediationServer
Cmdlet          Get-NpsRemediationServerGroup
Cmdlet          Get-NpsSharedSecretTemplate
Cmdlet          Import-NpsConfiguration
Cmdlet          New-NpsRadiusClient
Cmdlet          New-NpsRemediationServer
Cmdlet          New-NpsRemediationServerGroup
Cmdlet          Remove-NpsRadiusClient
Cmdlet          Remove-NpsRemediationServer
Cmdlet          Remove-NpsRemediationServerGroup
Cmdlet          Set-NpsRadiusClient


Let's walk through these:

Export-NpsConfiguration: This is great; exports all configuration of the NPS server EXCEPT templates to an XML file for backup or import to a different server. Anything containing template information will be converted to information specific to that configuration item and exported, i.e. if a client profile uses a template shared secret the shared secret will export successfully but it will be an asset of that client configuration rather than having the config linked to the template. This will remain true even if the target server for importing the profile already has the template elements defined by the same name. Also note that if you have a SQL server configured for auditing that information will not be exported either. Security Warning: All information including shared secrets will be stored in clear text. Command example:


Export-NpsConfiguration c:\temp\NPSConfig.xml


Get-NpsRadiusClient,Get-NpsRemediationServer,Get-NpsRemediationServerGroup,Get-NpsSharedSecretTemplate: Enumerates the Radiusclient, RemediationServer(groups), and shared secret templates on the local server. Only the Get-RemediationServer cmdlet requires an argument. The others will show all items on the server and you can use common parameters to parse. Security warning: Get-NpsSharedSecretTemplate will display shared secrets in clear text.

Import-NpsConfiguration: When supplied with an XML configuration file generated by the Export-NpsConfiguration(above) it will import an NPS server configuration. As noted above you cannot import information regarding templates or SQL auditing, but everything else will come over fine. These two commands could be used in a scheduled task if desired to sync configuration from a "master" NPS server to others within the organization. Command example:


Import-NpsConfiguration c:\temp\NPSConfigFromThatOtherServer.xml


New-NpsRadiusClient, New-NpsRemediationServer, New-NpsRemediationServerGroup, Remove-NpsRadiusClient, Remove-NpsRemediationServer,Remove-NpsRemediationServerGroup: Commands to setup and remove NPS/Radius clients, remediation servers, and remediation server groups. Pretty straightforward; here's a New-NpsRadiusClient example:


New-NpsRadiusClient -Name "NameOfMyClientGroup" -Address "10.1.0.0/16" -AuthAttributeRequired 0 -NapCompatible 0 -SharedSecret "SuperSharedSecretxyz" -VendorName "RADIUS Standard"


Set-NpsRadiusClient: All this does is change a value of an existing client specification. This would be useful for doing batch updates of all client profiles. Take, for example, this command which would disable all client profiles:


foreach ($i in Get-NpsRadiusClient){Set-NpsRadiusClient $i.name -Enabled 0}


So here's a fun idea: Automate config changes all your NPS/Radius servers to have a master/slave relationship using a shared storage space, powershell, and task scheduler. It's as easy as 1, 2, 3! (Sheesh, did I just say that?)


  1. Create simple powershell scripts to export the configuration to a shared file space (on "master" NPS server) and import from the shared file space (on "slave" NPS servers)  You may want to version them...
  2. Create Scheduled task on the "master" to export however often you like and one scheduled task on each "slave" NPS to import that config. Make sure the import comes after the export
  3. Profit!
Quick notes: if doing this be aware that changes will flow automatically so if you ruin your master you'll ruin your slaves too. As noted above I'd recommend versioning the configuration files (use the date) so that you have a history of the changes, just make sure you're fully aware of the fact that the shared secret is in the clear. If you wanted to get really fancy to protect that you could use a common service account and EFS, but that's a little deep for this article. :) 

In the mood for some references? Me too!
Technet NPS Migration Guide
Technet NPS Server Migration (different)
Technet NPS Cmdlets (Note the referenced -full and -examples aren't actually in the files)
Technet: Export NPS Config

Any questions? Let me know. Have fun!