Share via

Choose an Authentication and Authorization Scheme

  • Article

Applies To: Windows 7, Windows Server 2008 R2

Important

This topic describes design considerations for DirectAccess in Windows Server 2008 R2. For the design considerations of DirectAccess in Microsoft Forefront Unified Access Gateway (UAG), see the Forefront UAG DirectAccess Design Guide (https://go.microsoft.com/fwlink/?LinkId=179988).

By default, the DirectAccess Setup Wizard configures Windows Firewall with Advanced Security connection security rules that specify the use of the following types of credentials when negotiating the Internet Protocol security (IPsec) security associations for the tunnels to the DirectAccess server:

  • The infrastructure tunnel uses Computer certificate credentials for the first authentication and User (NTLMv2) for the second authentication. User (NTLMv2) credentials force the use of Authenticated Internet Protocol (AuthIP) and provide access to a Domain Name System (DNS) server and domain controller before the DirectAccess client can use Kerberos credentials for the intranet tunnel.

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

You can also specify additional authentication with selected server access, peer authentication methods for end-to-end access, and the use of smart cards for additional authorization.

Note

If you modify the connection security rules created by the DirectAccess Setup Wizard, you must use Network Shell (Netsh) commands. There are connection security rule settings that cannot be modified with the Windows Firewall with Advanced Security snap-in. If you modify these connection security rules with the Windows Firewall with Advanced Security snap-in, they will be overwritten with default values, which can result in incompatible connection security rules that prevent DirectAccess connections.

Additional end-to-end peer authentication for selected server access

If you configure selected server access, the DirectAccess Setup Wizard configures Windows Firewall with Advanced Security connection security rules to use Computer certificate or Computer (Kerberos V5) credentials for the first authentication and User (Kerberos V5) credentials for the second authentication to the selected servers.

Peer authentication for end-to-end access

When you manually configure the Windows Firewall with Advanced Security connection security rules for end-to-end access, you can configure your own methods for the first and second IPsec peer authentication. However, the following are recommended:

  • First authentication: Computer certificate or Computer (Kerberos V5)

  • Second authentication: User (Kerberos V5)

Note

If you modify the connection security rules created by the DirectAccess Setup Wizard, you must use Network Shell (Netsh) commands. There are connection security rule settings that cannot be modified with the Windows Firewall with Advanced Security snap-in. If you modify these connection security rules with the Windows Firewall with Advanced Security snap-in, they will be overwritten with default values, which can result in incompatible connection security rules that prevent DirectAccess connections.

Smart cards for additional authorization

On the Connectivity page of Step 2 in the DirectAccess Setup Wizard, you can require the use of smart cards for access to the intranet. When this option is selected, the DirectAccess Setup Wizard configures the IPsec connection security rule for the intranet tunnel on the DirectAccess server to require tunnel mode authorization with smart cards. Tunnel mode authorization is a new feature of Windows Firewall with Advanced Security for Windows 7 and Windows Server 2008 R2 that allows you to specify that only authorized computers or users can establish an inbound tunnel.

To use smart cards with IPsec tunnel mode authorization for the intranet tunnel, you must deploy a public key infrastructure (PKI) with smart cards infrastructure.

Because your DirectAccess clients are using smart cards for access to the intranet, you can also use authentication mechanism assurance, a new feature of Windows Server 2008 R2, to control access to resources, such as files, folders, and printers, based on whether the user logged on with a smart card-based certificate. Authentication mechanism assurance requires a domain functional level of Windows Server 2008 R2. For more information, see What's New in AD DS: Authentication Mechanism Assurance (https://go.microsoft.com/fwlink/?LinkId=159947).

Allowing access for users with unusable smart cards

To allow temporary access for users with smart cards that are unusable, do the following:

  1. Create an Active Directory security group to contain the user accounts of users who temporarily cannot use their smart cards.

  2. For the DirectAccess server Group Policy object, configure global IPsec settings for IPsec tunnel authorization and add the Active Directory security group to the list of authorized users.

To grant access to a user that cannot use their smart card, temporarily add their user account to the Active Directory security group. Remove the user account from the group when the smart card is usable.

Prompts for smart card credentials while on the intranet

Due to the timing between intranet detection and the automatic establishment of tunnels to the DirectAccess server, it is possible for users of DirectAccess clients using smart cards to be prompted for smart card credentials when they are directly connected to the intranet. This is a prompt that users can ignore without loss of connectivity. The solutions to this issue are the following:

  • Move the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) routing function to a separate server and then add packet filters to this server that block all User Datagram Protocol (UDP) traffic for Internet Key Exchange (IKE) and AuthIP from the Internet Protocol version 6 (IPv6) address prefix of the intranet to the IPv6 address of the DirectAccess server’s tunnel endpoint. These filters will drop the tunnel establishment traffic sent by DirectAccess clients while intranet detection is in progress. For an example of moving the ISATAP routing function to another server, see Capacity Planning for DirectAccess Servers.

  • Add a connection security rule that sends tunnel endpoint traffic to an invalid destination while intranet detection is occurring. For example, use the following Network Shell (netsh) command-line tool command: netsh advfirewall consec add rule name="Corp connectivity to prevent smart card prompt" endpoint1=IntranetIPv6Prefix endpoint2=IntranetIPv6Prefix localtunnelendpoint=InvalidIPv6Address mode=tunnel action=requireinrequireout auth1=computercert auth1ca="CN=NonExistentCA".

Both of these solutions prevent the tunnel negotiation with the DirectAccess server during intranet detection when the DirectAccess client is on the intranet. By preventing tunnel negotiation, smart card authorization will never occur and the user will not be prompted for their smart card credentials.

Under the covers: Smart card authorization

Smart card authorization works by enabling tunnel mode authorization on the intranet tunnel connection security rule of the DirectAccess server for a specific Kerberos-based security identifier (SID). For smart card authorization, this is the well-known SID (S-1-5-65-1), which maps to smart card-based logons. This SID is present in a DirectAccess client’s Kerberos token and is referred to as “This Organization Certificate” when configured in the global IPsec tunnel mode authorization settings.

When you enable smart card authorization in Step 2 of the DirectAccess Setup Wizard, the DirectAccess Setup Wizard configures the global IPsec tunnel mode authorization setting with this SID for the DirectAccess server Group Policy object. To view this configuration in the Windows Firewall with Advanced Security snap-in for the DirectAccess server Group Policy object, 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. You should see the “NT AUTHORITY\This Organization Certificate” as an authorized user.

Note

If you manually configure this setting with the Users tab, you must specify the name LocalComputerName\This Organization Certificate rather than NT AUTHORITY\This Organization Certificate.

To perform the equivalent configuration of the DirectAccess Setup Wizard with the Network Shell (Netsh) command-line tool, use the following commands:

  • netsh advfirewall consec add rule name=”Smart card tunnel” endpoint1=IntranetIPv6AddressSpace endpoint2=Any localtunnelendpoint=DirectAccessServerIPv6Address 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)