IIS Web Server Settings

Contents
sm1252sp1
Contents
Use any of the following settings to manage your Agent for IIS:
Configure Agents for IIS to Obtain User Credentials Without Redirecting to an NTLM Credential Collector (NTC)
By default,
CA Single Sign-On
Agents redirect requests for resources protected by the Windows authentication scheme to an NTLM credential collector (NTC) to retrieve their Windows credentials.
You can configure
CA Single Sign-On
Agents for IIS to obtain the credentials of the user from the HTTP request inline (that is, without redirecting to an NTC).
The following illustration describes the differences between the two credential collection methods:
SSO--Inline Credentials Parameter Behavior
SSO--Inline Credentials Parameter Behavior
To configure an agent to obtain credentials of the user from the HTTP request without redirecting to an NTC, set the InlineCredentials configuration parameter as follows:
InlineCredentials
Specifies how the Agent for IIS handles user credentials. When the value of this parameter is yes, the Agent for IIS reads the credentials directly from the HTTP request. When the value of this parameter is no, the Agent redirects to an NTC credential collector.
Default
: No
Note:
If any
CA Single Sign-On
Agents in your environment are configured to use NTC redirects, configure NT challenge/response authentication.
Record the User Name and Transaction ID in IIS Server Logs
The Web Agent generates a unique transaction ID for each successful user authorization request. The Agent adds the ID to the HTTP header. The ID is also recorded in the following logs:
  • Audit log
  • Web server log (if the server is configured to log query strings)
  • Policy Server log
You can track user activities for a given application using the transaction ID.
For more information, see the Policy Server documentation.
The transaction ID appears in the log as a mock query parameter in the log that is appended to the end of an existing query string. The following example shows transaction ID (in bold) appended to a query string (which ends with STATE=MA):
172.24.12.1, user1, 2/11/00, 15:30:10, W3SVC, MYSERVER, 192.168.100.100, 26844, 47, 101, 400, 123, GET, /realm/index.html, STATE=MA&SMTRANSACTIONID=0c01a8c0-01f0-38a47152-01ad-02714ae1
If no query parameters are in the URL, the Agent adds the transaction ID at the end of the web server log entry. For example:
172.24.12.1, user1, 2/11/00, 15:30:10, W3SVC, MYSERVER, 192.168.100.100, 26844, 47, 101, 400, 123, GET, /realma/index.html, SMTRANSACTIONID=0c01a8c0-01f0-38a47152-01ad-02714ae1.
Web Agents log user names and access information in native web server log files when users access resources.
Agents protecting resources on IIS servers do
not
record the
CA Single Sign-On
transaction ID and authenticated user name in the IIS server logs by default. Because these agents can operate as ISAPI extensions (in Classic Pipeline mode), the server would have already logged a transaction. You can force the agent to add this information with the following parameters:
AppendIISServerLog
Instructs the agent to add the authenticated user name and 
CA Single Sign-On
 transaction ID to the cs-uri-query field of the IIS server log. For URLs containing query strings, commas separate the query string, 
CA Single Sign-On
 transaction ID, and username in the cs-uri-query field of the IIS server log.
Default:
 No
SetRemoteUser
Specifies a value for the 
REMOTE_USER
 HTTP header variable which legacy applications could possibly require.
Default:
 No
To record the transaction ID and user name in the IIS server log.
  1. Set the value of the AppendIISServerLog parameter to yes.
  2. Set the value of the SetRemoteUser parameter to yes.
    The user name and transaction ID appears in the IIS server logs.
Use the NetBIOS Name or UPN for IIS Authentication
In an IIS network, you may have a NetBIOS name that is different than the domain name for the location of a requested resource. When a user tries to access a protected resource and there are multiple domain controllers, user authentication fails and the web server log shows an "IIS logon failure." You can control whether the UPN or NetBIOS name is sent to the IIS web server with the following parameter:
UseNetBIOSforIISAuth
Specifies whether the IIS 6.0 Web Agent sends the user principal name (UPN) or the NetBIOS name to the IIS 6.0 web server for IIS user authentication.
This parameter is valid only if an Active Directory user store is associated with the Policy Server.
If you enable this parameter, the Policy Server extracts the UserDN, the UPN, and the NetBIOS name from the Active Directory during 
CA Single Sign-On
 authentication, and sends this data back to the IIS 6.0 Web Agent.
