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:
- 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”:
- 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).
- Run “ipconfig /all” to see if the IPHTTPS has configured itself with IPv6 address:
- 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).
- 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.
- 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:
- 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!:
- 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.
- 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)
- 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:
Above tunnels can also be confirmed in the Windows Firewall Monitoring / Security Associations / Main Mode:
- From Direct Access Remote Client Status console I finally confirm that the client is connected and using User Kerberos as Authentication Method:
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