Authentication in ISA Server 2006

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 New

ISA 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, 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.


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 and You cannot configure SSO when publishing and The DNS suffix consists of the entire string that follows the first dot. For example, to configure SSO between and, you would use the DNS suffix

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.


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 Process

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


    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.

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.


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.


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


  • 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

  • When you configure a time-out for forms-based authentication, we recommend that the time-out be shorter than that imposed by the published server. If the published server times out before ISA Server, the user may mistakenly think that the session ended. This could allow attackers to use the session, which remains open until actively closed by the user or timed out by ISA Server as configured on the form setting.
  • You should ensure that your Web application is designed to resist session riding attacks (also known as cross-site-posting, cross-site-request-forgery, or luring attacks) before publishing it using ISA Server. This is particularly important for Web servers published through ISA Server, because clients must use the same trust level for all of the Web sites they access through the publishing ISA Server firewall.
  • In a forms-based authentication scenario where a client certificate is required, and the user declines to provide a certificate, the user is able to access the logon form. The logon is then denied by ISA Server because of the lack of a client certificate.
  • Forms customization involves modification of the Strings.txt file. If you provide the Strings.txt file to a third party for modification, validate that non-text additions have not been made to the file, because these may provide a means of attack on your networks.

HTTP Authentication

These types of HTTP authentication are supported:

  • Basic authentication
  • Digest and WDigest authentication
  • Integrated Windows authentication
Basic authentication

The Basic authentication method is a widely used, industry-standard method for collecting user name and password information. Basic authentication sends and receives user information as text characters that can be read. Although passwords and user names are encoded, no encryption is used with Basic authentication.

Security Note:
Passwords transmitted through Basic authentication are not secure and can be read during transmission. If you use Basic authentication, we recommend that you use SSL to encrypt the traffic.

The following steps outline how a client is authenticated using Basic authentication:

  1. The user is prompted to enter a Windows account user name and password, also known as credentials.

  2. ISA Server receives the HTTP request with the credentials, and if required by the rule, validates the credentials through the specified authentication provider.

  3. In passing the HTTP request to the Web server, ISA Server uses the credentials to authenticate to the Web server, according to the configured delegation method. The Web server must be configured to use the authentication scheme that matches the delegation method used by ISA Server. The plaintext password is Base64-encoded before it is sent over the network.

    Security Note:
    Base64 encoding is not encryption. If a Base64-encoded password is intercepted over the network by a network sniffer, unauthorized users can decode and reuse the password.
  4. When ISA Server verifies that the user name and password correspond to a valid Windows user account (Active Directory or LDAP) or RADIUS account, a connection is established.

The advantage of Basic authentication is that it is part of the HTTP specification and is supported by almost all HTTP clients. The disadvantage is that Web browsers using Basic authentication transmit passwords in an unencrypted form. By monitoring communications on your network, an attacker or malicious user can intercept and decode these passwords using publicly available tools. Therefore, Basic authentication is not recommended unless you are confident that the connection is secure, such as with a dedicated line or an SSL connection.

Digest and WDigest authentication

HTTP authentication includes Digest authentication and a new version of Digest authentication, WDigest authentication.

Digest authentication

Digest authentication offers the same features as Basic authentication but involves a different way of transmitting the authentication credentials:

  1. The authentication credentials pass through a one-way process, often referred to as hashing. The result of this process is called a hash or message digest, and it is not feasible to decrypt it—the original text cannot be deciphered from the hash.
  2. Additional information is added to the password before hashing so that no one can capture the password hash and use it to impersonate the true user.
  3. Values are added that help to identify the user, the user's computer, and the domain that the user belongs to.
  4. A time stamp is added to prevent a user from using a password after it has been revoked. This is a clear advantage over Basic authentication because the password cannot be intercepted and used by an unauthorized person.

