Web Agent Guides › Web Agent Configuration Guide › Authenticate Users with Forms › Use Credential Collectors for Authentication and Single Sign-On › How to Allow the NTC to Encode URLs During Redirects to Protected Resources › Change the Value of the DisableI18N parameter in your Agent Configuration Object

Change the Value of the DisableI18N parameter in your Agent Configuration Object

You can configure Windows credential collectors to process HTTP encoded characters in target URLs for centrally configured web agents. Centrally–configured web agents use parameter settings stored in an Agent Configuration object on the Policy Server.

Follow these steps:

1. Click the Infrastructure, Agent Configuration Objects.

   A list of Agent Configuration objects appears.

   Click the edit icon in the line Agent Configuration Object you want.

   The Modify Agent Configuration dialog appears.

2. Click the edit icon to the left of the following parameter:

   DisableI18N

   Specifies how the Windows credential collector (NTC) processes the TARGET URL during authentication when the characters of the TARGET URL use HTTP encoding. When the value of this parameter is no, any characters in the URL are decoded during authentication. The decoded characters are used in the redirect to the TARGET resource. When the value of this parameter is yes, characters in the TARGET URL are not decoded during authentication. Any characters using HTTP encoding remain encoded before and after authentication.

   Default: No.

   The Edit Parameter dialog appears.

3. Change the text in the Value field to yes.
4. Click OK.

   The Edit Parameter dialog closes, and the Modify Agent Configuration dialog appears.

5. Click Submit.

   The Modify Agent Configuration dialog closes, and a confirmation message appears.

6. (Optional) Enter any remarks about the change in the Comment field for future reference.
7. Click Yes.

   Your changes will be applied the next time the Web Agent polls the Policy Server.

Change the Value of the DisableI18N parameter in your LocalConfig.conf File

You can configure Windows credential collectors to process HTTP encoded characters in target URLs. Locally–configured web agents use parameter settings stored in a configuration file on each web server.

Follow these steps:

Locate the LocalConfig.conf file on your web server. Use the examples in the following list to locate the file on your type of web server:

IIS web server

web_agent_home\bin\IIS

Oracle iPlanet web server

Oracle_iPlanet_home/https-hostname/config

Apache web server

Apache_home/conf

1. Open your LocalConfig.conf file with a text editor, and then locate the following parameter:

   DisableI18N

   Specifies how the Windows credential collector (NTC) processes the TARGET URL during authentication when the characters of the TARGET URL use HTTP encoding. When the value of this parameter is no, any characters in the URL are decoded during authentication. The decoded characters are used in the redirect to the TARGET resource. When the value of this parameter is yes, characters in the TARGET URL are not decoded during authentication. Any characters using HTTP encoding remain encoded before and after authentication.

   Default: No.

