DirectAccess can be configured to enforce strong user authentication using smart cards or one-time passwords (OTP). This provides the highest level of assurance for remote users connecting to the internal network via DirectAccess. OTP solutions are commonly used because they require less administration and are more cost effective than typical smart card implementations. Most OTP solutions will integrate with DirectAccess as long as they support Remote Access Dial-In User Service (RADIUS).
Azure Multifactor Authentication (MFA) is a popular OTP provider used to enable strong user authentication for a variety of platforms, including web sites and client-based VPN. Unfortunately, it doesn’t work with DirectAccess. This is because Azure MFA uses a challenge/response method for which DirectAccess does not support. To use OTP with DirectAccess, the user must be able to enter their PIN and OTP immediately when prompted. There is no provision to begin the authentication process and wait for a response from the OTP provider.
PointSharp ID Multifactor Authentication
An excellent alternative to Azure MFA is PointSharp ID. PointSharp is a powerful OTP platform that integrates easily with DirectAccess. It is also very flexible, allowing for more complex authentication schemes for those workloads that support it, such as Exchange and Skype for Business.
You can download a fully-functional trial version of PointSharp ID here (registration required). The PointSharp ID and DirectAccess integration guide with detailed step-by-step instructions for configuring DirectAccess and PointSharp ID can be downloaded here. Consulting services are also available to assist with integrating PointSharp ID with DirectAccess, VPN, Exchange, Skype for Business, Remote Desktop Services, or any other solution that requires strong user authentication. More information about consulting services can be found here.
PointSharp Multifactor Authentication
Configure DirectAccess with OTP Authentication
DirectAccess Consulting Services
Implementing DirectAccess with Windows Server 2016
Posted by Richard M. Hicks on March 27, 2017
For DirectAccess manage out deployments using ISATAP, you may encounter a scenario in which you are unable to initiate outbound connections to connected DirectAccess clients from a Windows 10 computer. Outbound connections using ISATAP from Windows 7, Windows 8, Windows Server 2008/R2, or Windows Server 2012/R2 systems work without issue.
As it turns out, there is a bug in the Windows 10 DNS client code that prevents manage out using ISATAP from a Windows 10 client from working correctly. Thanks to the diligent effort of DirectAccess administrators Mike Piron and Jason Kuhns, a workaround has been identified. To deploy the workaround, it will be necessary to implement registry changes to alter the default behavior of the DNS resolver in Windows 10. You can implement these changes on a Windows 10 DirectAccess manage out machine by using the following PowerShell commands:
New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableParallelAandAAAA -PropertyType dword -Value 1 -Force
New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableServerUnreachability -PropertyType dword -Value 1 –Force
Once these registry changes have been made, you should now be able to use ISATAP for DirectAccess manage out connections from a Windows 10 machine.
Posted by Richard M. Hicks on November 10, 2015
For DirectAccess deployments where domain controllers are running Windows Server 2003 or Windows Server 2003 R2 using the File Replication Service (FRS) for replication, DirectAccess client and server settings Group Policy Objects (GPOs) may be deleted. If these GPOs are deleted, DirectAccess connectivity will be disrupted. If the GPOs cannot be recovered via backup, it will be necessary to rebuild the entire DirectAccess deployment from scratch.
Microsoft recently updated their DirectAccess Unsupported Configurations documentation to reflect new guidance for DirectAccess deployments where the FRS is used for the distribution of Active Directory GPOs. DirectAccess is no longer supported in environments where FRS is used for SYSVOL replication.
What this means is that if you plan to deploy DirectAccess, domain controllers must be running Windows Server 2008 or later, and Distributed File System Replication (DFS-R) must be used for replication.
More details can be found here.
Posted by Richard M. Hicks on July 27, 2015
One of the many advantages DirectAccess has over traditional client-based VPN is the ease with which DirectAccess clients can be provisioned. DirectAccess does not require any special software to be installed on the client. Everything that DirectAccess needs is included as part of the operating system. This makes onboarding a client for DirectAccess is as simple as adding a computer account to the DirectAccess client security group in Active Directory. That’s it! As soon as the client restarts it will be configured for DirectAccess.
This process works great if the client computer is already joined to the domain and has access to the LAN (either directly connected or via client-based VPN). But what if the client is in a remote location and isn’t yet joined to the domain? Offline Domain Join (ODJ) can help. ODJ is a feature of the Windows operating system introduced with Windows 7 and Windows Server 2008 R2 that allows an administrator to join a host to the domain without requiring the host to contact a domain controller. Beginning with Windows 8 and Server 2012, ODJ supports new command-line parameters that allow the administrator to configure the client machine to include DirectAccess certificates and policies.
Note: ODJ will only provision DirectAccess certificates and policies for Windows 8.x and later clients. ODJ with Windows 7 clients is limited to joining the domain only. ODJ cannot provision Windows 7 clients for DirectAccess.
To use ODJ to provision a DirectAccess client, first create a computer account in Active Directory and then add the account to the DirectAccess client security group. Next, open an elevated Command Prompt window on the DirectAccess server and execute the following command.
djoin.exe /provision /machine <client_machine_name>
/domain <domain_name> /policynames
/savefile <filename> /reuse
djoin.exe /provision /machine client5
/policynames "DirectAccess Client Settings"
/savefile c:\users\rhicks\desktop\provision.txt /reuse
On the DirectAccess client, copy the ODJ provisioning file locally. Open an elevated Command Prompt window and execute the following command.
djoin.exe /requestodj /loadfile <filename>
/windowspath <Windows_directory> /localos
djoin.exe /requestodj /loadfile c:\users\setup\provision.txt
/windowspath C:\Windows /localos
After a restart, the client will be joined to the domain and now be able to establish a DirectAccess connection to the corporate network. Users can now log on with their domain credentials.
Posted by Richard M. Hicks on June 22, 2015
Recently a new and very serious vulnerability in the SSL 3.0 protocol has been discovered that allows an attacker to recover sensitive information for an encrypted session. As DirectAccess uses SSL and TLS as part of the IP-HTTPS IPv6 transition protocol, I’ve had many customers ask me about mitigating this vulnerability on a DirectAccess server.
Figure 1 – Qualys SSL Labs Server Test Score for DirectAccess IP-HTTPS
However, is mitigating the POODLE attack on a DirectAccess server really necessary? Recall that, as I’ve discussed previously, the IP-HTTPS IPv6 transition protocol is only used to tunnel IPv6 traffic from the DirectAccess client to the DirectAccess server over the public IPv4 Internet. This traffic is already encrypted with IPsec, so there’s really nothing an attacker would gain by leveraging the POODLE attack on a DirectAccess session.
The recommended mitigation for the POODLE attack is to disable the use of SSL 3.0 on servers and clients. If you have deployed DirectAccess by itself, there’s no need to implement this mitigation as there is no real risk associated with this attack in this specific scenario. However, there are no negative side effects for doing so, and if you wish to disable SSL 3.0 just to avoid future audit findings, I see no problem with that.
If your DirectAccess server is also configured to support client-based VPN and you’ve enabled the Secure Sockets Tunneling Protocol (SSTP) then mitigating the POODLE attack is an excellent idea. SSTP also uses SSL and TLS, so this session could be hijacked by an attacker and sensitive information might be disclosed.
To disable SSL 3.0 on the DirectAccess server, execute the following commands from an elevated PowerShell window.
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" -Force
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" -PropertyType dword -Value 0 -Name Enabled
A restart of the server is required for the changes to take effect. To audit your DirectAccess server’s SSL and TLS configuration, visit the Qualys SSL Labs server test site. For more information about the POODLE SSL 3.0 vulnerability, click here.
Posted by Richard M. Hicks on October 21, 2014
Microsoft recently released a hotfix to resolve an issue where Windows 7 SP1 DirectAccess clients fail to connect to a DirectAccess server with the IP-HTTPS IPv6 transition protocol and using One-Time Password (OTP) authentication via the DirectAccess Connectivity Assistant (DCA) 2.0. In this scenario you may receive an HTTP 403 error from the DirectAccess server in response to the certificate signing requests and a 0x80040001 error after entering the OTP.
You can learn more about the hotfix for DCA 2.0 on Windows 7 SP1 and download the associated hotfix here.
Posted by Richard M. Hicks on May 9, 2014
When troubleshooting name resolution issues on a Windows client, NSlookup is an essential tool. However, it is important to understand that using NSlookup on a DirectAccess client might not always work as you expect. Although using NSlookup on a DirectAccess client will work normally when the client is on the corporate network, it will not provide the correct results to queries for internal hostnames when the DirectAccess client is outside of the corporate network without taking additional steps. This is because when a DirectAccess client is outside the corporate network, the Name Resolution Policy Table (NRPT) is enabled. The NRPT provides policy-based name resolution routing for DirectAccess clients, sending name resolution requests for certain namespaces to specific DNS servers. You can view the NRPT on a Windows 8.x DirectAccess client by issuing the following PowerShell command:
You can view the NRPT on a Windows 7 DirectAccess client by issuing the following netsh command:
netsh namespace show policy
Here you’ll notice that the namespace .lab.richardhicks.net is configured to use the DNS64 service running on the DirectAccess server at 2002:62bd:d898:3333::1. Notice also that the host nls.lab.richardhicks.net is not configured to use a DNS server. This effectively exempts this host from the NRPT, forcing name resolution requests for this Fully-Qualified Domain Name (FQDN) to be delivered to the DNS servers configured on the network adapter.
A Working Example
With the NRPT enabled, which occurs whenever the DirectAccess client is outside of the corporate network, a name resolution request for app1.lab.richardhicks.net would be sent to the DNS64 service on the DirectAccess server. A name resolution request for technet.microsoft.com would be sent to the DNS servers assigned to the network adapter because the NRPT contains no entry for this namespace. And even though the host nls.lab.richardhicks.net is a part of the internal namespace, a name resolution request for this host would also be sent to the DNS servers assigned to the network adapter because it has been specifically exempted from the NRPT.
The NSlookup utility is unaware of the NRPT. Whenever you use NSlookup it will, by default, automatically send queries directly to the DNS servers configured on the network adapter, regardless of the NRPT. If you wish to use NSlookup to test name resolution for external hostnames, use it as you normally would. However, if you wish to use NSlookup to resolve internal hostnames over the DirectAccess connection, you will need to tell NSlookup to use the DNS64 service running on the DirectAccess server. You can do this by running NSlookup interactively and using the server command to point it to the IPv6 address of the DNS64 service, which you can find in the NRPT.
This also applies to the PowerShell cmdlet Resolve-DNSname. Here you’ll use the -Server switch to specify the DNS64 server’s IPv6 address.
Resolve-DNSName –Server <DNS64_IPv6_Address> app1.lab.richardhicks.net
Posted by Richard M. Hicks on January 13, 2014
Microsoft recently released security advisory 2862152 to address a vulnerability in IPsec that could allow DirectAccess security feature bypass. The associated update addresses an issue with how the DirectAccess client authenticates with a DirectAccess server. Without the update, it is possible for an attacker to launch a man-in-the-middle attack to intercept DirectAccess communication.
The update itself does not resolve the issue directly, however. The update simply allows administrators to configure DirectAccess clients using specific registry settings to enforce more stringent checks during IPsec negotiation after the update is installed. The challenge with this update is that the documentation contained within the knowledge base article is extremely detailed and includes information that pertains to many different remote access scenarios, not just DirectAccess. This has led to much confusion, and many administrators are unclear for which clients and deployment scenarios the registry changes are required.
For DirectAccess deployments, the update needs to be applied to all of your DirectAccess clients. The update does NOT need to be applied to the DirectAccess server. The registry settings required on the client will be dictated based on the configured authentication method for your DirectAccess deployment. If you have configured DirectAccess to use certificate-based authentication by checking selecting the Use computer certificates option as shown below, you’ll only need to make registry settings changes on your Windows 7 clients. Windows 8/8.1 clients DO NOT require any changes be made to the registry when DirectAccess is configured to use certificate-based authentication.
If you are NOT using computer certificates for authentication, then you must make registry changes to all of your Windows 8/8.1 clients. For detailed, prescriptive guidance on implementing the client-side registry changes required to support this update and mitigate this vulnerability, Jason Jones has done a wonderful job documenting those steps specifically, so I’ll refer you to his post here.
You can find the update for KB2862152 for all supported clients here.
Posted by Richard M. Hicks on December 2, 2013