DirectAccess FAQ

So you’ve heard a bit about DirectAccess but want to know more. In this posting I’m including a FAQ of the most common questions I field every week with new customers looking at the DirectAccess Technology. This is by no means an all-encompassing list of FAQ so please leave any additional questions down below in the comments section and I’ll be sure to update the list in the future!

Are there any special schema extension required for DirectAccess?
Nope, you just need to have a Windows 2012 member server to get started with DirectAccess!

What are the minimum AD requirements?
You need to ensure you are at minimum running a supported version of Windows AD. At this time, this means you just need a minimum of Windows 2003 running on your domain controllers.

Do I need to have IPv6 running in my environment/ISP?
Nope, there is no IPv6 requirement on your existing network or ISP connection to get started with DirectAccess.

What’s this IPv6 requirement I keep hearing about for DirectAccess?
You just need to ensure that it’s enabled (but not configured) on the DirectAccess server and DirectAccess clients. Make sure the IPv6 checkbox is enabled on your DirectAccess server & DirectAccess client :

IPv6 NIC Check Box

IPv6 NIC Check Box

Also ensure you don’t have the DisabledComponents key set on any of your DirectAccess Clients & Servers otherwise it can cause issues :

http://support.microsoft.com/kb/929852

What versions of Windows are supported with DirectAccess?
We support Windows 7 Enterprise & Ultimate Edition, Windows 8 Enterprise, Windows 2008 R2, and Windows 2012 as a DirectAccess client.

What are the client-side requirements for DirectAccess?
Your DirectAccess clients must be domain-joined, have the DirectAccess Client GPO, have IPv6 enabled, and must be running the Windows Firewall on the public and private profiles. If you are running Windows 7 or a mixed Windows 7 & 8 DirectAccess deployment, then you also need to have workstation certificates installed on all your DirectAccess clients.

How do you configure the DirectAccess settings for a client?
The DirectAccess client settings are pushed to clients using group policies. There’s no agent or special software to install to get supported clients all setup and working with DirectAccess. As a matter of fact, you can potentially push the GPO settings silently so users can take their machines home and use DirectAccess without even rebooting!

What type of Internet Access does DirectAccess require?
Nothing special! We at a minimum need to reach TCP/443 to the DirectAccess servers in the infrastructure. Being a field based employee, I’ve used DirectAccess on a wide variety of Internet connections ranging from dial-up, 3G wireless, 4G LTE, Cable, DSL, Starbucks Wi-Fi, Airport Wi-Fi, even Satellite Internet on plane moving at 500 mph (804 kph for all you outside of the US).

How many DirectAccess clients can connect per DirectAccess server?
It really depends more on the sustained network I/O on the DA server rather than the number of clients connecting. The higher the sustained network I/O, the more strain on memory and especially CPU cycles to encrypt/decrypt the IPsec data for the DA Server. A lot will have to do with the activity of your users. If their users are just doing lightweight activities over the DirectAccess connection, you can handle a large number of users per DirectAccess server. If the users have a fast low-latency Internet connection and are pulling in large amounts of sustained data across DirectAccess, they will use significantly more resources on the DirectAccess servers. You can use our published capacity planning information here to start with building a baseline :

http://technet.microsoft.com/en-us/library/jj735301.aspx

Even better, a DirectAccess pilot will give you better real world numbers for your environment.

What can I do to enable high availability with DirectAccess?
Setting up more than one DirectAccess server is a good start. We offer two different ways to have high availability for DirectAccess. First would be to setup an array of DirectAccess servers using a load balancer. We natively support Network Load Balancing (NLB) that’s built into Windows otherwise you can use an External Load Balancer (ELB). We aren’t picky on the brand of the ELB as long as it can pass at a minimum TCP/443 to the DirectAccess servers.

Secondly you can setup multi-site with DirectAccess. This allows you to have DirectAccess servers in multiple data centers for geographic redundancy. Please note this is only officially supported with Windows 8 DirectAccess clients. Windows 7 DirectAccess clients do not have the ability to load more than one connection point at a time in their group policy settings.

Can you limit access for DirectAccess computers?
Yes, there are a couple possible ways to limit access for a specific set of machines. You could use the Windows firewall to natively block access to specific end resources. Secondly you could also manipulate the Name Resolution Policy Table (NRPT) on DirectAccess clients to only allow them to resolve specific internal resources while connected to DirectAccess.

