Direct Access + Network Access Protection – part 2 – LAB configuration and overview

This is Andrzej Kaźmierczak’s (KAZM) second part of my DA + NAP articles. You can read about overview in the first part: DA + NAP part 1: Introduction.

To get better overview and learn how to configure Direct Access with NAP follow those TechNet articles (even though some of them apply to Windows Server 2008 R2):

This is how my LAB is configured (the main parts of configuration are described only):


To configure my LAB, first of all I have installed and confirmed that Direct Access is working fine without NAP. After that, I have added SRVNPS server and switched DA to integrate with NAP server.


  • Internal network:
  • External (Internet) network:

Servers and Roles

Server OS Role Configuration
SRVDC Windows Server 2012 R2 Domain Controller FFL, DFL: 2008R2Domain: tst.lab
SRVPKI Windows Server 2012 R2 Enterprise Root CA used for issuing certificates for client machines and health certificates.SRVPKI is used for web enrollment and CDP/AIA paths publishing. CN= TST Root CA, C=PL2 NICs (Internal, External)*.crt/crl

TST Workstation Authentication certificate template for DA with EKU:

  • Client Authentication
  • Server Authentication

DA HRA Certificate template for NPS statement of health with EKU:

  • Client Authentication
  • System Health Authentication
SRVNLS Windows Server 2012 R2 Simple HTTPS website acting as NLS. https://nls.tst.lab
SRVFS Windows Server 2012 R2 File share and HTTPS site used for testing DA connection. \\srvfs.tst.lab\https://srvfs.tst.lab
SRVNPS Windows Server 2012 R2 NPS and HRA roles for Direct Access. System Health Validator: Default one, configured to allow any client computer (no firewall, no updates required, etc.)HRA detailed configuration see below
SRVDA Windows Server 2012 R2 Direct Access server NICs (Internal, External)

See detailed configuration below

Client Windows 7 Enterprise Client computer Forced GPOs before switching to external networkClient machine belongs to DA_Clients domain group

Direct Access server has been configured in the following way (if some setting is not mentioned, it has a default value):

  1. Remote Clients
    1. Deployment Scenario
      1. Deploy full Direct Access for client access and remote management – checked
    2. Select Groups
      1. Group: DA_Clients
      2. Enable Direct Access for mobile computers only – disabled (I could not test on client VM if this setting is enabled)
      3. Use force tunneling – enabled (my own requirement, could be disabled)
    3. Network Connectivity Assistant
      1. Allow Direct Access clients to use local name resolution – enabled
  2. Remote Access Setup
    1. Network Topology
      1. Network topology: Edge
      2. DA address:
    2. Network adapters
      1. IPHTTPS is not self-signed (issued by my SRVPKI), CN=
    3. Authentication
      1. As you can see I have chosen to use TST Root CA and enabled the “Enforce corporate compliance for Direct Access clients with NAP” option which simply enables NAP integration with DA.
      2. I didn’t choose “Use an intermediate certificate” because in this particular scenario I am having Root CA which issues certificates (try not to be confused). In any other well – designed PKI environment, one would use Subordinate Certification Authority as Issuing CA, NOT Root CA itself (this was done here only for LAB purposes and is crucial to understand the issue I’m describing in that article). If you have offline Root CA and separate online Issuing CA, you would need to enable “Use an intermediate certificate” option. Remember, if you do, the Browse button will show you only certificates that are stored in the “Intermediate Certification Authorities” Windows certificate store, not in the “Trusted Root Certification Authorities” store. I also have enabled Windows 7 computers, because this is OS of my client machine:
  3. Infrastructure Servers
    1. Network Location Server
      1. The network location server is deployed on a remote web server: https://nls.tst.lab
    2. DNS
      1. Default suffixes
      2. Use local name resolution if the name does not exist in DNS or DNS servers are unreachable when the client computer is on a private network (recommended) – enabled
    3. DNS Suffix Search List
      1. Default settings
    4. Management
      1. Management servers: srvnps.tst.lab (it has to be available in management tunnel for the client to issue a health certificate for the user that will let you access corp/intranet tunnel).

Health Registration Authority configuration:

  • Added TST Root CA,
  • Enabled to use DA HRA Certificate template (duplicated and configured manually on SRVPKI):DANAP03

The setup is done (above are described only major parts of it). You can now go to the next article: DA + NAP part 3: Single CA work flows explanation

Category: Knowledge Base

Leave a Reply