Depending on whether or not you selected the Run in Authenticated User's Security Context option for the user directory with the Administrative UI and how you set the UseNetBIOSforIIAuth parameter, a user's logon credentials are sent as follows:
  • When the UseNetBIOSforIISAuth parameter is set to no, the IIS 6.0 Web Agent sends the UPN name.
  • When the UseNetBIOSforIISAuth parameter is set to yes, the Web Agent sends the NetBIOS name.
The IIS web server authenticates the user with the credentials it receives from the Web Agent.
Default:
 No
To have the Web Agent use the NetBIOS name for IIS authentication, set the UseNetBIOSAuth parameter to yes.
Configure Agents for IIS to Support NT Challenge/Response Authentication
If any
CA Single Sign-On
Agents in your environment are configured to use NTC redirects, configure NT challenge/response authentication.
With NT challenge/response authentication, the IIS web server challenges the Internet Explorer browser of a user when that user requests access to a resource.
NT challenge/response authentication only works with Internet Explorer browsers.
You can implement NT challenge/response authentication in either of the following ways:
  • Challenge users when they try to access protected resources. Users in single-sign on environments are only challenged the first time that they request a resource.
  • Have your users configure the automatic logon feature of their Internet Explorer browser.
    The automatic logon feature allows users to access a resource without being challenged. The authentication process still takes place, but the NT challenge/response process between the browser and the server is transparent to the user. Automatic logon is typically used for Intranets where security is less strict and you want users to have seamless access to resources. We do not recommend using the Automatic logon feature for communication across the Internet.
CA Single Sign-On
Agents use credential collectors to gather the Windows credentials of users for the NT challenge/response authentication scheme. The agent supports the NTC extension for collecting NTLM credentials.
Set the NTCEXT only if you want to change this default behavior.
To make
CA Single Sign-On
operate with NT challenge/response authentication, use the following process:
  1. Set up the NT Challenge response authentication for the IIS web server with the following tasks:
  2. Configure policies for NT Challenge/Response authentication using the Administrative UI.
  3. (Optional) Have your users configure the automatic logon feature of their Internet Explorer browser.
    The NT Challenge Response Authentication for IIS is configured.
Map the .NTC File Extension
Map the .NTC file extension to the ISAPIWebAgent.dll application to configure NT Challenge/Response Authentication on the IIS Web Server.
To map the .NTC file extension
  1. Open the Internet Services Manager.
  2. Right-click Web Sites in the left pane, and then right-click Default Web Site in the right pane and select Properties.
    The Default Web Site Properties dialog appears.
  3. Click the Home Directory tab.
  4. In the Application Settings section, click Configuration.
    The Application Configuration dialog appears.
  5. Click Add.
    The Add/Edit Application Extension Mapping dialog opens.
    1. In the Executable field, click Browse and locate the following file:
      web_agent_home
      /bin/ISAPIWebAgent.dll.
    2. Click Open.
    3. In the Extension field, enter .ntc.
  6. Click OK three times.
    The Add/Edit Application Extension Mapping dialog, the Application Configuration dialog and the Default Web Site Properties dialog close. The .ntc file extension is mapped.
Create and Configure the Virtual Directory for Windows Authentication Schemes (IIS 7.5)
To use the
CA Single Sign-On
Windows authentication scheme, configure a virtual directory on the IIS 7.x web server. The virtual directory requires Windows challenge and response for credentials.
Follow these steps:
  1. Open the Internet Information Services (IIS) Manager.
  2. In the left pane, expand the following items:
    • The web server icon
    • The Sites folder
    • The Default Web Site icon
  3. Right-click the siteminderagent virtual directory, and then select Add Virtual Directory.
    The Add Virtual Directory dialog appears.
  4. In the Alias field, type the following value:
    ntlm
  5. Click the Browse button (next to the Physical Path field), and then locate the following directory:
    web_agent_home
    \samples
    The virtual directory is created.
  6. Configure the virtual directory with
    one
    of the following steps:
    • To protect all the resources on the entire website with the
      CA Single Sign-On
      Windows authentication scheme, click the Default Web Site icon.
    • If you do
      not
      want to protect the entire website, with the
      CA Single Sign-On
      Windows authentication scheme, click the ntlm virtual directory (you created in Step 4).
  7. Double-click the Authentication icon.
    The Authentication dialog appears.
  8. Do the following steps:
    1. Right-click Anonymous Authentication, and then select Disable.
    2. Right-click Windows Authentication, and then select Enable.
      The virtual directory for Windows authentication schemes is configured.
    Reboot the web server for these changes to take effect.