How do I monitor my DirectAccess clients?
The Remote Access console provides a list of currently connected clients, the username of the logged on user, and exactly what internal IP addresses and ports the computer is accessing at any given time. You can also enable historical logging to query historical connection information for auditing purposes as well.

How is my data protected across the Internet?
The DirectAccess clients negotiate AES-192 bit IPsec encryption by default between the DirectAccess server and the DirectAccess client to ensure all your data is protected and secured during transit. This is configurable to different methods but might require more CPU cycles on both the client and the server.

What happens if my DirectAccess computer gets stolen/compromised?
All that is required is to disable the AD computer account of the DirectAccess computer and this will prevent any further connections to the DirectAccess server.

Is the connection active even if nobody is logged in the DirectAccess client?
Yes, there is a limited tunnel that allows the computer account itself to contact the domain controllers and any other internal systems you desire. This means when the user logs on the DirectAccess client, they logon against live domain controllers, process logon scripts, update group policies just as if the user had their computer connected at work.

Can I manage a DirectAccess client from my internal network?
It’s possible to manage-out to a DirectAccess client from your internal network. This does involve either configuring ISATAP settings on your internal computer or using native IPv6 routing but isn’t all that difficult to setup with any type of DirectAccess deployment.

Tags: , , , , , , , , , , , , , , , , , , , , , , ,

Categories: FAQ