Digest authentication relies on the HTTP 1.1 protocol as defined in the RFC 2617 specification at the World Wide Web Consortium (W3C) Web site. Because Digest authentication requires HTTP 1.1 compliance, not all browsers support it. If a non-HTTP 1.1 compliant browser requests a file when Digest authentication is enabled, the request is rejected because Digest authentication is not supported by the client.

Digest authentication can be used only in Windows domains. Digest authentication works with Microsoft Windows Server® 2003 and Windows® 2000 Server domain accounts only, and may require the accounts to store passwords as encrypted plaintext.


Digest authentication is successful only if the domain controller has a reversibly encrypted (plaintext) copy of the requesting user's password stored in Active Directory. To allow passwords to be stored in plaintext, you need to activate the Store password using the reversible encryption setting on the Account tab of the user in Active Directory. Alternatively, you can set Group Policy to enable this capability. After making this setting, you need to set a new password to activate this feature because the old password cannot be determined.

WDigest authentication

Unlike regular Digest authentication, WDigest does not require that passwords be stored in reversible encryption. WDigest, which is supported by ISA Server 2006, is a new version of Digest authentication.

With WDigest, user name and domain name are case-sensitive. Users must type their user names (and domain names) exactly as they are stored in Active Directory. This differs from Digest, Basic, and Integrated Windows authentication, where only the password is case-sensitive.

When both ISA Server and the domain are based on the Windows Server 2003 operating system, the default authentication is WDigest. This means that when you select Digest authentication in a Windows Server 2003 environment, you are actually selecting WDigest.

Client authentication process

The following steps outline how a client is authenticated using Digest authentication:

  1. The client makes a request.
  2. ISA Server denies the request and asks the client for authentication information.
  3. The domain controller informs ISA Server of the authentication results.
  4. If the client is authenticated, ISA Server checks the firewall policy, to determine whether the object should be obtained, as appropriate.
Integrated Windows authentication

Integrated Windows authentication uses the NTLM, Kerberos, and Negotiate authentication mechanisms. These are secure forms of authentication because the user name and password are hashed before being sent across the network. When you enable NTLM, Kerberos, or Negotiate authentication, the user's browser proves its knowledge of the password through a cryptographic exchange with your Web server, involving hashing.


When you use Windows Integrated authentication, the user's domain must always be provided with the user name, in the format domain\username.

Client authentication process

The following steps outline how a client is authenticated using Integrated Windows authentication:

  1. Depending on browser configuration, authentication may not initially prompt for a user name and password. The current Windows user information on the client computer is used for authentication.
  2. If the authentication exchange initially fails to identify the user, the browser prompts the user for a Windows account user name and password, which it processes using Integrated Windows authentication.
  3. The Web browser continues to prompt the user until the user either enters a valid user name and password or closes the prompt dialog box.

Security Notes

  • Because authentication for an external connection will use NTLM authentication, we recommend that you use SSL encryption for the traffic between ISA Server and the client. NTLM authentication is per connection, and encryption will prevent improper reuse of connections by legacy proxy devices on the Internet.
  • Note that Integrated Windows authentication depends on an Active Directory server to validate client credentials. ISA Server will communicate with the Active Directory server whenever client authentication is required. For this reason, we recommend that you create a protected network for Active Directory and ISA Server, to prevent users (both external and internal) from accessing the communication.

Client Certificate Authentication

In the client certificate scenario, a certificate is provided by the client, and the client is authenticated by ISA Server on the basis of that certificate. This might be a certificate that is embedded in a smart card, or a certificate that is used by a mobile device so that it can connect to Microsoft ActiveSync®.

The following conditions need to be taken into account when client certificate authentication has been configured.

Multiple Client Certificates Installed on Client Computer

When there are multiple client certificates installed on the user's computer, and the Client Authentication Method selected on the Web listener is SSL Client Certificate Authentication, the user must select the correct certificate, from the Choose a digital certificate dialog box, when accessing the published Web server.

Single Sign On and Client Certificate Authentication

