Direct Access on Azure?

A customer recently requested Kloud to assist them in implementing a Windows 2012 R2 server based Direct Access (DA) service, as their work force had recently moved to a Windows 8 client platform.  What did surprise me was that they requested it be one of the first solutions to be hosted on their Microsoft Azure service.

Direct Access, for those unfamiliar with the technology, is essentially an ‘always on’ VPN style connection that provides a user access to a corporate network from any basic Internet network connection without any user interaction.  The connection is established prior to a user even logging into their laptop or tablet, so services such as Group Policy mapped drives and login scripts will execute just like a user logging into an internal corporate network.  This technology was introduced with Windows 7 Enterprise edition and continues with Windows 8 Enterprise edition.  Windows 10 appears to have this code as well (at least judging by the current technical preview and TechNet forum responses).

One of the first items to note is that Direct Access isn’t supported by Microsoft, at this stage in its life, on the Azure platform.  After implementing it successfully however for this customer’s requirements, I thought I would share some learnings about why this solution worked for this customer and how we implemented it, but also some items to note about why it may not be suitable for your environment.

This article can provide guidance if you’re considering a single DA server solution, however you might need to look for other advice if you’re looking at a multi-site, or multi-DA server solution requiring load balancing or high availability.  Primarily the guidance around IPv6 and static IP addressing that I address here may change if you look at these architectures.

Why?

My customer had the following business and technical requirements:

• They own a large fleet of Windows 8 laptops that ‘live’ outside the corporate network and primarily never connect to the corporate network and therefore never communicate with internal systems such as Active Directory for Group Policy updates or internal anti-virus systems.  The customer wanted to ensure their laptop fleet could still be managed by these systems to ensure compliance and consistency in user interface ‘lockdown’ (using Group Policy) for support teams in aiding troubleshooting and security updates.
• My customer wanted to remove their existing third-party SSL VPN solution to access internal services and recoup the licensing cost with this removal.  The Direct Access solution had already been ‘paid for’ in effect as the customer already had a Microsoft Enterprise Agreement.
• The exiting SSL VPN solution forced all Internet access (‘forced tunnelling’) during the session through the corporate network costing the customer on ISP Internet download fees, especially for users working from home.
• My customer did not have the budget to publish all existing internally accessible services to the Internet using publishing technologies such as Microsoft Web Application Proxy (WAP), for example.  This would require designing and implementing a WAP architecture, and then testing each service individually over that publishing platform.

Can’t or shouldn’t?

Microsoft Azure can host a Direct Access service, and for the most part it works quite well, but here are the underlying technologies that in my testing refuse to work with the Azure platform:

• ‘Manage out’ – this term refers to the ability for servers or clients on the corporate network being able to establish a connection (that is it creates the network packet) directly to the Direct Access client that is connected only to the Internet.  There is no official guidance from Microsoft about why there is a limitation, however in my testing, I find that it is related to IPv6 and the lack of ‘IPv6 Broadcast’ address ability.  I didn’t get time to run Wireshark across it (plus my version of Wireshark wasn’t IPv6 aware!) so if anyone has found a workaround to get this working in Azure, shoot me an email! (michael.pearn@kloud.com.au).
• Teredo – there are two types of Direct Access architectures on Windows Server 2012 R2: IP-HTTPS (that is an HTTPS tunnel is established between the client and the Direct Access server first, then all IPv6 communication occurs across this encrypted tunnel) or the use of ‘Teredo’ which is a IPv6 over IPv4 encapsulation technology.  Microsoft explains the various architectures best here: http://technet.microsoft.com/en-us/library/gg315307.aspx (although this article is in 2010 in the context of the now retired UAG product). Teredo however requires TWO network cards, and since Azure Virtual Servers only support one network card per server, then Teredo cannot be used as an option on Azure.  In all of my testing on Azure, I used IP-HTTPS.

The following is a good reason not (at least for now) to put Direct Access on Azure:

• There is no native way, using Direct Access configuration, to deny a Direct Access client from reaching any server or FQDN on the internal network (ie. a ‘black list’), if that connection can be established from the Direct Access server.  For example, if a DA client attempts to download large files to servers reachable from the Direct Access server (such as large image or CAD drawings), then unless the server is hosted in Azure as well, all downloads will occur over the Azure VPN site-to-site connection.  This can prove very costly in terms of Azure fees.  My customer used their VPN hardware (which had a firewall service) to establish a ‘black list’ of IP addressed sites, that were still on-premise, to prevent Direct Access clients reaching these services across the Azure VPN (although communicating this to your end clients why they can’t reach these services can be difficult, as they’ll just get a 401 web error or mapped drive connection failure).

How?

The key to getting a working Direct Access solution on the Azure platform is primarily configuring the environment with the following items:

