Export (0) Print
Expand All
1 out of 1 rated this helpful - Rate this topic

Deploy Remote Access with Network Access Protection

Published: September 13, 2012

Updated: September 13, 2012

Applies To: Windows Server 2012, Windows Server 2012 R2 Preview

[Content in this topic that applies specifically to Windows Server 2012 R2 Preview is preliminary and subject to change in future releases.]

You can deploy Network Access Protection (NAP) in your organization to help enforce corporate health requirements by monitoring and assessing the health of DirectAccess client computers that connect through the Remote Access server to access internal resources. Using NAP provides the following benefits:

  • Ongoing corporate health compliance for roaming computers—Because DirectAccess client computers always connect to intranet infrastructure resources when they have an Internet connection, their health is checked on an ongoing basis and they can always remain in compliance. Health checking is performed prior to user logon.

    noteNote
    You can also configure your deployment to allow clients to connect to a server on the Internet that checks their health.

  • Enforce corporate health compliance prior to intranet access—When the user logs on, the DirectAccess client computer attempts to access the entire intranet. NAP ensures that corporate health requirements are met before computers access the intranet.

The health verification process works as follows:

  1. When the DirectAccess client computer connects to the Internet, it sends information about its current health state to the Health Registration Authority (HRA) server.

  2. The HRA sends the health state information to the NAP server.

  3. If the NAP server assesses that the client computer is compliant with corporate requirements, the HRA obtains a health certificate (a computer certificate with the System Health object identifier (OID) extension for Enterprise CA templates) from a certification authority (CA) on the corporate network, and sends it to the DirectAccess client. If the health state is not compliant, the HRA does not issue a health certificate.

    noteNote
    You can configure the NAP server such that the HRA issues a health certificate with a ‘noncompliant’ state (OID).

  4. A client that has been issued a health certificate then uses it to authenticate for access to the second (intranet) tunnel, where the Remote Access server enforces the health certificate requirement.

  5. Clients who do not have health certificates can send update requests to appropriate remediation servers to fix any compliance issues. In some cases remediation might require users to initiate manual procedures. After remediation the client computer sends its updated health state information to the HRA, which then sends it to the NAP server. If the client computer is then compliant, the HRA issues a health certificate.

 

Component Usage Details

IPsec root certificate

Client authentication to the Remote Access server.

If you opted to use the built-in Kerberos proxy for computer authentication when you set up the single Remote Access server, you must change the setting to use computer certificates issued by an internal CA, since Kerberos proxy is not supported for a NAP deployment.

NAP CA

A CA is required to issue health certificates to DirectAccess clients.

  • Use a Windows-based CA for NAP

  • You can use an enterprise or standalone CA. If you use an enterprise CA, you will select an authenticated health compliant certificate template during NAP configuration.

  • For large deployments, we recommend that you use a dedicated subordinate or root CA

  • The NAP CA must chain up to the root CA used for IPsec authentication of Remote Access servers and DirectAccess clients.

NPS

A computer running Windows Server 2008 or later that acts as a NAP health policy server to perform health validation and logging.

The NPS server should not run on the Remote Access server.

HRA server

A computer running Windows Server 2008 or later.

The HRA server should not run on the Remote Access server.

The HRA server can be placed in the corporate network or directly on the Internet. Note the following requirements:

  • HRA inside the corporate network—You can place the HRA server inside the corporate network and allow access only over the Remote Access infrastructure tunnel; that is, client access to the HRA server is restricted through the Remote Access server. In this type of deployment, the HRA server must be included in the management servers list.

  • HRA on the Internet—In this type of deployment, DirectAccess clients can obtain a health certificate using an HTTPS connection to the HRA server that does not use IPsec computer authentication. DirectAccess clients can connect to the HRA server without using the Remote Access server; therefore, the HRA is not required to be included in the management servers list.

HRA SSL certificate

An SSL certificate used by client computers to authenticate the HRA server.

