Which three transition methods can DirectAccess use to establish a connection?
|
Inspired by the popular “Eat This, Not That!” weight loss and nutrition books, I’ve decided to share a few DirectAccess deployment tips using this familiar format. As a secure remote access solution, DirectAccess provides seamless and transparent, always-on remote corporate network connectivity for managed Windows clients. DirectAccess relies heavily on many common Microsoft platform technologies including Active Directory Domain Services (AD DS), Active Directory Certificate Services (AD CS), IPsec, IPv6, and more. DirectAccess also supports several different deployment scenarios to meet the needs of large and small organizations. With so many options and inter dependencies, it is easy to make poor design choices and end up implementing a solution that doesn’t work or isn’t supported. Show
So let’s consider a few important configurations and see what we should and shouldn’t be doing!  1. Do This! – Create a security group for DirectAccess clients. Don’t Do This! – Use ‘Enable DirectAccess for Mobile Computers Only’. Why? Because selecting the option to Enable DirectAccess for mobile computers only configures the DirectAccess client Active Directory (AD) Group Policy Object (GPO) to apply to all domain computers. It then relies on WMI filtering to identify the processor type as a mobile processor. This is less than ideal for a few reasons. First, it assumes that all of your DirectAccess clients will be using a mobile processor. Often this is not the case. In addition, the WMI filtering isn’t always 100% accurate, which leads to some clients not getting the proper configuration. Also, some features like multisite deployment require a security group. Creating one at the outset provides the flexibility to implement this important geographic redundancy feature without having to make additional changes. Finally, a dedicated security group for DirectAccess clients allows for the convenient application of additional client settings such as certificate auto enrollment, disabling of unused IPv6 transition protocols, etc. 2. Do This! – Deploy DirectAccess in a Perimeter/DMZ Network. Don’t Do This! – Configure DirectAccess with exclusive access to a Read-Only Domain Controller (RODC). Security best practices dictate that the DirectAccess server be deployed in a perimeter or DMZ network behind an edge-facing enterprise-class firewall. The DirectAccess server will be better protected there, but resist the temptation to deploy an RODC for it. Although this sounds intuitive, DirectAccess requires access to a full writable domain controller for proper operation. 3. Do This! – Plan for geographic redundancy. Don’t Do This! – Configure DirectAccess for multisite prior to production. So there you have it! Three quick do’s and don’ts to make your DirectAccess deployment go a little smoother. Celestix Networks offers professional services to assist you with the planning, design, configuration, and implementation of a DirectAccess solution. If you’re interested in having us help you with your project, drop a note to [email protected] for more details. Celestix SecureAccess is Microsoft DirectAccess on SteroidsMicrosoft DirectAccess is designed for managed Windows Enterprise Edition clients only. Celestix Edge solves this limitations by supporting for DirectAccess and secure connectivity on non-managed Windows computers or Mac computers and iOS devices (coming soon). Now, you can provide remote corporate network connectivity more securely and more cost effectively than Microsoft DirectAccess and traditional VPN. Click here to Request for A Demo. DirectAccess is promising to take remote access to a new level. Here's a look at what it offers and how it works. DirectAccess is promising to take remote access to a new level. Here’s a look at what it offers and how it works. DirectAccess is a new remote access technology that’s available with the combination of Windows Server 2008 R2 and Windows 7 Enterprise or Ultimate editions. DirectAccess promises to revolutionize the entire remote access experience so that employees can be productive from anywhere at any time, without the constraints of traditional remote access technologies, such as network-level VPNs, SSL VPN gateways, and reverse proxies. It provides a seamless experience for users and advanced management capabilities for IT. DirectAccess enables access from anywhere, even when the DirectAccess client system is behind a restrictive firewall. Note: This article is also available as a PDF download. 1: You can extend your corporate network to any Internet-connected clientThe goal of DirectAccess is to extend your corporate network’s reach to any DirectAccess client computer that’s connected to the Internet. A DirectAccess computer is a domain member, a managed computer that is subject to the same change management and control mechanisms as computers that never leave the physical boundaries of the corporate network. In addition to extending IT’s control over all managed computers, regardless of location, DirectAccess provides a seamless network access experience for users. They don’t have to remember one name for when they are on the corpnet and another name when they’re off the corpnet; that’s because they’re always on the corpnet. When a DirectAccess client computer starts, it establishes the “infrastructure” tunnel. This tunnel allows the DirectAccess client computer to connect to management and domain resources, such as domain controllers, DNS servers, and management servers. This tunnel is also bidirectional, so IT can initiate “manage out” connections to the DirectAccess clients on the Internet, in the same way they can when connecting to hosts on the intranet. After the user logs on, a second tunnel, called the “intranet tunnel,” enables users to connect to corporate resources in the same way an intranet host connects to those resources. They can use FQDNs or single label names to connect to file servers, Web servers, database servers, mail servers, or any other kind of server, and they never need to reconfigure their applications when they’re off the network. The DirectAccess user is always on the corporate network, regardless of location. 2: You’ll need to meet these DirectAccess requirementsYou must meet several requirements before starting a DirectAccess deployment. For starters, you need:
And you’ll need to meet these additional requirements:
3: IPv6 is the cornerstone of DirectAccess communicationsThe DirectAccess client always uses IPv6 to communicate with the DirectAccess server. The DirectAccess server will then forward these connections to IPv6-enabled hosts on the corpnet. The corpnet can use native IPv6 infrastructure (where the routers, switches, operating systems, and applications are all IPv6 capable) or it can use IPv6 transition technologies to connect to IPv6 resources on the corpnet. The DirectAccess server can use ISATAP (Intra-site Automatic Tunnel Addressing Protocol) to tunnel IPv6 packets inside IPv4 headers, which can then take advantage of your IPv4 routing infrastructure to move IPv6 packets throughout your network. DirectAccess clients connected to the IPv4 Internet can use a number of IPv6 transition technologies to connect to the DirectAccess server, including 6to4, Teredo, and IP-HTTPS. 4: IPSec secures communications from end to edge and end to endSince corpnet communications between the DirectAccess client and server are moving over a public Internet, it’s important that the communications be secured from interception and tampering. DirectAccess uses IPsec to secure the communications between the DirectAccess client and server. IPsec tunnel mode is used to establish both the infrastructure and intranet tunnels. In addition, you can configure DirectAccess to require end-to-end encryption between the DirectAccess client and destination server on the corpnet to use IPsec transport mode, so that the connection is encrypted from the client to its destination. DirectAccess also takes advantage of the new AuthIP feature that was initially introduced with Vista and Windows Server 2008, so that connections can be authenticated via user or computer credentials instead of just computer certificates. 5: Client applications must be IPv6 awareWhile the goal is to provide a computing experience that is the same as the corpnet-connected client, there is one major difference between the corpnet client and the DirectAccess client: The DirectAccess client must use and always uses IPv6 to connect to the DirectAccess server. That means that the client application on the DirectAccess client must be IPv6 aware. If the client application is not IPv6 aware (for example, the current OCS client), the connection will fail. This is true even if you use an IPv6 to IPv4 translator, which enables DirectAccess clients to connect to IPv4 servers on the corpnet. 6: Active Directory and Group Policy make it workA number of configuration changes are made to the DirectAccess server and DirectAccess client to make the solution work. To make these changes in the most efficient manner, the DirectAccess solution takes advantage of Active Directory and Active Directory Group Policy objects. The GPO is assigned to the DirectAccess server and DirectAccess clients. In addition, Active Directory is required for authentication. The infrastructure tunnel uses NTLMv2 authentication for the computer account connecting to the DirectAccess server, and that computer account must be part of an Active Directory domain. The intranet tunnel uses Kerberos authentication for the logged-on user to create the second tunnel. Although Active Directory and GPOs are required, the DirectAccess server does not need to be a member of the resource domain. As long as there is a two-way trust between the DirectAccess server domain and the resource domains/forests, the solution will work. 7: Network Location Servers let DirectAccess clients know when they’re on the corpnetDirectAccess is designed to work automatically and in the background. The user should never have to do anything to “turn on” the DirectAccess connection. All the user needs to do is turn on the computer. In fact, the user doesn’t even need to log on! Before the user logs on, the infrastructure tunnel is automatically established, and the DirectAccess client’s agents can connect to their management servers to obtain updates, desired configuration information, security configuration settings, and anything else that IT needs to do to make sure that the DirectAccess client remains in compliance with network configuration and security policies. To make this process transparent, there must be a mechanism where the DirectAccess client components know when to turn themselves off and on. This is where the Network Location Server comes in. The Network Location Server (NLS) is a Web server that allows incoming SSL connections. You can allow anonymous or integrated authentication to the NLS server. When the DirectAccess client connects to the NLS, it knows it’s on the corpnet, and it turns off the DirectAccess client components. If the DirectAccess client can’t contact the NLS server, it knows that it’s off the corpnet, and it automatically turns on the DirectAccess client components to establish the IPsec tunnels to the DirectAccess server over the Internet. The DirectAccess client does do a check on the Certificate Revocation List for the NLS Web server certificate, so the CRL must be available. Otherwise, the connection to the NLS SSL Web site will fail, and the intranet detection process will fail. 8: Certificates, certificates, certificates!Certificates are used in a number of places in the DirectAccess client/server solution. Places where you’ll see certificates include:
9: Name Resolution Policy Table provides policy-based DNS queriesThe DirectAccess client uses the Name Resolution Policy Table (NRPT) to determine which DNS server to use to resolve names. When the DirectAccess client is on the corpnet, the NRPT is turned off. When the DirectAccess client detects that it is on the Internet, the DirectAccess client turns on the NRPT and checks its entries to see which DNS server it should use to connect to a resource. You put your internal domain names and possible servers on the NRPT and configure it to use an internal DNS server to resolve names. When the DirectAccess client on the Internet needs to connect to a resource using a FQDN, it checks the NRPT. If the name is on it, the query is sent to an intranet DNS server. If the name is not on the NRPT, the DirectAccess client sends the query to the DNS server configured on its NIC, which is an Internet DNS server. The name of the NLS server is also placed on the NRPT, but it’s included as an exemption — meaning that the DirectAccess client should never use an intranet server to resolve the name of the NLS server. So the DirectAccess client on the Internet will never be able to resolve the name of the NLS server and thus will know that it is on the Internet and will turn on its DirectAccess client components. Even more important, when it connects to the corpnet over the DirectAccess connection, it doesn’t think that it’s connected to the corpnet by resolving the name of the NLS server. 10: DirectAccess enables “manage out” capabilitiesAs already mentioned, IT can take advantage of the “manage out” capabilities enabled by the infrastructure tunnel to connect to DirectAccess clients on the Internet. However, you will need to configure Firewall Rules in the Windows Firewall with Advanced Security (WFAS) to allow these connections for Teredo clients. When you create these rules, make sure that they have Edge Traversal turned on for the Firewall Rule. DirectAccess clients are Teredo clients when they are located behind a NAT device to connect to the Internet and the DirectAccess server, and the NAT device allows UDP port 3544 outbound. Check out 10 Things… the newsletterGet the key facts on a wide range of technologies, techniques, strategies, and skills with the help of the concise need-to-know lists featured in TechRepublic’s 10 Things newsletter, delivered every Friday. Automatically sign up today. Which communication protocol is used for DirectAccess?DirectAccess clients use only Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) to obtain IPv6 connectivity to the DirectAccess server over the IPv4 Internet. The only locations that a DirectAccess client can reach by default with IPv4 traffic are those on its local subnet.
What are the requirements for DirectAccess?Remote Access client requirements: DirectAccess clients must be domain members.. The DirectAccess server must be a domain member. ... . If the DirectAccess server is located behind an edge firewall or NAT device, the device must be configured to allow traffic to and from the DirectAccess server.. Which kind of connectivity does DirectAccess provide between client computers and network resources?DirectAccess allows remote connectivity to your corporate network without the need for a VPN. DirectAccess uses IPSec to create a secure connection between the client system and the corporate network.
What are the features of DirectAccess?The feature offers an alternative to traditional VPN access, which requires user action to connect. DirectAccess also allows administrators to manage remote machines through Group Policy settings and to distribute software updates whether or not the user is logged on to the network.
|
