Direct Access + Network Access Protection – part 3 – Single CA work flows explanation

This is a follow-up on previous Andrzej Kaźmierczak’s (KAZM) article DA + NAP part2: LAB configuration and overview , where I have described my LAB settings for explanation of how things are working for Microsoft Direct Access and Network Access Protection integration on Windows Server 2012 R2. You can use below steps as a part of troubleshooting activities for DA with NAP in your environment.

First of all read this great TechNet article by The Cable Guy on NAP and DA integration http://technet.microsoft.com/en-us/magazine/ff758668.aspx

Let’s start! User got DA GPOs from the Domain Controller and now switched to the Internet (External) network. This is how things should be working:

  1. When the user was inside corporate network, he received GPOs telling him to connect to Direct Access server when he is not connected to corporate network. To confirm being outside, client should not be able to resolve https://nls.tst.lab . Now client machine is aware that it is in the External (Internet) network. To confirm that run “netsh dns show state”:
    DANAPart03img01
  2. Client machine tries different transition technologies to setup Direct Access connection.
    I have disable IPv6 on client’s NIC, so no 6to4 is used. Also, in my LAB, client is connected directly to the same network as DA is located, so no NAT means no Teredo. Client will use IPHTTPS transition technology which simply speaking packages the data in an HTTPS tunnel. To achieve that, in GPO client has been configured Direct Access IPHTTPS URL to connect to (https://da.tst.com/iphttps). Its SSL certificate had to be issued by a trusted Root/Issuing CA for the client computer (in my case it had been issued by SRVPKI and CN=TST Root CA which is a trusted Root CA on the client).
  3. Run “ipconfig /all” to see if the IPHTTPS has configured itself with IPv6 address:
    DANAPart03img02
  4. The user should have setup infrastructure tunnel using “TST Workstation Authentication” certificate from the “TST Root CA, C=PL” Issuing CA that had been issued to the workstation with autoenrolment feature and user should be able to access SRVDC (Domain Controller).
  5. In NAP’s GPOs I have setup Health Registration and Trusted Server Group to point to https://srvnps.tst.lab/domainhra/hcsrvext.dll so once NAP client is started, DA client connects to this URL creating management tunnel. With this tunnel, SRVNPS (NPS + HRA) is accessible because it has been added to Management Servers in Direct Access configuration wizard. Management tunnel is created using “TST Workstation Authentication” from the “TST Root CA, C=PL” Issuing CA. At this point I am able to access both SRVDC and SRVNPS servers – if you try on your own, do not use “ping” command, because every server (that is ICMP enabled) will respond– even without corp/intranet tunnel enabled. Use share or a website if server has IIS role installed.
  6. The user is connected to SRVNPS and sends to HRA SoH (Statement of Health). The HRA sends it internally to the NPS health policy server (in my case it is one and the same server). NPS evaluates whether client computer matches the System Health Validators. I have setup policies letting every computer in, so every computer is compliant. NPS sends results to the HRA service. When the client computer is compliant, the HRA on behalf of the user, enrols health certificate using my “TST Root CA, C=PL” Issuing CA and “DA HRA Certificate” health certificate template. The certificate is sent back to the user in the management tunnel. You can confirm this by going to the CA server, open CA console an investigate Issued Certificates container. Also you can verify those on the HRA server in System Event Viewer. Event 22 “The Health Registration Authority has approved the request with the correlation-id-…. The Network Policy Server has indicated that the client should be given full network access” should be there. See figure below:
    DANAPart03img03
  7. Now, on the client computer I run certificate snap-in for the Local Computer store and verify that the client possesses 2 certificates, both issued by “TST Root CA” – THIS IS IMPORTANT!:
    DANAPart03img04

    1. Workstation/Computer certificate that had been issued only once through autoenrolment and stays in the certificate store. This one gives client Infrastructure and Management tunnels.
    2. System Health Authentication which HRA enrolled after confirming that client computer is complaint. This one gives us Corp/intranet tunnel (to other internal resources, such as SRVFS)
  8. From Client machine I initiate connection to one of my internal resources: \\srvfs.tst.lab . Access to such resources is possible because 3rd tunnel – corp/intranet tunnel is setup using health certificate issued through the HRA. There is a very good TechNet article ton how to check tunnels on the client: http://technet.microsoft.com/en-us/library/ee844114(v=ws.10).aspx . To verify tunnels I run “netsh adv mon show mmsa” command and as an output I can see computer certificate and health certificate that is used for UserKerb authentication (connection to \\srvfs.tst.lab) successfully. What is important is that those certificates are confirmed to be Health Certificates, see below figure:
    DANAPart03img05
    Above tunnels can also be confirmed in the Windows Firewall Monitoring / Security Associations / Main Mode:
    DANAPart03img06
  9. From Direct Access Remote Client Status console I finally confirm that the client is connected and using User Kerberos as Authentication Method:
    DANAPart03img07

Great! Everything’s working – what’s the problem then? Well, Microsoft in this MSDN article http://msdn.microsoft.com/en-us/library/cc731916.aspx recommends that “ (…)For optimal performance, a dedicated standalone subordinate CA should be used to issue health certificates.” This article also guides you on how to Configure Standalone CA, wait time, validity period, but there is not a single word on how new CA should fit into Direct Access with NAP integration.

To my environment I added a standalone CA and the very interesting results of what happened next are described in my last article DA + NAP: Potential issue with multiple CAs. Lessons learned

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):

