locked
Direct Access server URL FQDN is internal domain RRS feed

  • Question

  • Direct Access isn't working for me, and I think the issue I'm having is resolving the URL of the direct access server.  I'm trying to figure out how to make my clients connect to my DA server.

    I'm am trying to setup a DA server for the first time.  The domain I have joined my DA server to is a non-routable domain name, such as domain.local.  My thoughts were no big deal, I'll just use a DNS entry for a routable domain that we own.  The problem I'm running into is the direct access configuration wizard uses the FQDN assigned to the server and puts that in the xml configuration file that it builds.

    I have tried to modify this xml file to a URL that I can resolve from the internet, but whenever I try to modify it, I get access denied.  I am logged into the server as an administrator, I have tried launching Windows Explorer as administrator, I have launched notepad as administrator, and they all failed.  I've turned off UAC, and I still cannot modify this file.  I also cannot find a place in the setup to change the URL.

    One of the strangest things is for the purpose of testing, I added the server's FQDN to my local hosts file, and my Windows 7 box still will not resolve it using it's FQDN from the internet.  I've rebooted and everything.  If I do an ipconfig /displaydns I can see the entry listed for the server, but if I try to ping it or browse to it using IE, it is unable to resolve the name.

    I've posted an output of some commands below.  I had to change names and IP addresses because of corporate security policy.

     

    Microsoft Windows [Version 6.1.7600]
    Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

    D:\Users\user>netsh interface httpstunnel show interfaces

    Interface IPHTTPSInterface (Group Policy)  Parameters
    ------------------------------------------------------------
    Role                       : client
    URL                        : https://directaccess.domain.local:443/IPHTTPS
    Last Error Code            : 0x2afc
    Interface Status           : failed to connect to the IPHTTPS server. Waiting to
     reconnect


    D:\Users\user>netsh interface 6to4 show relay
    Relay Name             : x.x.x.x (Group Policy)
    Use Relay              : default
    Resolution Interval    : default


    D:\Users\user>netsh interface 6to4 show state
    6to4 Service State     : default
    Undo on Service Stop   : default


    D:\Users\user>netsh interface teredo show state
    Teredo Parameters
    ---------------------------------------------
    Type                    : client
    Server Name             : x.x.x.x (Group Policy)
    Client Refresh Interval : 30 seconds
    Client Port             : unspecified
    State                   : probe (primary server)
    Client Type             : teredo client
    Network                 : unmanaged


    D:\Users\user>netsh interface httpstunnel show interfaces

    Interface IPHTTPSInterface (Group Policy)  Parameters
    ------------------------------------------------------------
    Role                       : client
    URL                        : https://directaccess.domain.local:443/IPHTTPS
    Last Error Code            : 0x2afc
    Interface Status           : failed to connect to the IPHTTPS server. Waiting to
     reconnect


    D:\Users\user>ipconfig

    Windows IP Configuration


    Wireless LAN adapter Wireless Network Connection:

       Connection-specific DNS Suffix  . :
       Link-local IPv6 Address . . . . . : fe80::13:b734:53e4:7588%15
       IPv4 Address. . . . . . . . . . . : 10.127.52.13
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . : 10.127.52.1

    Ethernet adapter Local Area Connection:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : corp.loc

    Ethernet adapter Bluetooth Network Connection:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :

    Tunnel adapter isatap.{B8097AE7-164C-47D2-B6F8-27A1E1AA6A39}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :

    Tunnel adapter Teredo Tunneling Pseudo-Interface:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :

    Tunnel adapter iphttpsinterface:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :

    D:\Users\user>ipconfig /displaydns

    Windows IP Configuration

        y.y.y.y.in-addr.arpa
        ----------------------------------------
        Record Name . . . . . : y.y.y.y.in-addr.arpa.
        Record Type . . . . . : 12
        Time To Live  . . . . : 86400
        Data Length . . . . . : 8
        Section . . . . . . . : Answer
        PTR Record  . . . . . : directaccess.domain.local


        Record Name . . . . . : y.y.y.y.in-addr.arpa.
        Record Type . . . . . : 12
        Time To Live  . . . . : 86400
        Data Length . . . . . : 8
        Section . . . . . . . : Answer
        PTR Record  . . . . . : directaccess


        directaccess.domain.local
        ----------------------------------------
        Record Name . . . . . : directaccess.domain.local
        Record Type . . . . . : 1
        Time To Live  . . . . : 86400
        Data Length . . . . . : 4
        Section . . . . . . . : Answer
        A (Host) Record . . . : x.x.x.x


        directaccess.domain.local
        ----------------------------------------
        No records of type AAAA


        nla.external.domain
        ----------------------------------------
        Name does not exist.


        isatap
        ----------------------------------------
        Name does not exist.


        directaccess
        ----------------------------------------
        Record Name . . . . . : directaccess
        Record Type . . . . . : 1
        Time To Live  . . . . : 86400
        Data Length . . . . . : 4
        Section . . . . . . . : Answer
        A (Host) Record . . . : x.x.x.x


        directaccess
        ----------------------------------------
        No records of type AAAA



    D:\Users\user>ping directaccess.domain.local
    Ping request could not find host directaccess.domain.local. Please check the name and tr
    y again.

    D:\Users\user>

    Tuesday, May 25, 2010 5:35 PM