Configure the Windows Authentication Scheme for Challenge/Response Authentication
To implement NT Challenge/Response authentication, provide the policy administrator responsible for configuring the Windows authentication scheme with the following values:
  • Server Name
    The fully qualified domain name of the IIS web server, for example:
    server1.myorg.com
  • Target
    /siteminderagent/ntlm/smntlm.ntc
    The directory must correspond to the virtual directory already configured by the installation. The target file, smntlm.ntc, does not need to exist and can be any name that ends in .ntc or the custom MIME type that you use in place of the default.
  • Libra!ry
    smauthntlm
Specify an NTLM Credential Collector
The NTLM credential collector (NTC) is an application within the Web Agent. The NTC collects NT credentials for resources that the Windows authentication scheme protects. This scheme applies to resources on an IIS web server that are accessed by Internet Explorer browsers.
Each credential collector has an associated MIME type. For IIS, the NTC MIME TYPE is defined in the following parameter:
NTCExt
Specifies the MIME type that is associated with the NTLM credential collector. This collector gathers NT credentials for resources that the Windows authentication scheme protects. This scheme applies to resources on IIS web servers that only Internet Explorer browser users access.
You can have multiple extensions in this parameter. If you are using an Agent Configuration Object, select the multivalue option. If you are using a local configuration file, separate each extension with a comma.
Default:
 .ntc
If your environment already uses the default extension that the NTCExt parameter specifies, you can specify a different MIME type.
To change the extension that triggers the credential collector, add a different file extension to the NTCExt parameter.
Configure Automatic Logon for Internet Explorer
To authenticate users
without
the agent challenging them for their credentials, Internet Explorer browser users must configure the Automatic Logon browser security setting.
Follow these steps:
  1. Start the Internet Explorer browser.
  2. Open the Internet Options dialog. (Refer to the Internet Explorer online help to find out how to open the dialog for your version of the browser).
  3. Click the Security tab.
  4. Click the correct security zone.
  5. Click Custom Level.
  6. Scroll down to the User Authentication section. Under the Logon option, click the Automatic Logon with current username and password option.
  7. Apply the changes.
    The Security Settings dialog and the Internet Options dialog close. Your settings are saved, and automatic login is configured.
How to Implement an Information Card Authentication Scheme
CA
CA Single Sign-On
supports an Information Card Authentication Scheme (ICAS) that implements Windows CardSpace. Users who request access to protected resources can select an authentication card.
CA Single Sign-On
uses the information contained in the card to verify the identity of the user.
Implementing an ICAS requires configuration changes on the following
CA Single Sign-On
components:
  • The server hosting the
    CA Single Sign-On
    Web Agent
  • The
    CA Single Sign-On
    Policy Server
  • The smkey database
Follow these steps:
  1. Do the following tasks on the web server:
    1. Enable SSL communication on the IIS web server.
      For more information, see your Microsoft documentation, or go to http://support.microsoft.com/
    2. Export the web server certificate as a .pfx file.
    3. Customize the
      CA Single Sign-On
      InfoCard.fcc template.
  2. Do the following tasks on the Policy Server:
    1. Install the JCE on the Policy Server.
    2. Update the java.security file on the Policy Server.
    3. Update the config.properties file on the Policy Server.
    4. If you do not already have an smkey database, Create one with the Policy Server Configuration wizard.
    5. Add the .pfx file certificate from the web server to the smkey database.
    6. Configure the user directory in the Policy Server.
    7. Create a custom authentication scheme for CardSpace using the Administrative UI.
    8. (Optional) Store the claims in the session store to use in responses.
    9. (Optional) Enable personalization by allowing the retrieval of claim values from the session store.
    10. (Optional) Configure an active response to retrieve a stored claim value.
Configure an FCC Template for an Information Card Authentication Scheme
The
CA Single Sign-On
Web Agent includes a Forms Credential Collector (FCC) template that you can use to implement an ICAS in
CA Single Sign-On
.
Follow these steps:
  1. Open the following default FCC file with a text editor:
    web_agent_home
    \samples_default\forms\InfoCard.fcc
  2. Save a
    copy
    of the file to the following directory (creating a copy preserves the default FCC settings in case you need them later):
    web_agent_home
    \samples\forms\
  3. Record the following information from your copy of the FCC file:
    The Policy Server needs this information for its configuration.
    • The fully qualified domain name of the IIS web server that hosts the Web Agent.
    • The name of the FCC file you saved in Step 2.
    • The value (
      without
      quotation marks) of the requiredClaims parameter tag in the FCC file from Step 2. See the following example:
      http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
    • (Optional) The value of Level of Assurance (LOA) requiredClaims parameter tag when White List processing is done. See the following example:
      < param name="requiredClaims" value=" http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assurancelevel1 "/>
      The URIs for the various LOA’s are
      http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assurancelevel1 http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assurancelevel2 http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assurancelevel3
  4. (Optional) Use the text editor to make any of the following changes in copy of the FCC file.
    • To use a custom logo, replace the netegrity_logo.gif file with your own graphic and update the following link in the FCC file accordingly:
      <img alt="Logo" src="/siteminderagent/dmspages/netegrity_logo.gif">