DANAP01

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.

Network

  • Internal network: 12.12.12.0/24
  • External (Internet) network: 137.0.0.0/24

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)

http://pki.tst.com/CertEnroll/*.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 https://da.tst.com/IPHTTPS2 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: da.tst.com
    2. Network adapters
      1. IPHTTPS is not self-signed (issued by my SRVPKI), CN= da.tst.com
    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:
        DANAP02
  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

Direct Access + Network Access Protection – part 1 – Introduction

Hi, Andrzej Kaźmierczak (KAZM) here. Recently I’ve been doing some deep dive troubleshooting of two amazing technologies working together: Microsoft Direct Access and Network Access Protection. There is one thing I want to share about design of Certification Authorities for such implementation and a little bit of how to troubleshoot Direct Access client connection.

A few important words on those two technologies:

A really, really good overview on Direct Access can be find in Tim Warner’s YouTube CBT Nuggets https://www.youtube.com/watch?v=saYk4d3h6sY

Let me share what’s this series of articles is all about. It is divided into 4 sections:

  1. DA + NAP part 1: Introduction
    This introduction.
  2. DA + NAP part 2: LAB configuration and overview
    I do a quick overview of my Direct Access and NAP settings and general configuration on the LAB setup which is a core for further certificate issue investigation.
  3. DA + NAP part 3: Single CA work flows explanation
    In this section I am guiding through the step by step process happening under the hood of user getting access to internal resources using Direct Access with NAP policies. This scenario is working fine, as long as you use single CA.
  4. DA + NAP part 4: Potential issue with multiple CAs. Lessons learned.
    The last section describes what was the problem when having different CAs and what is the right design for such scenarios.

Enjoy!

P.S.

TL;DR version: What happened was that client didn’t show any error at all, had all required certificates (computer and health) issued but couldn’t setup the corp/intranet tunnel to internal resources with Direct Access client. There was no indication of any kind of errors neither on PKI, NPS/HRA, DA nor client machine side. At the end of the day it turned out it’s always about certificates. You can’t have 2 separated CAs: one for issuing machine certificates (enterprise CA with auto enrollment) and a separate CA for Health certificates (standalone CA) UNLESS THOSE DON’T HAVE COMMON ROOT CA. If they both are subordinate CAs to the same Root CA – that’s fine, but if they are separate machines and have nothing in common it is impossible to set DA with NAP to utilize those two.