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:
- Network Access Protection (NAP) is deprecated in Windows Server 2012 R2 (http://technet.microsoft.com/en-us/library/dn303411.aspx ) – so what does it mean and how does this affect your deployment? In general you can still use NAP, but its future is not crystal clear. You can have a read here: http://windowsitpro.com/blog/what-s-happening-network-access-protection .
- Direct Access is a Windows Server feature (http://technet.microsoft.com/en-us/network/dd420463.aspx) which in the newest OS version (Windows 2012 R2) has improved features comparing to Microsoft Forefront UAG (which by the way will not be continued http://blogs.technet.com/b/server-cloud/archive/2013/12/17/important-changes-to-the-forefront-product-line.aspx). New Direct Access on W2K12 R2, among other features, has following advantages:
- VPN and DA can be on the same server,
- You can use only single NIC ,
- DA accepts NAT,
- No PKI required (only for Windows 8 and self-signed certificates). You require PKI, however, for your VPN, IPsec, 802.1x deployments,
- Better performance for IPHTTPS (unnecessary encryption = null). Not true if DA and VPN is on the same server confirmed by Richard Hicks (http://directaccess.richardhicks.com/2014/06/24/directaccess-ip-https-null-encryption-and-sstp-vpn/) ,
- Second factor authentication.
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:
- DA + NAP part 1: Introduction
- 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.
- 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.
- 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.
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.