Client computers can access the HRA server over an HTTPS connection. To authenticate the HRA server, it must have a certificate that chains up to the root CA and with a subject name that resolves to the IP address of the HRA server.

Security Health Validators

Health policies to determine the health of client computers.

You can configure the NAP server with Security Health Validator (SHV) health policies that are used to determine whether a client computer is compliant or not. These policies can check for the presence, and state, of security products on the client computers; for example, firewalls, antivirus products, antispyware products.

A default SHV - the Windows Security Health Validator - is configured with the following settings:

  1. Firewall Settings—A firewall is enabled for all network connections.

  2. Antivirus Settings—An antivirus application is on and up-to-date

  3. Spyware Protection Settings—An antispyware application is on and up-to-date

  4. Automatic Updates Settings—Automatic updating is enabled

Other SHVs can also be configured depending on your requirements.

Remediation servers

Remediation servers provide the updates or resources that noncompliant DirectAccess clients need to meet system health requirements. Examples include Windows Software Update Services (WSUS) servers and anti-malware signature distribution servers.

During NAP server configuration, you can select to use remediation servers to update noncompliant DirectAccess client computers.

Make sure that remediation servers are included in the management servers list when you configure Remote Access.

noteNote
If remediation servers are directly accessible over the Internet, you do not need to include them in the management servers list.

Servers in this list are accessible over the first (infrastructure) tunnel. This ensures that remediation servers are accessible by client computers that are unable to access the second (intranet) tunnel because they do not have a health certificate.

In this document

noteNote
This topic includes sample Windows PowerShell cmdlets that you can use to automate some of the procedures described. For more information, see Using Cmdlets.

Before you deploy Remote Access with Network Access Protection, make sure that you have completed all the planning steps to deploy a single Remote Access server. See Plan an Advanced Remote Access Deployment.

You must configure a NAP server in your internal network that runs the Network Policy and Access Services role with the Network Policy Server and the Health Registration Authority role services. This procedure assumes that the NAP server is running Windows Server 2012.

  1. In the Server Manager console, in the Dashboard, click Add roles and features.

  2. Click Next three times to get to the server role selection screen.

  3. On the Select server roles dialog, select Network Policy and Access Services, click Add Features, and then click Next.

  4. Click Next twice.

  5. On the Select role services dialog, select the Network Policy Server and the Health Registration Authority check boxes, click Add Features, and then click Next.

  6. On the Certification Authority page, click Use an existing remote CA, click Select, on the Select Certification Authority dialog box, select the CA for your network, click OK, and then click Next.

  7. On Authentication requirements page click Yes, require requestors to be authenticated as members of a domain, and then click Next.

  8. On Server Authentication Certificate page, select the certificate in the list that you want to use for SSL encryption and then click Next.

    noteNote
    The subject name of this certificate should resolve to the IP address of the HRA server that you want clients to trust. This certificate should also be valid for server authentication.

  9. Click Next twice.

  10. On the Confirmation dialog, click Install and allow the installation to complete.

When you use an enterprise CA to issue certificates, you must configure a certificate template for the health certificate that will be sent to compliant DirectAccess clients. You should also grant permissions to the NAP server to manage the CA and to allow the NAP server to override the validity period of certificates.

  1. On your root CA or on a subordinate enterprise NAP CA, create a certificate template as described in Create Health Certificate Templates.

  2. Publish the NAP certificate template as described in Publish NAP Certificate Templates.

  1. On the internal CA, open the Certification Authority console: on the Start screen, type certsrv.msc, and then press ENTER.

  2. In the console tree, right-click the internal CA, and then click Properties.

  3. On the Security tab, click Add.

  4. Click Object Types, select the Computers check box, and then click OK.

  5. On the Select Users, Computers, Service Accounts, or Groups dialog box, in Enter the object names to select, type the name of the NAP server, for example APP3, and then click OK.

  6. On the Security tab, click the NAP server and select the Read, Issue and Manage Certificates, Manage CA, and Request Certificates check boxes, and then click OK.

  7. Close the Certification Authority console.

  1. Open an elevated Windows PowerShell window.

  2. Type Certutil -setreg policy\EditFlags +EDITF_ATTRIBUTEENDDATE, and then press ENTER.

  3. Type net stop certsvc, and then press ENTER.

  4. Type net start certsvc, and then press ENTER.