If you have configured single sign on between two published applications with different host names, for example and, and the Client Authentication Method selected on the Web listener is SSL Client Certificate Authentication, users will be prompted to select their certificate a second time when going from one published Web site to the second published Web site. Users will only be prompted for the PIN code the first time they select the certificate as long as the second published Web server is opened in the same browser application process.

This issue does not affect published Web sites that share the same host name, for example and

Domain Membership

Client certificate authentication is available only when your ISA Server computer or array is in a domain.

Methods for Validation of Client Credentials

You can configure how ISA Server validates client credentials. ISA Server supports these providers and protocols:

  • No authentication (allows the internal servers to handle authentication)
  • Windows Active Directory
  • Active Directory over the LDAP protocol
  • RADIUS one-time password
  • SecurID


A publishing rule with a Web listener that uses a specific form of credential validation must use a user set that is consistent with that form of validation. For example, a publishing rule with a Web listener that uses LDAP credential validation must also use a user set that consists of LDAP users. It cannot include Active Directory users.

Configuring Receipt and Validation of Client Credentials

You can configure the receipt and validation of client credentials on the Web listener for a publishing rule.

In the New Web Listener Definition Wizard, use the Authentication Settings page, and in the Web listener properties, use the Authentication tab.


When you use the same Web listener to publish more than one application in the same domain, a user who is authenticated for one application will also be able to access the others, even if single sign on is not enabled.

Windows Active Directory

