Forefront Unified Access Gateway (UAG) uses authenticated IPv6/IPsec tunnel to connect DirectAccess clients to DirectAccess servers and intranet resources. By default, the Forefront UAG DirectAccess Wizard configures Windows Firewall with Advanced Security connection security rules for the following:

  1. Infrastructure tunnel—This tunnel is used to allow DirectAccess clients to access a subset of internal infrastructure servers that are required for DNS name resolution, Active Directory authentication, HRA servers for NAP enforcement, remediation update servers etc. This tunnel is established before a user logs on. DirectAccess clients authenticate with a computer certificate and computer account-based NTLMv2 credentials. Successful authentication provides to the required infrastructure servers, and also allows these infrastructure servers to remotely manage DirectAccess clients. If NAP is enabled, the HRA server validates the computer credentials at this stage.

  2. Intranet tunnel—This tunnel is used to allow DirectAccess clients to access the rest of the intranet. If validation of computer credentials is successful, when a DirectAccess clients attempts to send traffic to an intranet server, the client automatically establishes a second IPsec ESP session with either end-to-edge tunnel mode IPsec or end-to-end transport mode IPsec, depending on policy. The tunnel is established after the computer certificate and the account of the logged on user (using Kerberos) are validated. After successful logon, the DirectAccess client can connect to any intranet resources for which access is authorized. Clients attempt to establish tunnels over IPv6. If this fails then the client will use a transition technology to encapsulate IPv6 in IPv4 packets. If this fails then IP-HTTPS will be used.

Strong authentication methods

Standard Forefront UAG DirectAccess supports client authentication using a user name and password. For greater security, you can implement two-factor authentication using smart cards or a one-time password (from Forefront UAG SP1).

Smart card authentication

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.

Typically, this requires a user to insert a smart card in addition to typing a smart card PIN. Smart card authentication prevents an attacker who acquires a user’s password (but not the smart card) from connecting to the intranet. Similarly, an attacker who acquires the smart card but does not know the smart card PIN, is unable to authenticate.

You can require smart card authentication in the following scenarios:

  • User authentication—Smart card authentication is required for specified users, regardless of which computer they use.

  • Computer authentication—Smart card authentication is required for specified computers, regardless of which user logs on.

  • Gateway authentication—The IPsec gateway requires smart card authentication before allowing connectivity. This type of configuration allows users to access Internet resources without their smart card, but requires a smart card before users or computers can connect to intranet resources (Forefront UAG DirectAccess uses this type of configuration). This can be combined with either of the previous smart card authentication scenarios.

    Note the following:

    Note:
    When smart card authentication is required for end-to-end authentication, you must use Active Directory Domain Services (AD DS) in Windows Server 2008 R2.

OTP authentication

To implement two-factor authentication you can require the use of OTP for access to the intranet. OTP authentication is based on the existence of a user and computer 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) 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 machine, returns them to the DCA, which uses the DCA service to install them in the DirectAccess client’s machine.

The following are required to deploy OTP authentication:

  1. OTP authentication server such as ACE— The ACE 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. Depending on the ACE configuration the user can also create a pin.

  2. CA server— The CA server is an essential part of configuring OTP. A dedicated CA server installed on a server running Windows Server 2008 R2 must be set up for OTP. It is recommended that you create a intermediate CA. Note that NAP also requires a dedicated CA server. You should not use the same CA for NAP and OTP.

  3. OTP certificate templates— The specified dedicated OTP CA server must meet the following requirements:

    1. 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 OTP in SP1.

    2. Templates should have read-only permissions assigned to Everyone, and write/enroll permissions for Forefront UAG DirectAccess servers.

    3. Certificates must have a lifetime of less than 24 hours

You can manually configure a CA server or configure it automatically by generating an OTP CA configuration PowerShell script in the Forefront UAG DirectAccess Configuration Wizard and applying it to update the CA server. If you are using OTP authentication, you must deploy the DirectAccess Connectivity Assistant application on DirectAccess client computers. Clients authenticating with OTP will specify credentials using a OTP credentials pop-up in DirectAccess Connectivity Assistant.

OTP trunk

If OTP is configured, after completing the DirectAccess Wizard, generating and applying DirectAccess settings (which might include the OTP CA configuration script), and activating the configuration Forefront UAG creates a read-only HTTP trunk whose sole purpose is to provide OTP authentication for DirectAccess clients. An HTTP trunk (rather than an HTTPS trunk) is created before 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 ACE (OTP) repository. It is a regular Forefront UAG trunk with the following exceptions: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.

  1. It is created after activating the Forefront UAG configuration

  2. It is published to an IPv6 address

  3. 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:

  1. 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.

  2. 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 machine.

  3. On the OTP authentication trunk, the ASP login page initiates validation of the OTP credentials with the ACE server.

  4. 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.

  5. The DCA service on the client installs the certificates on the DirectAccess client.

  6. 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.