This document describes how Microsoft® Internet Security and Acceleration (ISA) Server 2006 manages authentication. It provides information about new authentication and delegation methods supported by ISA Server, and how the authentication process is handled by ISA Server.
This document provides:
- Overview of new authentication features in this release.
- Description of the authentication process and the authentication options available in ISA Server 2006.
- Table summarizing how the authentication options work together.
What's NewISA Server 2006 provides the following new authentication features:
- Single sign on (SSO), in which a user authenticates once with ISA Server and can access any number of servers that are behind ISA Server, without reauthenticating.
- Two-factor authentication using forms-based authentication and a client certificate.
- Forms-based authentication support for publishing any Web server.
- Customizable forms for forms-based authentication and forms for mobile clients, and use of per-user-agent authentication schemes.
- Fallback from forms-based authentication to Basic authentication, for non-browser clients.
- Delegation of credentials by using NTLM or Kerberos authentication.
- Kerberos constrained delegation.
- Credentials caching.
- Password management, in which ISA Server can check the status of the user's account and report it to the user. This feature can also be configured to enable users to change their passwords.
- Secure Sockets Layer (SSL) client certificate constraints.
- Ability to assign a different digital certificate to each IP address on a network adapter.
- A new type of forms-based authentication: User name passcode/password, where the passcode is used for ISA Server authentication and the password is used for authentication delegation.
- Support for Active Directory® directory service authentication using the Lightweight Directory Access Protocol (LDAP), allowing Active Directory authentication when ISA Server is in a workgroup, or in a forest other than the one that contains the accounts of the user. ISA Server also supports multi-forest configurations, in which the user can be authenticated on a different set of LDAP servers.
- One-time password support for Remote Authentication Dial-In User Service (RADIUS). In ISA Server 2004, this support was provided for RSA SecurID only.
- Default blocking of authentication delegation.
Single sign on, two-factor authentication, and credential caching are described in the following sections. Many of the other new features are described later in this document, in the context of the general ISA Server authentication concepts.
Single Sign On
Single sign on (SSO) enables users to authenticate once to ISA Server, and then access all of the Web servers with the same domain suffix that ISA Server is publishing on a specific listener, without reauthenticating. Web servers can include Microsoft Outlook® Web Access servers and servers running Microsoft Office SharePoint® Portal Server 2003, as well as standard servers running Internet Information Services (IIS).
A typical example of SSO is a user who logs on to Outlook Web Access, providing credentials on a form. In one of the e-mail messages that the user receives is a link to a document that is stored in SharePoint Portal Server. The user clicks the link, and the document opens, without an additional request for authentication. This example relies on the use of persistent cookies, described in ISA Server Help.
Security Notes
- As long as a user's browser process is still running, that user is logged on. For example, a user logs on to Outlook Web Access. From the Microsoft Internet Explorer® menu, the user opens a new browser window, and then navigates to another site. Closing the Outlook Web Access window does not end the session, and the user is still logged on.
- When enabling SSO, be sure to provide a specific SSO domain. Providing a generic domain, such as .co.uk, will allow the Web browser to send the ISA Server SSO cookie to any Web site in that domain, creating a security risk.
- In a scenario where you create a Web listener that uses forms-based authentication and RSA SecurID, and enable Collect additional delegation credentials in the form, ISA Server does not validate whether a user enters the same or a different name for the additional credentials.
.gif) Note: |
|---|
| There is no support for SSO between different Web listeners. Published servers must share the same Domain Name System (DNS) suffix. For example, you can configure SSO when publishing mail.fabrikam.com and team.fabrikam.com. You cannot configure SSO when publishing mail.fabrikam.com and mail.contoso.com. The DNS suffix consists of the entire string that follows the first dot. For example, to configure SSO between mail.detroit.contoso.com and mail.cleveland.contoso.com, you would use the DNS suffix contoso.com. |
Two-Factor Authentication
Two-factor authentication provides improved security because it requires the user to meet two authentication criteria: a user name/password combination and a token or certificate, known as something you have, something you know. ISA Server supports two-factor authentication in these scenarios:
- The user has a certificate.
- The user has a SecurID token that provides a passcode.
- The user has a one-time password token that provides a passcode.
A typical example of two-factor authentication with a certificate is the use of a smart card. The smart card contains the certificate, which ISA Server can validate against a server that contains the user and certificate information. By comparing the user information (user name and password) to the certificate provided, the server validates the credentials, and ISA Server authenticates the user.
| Important: |
|---|
| Two-factor authentication using a client certificate is not supported for ISA Server deployment in a workgroup. |
Credential Caching
ISA Server 2006 can cache Basic and forms-based user credentials, improving the performance of revalidating the credentials for additional client requests. When credential caching is used, ISA Server validates the credentials once per TCP session,that is, for the first HTTP request of the session, and caches the credentials as validated. For subsequent HTTP requests, ISA Server validates the credentials by comparing them to the validated credentials that were cached in the first request.
You can enable credential caching in Web listener properties. This feature is disabled by default.
Credential caching is supported for Active Directory authentication, authentication over LDAP, and RADIUS authentication, and only when the client provides the credentials using HTTP Basic authentication or forms-based authentication.
Authentication ProcessThere are three components of the authentication process in ISA Server:
- Receipt of client credentials.
- Validation of client credentials against an authentication provider such as Active Directory, RADIUS, or SecurID Authentication Manager.
- Delegation of authentication to Web servers that are behind ISA Server, such as servers running SharePoint Portal Server 2003.Note:
The first two components are configured on the Web listener that receives client requests. The third is configured on the publishing rule. This means that you can use the same listener for different rules, and have different types of delegation.
The authentication process for forms-based authentication is demonstrated in the following figure. Note that this is a simplified description of the process, presented to describe the primary steps involved.
.gif)
Step 1, receipt of client credentials: The client sends a request to connect to the corporate Outlook Web Access server in the Internal network. The client provides the credentials in an HTML form.
Steps 2 and 3, sending credentials: ISA Server sends the credentials to the authentication provider, such as a domain controller for Active Directory authentication, or a RADIUS server, and receives acknowledgment from the authentication provider that the user is authenticated.
Step 4, authentication delegation: ISA Server forwards the client's request to the Outlook Web Access server, and authenticates itself to the Outlook Web Access server using the client's credentials. The Outlook Web Access server will revalidate those credentials, typically using the same authentication provider.
| Note: |
|---|
| The Web server must be configured to use the authentication scheme that matches the delegation method used by ISA Server. |
Step 5, server response: The Outlook Web Access server sends a response to the client, which is intercepted by ISA Server.
Step 6, forwarding the response: ISA Server forwards the response to the client.
Notes
- If you do not limit access to authenticated users, as in the case when a rule allowing access is applied to all users, ISA Server will not validate the user's credentials. ISA Server will use the user's credentials to authenticate to the Web server according to the configured delegation method.
- We recommend that you apply each publishing rule to all authenticated users or a specific user set, rather than selecting Require all users to authenticate on the Web listener, which requires any user connecting through the listener to authenticate.
Client Authentication Methods for Receipt of Client Credentials
ISA Server Web listeners accept the following types of authentication from clients:
- No authentication
- Forms-based authentication
- HTTP authentication (received in HTTP header)
- Client certificate authentication
No Authentication
You can select to require no authentication. If you do so, you will not be able to configure a delegation method on rules that use this Web listener.
Forms-Based Authentication
Forms-based authentication in ISA Server 2006 can be used for publishing any Web server. Three types of forms-based authentication are available in ISA Server:
- Password form. The user enters a user name and password on the form. This is the type of credentials needed for Active Directory, LDAP, and RADIUS credential validation.
- Passcode form. The user enters a user name and passcode on the form. This is the type of credentials needed for SecurID and RADIUS one-time password validation.
- Passcode/Password form. The user enters a user name and passcode and a user name and password. The user name and passcode are used for authentication to ISA Server using SecurID or RADIUS one-time password authentication methods, and the user name and password are used for delegation.
Fallback to Basic authentication
By default, when form-based authentication cannot be used with a specific client, ISA Server requires Basic authentication instead. This is configured in the ISA Server COM in the user agent mappings collection, FPCRuleElements.UserAgentMappings. For more information, see the ISA Server SDK documentation.
Forms for mobile clients
ISA Server provides forms for a variety of mobile clients. These forms are in the CHTML and XHTML (representing XHTML-MP forms) folders, located in ISA Server Installation Directory\CookieAuthTemplates\ISA. ISA Server determines the type of form to provide based on the User-Agent header provided by the mobile client.
Password management in forms-based authentication
When you use forms-based authentication, ISA Server enables you to warn users about passwords that are about to expire (in a number of days that you configure), and allow users to change their passwords. These two functionalities can be used separately or in combination. For example, you can warn users that their passwords are about to expire, but not allow them to change their passwords. Or, you can allow them to change passwords, but not provide a warning about passwords that are about to expire.
When you allow users to change their passwords, that option will be available on the logon form. When you configure ISA Server to warn users about passwords that are about to expire, users receive a separate warning page, on which they can choose whether to change their passwords.
Notes
- The HTML forms for forms-based authentication can be fully customized.
- When ISA Server is configured to require authentication, because a publishing rule applies to a specific user set or All Authenticated Users, or a Web listener is configured to Require all users to authenticate, ISA Server validates the credentials before forwarding the request.
- By default, the language setting of the client's browser determines the language of the form that ISA Server provides. ISA Server provides forms in 26 languages. ISA Server can also be configured to serve forms in a specific language regardless of the browser's language.
Security Notes
More Here
Courtesy:http://technet.microsoft.com/en-us/library/bb794722.aspx