Configure the Health Registration Authority (HRA) server that is running on the NAP server by confirming that the correct CA is in use, and by selecting the health certificate template.

  1. On the NAP server, on the Start screen, type HCSCFG.msc, and then press ENTER.

  2. In the left pane, expand Health Registration Authority (Local Computer), and click Certification Authority.

  3. Confirm that your internal CA is listed in the details pane; for example, App1.corp.contoso.com\corp-APP1-CA.

  4. In the left pane, right-click Certification Authority, and then click Properties.

  5. On the Certificate Authorities Properties dialog box, do the following, and then click OK:

    • Enter the time, in minutes, between requests when a server is identified as unavailable.

    • Configure the validity period for certificates approved by this HRA.

    • Choose whether to use a standalone CA or an enterprise CA. If you use a standalone CA, select to enable PolicyOIDs if required. If you use an enterprise CA, choose the health certificate template that you previously configured for both Authenticated and Anonymous clients, if required.

On the NAP server, create a connection request policy that determines that all RADIUS requests will be processed by the local server.

  1. On the NAP server, on the Start screen, type nps.msc, and then press ENTER.

  2. In the details pane, click Configure NAP.

  3. On the Select Network Connection Method For Use with NAP page, in Network connection method, select IPsec with Health Registration Authority (HRA), and then click Next.

  4. On the Specify Enforcement Servers Running HRA page, click Next if the HRA is running on the NAP server.

    TipTip
    If you configured the HRA to run on a remote server, add it as a RADIUS client.

  5. On the Configure Machine Groups page, click Next to apply this policy to all users. If you want to grant or deny access to groups of computers, add the groups to Machine Groups.

  6. On the Define NAP Health Policy page, clear the Enable auto-remediation of client computers check box if you do not want to enable auto-remediation, click Next, and then click Finish.

Configure the Windows Security Health Validator (WSHV) to define the compliance criteria for DirectAccess clients. By default the health validator enforces the following criteria for DirectAccess clients:

  • A firewall is enabled for all connections

  • An antivirus application is on and is up to date

  • An antispyware application is on and is up to date

  • Automatic updating is enabled

noteNote
You can configure custom SHVs, or additional SHVs based on the WSHV, as required.

  1. On the NAP server, on the Start screen, type nps.msc, and then press ENTER.

  2. In the Network Policy Server console tree, expand Network Access Protection/System Health Validators/Windows Security Health Validators, and then click Settings.

  3. In the details pane, double-click Default configuration.

  4. On the Windows 8/Windows 7/Windows Vista tab, make changes to the health validator as required, and then click OK.

Configure a NAP client configuration group policy and restrict the policy to only DirectAccess clients.