• Ensure all Direct Access servers use a Static Private IP address.   The new Azure Portal can easily assign a Static IP address, but only if the Virtual Machine is built into a custom network first.  If a Virtual Server is built using the default Azure internal networking (10.x.x.x.), the server can be rebuilt into a custom network instead however the server object itself has to be deleted and rebuilt.  If the Virtual Disk is kept during the deletion process, then the new server can just use the existing VHD during the install of the new object.  Browse to the new Azure Portal (https://portal.azure.com) and use the web interface to first configure a private IP address that matches the network in use (see example picture below).  The ‘old’ Azure portal (https://manage.windowsazure.com) cannot set a static IP address directly through the web interface and PowerShell has to be used instead locally on the server.  A connection connection to the Azure service (via the Internet) is needed to set a static IP address and more instructions can be found here: http://msdn.microsoft.com/en-us/library/azure/dn630228.aspx.  To use the Azure PowerShell commands, the Azure PowerShell commandlets have to be installed first and an Internet connection has to be present for the Powershell to connect to the Azure service to allocate a static IP address.  More instructions on getting the Azure PowerShell be found here: http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/
  
• Be sure to install all of the latest Hotfixes for Windows 8/8.1 clients and Server 2012 (with or without R2).  This article is excellent to follow the list of required updates:  http://support.microsoft.com/kb/2883952
• Install at least one Domain Controller in Azure (this is a good article to follow: http://msdn.microsoft.com/en-us/library/azure/jj156090.aspx).  The Direct Access server has to be domain joined, and all Direct Access configuration (for the DA clients and the DA server) are stored as Group Policy objects.  Also, the Direct Access server itself performs all DNS queries for Direct Access clients on their behalf.  If a Domain Controller is local, then all DNS queries will be contained to the Azure network and not be forced to go over the Azure VPN site-to-site connection to the corporate network.  Do not forget to configure your AD Sites and Services to ensure that Domain Controller in Azure is contained within its own AD site so the AD replication does occur too often across the VPN connection (plus you don’t want your on-premise clients using the Azure DC for authentications).
• When configuring Direct Access, at least as far as a single Direct Access server solution is required, do not modify the default DNS settings that are assigned by the configuration wizard.  It isn’t well documented or explained, but essentially the Direct Access server runs a local DNS64 service which essentially becomes the DNS server for all Direct Access clients (for all internal sites, not the Internet sites).  The DA configuration wizard assigns the IP address of the DA server itself and provides the IPv6 address of the server to the DA Client GPO for DNS queries.  The DA server will serve all DNS requests for addresses ending in the ‘DNS Suffix’ pool of FQDN’s specified in the DA settings.  If you have a ‘split-brain’ DNS architecture, for example you have ‘customer.com’ addresses on Internet DNS servers but you also overrule these records with an internal Primary zone (or stub records) for ‘customer.com’ for certain sites, then if you include ‘customer.com’ in the Direct Access DNS Suffix settings, then the client will only use internal DNS servers (at least the DNS servers that the Direct Access server can reach) for resolution for these names.  As with all things, test all of your corporate websites during the testing phase to ensure no conflicts.  One of the services that could cause conflicts would be solutions such as ADFS which are generally architected with the exact same internal/external FQDN (e.g. adfs.customer.com) – the internal FQDN generally points clients to use integrated authenticated, the external FQDN generally points to forms based authentication.  For my customer, re-directing all ‘customer.com’ requests to the internal corporate network, including ADFS, worked without issue.
• If you’re using Hyper-V Windows 8 clients in your testing, be aware that in my experience the testing experience is ‘patchy’ at best.  I did not have time to get a Windows 8 client VHD imported into Azure (there’s no native Windows 8 templates to use in Azure) so I used a local Hyper-V Windows 8 client in my testing and used the Offline Domain Join plus Group Policy option (there was no point to point network connection between my Azure DA server and my Hyper-V test client).  My experience was that the Hyper-V DA client would connect to the DA FQDN but often the DNS service provided by the DA server was very intermittent.  This article is excellent to follow to get the Direct Access Client Settings Group Policy onto the offline Hyper-V client for testing:  http://technet.microsoft.com/en-us/library/jj574150.aspx.  My experience is that a physical client should be used (if possible) for all Direct Access testing.
• CNAME records can be used instead of using the native Azure published ‘service.cloudapp.net’ FQDN for the DA service itself.  My client successfully used a vanity CNAME (e.g. directaccess.customer.com) pointing to their ‘service.cloudapp.net’ name, with a matching wildcard certificate that used the ‘vanity’ name in the subject field (e.g. *.customer.com).

Tips?

The following are some general points to follow to help get a DA service running on Azure:

• If you’re using Windows 8.1 for testing, and you’re finding the Direct Access Client Settings GPO are not reaching your test clients, then check the WMI filter to ensure they are not being excluded from targeting.  In my customer’s environment, the version only allowed 6.2% clients (ie. Windows 8, not Windows 8.1).  Be sure the WMI filter includes ‘like 6.3%’ in the filter, others Windows 8.1 clients will not receive the Direct Access policy correctly:

Select * from Win32_OperatingSystem WHERE (ProductType = 3) OR ((Version LIKE '6.2%' OR Version LIKE '6.3%') AND (OperatingSystemSKU = 4 OR OperatingSystemSKU = 27 OR OperatingSystemSKU = 72 OR OperatingSystemSKU = 84)) OR (Version LIKE '6.1%' AND (OperatingSystemSKU = 4 OR OperatingSystemSKU = 27 OR OperatingSystemSKU = 70 OR OperatingSystemSKU = 1 OR OperatingSystemSKU = 28 OR OperatingSystemSKU = 71))

• Once you’ve configured the Server and distributed the Direct Access Group Policy objects to your target clients, use the Direct Access Troubleshooter utility (http://www.microsoft.com/en-au/download/details.aspx?id=41938), see picture below.  This tool is essential to rapidly determine where failures might be occurring in your configuration.  It is limited however in that it does not report on certificate failures (eg. FQDN to subject mis-matches, expired certificates etc.) and it is limited in reporting on errors related to DNS name lookups (of which I provide a bit more guidance below).

• Verify that the client can establish an IP-HTTPS tunnel to your Direct Access server – if it cannot, then the problem is most likely the certificate you’ve used in the Client section of your DA configuration, or access to the Direct Access FQDN you have published the DA service under.  If the tunnel has established correctly, then you should see connection objects appear in the Windows Firewall location (in both Main Mode and Quick Mode), see picture below.  If you cannot see any objects, then test the Direct Access FQDN using a web browser – standard testing behaviour is to see no SSL certificate errors and an HTTP ‘404’ error.

• It may be easier to get the solution working first with the ‘self-signed’ certificate option provided by Microsoft first (the certificate is actually copied to the client using the Direct Access Client GPO), then move the solution to a third party, customer owned certificate.  This will rule out certificate problems first.
• If the IP-HTTPS tunnel is established, and you see positive connection numbers appear for clients in the Direct Access console, but the clients still cannot reach internal services over their respectiveFQDNs, then the problem is most likely the DNS configuration of your solution.  The key to testing this is using the following commands:
  • Open a command prompt (cmd.exe) with administrator credentials
  • Type ‘nslookup‘
  • Type ‘server’, space and then the IPv6 address of the Direct Access server, for example ‘server <ipv6 address>‘.  This forces the session to use the server you have specified for all future queries you type
  • Type the FQDN of your local Active Directory e.g. ‘latte.internal‘.  You should successfully see a response coming back from NSLookup with an IPv6 address of a domain controller.  The IPv6 is the translated IPv4 address that the DNS64 service is providing to the DA client (and not an IPv6 address bound to the network card of the domain controller in case you’re confused).
• If you cannot get any positive response for the DNS service on the Direct Access server, check:
  • The IPv6 address of the Direct Access server (see picture below) should match the exact IPv6 address that is in the NRPT policy of the Direct Access client.

• To verify the IPv6 address is configured correctly on the Direct Access client in theNRPT policy, the following two methods can be used:
  • 1. On the Direct Access Client, open Powershell.exe with Administrator privileges and type ‘Get-DnsClientNrptPolicy‘:

• 2. On the Direct Access Client, open the Registry (Regedit.exe) and browse to the following registry location:

• Using Either method above, the IPv6 address in the NRPT policy listed HAS TO match the IPv6 address of your Direct Access server.  If these addresses do not match, then verify the Direct Access Client GPO settings have reached your clients successfully.  The major reason in assigning a static IP address in Azure to the DA server is so that the IPv6 address allocated by the Azure service remains the same, even if the DA server is shut down (and IP address de-allocated from the VM) from the Azure portal.  Alternatively, modify the NRPT registry directly above to match the IPv6 address used on the DA server (but only do this during the test phase).  It is best practice to ensure clients update their DA GPO settings regularly.  All changes to DA settings should be delivered by GPOs where possible.
• Finally, ensure that the Firewall service is enabled on your Direct Access clients for the ‘private profile’ (at least).  The firewall service is used to establish the Direct Access connection.  If the Firewall service is disabled on the Private Profile, then the solution will not establish a connection to the Direct Access service.  The firewall service can be disabled without issue on the domain or public profiles (however that is not generally recommended).

I hope this article has proved useful to you and your organisation in reviewing or implementing Direct Access on Azure.