Control IIS 7.x Module Execution Order when using the
CA Single Sign-On
Agent for IIS
When you install and configure the 
CA Single Sign-On
 Agent for IIS on an IIS web server, the Agent for IIS executes before any other modules. If your IIS environment requires another module to execute first, you can change the number set the following location in the Windows Registry:
32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Netegrity\SiteMinder Web Agent\Microsoft IIS\RequestPriority
64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder Web Agent\Microsoft IIS\RequestPriority
For example, suppose another module in your IIS 7.x web server (like UrlScan) is assigned the same execution priority as the 
CA Single Sign-On
 Agent for IIS. Use this setting to control when the 
CA Single Sign-On
 module executes.
Follow these steps:
  1. Open the Windows Registry Editor on your IIS web server.
  2. Expand the following keys:
    32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Netegrity\SiteMinder Web Agent\Microsoft IIS
    64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder Web Agent\Microsoft IIS
  3. Locate the following value:
    RequestPriority
  4. Change the value of RequestPriority to the number which corresponds to the following value you want:
    • PRIORITY_ALIAS_FIRST
      Executes the CA Single Sign-On Agent for IIS before any other modules on your IIS web
      server. This setting is the default.
      Example:
       0 (First)
      Default:
       0
    • PRIORITY_ALIAS_HIGH
      Executes the CA Single Sign-On Agent for IIS module after any modules set to execute first, but before any modules set to execute with medium, low or last priority.
      Example
      : 1 (High)
    • PRIORITY_ALIAS_MEDIUM
      Executes the CA Single Sign-On Agent for IIS module after modules set to execute first and high, but before modules set to execute with low or last priority.
      Example:
       2 (Medium)
    • PRIORITY_ALIAS_LOW
      Executes the CA Single Sign-On Agent for IIS module after modules set to execute first, high, and medium, but before modules set to execute with last priority.
      Example:
       3 (Low)
    • PRIORITY_ALIAS_LAST
      Executes the module for the CA Single Sign-On Agent for IIS after all other modules.
      Example:
       4 (Last)
  5. Save your changes and close the registry editor.
  6. Test your settings and verify that the module you want executes before the Agent for IIS module executes.
Use an IIS Proxy User Account (IIS Only)
If users try to access resources on an IIS web server protected by
CA Single Sign-On
, the Web Agent may deny access if those users lack sufficient IIS privileges for those resources. For example, if users are stored in an LDAP user directory on a UNIX system, those users may not have access to the Windows system with the IIS web server.
The IIS web server has a default proxy account that has sufficient privileges for users who are granted access by
CA Single Sign-On
. The Web Agent uses the values of the DefaultUserName and DefaultPassword parameters as credentials even if the user has a valid Windows security context.
Follow these steps:
  1. Set the value of the ForceIISProxyUser parameter to
    one
    of the following values:
    • If access to the applications on the IIS server is based on the users' credentials themselves, set the value of the ForceIISProxyUser parameter to yes.
    • If access to the applications on the IIS server is based on a specific account (such as a proxy) which acts on behalf of the users, set the value of the ForceIISProxyUser parameter to no.
    Default:
    No
  2. If you are
    not
    using either of the following Windows features, continue with Step 3:
    • The Windows authentication scheme
    • The Windows User Security Context
  3. Enter the user name for the proxy user account in the DefaultUserName parameter. If you are using a domain account, and the local machine is not a part of that domain, use the syntax shown in the following example:
    DefaultUserName=
    Windows_domain
    \
    acct_with_admin_privilege
    Otherwise, specify just the user name.
  4. Enter the password associated with the existing Windows user account in the DefaultPassword parameter.
    We recommend setting this parameter in your Agent Configuration Object because you can encrypt it. If you set it in a local configuration file, the value is stored unencrypted in plain text.
    The IIS Proxy account is configured.
Enable Anonymous User Access
If you do not want users to have access as the proxy user, you can set the following parameter:
UseAnonAccess
Instructs the IIS Web Agent to execute the web application as an anonymous user, instead of using credentials of the proxy user.
Default:
 No 