29 Comments on “DirectAccess FAQ”

  1. August 20, 2013 at 14:06 #

    Any idea when RemoteAssist will be supported over DA?

    • August 20, 2013 at 14:42 #

      Hi RichardP,

      I did a little bit of digging into Remote Assist (RA) and found there is an issue with the listener for RA when using unique local IPv6 addresses. Currently RA will only listen on the link local (FE80::/64) or global IPv6 addresses (starting with a “2” or “3”). I’m making the assumption your DA clients are using IP-HTTPS to connect to the DA server which will by default hand out an IPv6 address in the unique local range (FD00::/8). Unfortunately when this happens, RA does not listen on this IPv6 address located on the DA Client.

      As a workaround, you can change the IPv6 prefix handed out to your IP-HTTPS DA clients to something that starts with a “2” or “3” so RA will start listening on your clients. You can run the following PowerShell command on the DA Server to view the current DA Client IPv6 Prefix (good for your reference) :

      Get-DAServer | ft ClientIPv6Prefix

      If you want to try changing the Prefix, you can use the following PowerShell command on the DA Server :

      Set-DAServer -ClientIPv6Prefix

      If I hear anything more about RA supporting unique local IPv6 prefixes, I’ll be sure to reply back.

    • January 14, 2014 at 20:45 #

      Hi RichardP,

      You will be happy to know that we now have a public hotfix for Remote Assist in Windows 7 to properly work with DirectAccess. Please have a look at :

      http://support.microsoft.com/kb/2912883

  2. Bocko
    September 12, 2013 at 14:24 #

    Is there a way to disable DA if the network latency is too high? Maybe don’t try to connect if round trip is over 100ms. I’m having issues with users traveling in Europe. DA connects and the laptops become almost unusable.

    • September 16, 2013 at 19:48 #

      Hi Bocko,

      There’s nothing built-in Windows to disable DirectAccess on specific types on Internet connections. With my travels, I’ve used DirectAccess on a variety of Internet connection from fiber to high latency satellite connections (1000+ ms) without issues. What kind of problems are you noticing on your laptops when they try to connect with DirectAccess?

  3. Stephen Brown
    November 6, 2013 at 06:45 #

    I’m looking at an HA option that will support Windows 7. I understand that this would be NLB. Would I be able to run NLB with a shared subnet and VLAN for the cluster addressing side (DMZ) and geographically diverse (but routable) subnets for the internal network using a dual NIC setup, subject to support for static MAC mappings with my provider?

    • November 6, 2013 at 14:32 #

      Hi Stephen,

      Thanks for reading! You have two high availability options for a DirectAccess cluster which include using the built-in OS Network Load Balancing (NLB) or using an external load balancer. With either load balancing technology, the NICs on the DirectAccess server will have to be on the same subnet in order to work properly. This includes both the external and internal NICs in a two-NIC design.

      If your servers will be in different physical sites, you might look at doing multi-site DirectAccess arrays instead :

      http://technet.microsoft.com/en-us/library/hh831664.aspx

      Be aware that we only support multi-site with Windows 8 or above clients currently.

      • Stephen Brown
        January 10, 2014 at 05:46 #

        Hi,

        Thanks for that information. We now have a POC operating on a single server for now. It is looking likely we will run NLB on one site with a second entry point at another site for our Win8 clients as this develops, so will be referring to this and other materials.

        I have another issue I’m now trying to work out. We want to enable a highly secure firewall policy on our clients to allow DA connectivity to work like Domain based policy, but otherwise to limit communications to permit ability to connect to DA only. Is there a list of required rules in this scenario anywhere for reference that I can use?

      • January 10, 2014 at 09:23 #

        Hi Stephen,

        Are you trying to limit access for the DA client for the public firewall profile? By default the public firewall profile that should load for your DirectAccess clients while outside of your corporate network and is fairly locked down by default. This profile will block most incoming ports for the client.

      • Stephen Brown
        January 10, 2014 at 09:52 #

        We are using forced tunnel mode, so perhaps we’ve already secured this, but I’m trying to cover for every eventuality.

        For inbound I want to ensure that connectivity is limited to connections from DA origin (I’m guessing altering existing settings to limit to the IPv6 addresses in use by DA would accomplish this). We want to be able to connect to a DA client as if they were inside (via the IPv6 tunnel). Unless I’m missing something, this seems to me that I will need to enable Firewall rules on the Public / Private profiles.

        The Outbound policy, which by default is open, is my real issue here. The idea is to prevent my userbase connecting to their local NAS devices etc when working from home, for example.

        I know that forced tunnel should stop all that, but if the internet connection is down on the public network this might expose that risk. I don’t want to leave it to chance that it would be secure, I want to be certain!

        I’m going to test the basic policies from home tonight, to see if I can breach them….

  4. Stephen Brown
    January 15, 2014 at 06:47 #

    Following up on this, I’ve identified that if I configure IPv6 rules for our DA connectivity against Private and Public profiles, I can then connect to DA with outbound connections blocked, which then allows me to prevent access to devices not within our corporate environment – I cannot connect to my NAS at home, and therefore cannot transfer data outside of our corporate environment whether connected to DA or not.

    This then leaves me with a problem on how to allow the Windows 7 client to determine when it is connected to the Domain – this now does not work unless I permit all outbound connections on private and public profiles.

    Any clues?

    • January 16, 2014 at 22:36 #

      When you are connected to DirectAccess, the public or private firewall profile will still be loaded and used for firewall rules (both inbound and outbound).

      Your DirectAccess client will attempt to reach the NLS location to determine if it’s inside or outside of your corporate network. If the NLS location is reachable, then the NRPT table will not load on the DA client and it should automatically detect the domain controllers are reachable and load the “work” firewall policy. Are you not finding this behavior with your Windows 7 DA client?

      • Stephen Brown
        January 17, 2014 at 01:56 #

        When the outbound defaults are retained on private and public, connecting to the corporate network internally works. When set to block, it doesn’t. It appears that the firewall falls back to public / private whilst determining whether connected to the internal corporate network, so a default block is preventing the client confirming domain connectivity.

        I’ve opened a support case for this as it appears some simple rule changes on those profiles should fix the issue, but haven’t.

      • January 21, 2014 at 15:55 #

        When you plug a modern (Vista+) Windows machine into a network, it does a DNS lookup of the forest root domain and tries to make a LDAP call to the forest root PDCE. You might need to allow this outbound traffic in your firewall rules so that NLA can properly determine the domain profile. Check out the following KB for more information on this process :

        http://support.microsoft.com/default.aspx?scid=kb;EN-US;980873

  5. Stephen Brown
    January 17, 2014 at 01:58 #

    I should have also said that DA performs fine so long as I specify a rule with the IPv6 address subnet used by DA in it for Outbound on the Public and Private profiles.

  6. Mick
    January 21, 2014 at 15:13 #

    Hi
    i cannot find anywhere if MAC OSX is supported for DA 2012. If it is, is it through the VPN needing the PKI? There is not much infomation on setups around for NON microsoft OS machines…. any help would be great
    cheers

    • January 21, 2014 at 15:40 #

      Hi Mick,

      Most non-Microsoft Operating Systems don’t have the network & security stack from their vendors to support the required security components for DirectAccess. It’s worth asking your OS vendor to see if they natively support the required network and security stack for DirectAccess.

      With that being said, I have run across a third-party who advertises their product can add the required security components to some other non-Microsoft Operating systems. You might see if this product from Centrify meets your needs :

      http://www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp

      Hope this helps!

      • Mick
        January 21, 2014 at 18:43 #

        thank you!

  7. Fred
    March 7, 2014 at 05:08 #

    Hi

    I have a question about memory configuration for a virtual machine with direct access fonctionnality

    Is it a good idea or not to configure dynamic memory for the virtual machine with this value
    Ram for Boot 2048 Mo
    Minimum Ram 512 Mo
    Maximum Ram 4094

    Regards

    Fred

    • March 7, 2014 at 13:12 #

      Hi Fred,

      I would not recommend using dynamic CPU or memory resources for a VM running the DirectAccess server. For a small install I would recommend a minimum of 4GB of RAM and scale up if you start adding lots of DirectAccess clients. The dynamic nature of CPU and memory adds latency for the DirectAccess process that can lead to network timeouts and very poor performance for your DirectAccess clients.

      It’s also quite important to make sure you’ve added the appropriate CPU resources on the DirectAccess server. This is the main resource that gets used as more and more DirectAccess clients connect. If you are running VMs for the DirectAccess servers, I would recommend mapping a 1 to 1 Virtual CPU to Physical CPU to get the best CPU performance possible.

      • Fred
        March 9, 2014 at 10:20 #

        Hi
        Ok
        Thanks for your answer

  8. March 26, 2014 at 03:18 #

    Hi! We plan to use DA with Windows 7 clients. We built a scenarion with WPAD proxy configuration. However, there exists software out there using IP-Addresses instead name resolution (telnet based software). So the software can use the internet without wpad-proxy config and with no smart filter rules. We do not want to activate force tunneling because of teredo. Is it possible to configure the Windows Firewall to only accept traffic to the DirectAccess endpoint for all traffic after the tunnel is established?

    Thanks. Dietmar

    • March 27, 2014 at 18:15 #

      Hi Dietmar,

      You can control the Windows Firewall rules via GPO but they cannot be triggered by the DirectAccess connection itself since DirectAccess doesn’t change the state of the Windows Firewall. This is due to the fact that the Windows Firewall loads it’s profile based on the Internet connection type (Public or Private), not the DirectAccess connection.

      Another option you can try is to create an internal DNS entry for the software and point this to the Internet IP. Then add an entry in the NRPT for the newly created DNS name and you can even specify a specific proxy server to use in the NRPT settings. This might accomplish the task.

      • March 27, 2014 at 23:09 #

        Hi! Thanks for answer. We will try.

  9. kleinem
    July 9, 2014 at 07:19 #

    Hi,

    thanks for the great overview on DirectAccess.

    I was wondering if there is some WMI Event or Trigger whenever the DA Connection comes up or down on the Client.

    Regards,
    kleinem

    • July 9, 2014 at 18:09 #

      Hi Kleinem,

      You can look for event ID 4981 in the security log which will indicate that DirectAccess tunnels are being established under the user context :

      http://support.microsoft.com/kb/977519

      What post connection task are you looking to run on the DirectAccess client?

      Regards,

      Tom

      • kleinem
        July 9, 2014 at 23:12 #

        Hi Tom,

        i’m not really sure what the Client Workstation Team is planning, but i think it will be mounting shares and such.
        Oh and it appears they are using appsense, not WMI but the security event is still a good hook.

        Regards,
        kleinem

  10. August 29, 2014 at 08:23 #

    Hi,

    I have been seeing an issue with our DirectAccess clients where we get the status “Action needed: the firewall must be on” even though the public and private firewall profiles are set to on in GPO. Has anyone else seen this happen? I didn’t see this during original testing but the firewalls were manually configured at that point. Thanks!

  11. mattmcnabb
    August 29, 2014 at 08:25 #

    Hi, I have begun seeing issues on some of our Windows 8.1 Enterprise clients where DirectAccess states ‘Action needed: firewall must be turned on’ even though the public and private profiles are indeed on.

    Has anyone else seen this issue? Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: