Planning for Forefront UAG DirectAccess client authentication

This topic describes the authentication and authorization options that are available to help you develop a deployment strategy for Forefront Unified Access Gateway (UAG) DirectAccess.

By default, the Forefront UAG DirectAccess Configuration Wizard configures Windows Firewall with Advanced Security connection security rules that specify the use of the some types of credentials when negotiating the IPsec security associations for the tunnels to the Forefront UAG DirectAccess server, as follows:

The infrastructure 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 Authenticated Internet Protocol (AuthIP), and because the DirectAccess client needs Domain Name System (DNS) and domain controller access before it 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 specified server access, peer authentication methods for end-to-end access, and the use of smart cards for additional authorization.

The following sections describe the authentication and authorization design considerations to be taken when deploying a Forefront UAG DirectAccess solution.

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

If you configure specified server access, the Forefront UAG DirectAccess Configuration 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, it is recommended that you use Computer certificate or Computer (Kerberos V5) for the first authentication, and User (Kerberos V5) for the second authentication.

Note:
If you modify the connection security rules created by the Forefront UAG DirectAccess Configuration Wizard without using the Forefront UAG DirectAccess Configuration 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.

Note:

If you modify the connection security rules created by the Forefront UAG DirectAccess Configuration Wizard without using the Forefront UAG DirectAccess Configuration 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.

Two-factor authentication for additional authorization

Forefront UAG DirectAccess supports standard user authentication using a user name and password. For greater security, you can implement as a requirement, two-factor authentication which provides improved security because it requires the user to meet two authentication criteria. Forefront UAG DirectAccess works with:

Smart cards
One-time password (OTP)

Smart cards

Smart cards for additional authorization

On the Client Authentication page of the Forefront UAG DirectAccess 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, which 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 PKI with smart cards infrastructure.

Note:
The infrastructure tunnel does not require smart card authorization. This allows the DirectAccess client computer access to the defined infrastructure servers for authentication without the user smart card authorization. You can move antivirus and Windows Server Update Services (WSUS) servers so that they are accessed through the infrastructure tunnel. This enables you to update DirectAccess client antivirus settings and Windows updates without the requirement for smart card authorization.

Note:

The infrastructure tunnel does not require smart card authorization. This allows the DirectAccess client computer access to the defined infrastructure servers for authentication without the user smart card authorization.
You can move antivirus and Windows Server Update Services (WSUS) servers so that they are accessed through the infrastructure tunnel. This enables you to update DirectAccess client antivirus settings and Windows updates without the requirement for smart card authorization.

Allowing access for users with unusable smart cards

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

Create an Active Directory security group that will contain the user accounts of users who temporarily cannot use their smart cards.
For the Forefront UAG 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 Forefront UAG 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 as follows:

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 Forefront UAG 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.

This solution prevents the intranet tunnel negotiation with the Forefront UAG DirectAccess server during intranet detection when the DirectAccess client is on the intranet. By preventing the intranet tunnel negotiation, smart card authorization never occurs, and the user will not be prompted for 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 Forefront UAG DirectAccess server, for a specific Kerberos-based security identifier (SID) in a DirectAccess client’s Kerberos token. For smart card authorization, the authorized user is 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 configured in the global IPsec tunnel mode authorization settings.

When you enable smart card authorization in the Client Authentication page of the Forefront UAG DirectAccess configuration Wizard, the wizard configures the global IPsec tunnel mode authorization setting with this SID for the Forefront UAG DirectAccess server Group Policy object. To view this configuration in the Windows Firewall with Advanced Security snap-in for the Forefront UAG DirectAccess server Group Policy object, do the following:

Right click Windows Firewall with Advanced Security, and then click Properties.
On the IP Settings tab, in IPsec tunnel authorization, click Customize.
Click the Users tab. You should see the “NT AUTHORITY\This Organization Certificate” as an authorized user.

One-time password (OTP)

On the Client Authentication page of the Forefront UAG DirectAccess Configuration Wizard, you select whether you want to use two-factor authentication. You can require the use of OTP for access to the intranet. Forefront UAG DirectAccess OTP access control is based on the existence of a user and workstation certificates on the DirectAccess client. The IPsec rules require that the DirectAccess client has a certificate from a designated CA server in order to gain access to the intranet.

A client acquires these certificates by supplying his OTP credentials via the DirectAccess Connectivity Assistant (DCA) client software, or by entering OTP credentials when prompted, to an automatically created OTP Web portal (trunk) for authentication. If the authentication succeeds, the Forefront UAG DirectAccess server enrolls two certificates from the designated CA server, on behalf of the user and the workstation, returns them to the DCA, which uses the DCA service to install them in the DirectAccess client’s computer.

OTP for additional authorization

The following are required to support OTP and are selected or configured in the Forefront UAG DirectAccess Configuration Wizard:

An RSA SecurID or a RADIUS authentication server— An RSA SecurID or a RADIUS authentication server is used to authenticate OTP clients. When challenged, the user enters a password that is a combination of two numbers: a personal identification number (PIN) supplied by RSA, and a token code, which is the number displayed on the RSA SecurID authenticator, or by just entering a token code.

Note:

Depending on the RSA SecurID configuration, a user can also create a PIN.