Answers

  • Hi,

    The IP-HTTPS connection is based on SSL. This means, the host name of the URL used must be authenticated using a certificate with the same name. You cannot modify the IP-HTTPS URL https://directaccess.domain.local:443/IPHTTPS , In the UAG DirectAccess UI since this URL is derived from the certificate you chose for IP-HTTPS.

    Please check your computer's personal store. There should be a certificate with directaccess.domain.local in the subject.

    If you'd like to use an IP-HTTPS URL with a different host name, then you simply need to import a certificate with the required subject name and choose that certificate in the DirectAccess configuration.

    Regarding the configuration XML that you were trying to modify, can you please specify where is this XML located? Are you refering to the group policy configuration script or to UAG's configuration store?

    Your last finding with the hosts file is indeed strange, as I see no reason why this shouldn't work. I also tried creating a line in the hosts file with directaccess.domain.local and a fictitious IP address, and ping succeeds in resolving the address. Can you try to add different host names to the hosts file and see if it works?

    Thanks,

    Yaniv

    • Marked as answer by Modeverything Wednesday, May 26, 2010 12:44 PM
    Tuesday, May 25, 2010 8:32 PM
  • Run the DA wizard again, choose the cert again, then Activate again.
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Modeverything Wednesday, May 26, 2010 1:44 PM
    Wednesday, May 26, 2010 1:38 PM

All replies

  • Hi,

    The IP-HTTPS connection is based on SSL. This means, the host name of the URL used must be authenticated using a certificate with the same name. You cannot modify the IP-HTTPS URL https://directaccess.domain.local:443/IPHTTPS , In the UAG DirectAccess UI since this URL is derived from the certificate you chose for IP-HTTPS.

    Please check your computer's personal store. There should be a certificate with directaccess.domain.local in the subject.

    If you'd like to use an IP-HTTPS URL with a different host name, then you simply need to import a certificate with the required subject name and choose that certificate in the DirectAccess configuration.

    Regarding the configuration XML that you were trying to modify, can you please specify where is this XML located? Are you refering to the group policy configuration script or to UAG's configuration store?

    Your last finding with the hosts file is indeed strange, as I see no reason why this shouldn't work. I also tried creating a line in the hosts file with directaccess.domain.local and a fictitious IP address, and ping succeeds in resolving the address. Can you try to add different host names to the hosts file and see if it works?

    Thanks,

    Yaniv

    • Marked as answer by Modeverything Wednesday, May 26, 2010 12:44 PM
    Tuesday, May 25, 2010 8:32 PM
  • Hi Yaniv,

    Thanks for the feedback.  The issue was indeed that the certificate being used had the same name as the computer.  I changed the certificate and now the external URL that I want to use is showing up properly in the xml config file and in group policy.  This makes sense as to why it was happening, I just didn't even think about checking that certificate.

    The xml file I'm referring to is located at C:\Windows\DirectAccess.  It's called DirectAccessConfig.

    I agree that the hosts file issue is strange, and it's something I've never seen before.  I admit I'm kinda new to Windows 7 and Windows 2008, so I only brought it up in case there was some new security feature or something I didn't know about that prevents clients from checking their local hosts file.  I know Microsoft has been doing a lot more with security, so you never know I suppose.

     

    I have one additional question if you wouldn't mind...

    I added a Web Server certificate for whose enhanced key usage is Server Authentication.  I verified the subject and DNS name matches the external domain name that I want to use.  In the Direct Access management console, I updated the Direct Access server to use this certificate, then saved and wrote the changes.  I then browsed to the web address https://daserver.external.com:443/IPHTTPS (the real external domain name is different) which matches the URL given by the Direct Access policy.  I received a certificate error.  I checked the certificate and found that it is still using the old certificate that has the machine's FQDN, not the new one for Web Authentication that I just assigned it.  I verified in the Direct Access management console that the Web certificate with correct external URL is being used.  I also verified in the Direct Access xml config that the IPHTTPSCertHash matches the thumbprint of the correct cert.

    I couldn't figure out why no matter what I did, I kept getting the certificate error and the server using the wrong cert, so I rebooted the server.  Now that the server has come back up, I am no longer able to connect to the Direct Access URL; I simply get a page cannot be displayed.  I checked netstat and I do see the server listening on port 443, but I cannot connect.  I tried to find the Direct Access config in IIS, but nothing is listed there except my CRL that I manually created, and it's listening on port 80.

    Does anyone have any idea why the server is no longer responding to https requests for the direct access URL?

     

    Thanks!

    Wednesday, May 26, 2010 12:44 PM
  • Run the DA wizard again, choose the cert again, then Activate again.
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Modeverything Wednesday, May 26, 2010 1:44 PM
    Wednesday, May 26, 2010 1:38 PM
  • Run the DA wizard again, choose the cert again, then Activate again.
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Yeah, I undid all of the config, then re-setup the server and now it works.

    Thanks for your help!

    Wednesday, May 26, 2010 1:44 PM
  • Hi,

    Are you deploying DirectAccess using UAG or using the Built-in windows feature for DirectAccess?

    The file C:\Windows\DirectAccess\DirectAccessConfig.xml is actually the configuration for Windows DirectAccess, and is never used by UAG.

    When making changes in the UAG DirectAccess configuration, always make sure you both generate the Group Policies and Activate UAG.

    Wednesday, May 26, 2010 6:27 PM
  • I am using the Direct Access that is installed from the Server Features of Windows 2008 R2.  I'm new to this product, so I haven't even looked at UAG, which I think is part of Forefront.  I didn't even realize initially that UAG provided a DirectAccess solution.  Should I be using that one instead?  We are licensed for all of the Forefront products.

    Whenever I make changes to my Direct Access config, I save, then finish which generates the new xml file.

    Wednesday, May 26, 2010 7:15 PM
  • Hi Mode,

    The DirectAccess that comes with Windows Server 2008 R2 and that provided by UAG are quite a bit different in terms of what they support, the configuration requirements, and the back-end server requirements.

    So, since you are licensed to use the Forefront product, I think we all agree that this is the recommended way for you to proceed. And when you have problems, we'll all be here to help you out! :)

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, May 26, 2010 7:38 PM