This parameter applies to IIS Web Agents only.
To enable anonymous user access, set the UseAnonAccess parameter to yes.
Disable Windows Security Context on Agents for IIS
The
CA Single Sign-On
Policy Server obtains the Windows security context from the session of the user. In most situations, this environment is acceptable for single-sign on because the session information is available to all agents.
The following situation provides an example of a situation where different settings are required for single-sign on:
  • One
    CA Single Sign-On
    agent uses the Windows security context.
  • Another
    CA Single Sign-On
    agent does not use the Windows security context.
This situation is shown in the following illustration:
SSO--DisableWindowsSecurity Context Parameter Effects
SSO--DisableWindowsSecurity Context Parameter Effects
To permit SSO between a Windows domain using Windows security context and a Windows workgroup not using Windowssecurity context, set the following parameter:
DisableWindowsSecurityContext
Disables the Windows security context for the agent. When the value of this parameter is yes, the agent ignores the Windows security context of the user. When the value of this parameter is false or no, the agent uses the Windows security context contained in the session of the user. This parameter allows single-sign on between Windows environments which use the security context Windows environments that do not.
Default
: False
Limits
: Yes, No
Prevent Caching of Server Responses Containing Cookies
IIS web servers use output caching to store their responses. Responses to agents contain cookies. If the IIS web server sends an authentication response from its output cache, a different user could receive the authentication cookie in the cached response.
For example, user one authenticates successfully and the IIS server caches the response with the cookie. If user two accesses the same resource as user one, the IIS web server could possibly return the response for user one to user two.
The product disables the IIS output cache for items containing cookies by default. To revert to the behavior of the previous versions of the product for backward compatibility, change the value of the following parameter to no:
IISCacheDisable
Specifies if the IIS web server stores responses containing cookies in an output cache. The IIS web server sends cached responses before 
CA Single Sign-On
 processing occurs. Disabling the output cache forces IIS to authenticate and authorize each transaction. Setting the value of the parameter to yes prevents one user from accidentally receiving authentication or authorization responses that are meant for another user.
Default
: Yes (cache disabled)
Determine when the Agent for IIS Sets Cookies
CA Single Sign-On
Agents for IIS support the Application Request Routing (ARR) feature that IIS 7.x web servers offer. ARR operates on a Microsoft IIS web server similar to the reverse proxy server feature provided by other web server vendors.
All
CA Single Sign-On
agents process cookies. Situations for controlling when the cookie processing occurs include any of the following conditions:
  • ARR is used.
  • The value of the FCCCompatMode agent configuration parameter is yes.
  • You are using a custom agent (developed with the
    CA Single Sign-On
    SDK).
Controlling when the agent processes the cookie maintains security by enforcing
CA Single Sign-On
protection levels.
Some deployments of 
CA Single Sign-On
 agents require that the 
CA Single Sign-On
 cookie processing at a particular point in a transaction. All 
CA Single Sign-On
 agents use and process cookies. Some circumstances require processing a cookie earlier in a transaction. Other circumstances require processing a cookie later. Processing cookies at the proper time verifies that 
CA Single Sign-On
 properly protects your resources.
 
Processing cookies at the wrong time affects protection levels. The additional processing that the ARR feature performs requires changing the relative time at which the
CA Single Sign-On
agent processes the cookie.
Follow these steps:
  1. From the Administrative UI, open the agent configuration object that you want.
  2. Locate the following parameter:
    • EarlyCookieCommit
      Specifies if cookies are set at an early point during processing or at a later point. Set the value of this parameter to yes when any of the following conditions exist:
      • The IIS web server uses Application request routing (ARR).
      • The value of the FCCCompatMode parameter is yes.
      • You are using a custom agent (developed with the 
        CA Single Sign-On
         SDK).
      When this value is yes, cookies are committed (earlier) after the web agent processes the request using the OnAuthenticateRequest or OnPostAuthenticateRequest notification methods.
      Set the value of this parameter to yes to preserve the behavior of earlier 
      CA Single Sign-On
       agents for any custom applications requiring early cookie processing.
      When this value is no, cookies are committed into the response (later) at the end of the pipeline during the OnSendResponse request notification method.
      Limits
      : Agents for IIS 7.x only. This setting only supports web applications that use Integrated pipeline mode.
      Default
      : No (cookies are set (later) during the OnSendResponse request notification method).
  3. Click the value field, and then change the value of the previous parameter to yes.
  4. Click OK.
  5. Click Submit.
    A confirmation message appears.