DirectAccess Consulting Services

Microsoft Certified Solutions Associate (MCSA)I’ve been helping organizations large and small deploy DirectAccess since it was first introduced more than six years ago. During that time I have amassed a wealth of knowledge and experience with this unique technology. DirectAccess is not trivial to install, configure, or troubleshoot. Also, it’s easy to make mistakes in the planning and design phase that can turn in to serious issues later in the deployment. To make matters worse, many organizations are deploying DirectAccess for the first time, and without essential guidance they are prone to making common mistakes or choosing configuration options that are less than optimal both in terms of supportability and performance.

Having deployed DirectAccess for some of the largest companies in the world, there isn’t much I haven’t already encountered. If you are looking for the best chance of success for your DirectAccess deployment, consider a consulting engagement with me. I can provide assistance with all facets of DirectAccess implementation including planning and design, installation, configuration, and troubleshooting. Consulting services at reasonable rates are available for all types of DirectAccess work including:

  • New DirectAccess installations
  • Migration from previous versions of DirectAccess
  • Upgrade or expansion of existing DirectAccess deployment
  • Enterprise planning and design for large-scale, multisite DirectAccess deployments
  • DirectAccess high availability (local and geographic)
  • One-time Password (OTP) integration
  • Manage-out for DirectAccess with external hardware load balancers and/or multisite configuration
  • Existing DirectAccess design review and security assessment
  • DirectAccess troubleshooting
  • DirectAccess training

All services can be performed on-site or remotely. Complete and submit the form below for more information.

Leave a comment

