Direct Access + Network Access Protection – part 4 – Potential issue with multiple CAs. Lessons learned.

Hi, Andrzej Kaźmierczak (KAZM) again with the last article on DA + NAP integration. In my previous articles I have successfully configured and tested Direct Access with NAP integration using single, enterprise Issuing CA (DA + NAP part 3. Single CA work flows explanation).

There is a Microsoft MSDN article (http://msdn.microsoft.com/en-us/library/cc731916.aspx) recommending to use a dedicated standalone subordinate CA for NAP health certificates. And so I did in my LAB to show that it isn’t that simple with multiple CAs around. This is how my LAB changed comparing to its original setup (DA + NAP part 2: LAB configuration and overview):

  1. I added a Standalone CA role on SRVNLS server that will be used only for issuing health certificates (CN=Standalone CA,C=PL):
    image1
  2. I have reconfigured Health Registration Authority to use Standalone CA and not to use enterprise certificate templates (which by the way can be used even with standalone CA):
    image2
  3. On the properties of the Standalone CA in the Security tab I gave the SRVNPS computer account full permissions. Also, in Policy Module tab I set Request Handling to “Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate” so that HRA request will not hit “Pending” state but will be automatically issued:
    image3

Everything is setup, so I start the client connected to the Internet (External) network and…. Hhmm… from the client machine I am able to connect to the SRVDC (Domain Controller) and to SRVNPS (NPS + HRA) – which means that infrastructure tunnel was working. Unfortunately I could only ping my internal server SRVFS as seen on below figure:

image4

Let’s start troubleshooting:

  1. Quick look on the Direct Access server, everything looks green and good:
    image5
  2. What about the Remote Access Clients Status console? Ok, so user doesn’t have User Kerberos Authentication Method which is used for accessing intranet resources – that confirms that user cannot connect to SRVFS, but have to look deeper to get the cause:
    image6
  3. On the SRVNPS I can see that HRA has approved the request and enrolled a health certificate to the user, which means that the user was able to send statement of health (infrastructure and management tunnels are working fine) and HRA can “talk” to the new standalone CA as well:
    image7
  4. I confirm on the Standalone CA that health certificates have been issued to the SRVNPS (on behalf of the user):
    image8
  5. But have the user received health certificate? Yes, he did:
    image9
  6. Let’s have a look in client’s Windows Firewall – there is no User Kerberos – so no corp/intranet tunnel is created:
    image10
  7. In Event viewer on the SERVER and CLIENT there are NO THINGS that can lead to the problem cause. On the client, IKE negotiations logs are not shown by default, but you can view the success or failure of IKE negotiations in the Event Viewer security log doing little trick. To view these events, enable success or failure auditing for the Audit logon events audit policy for your domain or local computer (http://technet.microsoft.com/en-us/library/cc737812(v=ws.10).aspx). After doing this I could see more useful data:
    1. EVENT ID 4653 “An IPsec main mode negotiation failed” with Failure reason “No policy configured”
    2. EVENT ID 4984 “An IPsec extended mode negotiation failed” with Failure reason “SA establishment is not authorized”

    image11

  8. So everything seems to be ok, the client machine receives health certificate, but still no corp/intranet tunnel is setup. This has to be something with the health certificate! New Standalone CA certificate is trusted for the client computer (it is added to the Trusted Root Certification Authorities). I verify certificates for Main Mode SA with “netsh adv mon show mmsa” and everything should be clear now:
    image12
  9. Although certificates issued by the Standalone CA are trusted by the client computer and operating system, but they are not trusted by the service to setup IPsec Security Association (http://technet.microsoft.com/en-us/library/cc759130(v=ws.10).aspx). Why? Well, let me remind you that Standalone CA was not configured as trusted for Direct Access. Only TST Root CA (my issuing CA that issued certificate for workstation used for infrastructure and management tunnel) is setup to be trusted in Direct Access configuration wizard:
    image13

But wait… what? so I’m using enterprise CA to issue computer certificate and a standalone CA to issue health certificates and there’s only one place in the DA configuration to setup a CA trust for that? How is that possible? The answer is very simple: in the DA configuration use common Root CA for both Enterprise and Standalone CA!

Lessons learned:

  1. If you want to have only 1 Issuing CA for both certificates: computer (workstation) certificate and a health certificate – that’s fine! You can even have a Standalone CA for that, but you have to MANUALLY issue all: SSL (even Direct Access IPHTTPS) and computer certificates as there is no way for auto enrolment feature with standalone CA.
  2. If you want to use 2 Issuing CAs – one for computer/workstation certificates and the second one for health certificates you should have a common offline Root CA, which would be pointed in the Remote Access Server Setup / Authentication page of the Direct Access configuration wizard. This is how my LAB environment should look like:
    image14
  3. If you don’t have root and have 2 separate CAs, you should reconsider changing your PKI architecture to meet the PKI best practice design (http://kazmierczak.eu/itblog/2012/08/22/the-dos-and-donts-of-pki-microsoft-adcs/) . Or you can take your current issuing CA and consider it as a root – so standard CA will become a subordinate to your issuing CA, and DA should be configured with your issuing CA certificate in the Remote Access Server – which is not recommended, but will do the trick.
  4. When troubleshooting, ALWAYS read carefully Root/Issuing CA names and confirm with certificate thumbnail which certificate you are using for what . Sometimes Root and Issuing CA names are very similar and is very easy to get confused which one is which.
Category: Knowledge Base

Leave a Reply