Partilhar via

Direct Access for Windows 7 Works! ... and then it stops.

  • Artigo

I'm seeing lots of cases were a Direct Access proof of concept has been set up and it works really well for a while with both Windows 8 and Windows 7 (Server 2012 for the DA server - don't waste your time with 2008 R2).

The problem is that all of a sudden the Windows 7 test clients stop working. I do it all the time in my lab as well, mostly because i only need it to work for a while so i forget an important step for ongoing Win7 connections. Its really frustrating when you come back to a lab that is saved and its broken, especially when you are trying to show someone how awesome Direct Access is.

Thinking about the differences between the Windows 8 and Windows 7 clients you can probably imagine what is going on but i just wanted to note down the steps that can help you find out for sure, and then fix it up.

So the difference i am talking about is that Windows 7 clients still rely on certificates for authentication. They don't have the Kerberos proxy client built in. So if something goes wrong with the certificates, the Win 7 clients are in strife.

The problem i am seeing a lot is that the CRL is unreachable for checking the validity of certificates. It shows up as a client that is unable to obtain their IPHTTPS connection, and there is a netsh command we can use to dig a bit deeper:

We can resolve the external name of the DA server, in this case da.contosoglobal.com, but for some reason we cant get the tunnel established.

To check why, use the command: netsh int httpstunnel show int

 

You can see that the IPHTTPS tunnel has been tried, but it is failing.

If we take the error code and look it up on MSDN or TechNet we can get a clue on the reason: "Because the revocation server was offline, the called function wasn't able to complete the revocation check.".

Of course, i haven't made the CRL available. Woops. It could also be that the location is down, there is a typo in the configuration, something along those lines but for me - i just never bother to do this step because when i'm setting up DA, i just need it to work for a few hours while i'm showing someone.

So: Fixing it. Well, all you need to do is edit the CRL path for your certificates. For me, i typically make it available on the 'external' web server in my lab. For a real POC you might choose an external server your organisation hosts, or has access to for hosting the CRL.

By the way, if you cant find your CA management bits, you might need to install them :) - i admit I spent a little time looking for them this morning, i could have sworn they were already there but maybe not. (install-windowsFeature RSAT-ADCS-Mgmt)

 

If i look at the properties of the CA, the thing i want to do is add a location for the CRL:

This is just an 'external' web server in my lab, somewhere CRL checking can reach for the DA connections. For my lab, i'm just going to copy the CRL from the CA to this location.

The CRL and the Delta are copied to the external web server - just in the default web directory. I've also re-issued the certificates to my clients so the path is included for the CRL at the external location:

So, moment of truth - will this fix up the IPHTTPS connection error?

 

Sure Does. We can see the active iphttps interface, the confirmation that the tunnel is up, and we are pinging resources using IPv6.

Neat.

Comments

  • Anonymous
    December 11, 2012
    Just a sidenote, another (better) fix for this for most companies is to use an SSL certificate from a public CA in the first place for your IP-HTTPS listener. I know you are talking about a lab and/or POC here, and for those sure it makes sense to use your own if you can, you can also get a 30 day trial on an SSL certificate from a few public CAs. I always recommending using a cert from a public CA for production. There are many things that can go wrong when trying to publish your own CRLs, and using a public cert places all of that responsibility onto the CA. Thanks for the post about DirectAccess!
  • Anonymous
    January 12, 2013
    Really good point Jordan! It makes things a lot easier.Thanks for the follow up (and really sorry for the late reply).