I’ve seen a fair share of DirectAccess installations recently. Here are some quick questions to ask before you or your customer start getting into the technical titbits.
- Licensing: DirectAccess requires the Enterprise Edition of Windows on the Client side!
- Version:
- Client: DirectAccess works with Windows 7 and later, Windows 8.1 i preferred as the technology has evolved
- Server: DirectAccess works with Windows Server 2008R2 and later, but Windows 2012 is highly recommended as NAT64 and DNS64 have been included. </ul>
- IPv6: Yep, DirectAccess is an IPv6 technology. Make sure your applications support IPv6 and make sure applications always use DNS names to connect to the Servers. If the client is configured to connect to an IPv4 address directly, DirectAccess will not work.
- Windows Firewall: It’s sad but I do still see many organizations disabling Windows Firewall via Group Policy. Well in that case, not only are you putting your users at risk, DirectAccess will also not work. Windows Firewall must be enabled as DA uses Connection Security Rules.
- Dual NIC: The DircetAccess Server should be configured with to NICs, one for external/dmz connectivity and one for connectivity to the internal network.
- Static Routing: As you set the the default gateway to the external NIC, static routes will have to be created for internal networks. Make sure to use “New-NetRoute” as “route add” is no longer recommended.
- Firewall: DirectAccess requires tcp/443 to be allowed from the Internet to the external network adapter of the DA server.
- Public DNS: A name must be registered in the public DNS zone, clients will use this name to connect to the corporate network.
- Public Certificate: A certificate issued by a publicly trusted Certification Authority is highly recommended for the DirectAccess server’s public DNS name. The DA Client checks the Certificate Revocation List before connecting, so if you are using an internal CA, make sure the CRL is available without connectivity to the corporate network.
- No Schema or AD changes required: The only requirement for DirectAccess is a Windows Server 2012 (preferably 2012R2) member server. As long as you are on a 2003 or later domain level, you are good to go.
- Probe Host: Clients try to connect to a “Probe Host” do determine whether or not a DirectAccess connection should be attempted. This host should, obviously, only be accessible from inside the corporate network. The DirectAccess Wizard resolves name in the Probe Host certificate’s subject, if there is no DNS record, or the DNS record points to an incorrect IP address, the Wizard will fail. Also if the probe host fails, Clients will attempt DA connections even if they are connected to the corp. network, which may lead to problems.
- 2FA: DirectAccess can be configured for two-factor authentication. Force Tunnelling is not supported in that scenario.
- High Availability: Multiple DirectAccess Servers can be deployed for high availability. Windows Network Load Balancing can be used but I’d recommend you use an external Load Balancer.
- VPN: The Remote Access Server can be configured for VPN as well. </ul>
Phew. I don’t like bullet lists… Whatever, with those in mind you should be able to plan your remote access strategy :)
Tom