87 Comments

  1. I have advocated DirectAccess for the last 3 years at our company. We are mainly a Windows shop running Win7 and Server 2008 R2. Our director (of IT) is old school and doesn’t listen to many new ideas. Any thoughts on how to pull him into the 21st century?

    Reply
  2. Hi richard
    I wanna now how can I allow direct access clients in different remote location to contact each other
    The direct access clients in all remote location can successfully connected to the edge and DC server
    But not to each other

    Reply
    • If remote DirectAccess clients can connect to on-premises resources, then they should be able to communicate with other connected DirectAccess clients. If that’s not the case, I’d suggest looking closely at the firewall rules on your clients to ensure they are allowing whichever protocols and ports are required.

      Reply
      • Thanks for reply
        In DirectAccess server GPO
        I already configured firewall to allow ICMP v 4 and 6
        Also
        My DC and Edge can successfully ping and receive ping from DirectAccess Clients from different locations via internet however those clients can also successfully ping DC and Edge from remote location via internet via IPv6
        But when those clients trying to ping each other they failed but
        Without Request timed out
        But the pc can’t resolve this pc name
        Thanks

      • If you know the client’s IPv6 address you can try pinging that directly. However, you’ll definitely want to make sure that DNS name registration is working because remembering IPv6 addresses is prohibitively difficult. 🙂

  3. angelo

     /  January 9, 2016

    Hi Richard, why direct access clients are unable to communicate with system via IPv4.
    In my organization, we have a client soluzion (cyber ark outlook plug-in) installed client side and this plug-in contact the cyber ark vault server) calling his IPV4 IP(not use FQDN) so the communication faults.
    May you please, why the mechanism used by DA client ?
    and, if possible, is there a way to bypass this problem (from infrastructures side) not application side (cyber ark client side–> i should ask to vendor for release new version of client–> too long time)
    thank you very much
    Angelo

    Reply
    • Because DirectAccess is designed to use IPv6 exclusively. The majority of applications work, but some do not. There is no workaround. The application must be able to use host names in order to work over DirectAccess.

      Reply
  4. Hi Richard, I’m looking for some advice on DirectAccess and DPM backup for clients, I thought that DPM could resolve host names. Yet DPM client back up fail for me, do you have any experience in this area?

    Reply
    • Unfortunately, no. I’ve never had to configure DPM to work over DirectAccess. If you learn more though, please do share! 🙂

      Reply
  5. Hi Richard , hope everything going well , can i ask you are there any validation checks when client establish tunnel , what i know it did not do any validation check

    Reply
    • Yes. When the client connects it will attempt to connect to the web probe host URL. You’ll find this information in the output of Get-DAClientExperienceConfiguration under corporate resources.

      Reply
  6. Magali Sourbes

     /  January 25, 2016

    HI Richard, I successfully implemented a 1 server only DirectAccess solution but would now like to make it highly available by adding another server 2012 R2 to the config and utilize the built-in load-balancing. Will there be any downtime (except for when turning off the VM to enable mac address spoofing on the NIC)? I constantly have users connected, working off-site. Does the 2nd server inherit settings from the 1st one when joining the “cluster”?

    Thanks for your input and great site!

    Reply
    • You might experience a bit of downtime, but nothing that will seriously impact availability. And yes, when you add the second server to the cluster it will receive all settings from group policy. Just be sure to have the DirectAccess-VPN role and all certificates installed before joining to the array.

      Reply
  7. To help with the DPM question, we were able to successfully enable remote backup to DPM 2010 using the registry and firewall settings discussed in this link.

    https://social.technet.microsoft.com/forums/en-US/e2267282-5cae-4605-8792-c83e4d99f881/dpm-2010-over-directaccess

    Reply
  8. megatc101

     /  March 31, 2016

    Hi Richard

    I’ve got DA working perfectly, I have a configuration that uses multisite with three entry points. I now need to decommission one of the entry points. I’ve found the powershell commandlet remove-DAEntryPoint but not much else documentation on how to proceed.
    Do I simply run the command and delete the GPO?
    The reason why I’m concerned is because the entry point that I need to remove was the first entry point that was configured.

    Reply
    • You should be able to do this easily enough using the Remote Access Management console. No need to remove the servers first, just highlight the entry point you want to remove and click Remove Entry Point in the Tasks pane. With DirectAccess, there is no concept of primary/secondary, so removing any entry point, even the first one, should not be an issue.

      Reply
      • megatc101

         /  April 4, 2016

        Hi Richards

        Feel a bit foolish that I didn’t spot that. Thanks for the help and thanks for the really great resource.

      • megatc101

         /  April 4, 2016

        Hi Richard

        Thanks again for the response, I removed the entry point and all appeared to be well, until attempt was made to connect a laptop that was using the automatically selected entry point setting. got the following error “multisite settings aren’t available”. Found that my merging the following setting HKLM\SYSTEM\CurrentControlSet\Services\iphlpsvc\DAMultisite from a working laptop managed to re-establish a connection. If however, automatic selection is chosen again, the error returns.
        I plugged the laptop into the LAN, removed it from the DA group, ran gpupdate, which effectively removed DA. Rebooted and added it back, this did not fix the problem.
        The best guess is that we need to edit the client GPO to assign one of the entry points as default. I also believe that until this is sorted we are not going to be able to automatically configure any more DA clients. Any Ideas?

      • That’s certainly unusual. I would have to believe that somehow the existing GPOs aren’t being updated if they still contain stale entry point information. I’d verify that the information has been removed properly. Perhaps it’s a replication issue also?

      • Hi Richard,

        Running on Server 2016. I’m still working on a lab setup, running as VMs in a sandbox, and have come across what seems to be a related issue. What I am doing is building a DA server, then I enable multi-site, since doing so after deployment is disruptive to the users. Once multi-site is enabled (still with only one site defined), the client will connect for 20 or 30 seconds, then will completely lose the ip-https tunnel. It is gone, and is not showing in ipconfig. I also lose the multi-site options for DA in control panel. In those first few seconds of up time I exported the registry mentioned herein. Once it fails, replacing the hklm\system\currentcontrolset\services\iphlpsvc\damultisite registry entries with the exported copies brings back the multi-site choice in windows settings. Some jiggling of this site list in settings (specific site, auto, back to specific site), seems to be needed to get it to actually connect though. The only other recovery seems to be to reconnect to the internal net, then disconnect the internal, which fires up the DA connection again. If while those options still show, I change from “automatic” to the one defined site, then it does not fail out. Changing it to “automatic” will again however result in dropping it all in 20 or 30 seconds. Seems like their auto-selection routine may be a bit broken somehow? I’ve never had more than the one site, so there aren’t any remnants of an old entry it could have by accident.

        I’m doing this on clean lab machines, basically a bare OS load, with no added software, even tested without 3rd party AV, just Server 2016. Each test run while diagnosing, I went back to bare OS and full reinstall.

        I’d really like to preconfigure the multi-site setting, but at this point it seems like that might not be a viable option.

        Warren

      • That’s quite unusual. I suspect that something else must be broken. I’ve deployed DirectAccess multisite numerous times without issue using the exact same procedures you describe here. Not sure what’s different in your configuration, but something must be amiss. What that is I don’t know, unfortunately.

  9. Hi Richard,
    My organisation is attempting to get DirectAccess up and running, to support a small (initially), and then a large number of potenial clients. This will be run through a complex Gateway environment, and run on 2012R2 Servers, with Win7 clients initially, and later Win10 clients. It should be noted that we are an IPV4 network internally.
    My question relates to ISATAP. Noting that ISATAP is now unsupported by Microsoft, what would your recommendations be for future-state alternatives for “manage-out” capabilities for DA implementations, in an IPV4 internal network scenario? Enjoy your blog, BTW.

    Reply
    • Hi Michael,

      Glad you are enjoying the site. 🙂 Yes, Microsoft’s official position on outbound management is to deploy IPv6. Obviously that is the ideal situation. However, deploying IPv6 is not trivial, and there are myriad factors that have to be considered when deploying IPv6 on the intranet. It’s an excellent idea, of course, but often not something an organization wants to do just to enable outbound management for DirectAccess clients.

      As for ISATAP, although it is expressly unsupported by Microsoft, it is still fully functional and in my opinion a viable alternative to deploying IPv6. When properly deployed it can serve as an effective solution for outbound management, even in scenarios where the DirectAccess servers are configured with an external load balancer or in a multisite deployment. These scenarios require custom ISATAP configuration, but it works well.

      Reply
  10. simon harris

     /  June 6, 2016

    I have an issue with DA and Citrix XenApp – i can launch xenapp apps from the Web Interface but cannot launch then from a citrix-connector embedded form on an intranet page (i get the ICA file) but it just does not connect to the XenApp server. Telnet 1494 from DA Client shows no connectivity issues….. any ideas??

    Reply
    • Take a close look at the ICA file. If it returns an IPv4 address, it won’t work with DirectAccess. It must be configured to return an FQDN, which is a setting on the Citrix XenApp server.

      Reply
  11. Victor

     /  June 7, 2016

    Everytime I type in directaccess in google your name always seems to pop out 🙂
    I am currently doing an internship in a big firm that still uses VPN for mobile workers to
    access resources on it’s Intranet. One of the requirements for a successful Internship is the carrying out of a project and I have decided to do directaccess (hope it doesn’t come back to bite me ).
    I need help in building a testlab that would represent the firm’s current IT infrastructure.
    Currently the firm has a Citrix farm in place and a cisco ASA550 as Firewall and NAT.
    They also run their own PKI.
    What I have done so far: I have plemented my test lab based on TLGs from microsoft
    and it only seem to work with just simplified wizard. This is just too basic for me.
    I think I may have taken on a project too big for me but I intend to see it through.
    That is why I need some form of guidance or advice.
    The company won’t allow access to the firewall or Citrix farm. In other words, I am on my own. However, the Project will be implemented based on it’s functionability and how well it is presented. Thanks.

    Reply
  12. Victor

     /  June 16, 2016

    Thanks for the reply. I did check the videos and they were quite explanatory.
    I have began following the procedures with a little twist to my LAB. My challange is How do I introduce a real client computer into a virtual domain? My guess is when I bind the Host(Physical) Server’s network card with a virtual External Network Switch and then attach the client to a physical switch attched to the Host Server’s network card?
    Thanks for your time.

    Reply
    • Assuming your lab has real Internet access, you can use offline domain join as described here. Otherwise you’ll have to come up with some way to connect the physical device to your virtual network. For my labs I have a virtual network interface connected to a physical switch. If I need to connect a real computer I connect it to that switch.

      Reply
      • Victor

         /  July 7, 2016

        Thanks a lot Richard. I have never seen someone take so much time out to answer blog post. Kudos to you. I have everything up and running now but still have a question regarding manage-out. I have decided for a selective ISATAP environment. What I have done so far include setting up dns A record ( name-Isatap.domain.com), setting up a management pc (win8) and enabling ISATAP on the management pc via GPO. I also changed firewall setting on DA Clients. My question is would I ttill have to tweak some settings on the DA Server even after all these? And if I do have SCCM on board, would I still require to set up ISATAP? Thanks 🙂

      • Thanks for the kind words Victor. Much appreciated! 🙂

        As long as you have a single DirectAccess server, just configuring your management workstation to use it as its ISATAP router via group policy is all that’s required. If you have more than one DirectAccess server (load balanced, multisite, or a combination of both), additional configuration is required.

  13. Bryan

     /  September 19, 2016

    Hi Richard!

    Thanks for your generous DirectAccess resources! I’ve had a single-server DirectAccess configuration working well in testing for some months now.

    We’ve reached a point where we need to create a few exclusions in our DirectAccess configuration, and I may be interested in engaging you depending on how complex you think the answer may be to my question. We have recently re-configured our Cisco phone system to be published via Cisco’s Expressway gateway product, so that clients can be connected to voice (SIP), presence, and voicemail services when offsite. It’s working properly for Windows clients NOT using DirectAccess, but for my clients testing DirectAccess it’s (as I expected) not connecting properly. Because the DirectAccess tunnel allows clients to successfully resolve DNS queries for internal resources, the Cisco client software thinks it’s on-network and does not try to contact the gateway to establish connections.

    All my googling has returned almost no information about how to exclude specific FQDNs from using the DirectAccess tunnel. I see nothing in the server-side GUI, so I assume it may require PowerShell on the server. Can you shed some light, or let me know if I need to contact you privately for a more thorough discussion about how to engage you?

    Thanks!

    Bryan

    Reply
    • If you were having trouble finding information about configuring NRPT exemptions, perhaps that’s a good idea for a blog post. 🙂 It’s easy enough to configure. Reach out to me directly via email and I’ll provide some guidance. FYI, it can be done in the GUI if you prefer that over PowerShell.

      Reply
  14. Matt

     /  September 20, 2016

    Hi, Been using your blog ever since implementing DA last year. Find it very difficult to get any support for it though. I have one issue at the moment. Some machines I have using DirectAccess often use the sleep power option. Ive found that when users connect again after coming out of sleep mode DNS can fail. Its only when I flush DNS that it will resolve this? Also, for example if a user still has Lotus Notes client open when coming out of sleep it will not be able to ping the Notes server until we flush DNS. Any suggestions on this?

    Reply
    • Hi Matt. Hope you are finding the site informative and useful. 🙂 The issue you describe can be related to IPsec tunnel establishment timing and the client attempting to make name resolution requests before the DirectAccess tunnels are fully established. I’d suggest disabling negative DNS caching on one DirectAccess client to see if it resolves the issue. You can disable negative DNS caching by running the following PowerShell command:

      New-ItemProperty -Path “HKLM:\System\CurrentControlSet\Services\Dnscache\Parameters” -Name MaxNegativeCacheTtl -PropertyType DWORD -Value “0”

      Let me know if that helps!

      Reply
  15. Serghei

     /  September 29, 2016

    Hi Richard,

    Thank you for your great web site. We have single DirectAccess 2012 server implemented several years ago with Windows 2003R2 only Active Directory Servers. We don’t have any issues now but we are in process of upgrading AD servers to the version Windows 2012R2. We are going to demote our old 2003 R2 AD servers but when I checked the DirectAccess Server Settings group policy I found our old domain controllers under Computer Configuration > Polices > Administrative Templates > Extra Registry Settings : Software\Policies\Microsoft\Windows\RemoteAccess\Config\ManagementServerInfo H=DC1.domain.local;T=D;A=aaaa:bbbb:d7b5:7777::c0a8:301,2002:bbbb:1:0:5efe:192.168.3.1
    (IPv6 addresses were changed)

    At the DirectAccess server we don’t have any servers in Remote Access Management Console > Configuration > Infrastructure Servers (Step3) > Management

    How to update this settings with new AD controllers? Will we have any problems if we demote our old AD controllers? I tried to find any info in Internet but without any success.

    Thank you

    Reply
    • After you’ve made the changes to your infrastructure servers, open the Remote Access Management console, highlight DirectAccess and VPN, and then click “Refresh Management Servers” in the Tasks pane. Alternatively you can simply run the Update-DAMgmtServer PowerShell command on the DirectAccess server. This will bring the management and infrastructure servers list up to date in the DirectAccess GPOs. 🙂

      Reply
  16. Vishal

     /  October 11, 2016

    Hi Richard,

    First of all thanks for so much of valuable information around DA.
    We are trying to setup a DA with high availability in Azure and as per your article we can use 3rd party LB for NLB.

    Can you please let me know what 3rd party LB is available in Azure as per your article. I can’t locate one.

    Cheers,
    Vishal

    Reply
    • All of the popular load balancers such as F5, Citrix NetScaler, and KEMP LoadMaster are available in Azure. You can find them in the Azure marketplace. You’ll need to use the new management portal to find them, however.

      Reply
  17. Ajeesh

     /  November 22, 2016

    Hi Richard, Is it recommended to configure DA and NLS in Different VLANS under a L3 switch were inter-vlan routing is enable. Will it create any issues in DA functionality. Your ASAP revert will help me

    Reply
    • The DirectAccess Network Location Server (NLS) can be located anywhere on your internal network. However, if you are enabling load balancing for DirectAccess, the DirectAccess servers themselves must be on the same subnet.

      Reply
  18. Andrew

     /  December 2, 2016

    Richard,
    We are having the same issue as Matt above and we have tried your recommendation – disable negative DNS caching but it did not fix our issue. We have the same issue as Matt but flushing the DNS does not fix the issue. Users have to reboot in order to appear as inside the network. Running the diagnostics shows clients as outside the network, all DA servers are available if you ping the IP address and if you use NSLOOKUP it resolves the names but not thru ping. Any other suggestions to troubleshoot?

    Thanks in advance for your help!

    Andrew

    Reply
    • This might be a driver issue. Make sure your drivers are up to date and see if that helps. If it doesn’t, you’ll probably have to open a support case with Microsoft. I’ve heard of this happening with other customers in the past (not mine) so you probably won’t be the first person calling in with this issue. Hopefully they have a private hotfix they can give you. 🙂

      Reply
  19. Marcel

     /  January 25, 2017

    I’ve setup a new 2016 Server with DirectAccess as Edge deployment with IPv4/IPv6 Internet and IPv4/IPv6 Intranet.
    When the clients are connecting via IPv4 (6to4, teredo, IPHTTPS) everything is working fine.

    But when clients are connecting by native IPv6 and try to use IPv4-only ressources, the connection might fail.
    I tracked this down to MTU issues and misleaded ICMPv6 “Paket too Big” messages, but I currently have no idea how to fix this.

    The Setup:

    DA Server external Interface: xx.xx.xx.10
    xx.xx.xx.11
    2001:DB8:C1:DA::DA(/64)
    2001:DB8:C1:DA::DB(/64)

    DA Server internal Interface: 10.20.30.40
    2001:DB8:C1:DB::DA(/64)

    Internal Network: 2001:DB8:C1:100::/56
    NAT64 Prefix: FDC6:55FD:D741:7777::/96

    When a client now tries to connect to a IPv4 ressource, the communication will work as long as the pakets are not getting too big.
    If so, the DA server drops the paket and generates a ICMPv6 PTB messages. This should notify the sender of the too big paket about the maximum MTU to use.
    The Problem is: the DA server sends the paket through the wrong interface.
    PTB Message does exit the external interface as ICMPv6 with a destination IP FDC6:55FD:D741:7777::/96 where it should be converted by NAT64 to an ICMPv4 message and sent through the internal interface to an IPv4 destination address.

    “ping -6 fdc6:55fd:d741:7777::a60:430a” for example does not work from the DA Server, while “ping -6 fdc6:55fd:d741:7777::a60:430a -S 2001:DB8:C1:DB::DA” does work on the DA Server.

    It looks like some strange source selection/routing issue but I dont get the clue.
    Do you have any idea in which direction I should research further?

    regards,

    Marcel

    Reply
    • Hi Marcel,

      Unfortunately, there are a number of issues with DirectAccess that arise when you have IPv6 deployed natively. I’m aware of potential routing issues, specifically when a DirectAccess client connects with an IPv6 address and doesn’t use a transition technology. The only way I’m aware of to resolve this issue now is to configure the DirectAccess server as the internal network’s default gateway. Obviously that’s less than ideal. There may be a better way to address this, but I’m not aware of one at the moment. As for MTU issues, that’s odd as well. DirectAccess deployments with native IPv6 are quite uncommon in my experience so I don’t have a lot to offer in terms of advice. You may want to open a support case with Microsoft on this though because it sounds like a possible bug.

      Reply
      • Marcel

         /  January 30, 2017

        Hi Richard,

        Unfortunatly we need to use native IPv6 as some ISPs of our users are using DS-Lite. Some of those DS-Lite can’t reach the DA Server 6to4 IPv6 DTE for some reasons, others have problems with carrier-grade NAT and IP-HTTPS. So just disabling IPv6 on client LAN/WiFi adapter won’t help.
        I’ll deal with the routing issues later (got an idea how this could work) as currently we don’t have any native IPv6 hosts the users will need to use by DA.
        I’ve already opened a case with MS but as we don’t have a premier contract yet (working on it) they refused to analyze the cause and suggested to permanently lower MTU für IPv6 on client side. This has been rejected by my supervisors for several reason so MS is currently no real help.
        I suspect some changes to the network stack with server 2016 so maybe they introduced a new bug with 2016. I’ll “downgrade” my lab to 2012 R2 for testing purposes.

        Anyway, I’ve read your book “Implementing DirectAccess with Server 2016” and got a correction and some comments regarding native IPv6 you might find interesting.

      • The IPv6 addendum in my DirectAccess book is based on my somewhat limited experience with DirectAccess and native IPv6 deployments. I wanted to include something on the topic, however. I’ve since had more exposure to this scenario and I admit that I learn something new every time. I look forward to hearing your feedback too.

  20. BenPetz

     /  March 20, 2017

    Hi Richard, quick question: we have the DA implementation running quite well over a Netscaler. Everything is stable. The only thing we have noticed is, if a client goes quick in standby or the connection is disrupted for a shorttime and comes back the DA tunnel won´t be restored Client OS is Win10 (1511) is telling “Action needed” and says “turn on Windows firewall” although it shows the firewall is turned on. Only a reboot of the client does resolve the issue. Normal behaivour (regarding token) or bug? Couldn´t find an answer in your really great book.

    Best Regards

    Ben

    Reply
  21. marwan

     /  April 13, 2017

    Hi
    I am working at a small company of 6 people.
    The problem:
    We have a customer, he has 10sites in different cities.
    Each site has between 5 to30 computers
    Each site has win server 2012 R2 installed
    The first two sites has win 10 clients.
    The other sites has win 8 home edition and they do not want to pay for upgrade.
    At the moment we use teamviewer to give support to the 10 sites .
    Is it possible to use Direct Access to give them support.
    Usually permission issues or installing new printer and share it , creating new shared folders.

    Note: I need my supporting team to work remotely.

    Reply
    • That would depend entirely on how you provide support. If you plan to use DirectAccess yourself to access their network, it probably won’t provide much value over and above what TeamViewer is providing. However, if you want the customer’s machines to be better managed by having consistent connectivity to the corporate network, then DirectAccess will provide some value to you.

      Reply
      • marwan

         /  April 16, 2017

        Thanks a lot for your reply
        I am planning to use direct access to access their network (servers and Pcs).

      • marwan

         /  April 16, 2017

        Colud you please advice me what to use for accessing their network and keep giving them support?

      • It depends on a lot of things, but using a client-based VPN is probably the easiest way to accomplish what you want. Most firewalls support VPN, or you could easily stand up a Windows server and install RRAS. I just don’t recommend installing RRAS/VPN on the DirectAccess server if you deploy one.

  22. Bryan Linton

     /  April 17, 2017

    Hi Richard,
    I recently submitted a question to you via a different web form, when what was looking for all along was this page, which I finally found again today. So please pardon if this is a duplicate question for you.

    We run a single-server DirectAccess solution, thanks to your blog and your generosity of a quick phone call with me, quite a few months ago. It’s working well, hosted on Server 2012 R2. Most DA clients are Windows 8.1 with a couple running Windows 10 Enterprise. So they should all be using IP-HTTPS with null encryption.

    I recall from our implementation that if I were to install the RRAS role on this server to terminate client VPN connections, support for the null cipher suite would be removed and DirectAccess performance would suffer. Fortunately, I don’t need my DA server to terminate VPN connections – we have another VPN solution to fall back on when needed. However, I DO need to set up a RADIUS server. I’d like to begin using RADIUS for our corporate Wi-Fi, but I’d prefer not to spin up a totally new server to do this, so I’m considering adding the Network Policy Server role to my DirectAccess box.

    My DirectAccess server is located within our data center, and my access points are obviously located within my three branch offices. This means the Network Policy Server authenticating wireless clients would not be on the same broadcast domain as all the Wi-Fi APs; some RADIUS authentication requests would have be routed across a direct WAN link, others routed through a site-to-site VPN tunnel between two ASAs, to reach the RADIUS server.

    Is there anything about my DirectAccess configuration that would be affected if I were to add the NPS role to the DirectAccess server?

    Thanks!
    Bryan

    Reply
    • Hi Bryan,

      I don’t believe that installing the NPS role on the DirectAccess server would have any adverse affects. However, this is not something I have tested. Generally speaking it is not recommended to install other roles on the DirectAccess server, but for small implementations it might be unavoidable. Let me know how it goes!

      Reply
  23. Chris S.

     /  May 10, 2017

    Hi Richard,

    First, thank you for all you do here. Your information has helped me get over a few hurdles in the past.

    My question is regarding accurately tracking DA users who use shared computers in a configuration which includes a forward proxy using cached credentials. We do not have the resources available to authenticate every HTTP request from a browser against AD. The problem arises wherein a user logs off of a shared machine and another logs in. Due to the DA server only serving addresses from 2 NICs (as opposed to an assigned IP pool) we will sometimes see the previous user’s AD credentials authenticating for web traffic until the timeout is reached on the proxy cache.

    This problem makes our ability to identify user traffic questionable, and may result in legal issues for us in a scenario in which disciplinary action is taken against a user for their browsing activity (we can’t absolutely be sure someone else didn’t log on to the same machine which was still using their cached credentials and then do naughty things).

    Is there any way around this? As I said, we don’t currently have the capability of authenticating all traffic line-by-line, and have to rely on the proxy caching credentials.

    Reply
    • I’m not aware of any effective workaround for this issue outside of using some sort of client-side authentication agent perhaps. This really is a limitation imposed by the fundamental design of DirectAccess, whereby all traffic is translated at the DirectAccess server. Here is where either remote filtering agents or cloud-based security solutions such as Zscaler are a more effective way to enforce browsing protections, with the added benefit of not having to backhaul all of your user’s Internet traffic over the DirectAccess connection. 🙂

      Reply
  24. Aziz

     /  July 4, 2017

    Hi Richard,

    In the following article, it says that Direct Access is not Supported in Azure Microsoft server software support for Microsoft Azure virtual machines
    (Last Review: 26 May 2017)
    https://support.microsoft.com/en-gb/help/2721672/microsoft-server-software-support-for-microsoft-azu

    Technically this can be done ( from your blog)
    https://directaccess.richardhicks.com/2016/09/19/deploying-directaccess-in-microsoft-azure/

    Question
    :::::::::::::::

    What alternative solutions are available if this is not supported by Microsoft?
    Can Azure VPN Gateway be an alternative Solution?
    https://azure.microsoft.com/en-us/services/vpn-gateway/

    Thanks.

    Reply
    • Hi Aziz. So yes, DirectAccess is not formally supported in Azure. It does work though and I have a number of customers who are running DirectAccess in Azure and also in AWS. If you are willing to forego the supportability, it can be an excellent solution. Azure does provide supported remote access alternatives though. The Azure VPN gateway supports site-to-site (client-based) VPN which might address your remote access needs.

      Reply
  25. Ben

     /  November 21, 2017

    Hello
    I’m sorry I did not put it in the right place
    I’m doing a side-by-side migration (Forefront UAG SP1 DirectAccess to Direct Access 2012 R2)
    my Forefront UAG SP1 DirectAccess server is a physical machine
    the server Direct Access 2012 R2 is a virtual machine under Hyper-v
    the client computers are under windows 7, 8,10
    I have a firewall (sonicwall NSA 6600)

    my question is, how to create an external address( external IP) on the new virtual server .in LAN .without going through a NAT?
    I thought I read that if there are client computers under Windows 7 you have to avoid doing NAT or you have another solution to offer me
    thank you very much for your return

    Reply
    • Hi Ben. Beginning with Windows Server 2012, it is no longer required to use public IPv4 addresses on the DirectAccess server’s external interface. In this scenario you can configure the public IPv4 address on your existing edge security device and create an ACL and NAT rule to forward TCP port 443 to the DirectAccess server. All clients are supported in this configuration, including Windows 7. However, performance will suffer a bit for Windows 7 clients because they don’t support null encryption for IP-HTTPS connections. More details here: https://directaccess.richardhicks.com/2013/03/19/directaccess-and-nat/

      Reply
      • BEN

         /  November 21, 2017

        Hi Richard,
        thank you very much for your responsiveness, but, I realize that I did not give you all the information, sorry …
        the Forefront UAG SP1 DirectAccess server has two consecutive IPV4 external address, it must absolutely remain active during the migration (computers will migrate little by little) .the servers will be removed at the end of the migration.

        The Direct Access 2012 R2 server must respond to one or more external IPV6 addresses.
        for the problem of performance, while waiting to acquire a F5 BIG-IP, that they are the characteristics that you advise me for the server Direct Access 2012 (memories, processors …)

        there are around three hundred computers direct access (90% in seven)
        for information I have the opportunity to do load balancing (several servers direct Access) we have a KEMP

        in advance thank you for your answer and your advice

      • I think you can safely put 300 DirectAccess clients, even if all of them are Windows 7, on one DirectAccess server without too much of a performance hit. Where Windows 7 clients really cause problems are when you get to that 1000-1500 per server range. That’s where you really start to see resource utilization issues. Personally, I would implement your new parallel DirectAccess deployment behind a NAT and migrate your clients over in phases. You can monitor resource utilization on your server as you migrate and if it turns out to be an issue, simply add more resources (more CPUs/memory or additional servers).

  26. Hi Richard, I’m seeing an issue with a multi-site DA implementation where the time zone on client computers is updating depending on the site connected i.e. Aus Central Std Time, or NZ time. Have you seen this before? Perhaps we should turn off location services? While not directly related to DA, it is happening in a new DA implementation. Suggestions welcome.

    Reply
    • I’ve had a few people report this same issue. In Windows 10 there is an option to set the time zone automatically. It doesn’t appear to be enabled by default, but perhaps it is configured manually by the user to via group policy? You can try disabling that to see if that resolve the issue.

      Reply
  1. DirectAccess and Surface Pro for the Enterprise | Richard Hicks' DirectAccess Blog
  2. DirectAccess and Windows 10 Better Together | Richard Hicks' DirectAccess Blog
  3. Enterprise Nirvana with Surface Pro 4, Windows 10, and DirectAccess | Richard Hicks' DirectAccess Blog
  4. 3 Important Things You Need to Know about Windows 10 and DirectAccess | Richard Hicks' DirectAccess Blog
  5. Windows 10 November Update Available Today | Richard Hicks' DirectAccess Blog
  6. DirectAccess and Windows 10 Professional | Richard Hicks' DirectAccess Blog
  7. DirectAccess vs. VPN | Richard Hicks' DirectAccess Blog
  8. DirectAccess and Windows 10 in Action | Richard Hicks' DirectAccess Blog
  9. DirectAccess and Windows 10 in Education | Richard Hicks' DirectAccess Blog
  10. Deploying DirectAccess in Microsoft Azure | Richard Hicks' DirectAccess Blog
  11. DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016 | Richard Hicks' DirectAccess Blog
  12. DirectAccess and Azure Multifactor Authentication | Richard M. Hicks Consulting, Inc.
  13. Troubleshooting DirectAccess IP-HTTPS Error 0x80090326 | Richard M. Hicks Consulting, Inc.
  14. DirectAccess Troubleshooting with Nmap | Richard M. Hicks Consulting, Inc.
  15. DirectAccess Network Connectivity Assistant Missing in Windows 10 | Richard M. Hicks Consulting, Inc.
  16. DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016 | Richard M. Hicks Consulting, Inc.

Leave a Reply to megatc101Cancel reply