RSA SecurID and RADIUS authentication servers can be added in the Forefront UAG DirectAccess Configuration Wizard, and are automatically added as RSA SecurID and RADIUS authentication servers in Forefront UAG. If you already have an RSA SecurID or RADIUS authentication server configured in Forefront UAG, it can be selected from the Forefront UAG DirectAccess Configuration Wizard.
Certification Authority (CA) server—The CA server is an essential part of configuring OTP. A dedicated CA server must be set up for OTP with the following requirements:
- Must be an Enterprise CA running under Windows Server 2008 R2.
- If the root of the OTP CA server is not the same root as the CA server that issues the computer certificate used in the infrastructure tunnel authentication, ensure that the root OTP CA server is added in the Trusted Root Certification Authorities on all DirectAccess clients.
- Cannot be the CA that issues the certificates for IPsec authentication, or one of its parent CAs.
- Must be an OTP dedicated CA server so that the client cannot open the intranet tunnel using a certificate issued for another purpose from that CA server.
  
  Note:
  
  It is recommended that it is created as an intermediate certification authority.
  
  Note:
  
  The same CA server cannot be not be used for OTP and NAP.
OTP certificate templates—The specified dedicated OTP CA server must meet the following requirements:
- The CA server must contain the following certificate templates only; A Workstation template, and a User template. Both should be configured as described in Configuring two-factor authentication in SP1.
- Templates should have read-only permissions assigned to Everyone, and write/enroll permissions for Forefront UAG DirectAccess servers.
- Certificates must have a lifetime of less than 24 hours.
A specified CA server can be configured manually, or by generating and applying an OTP CA configuration PowerShell script in the Forefront UAG DirectAccess Configuration Wizard and applying it to update the CA server.

If you use the OTP CA configuration script to configure the CA server, the following should be noted:
- If the OTP CA configuration script is run from the Forefront UAG DirectAccess server, you should only apply it once the Forefront UAG DirectAccess configuration has been applied and Forefront UAG activated.
- If the OTP CA configuration script is run from a computer that is not the Forefront UAG DirectAccess server, it can be run so long as the above CA server requirements have been met.
Note:

Any additional templates are deleted from the CA server when the OTP CA configuration script is run. The templates are not deleted from Active Directory.

Note:
Depending on the RSA SecurID configuration, a user can also create a PIN.

Note:
It is recommended that it is created as an intermediate certification authority.

Note:
The same CA server cannot be not be used for OTP and NAP.

Note:
Any additional templates are deleted from the CA server when the OTP CA configuration script is run. The templates are not deleted from Active Directory.

DirectAccess Connectivity Assistant (DCA)—The DCA is an integral part of the OTP authentication process. For full OTP functionality, you must configure the DCA in the Forefront UAG DirectAccess Configuration Wizard, and install DCA version 1.5 on the DirectAccess client.

Note:
You can use OTP authentication even when the DCA has not been configured in the Forefront UAG DirectAccess Configuration Wizard. However you are still required to install DCA version 1.5 on the DirectAccess client.

Prompt for OTP credentials

When OTP is configured in the Forefront UAG DirectAccess Configuration Wizard, all clients connecting to the Forefront UAG DirectAccess server need to authenticate with the specified RSA SecureID or RADIUS authentication server. This is done by presenting the client with a One-time Password credentials pop-up. This is one of the new features in DCA 1.50.

Note:
For OTP authentication to function on an OTP client, the DCA version 1.50 must be installed on the DirectAccess client.

The OTP trunk

Once you complete the Forefront UAG DirectAccess Configuration Wizard, and generate and apply the Forefront UAG DirectAccess Configuration Wizard script (and optionally the OTP CA configuration script), you must activate the configuration in Forefront UAG. If OTP is configured, when you activate the configuration in Forefront UAG, Forefront UAG creates a read-only HTTP Web portal whose sole purpose is to provide OTP authentication for DirectAccess clients.

Note:
The reason an HTTP and not an HTTPS trunk is created is because there is no need for SSL encryption as traffic to this trunk passes through the infrastructure tunnel and is therefore IPsec encrypted.

The OTP trunk is used to authenticate DirectAccess OTP users against an RSA SecurID or RADIUS repository. It is a regular Forefront UAG trunk with the following exceptions:

It is created once you activate the Forefront UAG configuration.
It is published to an IPv6 address. This address is typically the 6to4 address created using the second of the consecutive IPv4 addresses configured on the external adapter on the Forefront UAG DirectAccess server. This allows DirectAccess OTP users to access the trunk from the Internet through the infrastructure tunnel.
It uses customized ASP login and validation pages.

How the OTP logon process works

The basic OTP mechanism consists of client-side DCA service and DCA tray that notify the user whenever an OTP password needs to entered and requests and installs the required short-term certificates.

The OTP logon process works as follows:

The DirectAccess client enters domain credentials to access the infrastructure tunnel. Connectivity verifiers configured as part of the DirectAccess Connectivity Assistant configuration in the Forefront UAG DirectAccess Client configuration, are used to check connectivity to the intranet. When there is no connection to the intranet, due to an IKE failure, an expired short-term OTP certificate, or a non-existent short-term OTP certificate, the OTP credentials window pops-up.
Once the OTP credentials have been entered they are sent through the infrastructure tunnel to the OTP authentication trunk, together with a request for two short-term certificates, one for the user and the other for the computer.
On the OTP authentication trunk, the ASP login page initiates validation of the OTP credentials with the ACE server.
If successful, the Forefront UAG DirectAccess server forwards the certificate requests sent earlier by the DCA to the CA server. The CA server then issues the appropriate certificates and send them back to the Forefront UAG DirectAccess server which forwards them to the DirectAccess client.
The DCA service on the client installs the certificates on the DirectAccess client.

When user logs off or when you unlock a DirectAccess client, the short-term certificates are deleted from the relevant certificate stores, and the user is presented with the OTP credentials pop-up the next time an attempt is made to access the intranet.