noteNote
The following procedure assumes that you are configuring NAP to enforce client health. For information about configuring NAP in monitoring mode, see Configure Network Policy for Reporting Mode.

  1. On the domain controller, on the Start screen, type gpmc.msc, and then press ENTER.

  2. In the Group Policy Management console, in the console tree, expand the local forest and then expand Domains; for example, Forest: corp.contoso.com/Domains.

  3. Right-click the domain and click Create a GPO in this domain, and Link it here.

  4. On the New GPO dialog box, in the Name text box, enter a name for the policy, for example, NAP Client Configuration, and then click OK.

  5. Click the newly created NAP client configuration policy, and then click OK.

  6. In the details pane, in the Security Filtering area, click Authenticated Users, and click Remove. Click OK to confirm, and then click Add.

  7. In Enter the object name to select, enter the security group that contains DirectAccess clients, and then click OK.

  8. To configure NAP in enforcement mode, continue with this procedure. If you are configuring NAP for monitoring only, continue with Step 7: Enable NAP on the Remote Access server.

  9. In the console tree, right-click the new policy, and click Edit to open the Group Policy Management Editor.

  10. In the Group Policy Management editor, in the console tree, under Computer Configuration, expand Policies/Windows Settings/Security Settings/Network Access Protection, expand the new policy, and then click Enforcement Clients.

  11. In the details pane, right-click IPsec Relying Party, and then click Enable.

  12. In the console tree, expand Health Registration Settings, right-click Trusted Server Groups, and then click New.

  13. On the Group Name page, enter a name for the group, for example, Trusted Servers, and then click Next.

  14. On the Add Servers page, enter the URL of the health registration authority that you want clients to trust, for example, https://app3.corp.contoso.com/domainhra/hcsrvext.dll, click Add, and click Finish.

    noteNote
    This URL must match the certificate chosen for the HRA server.

  15. In the console tree, under Security Settings, click System Services.

  16. In the details pane, double-click Network Access Protection Agent and on the Network Access Protection Agent Properties dialog box, select the Define this policy setting check box. Under Select services startup mode, click Automatic, and then click OK.

  17. In the console tree, expand Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer/Windows Components, and click Security Center.

  18. In the details pane, double-click Turn on Security Center, on the Turn on Security Center dialog box, click Enabled, and then click OK.

On the Remote Access server, enable NAP, add the NAP server to the management servers list, and then apply the configuration.

Do this step using Windows PowerShell

  1. On the Remote Access server, on the Start screen, type RAMgmtUI.exe, and then press ENTER.

  2. In the Remote Access Management console, under Step 2 Remote Access Server, click Edit.

  3. In the Remote Access Server Setup wizard, on the Authentication page, select the Enforce corporate compliance for DirectAccess clients using NAP check box, and then click Finish.

  4. In the Remote Access Management console, under Step 3 Infrastructure Servers, click Edit.

  5. In the Infrastructure Server Setup wizard, on the Management page, double-click an empty row to open the Add a Management Server dialog box.

  6. In Computer Name, enter the FQDN of the NAP server; for example, app3.corp.contoso.com, click OK, and then click Finish.

    noteNote
    Adding the NAP server to the management servers list is required only if the NAP server is not directly connected to the Internet.

    Add remediation servers if they are not available on the Internet.

PowerShell LogoWindows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

To configure NAP on the Remote Access server named EDGE1.corp.contoso.com and to add the NAP server named app3.corp.contoso.com to the management servers list:

Set-DAServer -HealthCheck 'Enabled'
Add-DAMgmtServer –MgmtServer @('app3.corp.contoso.com')

After configuring the NAP deployment, you can verify that it is working correctly by updating a client computer with the new group policy and then moving the client to the Internet and forcing it into a noncompliant state.

  1. Connect a DirectAccess client computer to the corporate network and obtain the group policy.

  2. Open an elevated Windows PowerShell window and run the command Get-Service napagent. The Network Access Protection Agent should be running.

  3. In the Windows PowerShell window, run the command netsh nap client show grouppolicy.

    Make sure that the enforcement client IPsec Relying Party is Enabled and that the URL of the health registration authority is included in the trusted servers group previously defined.

  4. Connect the client computer to the external network.

  5. Turn off one of the settings that is used to check for compliance by the configured SHVs. For example, turn off automatic updating.

    A Network Access Protection dialog box should be displayed stating that network access is limited.

  6. In the Windows PowerShell window, run the command certutil –viewstore My.

    Confirm that there is no health certificate with the intended purpose of System Health Authentication issued for the client.

  7. Reconfigure the client to be in a compliant state.

  8. In the Windows PowerShell window, run the command napstat.

    You should see a Network Access Protection message stating that you have full network access.

  9. In the Windows PowerShell window, run the command certutil –viewstore My.

    Confirm that there is a health certificate with the intended purpose of System Health Authentication issued for the client.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

Show:
© 2014 Microsoft. All rights reserved.