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:
- 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.
- 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
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.
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:
- 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.
- 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.
- 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 OTP in SP1.
- Templates should have read-only permissions assigned to
Everyone, and write/enroll permissions for Forefront UAG
- Certificates must have a lifetime of less than 24 hours
- 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.
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.
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.
- It is created after activating the Forefront UAG
- It is published to an IPv6 address
- 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 machine.
- 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
- 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