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.
|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 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.
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
- 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
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.
- 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
- 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.
- Must be an Enterprise CA running under Windows Server 2008 R2.
- OTP certificate templates—The
specified dedicated OTP CA server must meet the following
- 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.
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
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.
- 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.
- 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.
|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.
|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
- 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
- It uses customized ASP login and validation
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
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.