2. Change the value of the DisableI18n parameter to yes.
3. Locate the following parameter:

   BadUrlChars

   Specifies the character sequences that cannot be used in URL requests. The Web Agent checks the characters in the URL that occur before the "?" character against the list in this parameter. If any of the specified characters are found, the Web Agent rejects the request.

   You can specify the following characters:

   • a backward slash (\)
   • Two forward slashes (//)
   • Period and a forward slash (./)
   • Forward slash and a period (/.)
   • Forward slash and an asterisk (/*)
   • An asterisk and a period (*.)
   • A tilde (~)
   • %2d
   • %20
   • %00-%1f
   • %7f-%ff
   • %25

   Separate multiple characters with commas. Do not use spaces.

   You can use the bad URL characters in CGI parameters if the question mark (?) precedes the bad URL characters.

   Default: //,./,/.,/*,*.,~,\,%00-%1f,%7f-%ff,%25

   Limits:

   • The default hexadecimal numbers apply to English characters. For other languages, remove any hexadecimal values that correspond to the characters of the language that you want to allow. Examples of such languages include (but are not limited to), Brazilian Portuguese, French, Japanese, and Chinese.
   • You can specify characters literally. You can also enter the URL-encoded form of that character. For example, you can enter the letter a, or you can enter the encoded equivalent of %61.
   • You can specify a maximum number of 4096 characters (including commas that are used for separating characters).
   • You can specify ranges of characters that are separated with hyphens. The syntax is: starting_character-ending_character. For example, you can enter a-z as a range of characters.

   Specify any quotation marks (") with the URL-encoded equivalent of %22. Do not use ASCII.

4. Remove the following values from the BadURLChars list:

   ,%25
   

5. Save the changes to your LocalConfig.conf file, and then close the text editor.
6. Repeat Steps 1 through 5 on all web servers which you want to change.

   Windows credential collectors are allowed to process HTTP encoded characters in TARGET URLs.

FCC Directive for Encoding Query Strings of Redirect URLs

You can encrypt the query strings of redirect URLs for credential collectors. The credential collectors provide the keys that are used to encrypt the query data.

For forms authentication schemes, the query string directive, smquerydata, is part of the FCC template. The agent serving the FCC uses this directive to send the encrypted query data to the target agent when the FCC is posted.

The following directive is used:

<INPUT type='hidden' name='smquerydata' value='$$smquerydata$$>

Note: If you are using custom FCCs, add the smquerydata directive with other FCC directives, such as TARGET to the custom FCC.

SiteMinder r12.0 SP3 agents with the SecureUrls parameter enabled can operate only with credential collectors served from other agents that support this functionality.

How to Configure the FCC to Allow Windows Authentication

The SiteMinder Forms Credential Collector (FCC) is designed to enable CA Services to trigger custom authentication schemes securely. As such, the FCC can authenticate users against any authentication scheme. However, the FCC does not authenticate against Windows authentication schemes by default. This behavior prevents an attacker from exploiting the FCC to generate a SiteMinder session for any valid Windows user in certain configurations.

If your environment requires the FCC to authenticate against the Windows authentication scheme, you can enable it by specifying the EnableFCCWindowsAuth agent configuration parameter. However, before you enable FCC support for Windows authentication, review the risks of doing so and be aware of configurations that expose the vulnerability.

1. Review the risks of enabling the FCC to allow Windows authentication.
2. Configure the FCC to allow Windows authentication.

Risks of Enabling the FCC to Allow Windows Authentication

By default, the FCC does not authenticate against Windows authentication schemes. You can enable the FCC to allow Windows authentication. However, doing so exposes a vulnerability whereby an attacker could use an FCC to generate a SiteMinder session for any valid Windows user in certain configurations.

The vulnerability is present in configurations in which the same SiteMinder Agent name or Agent group name is used in both an HTML Forms-protected realm and a Windows-protected realm. For example, a configuration in which a single Web Agent is configured to protect different realms that are configured with HTML Forms and Windows authentication.

Consider the following example scenario:

• Resource A is configured in a realm protected using HTML Forms authentication. The FCC challenges users accessing Resource A with an HTML form.
• Resource B is configured in a realm protected using Windows authentication. Users accessing Resource B complete Windows authentication.
• Both resources are hosted on the same IIS Server and are protected by the same Web Agent. Both realms are therefore configured with the same Agent name.

The attack occurs as follows:

1. The attacker modifies the TARGET parameter in the HTML form from "Resource A" to "Resource B."
2. The attacker submits the form with any valid Windows username.
3. The FCC passes the username to the Policy Server for authentication. SiteMinder executes the Windows authentication scheme instead of the HTML Forms authentication scheme and the username is validated.

The result is a SiteMinder session returned to the user which enables single sign-on for all following requests where the new session is considered valid. The attacker is now impersonating the user whose Windows username was submitted to the FCC.

Configure the FCC to Allow Windows Authentication

You configure the FCC to allow Windows authentication by specifying the following agent configuration parameter:

EnableFCCWindowsAuth

Specifies whether an agent, acting as an FCC, can authenticate users against resources that the SiteMinder Windows authentication scheme protects.

This parameter uses the following values:

• Yes—FCCs can authenticate against a Windows authentication scheme.

  Important! When this parameter is set to Yes, an attacker can potentially exploit the FCC to impersonate Windows users without providing required credentials.

• No—FCCs cannot authenticate against a Windows authentication scheme.

Default: No