In a very specific DirectAccess deployment scenario it is possible that users may be prompted repeatedly for One-Time Password (OTP) credentials. Specifically this may occur when you have Windows 7 clients accessing a Forefront UAG 2010 DirectAccess server with two-factor authentication enabled with OTP, along with forced tunneling required and the client configured to use a corporate web proxy server. The root cause of the issue has to do with Network Connectivity Status Indicator (NCSI) probes and security permissions on the private key of the certificate used for OTP authentication. To resolve the issue will require creating a custom certificate template for use with two-factor authentication and setting key permissions for the NETWORK SERVICE on the certificate template. You can also workaround this issue by disabling forced tunneling or disabling the 6to4 and Teredo adapters, which will stop the NCSI probes from occurring. For more detailed information read Microsoft KB article 2797301.
Posted by Richard M. Hicks on March 26, 2013
One of the more common barriers to adoption for DirectAccess in Windows Server 2008 R2 and Forefront Unified Access Gateway (UAG) 2010 is the strict requirement for two consecutive public IPv4 addresses to be assigned to the external network interface of the DirectAccess server. Many small and mid-sized businesses have only a single public IPv4 address, or have a very small range of public IPv4 addresses that are already in use. For large organizations, corporate security policies often dictate that Windows-based systems cannot be internet facing, and many object to having a domain-joined Windows system exposed directly to the Internet. Further complicating matters is the fact that deploying a Window Server 2008 R2 or Forefront UAG 2010 DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is explicitly not supported.
Beginning with Windows Server 2012, deploying the DirectAccess server behind a border router or edge firewall performing NAT is now fully supported. No longer is there a requirement to have public IPv4 addresses assigned to the DirectAccess server’s external network interface. In fact, DirectAccess in Windows Server 2012 can be deployed with a single network adapter, allowing the DirectAccess server to be completely isolated in a perimeter or DMZ network.
Be advised that deploying a Windows Server 2012 DirectAccess server behind a NAT device will result in all DirectAccess client communication being delivered to the server exclusively using the IP-HTTPS IPv6 transition protocol. If you are using Windows 8 clients, there’s nothing to worry about in terms of performance and scalability because Windows 8 clients leverage NULL encryption for IP-HTTPS traffic. However, Windows 7 clients cannot utilize NULL encryption and will instead encrypt all DirectAccess client communication using SSL/TLS. DirectAccess communication is already encrypted using IPsec, so this presents a problem. Double encryption places high demands on the DirectAccess server’s CPU and memory and will significantly impact performance on the client and the server. It will also impede the scalability of the solution by dramatically reducing the number of DirectAccess clients supported on a single DirectAccess server.
So, if you’re planning to deploy a Windows Server 2012 DirectAccess server behind a NAT, and you are also planning to support a lot of Windows 7 clients, please proceed cautiously. Monitor the DirectAccess server performance closely during your pilot and, if at all possible, offload SSL/TLS off box using F5 BIG-IP Local Traffic Manager (LTM) or equivalent device.
Posted by Richard M. Hicks on March 19, 2013
I’m pleased to announce that my Windows Server 2012 DirectAccess video training course is now available from TrainSignal! The course covers planning, installing, and configuring DirectAccess in Windows Server 2012 in a variety of different deployment scenarios. Here’s the course outline:
Lesson 1 – Introduction
Lesson 2 – DirectAccess Overview
Lesson 3 – Planning for DirectAccess
Lesson 4 – Configuring DirectAccess (Simplified Deployment)
Lesson 5 – Configuring DirectAccess (Complex Deployment)
Lesson 6 – Configuring DirectAccess (Multi-site Deployment)
Lesson 7 – Enabling Support for Windows 7 DirectAccess Clients
Lesson 8 – Enabling High Availability with Network Load Balancing
Lesson 9 – DirectAccess Monitoring and Reporting
Lesson 10 – DirectAccess Troubleshooting
Lesson 11 – Enabling Legacy Remote Access VPN
Special thanks goes to my friend and fellow MVP Jordan Krause who served as the technical reviewer for this series and provided valuable input and feedback during the production of the course. Before you implement DirectAccess with Windows Server 2012, be sure to sign up for a subscription at Trainsignal.com and not only will you receive this great DirectAccess training course, you’ll have access to the entire TrainSignal library of content for just $49.00 per month!
Posted by Richard M. Hicks on March 11, 2013
I’ve been frustrated recently with a number of articles and blog posts I’ve seen indicating Windows 8 DirectAccess clients connecting to a Windows Server 2012 DirectAccess server require a Trusted Platform Module (TPM) and the use of smart cards for authentication. This is a myth, and nothing could be further from the truth. TPM and smart cards are indeed supported (TPM with Windows 8, smart cards with Windows 7 and Windows 8 DirectAccess clients) but they are not explicitly required. For the posts I’ve seen I have asked the authors to correct their statements, and to their credit some of them have. Others, unfortunately, have not. I’m not sure if they are simply misinformed or if they are deliberately misleading their readers to downplay DirectAccess in an effort to sell another VPN solution. Regardless, I am compelled to set the record straight here. So, to be perfectly clear:
TPM is NOT a requirement for DirectAccess clients.
There you have it. Now go out and deploy DirectAccess today!
Posted by Richard M. Hicks on March 8, 2013