In Windows Active Directory validation, the credentials entered by the client are passed to a domain controller, which checks the credentials against the Active Directory list of users. The client must therefore enter the credentials recognized by the domain controller, in one of these formats:

  • SAM account name (domain\username)
  • User principal name (
  • Distinguished name

Active Directory validation can only take place when ISA Server is a domain member (either the same domain as the domain controller or in a trusted domain).

Active Directory over LDAP Protocols

This validation method is similar to Windows Active Directory validation. In this method, ISA Server connects to an LDAP server over an LDAP protocol. (LDAP, LDAPS, LDAP-GC, and LDAPS-GC are supported.) Note that every domain controller is an LDAP server. The LDAP server has a store of the Active Directory users' credentials. Because each domain controller is only able to authenticate the users in its domain, ISA Server by default queries the global catalog for a forest to validate user credentials.

The client must enter the credentials recognized by Active Directory in one of these formats:

  • SAM account name (domain\username)
  • User principal name (
  • Distinguished name


RADIUS is used to provide credentials validation. When ISA Server is acting as a RADIUS client, it sends user credentials and connection parameter information in the form of a RADIUS message to a RADIUS server. The RADIUS server authenticates the RADIUS client request, and sends back a RADIUS message response.

Because RADIUS servers authorize client credentials in addition to authenticating them, the response that ISA Server receives from the RADIUS server indicating that the client credentials are not approved, might actually indicate that the RADIUS server does not authorize the client. Even if the credentials have been authenticated, ISA Server may reject the client request, based on the RADIUS server authorization policy.


When RADIUS users provide credentials to ISA Server, the credentials must be passed as domain<EM>user (and not as user@domain).

You can configure ISA Server to use specific RADIUS servers, which will be responsible for performing RADIUS user authentication.

RADIUS authentication for outgoing requests

When using Internet Authentication Service (IAS) as your RADIUS server, be sure to enable unencrypted authentication, which is Password Authentication Protocol (PAP), in the dial-in profile of IAS remote access policy. Enabling IAS for PAP is a per-profile IAS setting. All RADIUS clients that match the policy conditions will be able to connect to the IAS server by using PAP.

Configuring ISA Server for RADIUS authentication

When you configure the Web listener on ISA Server, select RADIUS authentication as the authentication provider. When you add a RADIUS server, you must configure the following:

  • Server name . The host name or IP address of the RADIUS server.
  • Secret . The RADIUS client and the RADIUS server share a secret that is used to encrypt messages sent between them. You must configure the same shared secret on ISA Server and on the IAS server.
  • Authentication port . ISA Server sends its authentication requests using a User Datagram Protocol (UDP) port on which the RADIUS server is listening. The default value of 1812 does not need to be changed when you are using the default installation of IAS as a RADIUS server.


When you configure ISA Server for RADIUS authentication, the configuration of RADIUS servers applies to all rules or network objects that use RADIUS authentication.

Security considerations

The RADIUS User-Password hiding mechanism might not provide sufficient security for passwords. The RADIUS hiding mechanism uses the RADIUS shared secret, the Request Authenticator, and the use of the MD5 hashing algorithm to encrypt the User-Password and other attributes, such as Tunnel-Password and MS-CHAP-MPPE-Keys. RFC 2865 notes the potential need for evaluating the threat environment and determining whether additional security should be used.

You can provide additional protection for hidden attributes by using Internet Protocol security (IPsec) with Encapsulating Security Payload (ESP) and an encryption algorithm, such as Triple DES (3DES), to provide data confidentiality for the entire RADIUS message. Follow these guidelines:

  • Use IPsec to provide additional security for RADIUS clients and servers.
  • Require the use of strong user passwords.
  • Use authentication counting and account lockout to help prevent a dictionary attack against a user password.
  • Use a long shared secret with a random sequence of letters, numbers, and punctuation. Change it often to help protect your IAS server.
  • When you use password-based authentication, enforce strong password policies on your network to make dictionary attacks more difficult.

RADIUS One-Time Password

RADIUS one-time password can be used by ISA Server for credentials validation. One-time password mechanisms typically consist of portable devices (physical tokens) and a server. The server and the devices each produce a new passcode at a given frequency. The passcodes are specific to each device. (No two devices share the same passcode.) The server that validates the passcodes is installed on a RADIUS server and can be associated with the existing list of RADIUS users. Each passcode can only be used once.

The user enters the user name and passcode provided by the portable device on the form provided by ISA Server. ISA Server sends the user name and passcode to the RADIUS server for validation.

Because the passcode cannot be used a second time, ISA Server does not revalidate the credentials for each request. Rather, ISA Server issues a cookie to the client that allows continued communication without reauthenticating.

Some RADIUS servers will block the logon of a user who has failed to log on a specified number of times. If a malicious user intentionally attempts to log on that many times using a legitimate user name and wrong passcodes, that user will be locked out of the system until you reset access for that user. We recommend that you disable the lockout feature on the RADIUS one-time password server, to prevent this from occurring. The ISA Server HTTP requests per minute, per IP address setting (which you can configure on the Flood Mitigation properties of ISA Server) mitigates brute force password-guessing attacks, so you can disable the RADIUS lockout feature safely.


ISA Server can also use SecurID for credential validation. The SecurID product from RSA enforces a requirement that a remote user must provide the following to gain access to protected resources:

  • Personal identification number (PIN)
  • Physical token that produces a time-limited, one-time password

Neither the PIN nor the token-generated one-time password will grant access in isolation from each other. Both are required.

When a user attempts to access Web pages that are protected by RSA SecurID, the ISA Server computer, on behalf of the server running IIS that it secures, checks for a cookie. This cookie will only be present if the user has authenticated recently, and it is not persistent. If the user's cookie is missing, the user is prompted for a user name and passcode for SecurID. The passcode consists of a combination of the user's PIN and tokencode. The RSA ACE/Agent® on the ISA Server computer passes these credentials to the RSA Authentication Manager® computer for validation. If the credentials are successfully validated, a cookie is delivered to the user's browser for subsequent activity during the session, and the user is granted access to the content.


  • For SecurID delegation, ISA Server generates cookies that are compatible with RSA Authentication Agent 5.0. When you use SecurID delegation, you must configure the authentication agent computer to trust those cookies. To do so, in the authentication agent computer registry, add the string value Agent50CompatibleCookies under HKLM\Software\SDTI\RSAAgent.
  • If ISA Server is configured with multiple network adapters and you create a Web listener with RSA SecurID authentication enabled, you should explicitly configure the network adapter address through which ISA Server will connect to the RSA Authentication Manager for authentication purposes. Otherwise, ISA Server may fail to perform SecurID authentication. Specify the IP address in registry key HKEY_LOCAL_MACHINE\SOFTWARE\SDTI\AceClient\PrimaryInterfaceIP, as a string value.
  • We recommend that you use SSL to encrypt the communication between the client and ISA Server.
  • For additional information about RSA Authentication Manager installation, configuration, and authentication concepts, see the documentation available at the RSA Web site,
  • RSA SecurID is based on technology from RSA Security Inc.
How authentication for RSA SecurID functions

The following terminology is used in this section:

  • RSA Authentication Manager . This computer retains information about users, groups, hosts, and tokens. For each user, the RSA Authentication Manager maintains a list of hosts to which the user can log on, and a logon name, which can differ from one host to the other.
  • RSA ACE/Agent . This computer provides Web content (the ISA Server computer or array), and requires the user to provide credentials for RSA SecurID.
  • Client . Usually, this is a Web browser that receives Web content.

When a client sends a GET /x request to ISA Server, the following process occurs:

  1. The ISA Server Web filter for forms-based authentication (Forms-Based Authentication Filter) intercepts the request, and returns an RSA SecurID authentication form to the client.
  2. The client is required to fill in the form with a logon name and a passcode. Optionally, the client may be required to provide additional credentials to be used for delegation.
  3. The browser uses the HTTP POST method to return the form to the Web filter.
  4. The Forms-Based Authentication Filter communicates these details to the RSA Authentication Manager, to verify that the user is allowed to access using the ISA Server computer. If the answer is positive, the Web filter returns a response which includes a Set-Cookie header to the client.
  5. The Set-Cookie header writes a cookie to the browser's memory. The cookie contains information about the user. This information is signed with a secret known only to ISA Server. This means that the cookie cannot be modified by other users.
  6. The response contains a Refresh header, which instructs the browser to resend the original GET /x request to the server.
  7. When the Web filter receives a request with a cookie, it verifies that the cookie is valid, by checking:
    • Expiration time
    • IP address (if specified)
    • Signature (to ensure that the data was not tampered)

Authentication Delegation

After validating the credentials, you can configure publishing rules to use one of the following methods to delegate the credentials to the published servers:

  • No delegation, and client cannot authenticate directly
  • No delegation, but client may authenticate directly
  • Basic
  • NTLM
  • NTLM/Kerberos (Negotiate)
  • SecurID
  • Kerberos constrained delegation

Configuring Authentication Delegation

Delegation of client credentials is configured on the publishing rule. In the Publishing Rule Wizard, configure this on the Authentication Delegation page. In the publishing rule properties, the authentication settings are on the Authentication Delegation tab.

No Delegation, and Client Cannot Authenticate Directly

This is a new feature in ISA Server 2006, in which credentials are not delegated. This is intended to prevent the unintentional delegation of credentials into the organization, where they might be sniffed. This is the default setting in some ISA Server publishing wizards, so that if you want to delegate credentials, you must change the default.

No Delegation, but Client May Authenticate Directly

When you select the delegation method No Delegation, but client may authenticate directly, the user's credentials are passed to the destination server without any additional action on the part of ISA Server. The client and the destination server then negotiate the authentication.


In Basic delegation, credentials are forwarded in plaintext to the server that requires credentials. If authentication fails, ISA Server replaces the delegation with the authentication type used by the Web listener. If the server requires a different type of credentials, an ISA Server alert is triggered.


In NTLM delegation, ISA Server delegates the credentials using the NTLM challenge/response authentication protocol. If authentication fails, ISA Server replaces the delegation with the authentication type used by the Web listener. If the server requires a different type of credentials, an ISA Server alert is triggered.

NTLM/Kerberos (Negotiate)

When you select Negotiate as a delegation method, ISA Server first attempts to obtain a Kerberos ticket for the client from the domain controller. If ISA Server does not receive the Kerberos ticket, it uses the negotiate scheme to delegate the credentials using NTLM. If ISA Server receives the Kerberos ticket, it uses the negotiate scheme to delegate the credentials using Kerberos. If authentication fails, ISA Server provides the server's failure notice to the client. If the server requires a different type of credentials, an ISA Server alert is triggered.

The default service principal name (SPN) used to obtain the ticket is http/internalsitename. In the case of a server farm, the SPN is the name of the farm. The default SPN can be changed in ISA Server Management on the Authentication Delegation tab of the rule.


In Microsoft Exchange Server 2003, IIS runs under the Network Service account. ISA Server uses the wildcard SPN HTTP*, and replaces the asterisk with the host name of the published site.


When a client provides SecurID credentials, you can use SecurID authentication delegation. ISA Server passes the proprietary SecurID cookie to the published server. Note that ISA Server and the published server must have the same domain secret and cookie name.

Kerberos Constrained Delegation

ISA Server 2006 introduces the use of Kerberos constrained delegation, which is described in the article Kerberos Protocol Transition and Constrained Delegation. Without Kerberos constrained delegation, ISA Server can delegate credentials only when client credentials are received using Basic or forms-based authentication. With Kerberos constrained delegation, ISA Server can accept other types of client credentials, such as client certificates. ISA Server must be enabled on the domain controller to use Kerberos constrained delegation (constrained to a specific service principal name).

If authentication fails, ISA Server provides the server's failure notice to the client. If the server requires a different type of credentials, an ISA Server alert is triggered.


  • Use of Kerberos constrained delegation requires that you configure Active Directory to recognize ISA Server as trusted for delegation.
  • The default SPN used to obtain the ticket is http/internalsitename. In the case of a server farm, the SPN is the name of the farm. The default SPN can be changed in ISA Server Management on the Authentication Delegation tab of the rule.
  • To use Kerberos constrained delegation, your domain must run in the Windows Server 2003 domain functional level.
  • Kerberos authentication depends upon UDP packets that are commonly fragmented. If your ISA Server computer or array (in Enterprise Edition) is in a domain, and you enable the blocking of IP fragments, Kerberos authentication will fail. For example, if the computer uses Kerberos for authentication during user logon, logon will fail. We recommend that you do not enable the blocking of packets containing IP fragments in scenarios where Kerberos authentication is used.
  • SharePoint Portal Server 2003 disables Kerberos by default, so NTLM/Kerberos (Negotiate) and Kerberos constrained delegation will not work with SharePoint publishing. To enable Kerberos, follow the instructions at Microsoft Help and Support.
  • In Microsoft Exchange Server 2003, IIS runs under the Network Service account, and ISA Server uses the wildcard SPN HTTP\*, and replaces the asterisk with the host name of the published site.

Valid Combinations of Client Credentials and Delegation Methods

Not every method of delegation is valid for a particular type of client credential. The following table summarizes the valid combinations.

Receipt of client credentials Authentication provider Delegation

Forms-based authentication (password only)


Active Directory (Windows)

Active Directory (LDAP)


No delegation, but client may authenticate directly

No delegation, and client cannot authenticate directly




Kerberos constrained delegation



Active Directory (Windows)

No delegation, but client may authenticate directly

No delegation, and client cannot authenticate directly

Kerberos constrained delegation

Forms-based authentication with passcode


RADIUS one-time password

No delegation, but client may authenticate directly

No delegation, and client cannot authenticate directly


Kerberos constrained delegation

Forms-based authentication (passcode and password)


RADIUS one-time password

No delegation, but client may authenticate directly

No delegation, and client cannot authenticate directly





Client certificate

Active Directory (Windows)

No delegation, but client may authenticate directly

No delegation, and client cannot authenticate directly

Kerberos constrained delegation