locked
Server 2012 R2 DirectAccess - 2008 R2 Client RRS feed

  • Question

  • I have things working for Server 2012 R2 Direct Access and Windows 8.1 Enterprise machines. Now moving on to Server 2008 R2 as a client, the environment is not working.

    I just tried turning on Windows 7 support and applying but still no luck.  I am not seeing much on this, so I suspect it usually just works for Server 2008 R2?


    Mike


    • Edited by mlaskie Wednesday, October 29, 2014 1:13 AM
    Thursday, October 23, 2014 7:39 PM

All replies

  • Hi,

    Have you tried ticking the box to support Windows 7 Client in the configuration wizard?

    Regards


    Regards, Rmknight

    Friday, October 24, 2014 8:24 AM
  • When you say you have enabled, you must have enabled Computer cert based authentication.

    Also can you confirm, if you have proper machine auth certificates at both the ends? 

    Does your 2012 Dashboard looks healthy? You might need DCA 2.0 if you have Win7/08 R2 clients connecting to 2012 R2.

    What does DCA report say?

    Friday, October 24, 2014 9:24 AM
  • Yes you must when enable Windows 7 is checked.

    >> Enabled

    In the configuration, for Direct Access "Server" > Authentication, I have...

    • Selected - Active Directory credentials 
    • Checked - Use computer certificates
    • Checked - Use an intermediate certificate
    • Browsed and selected our domain's certificate authority
    • Checked Enabled Windows 7
    • Applied the settings

    >> 2012 R2 Dashboard

    Looks healthy, green and good to go.  The event log is uneventful.

    >> Might need DCA 2.0

    The DCA 2.0 installer is for Windows 7, which is why I posted, what to do for 2008 R2 clients?


    Mike






    • Edited by mlaskie Wednesday, October 29, 2014 1:19 AM
    Tuesday, October 28, 2014 10:11 PM
  • So I forged ahead with an actual fresh Windows 7 machine, all service packed up, instead of the existing 2008 R2 machine that we need to keep for sometime.

    I've installed the DCA 2.0, made the Group Policy edits on the domain.  The Windows 7 machine has received the updates and DCA appears happy when on the private network.

    However when the Windows 7 machine is switched over to the public network, no connection.  Not really much of a hint as to what the problem is.

    • RED: Corporate connectivity is not working.
    • "Your computer cannot connect to the DirectAccess server. If the problem persists, contact your administrator.
    • The Probes FAIL, DTEs FAIL.

    The 2012 R2 DirectAccess server has no knowledge of the failed connection attempts.

    This is quite the challenge... 


    Mike

    Wednesday, October 29, 2014 1:10 AM
  • Can you please upload or post the DCA Logs here?
    Wednesday, October 29, 2014 6:27 AM
  • Hi,

    You say "Checked - Use an intermediate certificate" how many intermediate CA do you have?

    I would recommend just pointing to the Root CA so any certificates within the chain will be supported.

    DCA 2.0 is only required for OTP in DA 2012. you should be able to use ether DCA 1.5 and 2.0.


    Regards, Rmknight

    Wednesday, October 29, 2014 9:26 AM
  • Thanks, here...


    Mike


    • Edited by mlaskie Wednesday, October 29, 2014 3:00 PM
    Wednesday, October 29, 2014 2:57 PM
  • The check for "Use an intermediate certificate" is required to enable Windows 7.  The browse offered the domain one and only Root CA so that is employed.

    Is DCA an actual requirement or just helpful for the diagnostic experience?  As there is no DCA for 2008 R2.

    I ask because the process to make a GPO for "DirectAccess Connectivity Assistant" is to just a copy the Corporate Resource, DTE and Support email settings from the "DirectAccess Client" object.  Then make a WMI filter for the 6.1% operating system versions, and link it to the domain.  The machines are already picking that up from the "DirectAccess Client" but to satisfy DCA we make the extra object.  It seems redundant and only a requirement for diagnostics not connectivity?


    Mike

    Wednesday, October 29, 2014 3:32 PM
  • Hi,

    "Use an intermediate certificate" is NOT required to enable Windows 7

    Only certificate authentication is a requirement.

    I would recommend removing the tick for "Use an intermediate cert" and then update the GPO's on the servers and clients. and test again

    If the client is configured correctly then you do not need the DCA. unless you require One Time Passwords.


    Regards, Rmknight

    Wednesday, October 29, 2014 3:38 PM
  • Perhaps I have a newer version, as it now appears quite required.


    Mike

    Wednesday, October 29, 2014 3:46 PM
  • No you don't have a newer version.

    Untick use intermediate and then browse for your root certificate.

    The screen shot is taken from a working Multisite test system. Its missing the Windows 7 tick box, because it is different for Multisite.


    Regards, Rmknight

    Wednesday, October 29, 2014 3:50 PM
  • Ah... I get it thanks.  I was pretty optimistic there but after applying the changes and forcing gpupdates, still unable to connect.  I refreshed the log...


    Mike

    Wednesday, October 29, 2014 4:08 PM
  • Right. Looked at the log and your IP-HTTPS connection is failing. Windows 7 client have to do a CRL of the IP-HTTPS certificate before making a connections.

    What kind of certificate are you using for the IP-HTTPS interface? a self signed is not supported for Win7.

    Have a look here http://support.risualblogs.com/blog/2012/12/12/direct-access-iphttps-error-0x80092013/ at the error and a fix that may help.

    If you are using a internal certificate you need to publish the CRL to the internet.


    Regards, Rmknight

    Wednesday, October 29, 2014 4:14 PM
  • Thanks, been looking into 0x80092013. 

    One thing I had was both internal and external as http://crl.corp.domain.com.  While efficient, as it's always the same, when the DirectAccess policy is implemented ALL calls to http://crl.corp.domain.com are directed to use private DNS, based on the suffix search list.

    I changed CRL to refer to external http://crl.domain.com and updated public DNS.  It is now always available to the Windows 7 machine.

    I regenerated the certificate for IP-HTTPS, went through the DirectAccess configuration and applied the settings.

    No change on the Windows 7.


    Mike

    Wednesday, October 29, 2014 9:23 PM
  • I just tried setting the IIS 7.5 server with allowDoubleEscaping = True

    Still no luck with Windows 7.  I am not able to find out why CRYPT_E_REVOCATION_OFFLINE occurs?


    Mike

    Thursday, October 30, 2014 12:00 AM
  • CRYPT_E_REVOCATION_OFFLINE occurs when CRL checking fails.

    I see you have published CRL in internet and even after that it fails?

    Can you check the value you have for the property "CRL Distribution points" in IP-HTTPS Certificate ?

    And the CRL that you see there should be accessible from internet.

    If you see the old entry there  , you can change the CRL to any url which is accessible from internet and re-issue the certificate for IP-HTTPS.


    • Edited by Vasu Deva Friday, October 31, 2014 5:41 AM
    Friday, October 31, 2014 5:41 AM