Additional Deployment Options and Considerations

The topics discussed in this section are intended as an introduction and primer to new technical concepts. Do not perform any of these steps as they are listed in this section at this time. Actual implementation will come during installation, which is covered in the Appendices.

Force Tunneling

By default, remote DirectAccess clients are able to access the Internet, the intranet, and their local subnet simultaneously. DirectAccess clients are configured to send all intranet name query requests to their intranet DNS servers, and unrecognized or exemption name query requests to their ISP’s DNS servers. This is the default and recommended operating mode of DirectAccess.

To force all of your intranet and Internet traffic to flow through the DirectAccess connection, you can use Force Tunneling. You can enable Force Tunneling with the following Group Policy setting on the Group Policy object for your DirectAccess clients:

Computer Configuration\Administrative Templates\Network\Network Connections\Route all traffic through the internal network

When Force Tunneling is enabled, all traffic from the DirectAccess client must be IPv6 traffic and will be routed to the intranet over an IP-HTTPS tunnel. Force Tunneling-enabled clients will still be able to access any resources on their local subnet, such as network printers, but any network traffic beyond the local subnet must be IPv6 traffic.

To reach resources on the IPv4 Internet when Force Tunneling is enabled, use an IPv6-capable Web proxy server. Alternately, you can use NAT-PT device on your intranet and route the resulting IPv4 Internet traffic to your IPv4-based Web proxy servers. To reach these resources for IPv4 Internet traffic, you must configure the following additional NRPT rule in the DirectAccess Setup Wizard:

• Name suffix set to “.”

• DNS server IPv4 or IPv6 addresses set to the IPv6-capable proxy server or NAT-PT

Note

Due to the infrastructure requirements and reduced performance for accessing IPv4 Internet resources, Microsoft does not recommend the use of Force Tunneling for DirectAccess.

Managing DirectAccess clients remotely

With DirectAccess, IT staff has the ability to remotely administer DirectAccess client computers. This might include pushing out security updates, retrieving hardware and software inventory reports, installing application updates, or even helping a user perform a complex task with Remote Desktop. Since DirectAccess client communications use IPv6 exclusively, any application an administrator uses to connect to a remote DirectAccess client must be IPv6-enabled.

Additionally, when an administrator uses an application that connects to a DirectAccess client using Teredo as the transition technology for sending IPv6 traffic over the IPv4 Internet, a firewall rule for that application with the Edge Traversal flag enabled needs to be configured on the client computer. You can set this flag in the following ways:

• Use the Windows Firewall with Advanced Security snap-in (within the Group Policy object). Obtain properties of an inbound rule, click the Advanced tab, and then select Allow edge traversal in Edge traversal.

• Use the edge=yes option for the netsh advfirewall firewall command when adding or changing an inbound rule.

For a computer that is being managed to be reachable over Teredo, ensure that the computer has an inbound ICMPv6 Echo request allow rule with edge traversal enabled. The Netsh.exe command for this rule is the following:

netsh advfirewall firewall add rule name="Inbound ICMPv6 Echo request with Edge traversal" protocol=icmpv6:128,any dir=in action=allow edge=yes profile=public,private

Here is an example of how a Remote Desktop rule with edge traversal can be enabled using a Netsh.exe command:

netsh advfirewall firewall add rule name=”remote desktop” profile=public,private dir=in program=system action=allow protocol=tcp localport=3389 edge=yes remoteip=<Corp v6 range>

To further ensure that the remote desktop connection is authenticated and encrypted, add the following rule, which uses the security keyword

netsh advfirewall firewall add rule name=”remote desktop” profile=public,private dir=in program=system action=allow protocol=tcp localport=3389 security=authenc edge=yes remoteip=<Corp v6 range>

To use this setting, you need to ensure that there is a transport mode IPsec policy that secures the connection between the management server and the client.

Note

If the computer that is managing a DirectAccess client from the intranet is running Windows Vista or Windows Server 2008 and IPsec transport mode is required between the managing computer and the DirectAccess client, both computers must have the same quick mode lifetimes.

Publicly available names

If your DirectAccess policies are configured using server names instead of IP addresses, the Teredo server, 6to4 Relay, and IP-HTTPS server names must all be resolvable from the public Internet namespace. These servers may all be physically located on the same server, in which case only a single name needs to be made available. If these server names are not resolvable from outside your organization, DirectAccess users will not be able to connect from the Intranet.

As an alternative, DirectAccess policies can be configured using IP addresses for the Teredo server, 6to4 Relay, and IP-HTTPS server, in which case these server names do not need to be publicly resolvable.

Note

By default, the DirectAccess Setup Wizard configures the 6to4 relay and the Teredo server with an IPv4 address and the IP-HTTPS server with an FQDN.

Connections between DirectAccess clients

Depending on the application being used, DirectAccess clients can communicate directly with other DirectAccess clients, even when outside of the intranet. Applications that allow clients to connect directly from one to another are broadly referred to as Peer-to-Peer (P2P) applications.

Many P2P applications provide their own built in security, such as Groove or Office Communicator. Some applications do not provide any additional security. Remote Assistance, Remote Desktop, and File and Printer Sharing are in this category. By leveraging IPsec, DirectAccess allows these applications to communicate securely even when they lack their own security mechanisms.

To secure connectivity for specific applications:

• Create an IPsec transport mode rule and associated firewall rules for each application you wish to secure using the following general policy guidelines: Transport mode, RequestinRequestout, Non-Corp v6 <=> Non-Corp v6 , Auth = Computer certificate, Profile=public, private

• Create Windows firewall rules for each application. For example, for Remote Desktop, the Windows Firewall rule would look like the following: Profile= Public, Private; Program = c:\windows\system32\mstsc.exe; Allow if secure + encryption; Inbound; TCP 3389

To configure the IPsec rule using Netsh.exe, you can use the following format:

netsh advfirewall consec add rule endpoint1=<Non-Corp v6> endpoint2=<Non-Corp v6> action=requestinrequestout profile=public,private auth1=computercert auth1ca=<CA Name>

To configure the Windows Firewall rule using Netsh.exe, you can use the following format:

netsh advfirewall firewall add rule name=”remote desktop” profile=public,private program=system action=allow security=authenc protocol=tcp localport=3389

Finally, additional security can be configured to prevent communication between DirectAccess clients unless the traffic is secured. This is accomplished by modifying the action on the connection security rule for action=requireinrequestout, which will result in the host dropping any connections from IPv6 hosts that are not encrypted.

Outgoing connections to other DirectAccess clients will be secured regardless of the application. Outgoing connections to Internet and non-DirectAccess clients will result in successful unprotected communication.

Handling a high volume of authentications

To increase the number of concurrent authentication calls in progress at one time between the DirectAccess server and the domain controller, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\ MaxConcurrentApi (REG_DWORD) registry value to 5, and then restart the NETLOGON service.

Using smart cards with DirectAccess

If you do not specify management servers, there are two IPsec tunnel mode rules in a default DirectAccess configuration as configured by the DirectAccess Setup Wizard:

• The first tunnel is from the DirectAccess client to the DirectAccess server to support access to the IPv6 addresses of DNS servers and AD DS domain controllers.

  This tunnel uses Computer certificate credentials for the first authentication and User (NTLMv2) for the second authentication. User (NTLMv2) credentials are used to force the use of AuthIP and because the DirectAccess client needs DNS and domain controller access before it can use Kerberos credentials for the second tunnel.

• The second tunnel is from the client to the DirectAccess server to support access to the IPv6 address space of the intranet.

  This tunnel uses Computer certificate credentials for the first authentication and User (Kerberos V5) for the second authentication.

Additionally, IPsec tunnel mode settings can be used to require smart card-based authorization for remote users by the DirectAccess server. This IPsec tunnel authorization can be used specifically to require smart cards for remote DirectAccess connectivity. IPsec authorization is an extended setting on IPsec tunnels that enforces authorization for specific computer or user security groups by enforcing the existence of a specific Kerberos-related security identifier (SID) that is generated when a user logs on with a smart card.

IPsec authorization for requiring smart cards should only be configured on the tunnel that is used to provide access to the intranet (the second tunnel previously described), not on the tunnels that are used for DNS and domain controller or management server access. DirectAccess clients require access to the core domain infrastructure to validate their credentials, including their smart card credentials. These credentials are then used to gain access to the rest of the intranet using the second IPsec tunnel.

To use smart cards with IPsec tunnel mode authorization, you must first have a PKI deployment and client smart card infrastructure. See the following resources for information on deploying smart cards:

• Public Key Infrastructure for Windows Server 2003

• Deploying smart cards

• Administer smart cards

After the PKI and smart card infrastructure is in place, you add global IPsec tunnel mode authorization settings to the Group Policy object for the DirectAccess server, specifying the authorization identifier for smart card logons.

The way smart card enforcement works with IPsec authorization is that IPsec can be configured to look for specific Kerberos-based SIDs in a client’s Kerberos token. IPsec is configured to enforce Kerberos-based user authentication and is also configured to look for specific authorized users. For smart card enforcement, the authorized user is actually a well-known SID (S-1-5-65-1) that maps to smart card-based logons. This SID is referred to as “This Organization Certificate” when it is configured in the global tunnel mode authorization settings.

When smart card authorization is enforced at the edge by using an IPsec authorization policy and a user logs in without a smart card, a message displays in the notification area. The following figure shows an example:

 

 

Users can click this message and provide their smart cards and PINs to gain access to intranet resources.

You can require users of DirectAccess client computers to provide their smart card credentials before allowing access to intranet resources by selecting the Require smart card login for users check box on the Connectivity page of Step 2 of the DirectAccess Setup Wizard. The following figure shows an example:

 

 

The following figure shows an example of the global IPsec tunnel mode authorization setting when you select the Require smart card login for users check box in the DirectAccess Setup Wizard.

 

 

To view this dialog box in the Windows Firewall with Advanced Security snap-in, do the following:

1. Right-click Windows Firewall with Advanced Security, and then click Properties.

2. On the IP Settings tab, in IPsec tunnel authorization, click Customize.

3. Click the Users tab.

To perform the equivalent configuration of the DirectAccess Setup Wizard with the Netsh.exe tool, use the following commands:

netsh advfirewall consec add rule name=”Smart card tunnel” endpoint1=Intranet IPv6 address space endpoint2=Any localtunnelendpoint=DirectAccess server IPv6 address 2 remotetunnelendpoint=any auth1=Computercert auth1ca=”Certificate Auth name certmapping:yes” auth2=userkerb applyauthz=yes

netsh advfirewall set global ipsec authzusergrp=O:LSD:(A;;CC;;;S-1-5-65-1)

Locking out DirectAccess clients

If you need to lock out a DirectAccess client and prevent it from making DirectAccess connections, you can do so by disabling the computer account in Active Directory. This is the recommended method.

Another method is to enable strong CRL checking for IPsec and then revoke the DirectAccess client’s certificate, preventing authentication with the DirectAccess server. Strong CRL checking is not enabled by default; if you revoke a computer certificate of a DirectAccess client, it will still be able to make authenticated connections to the DirectAccess server.

To enable strong CRL checking for IPsec authentication, use the following procedure:

1. On the domain controller, run the following commands:

   netsh adv set store gpo=[domain name]\[GUID for the DirectAccess server GPO]
   
   netsh adv set global ipsec strongcrlcheck 2
   

2. On the DirectAccess server, use the gpupdate /target:computer command to update computer configuration Group Policy settings.

Note

If you enable strong CRL checking and the DirectAccess server cannot reach the CRL distribution point, IPsec authentication for all DirectAccess connections will fail.

If you are using NAP and health certificates and you enable strong CRL checking, IPsec authentication for all DirectAccess connections will fail. Health certificates do not have CRLs because their lifetime is typically on the order of hours, instead of years for typical computer certificates.

Securing Internet Explorer

Set the Group Policy setting for Computer Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page\Turn on automatic detection of the intranet to Disabled. This disables the ability of Internet Explorer® to leak NTLM credentials by default when single-label names are used. You can set the setting in the Group Policy object (GPO), never prompt, to prevent NTLM from being used in the Internet or Local Intranet Zone entirely. List the known intranet sites in the Trusted Sites Zone.

Enable the setting to prevent elevation to Local Intranet Zone from Internet Zone.