Web Agent Guides › Web Agent Configuration Guide › SSO Security Zones › IIS Web Server Settings

IIS Web Server Settings

Use any of the following settings to manage your Agent for IIS:

• Remove integrated windows authentication (IWA) redirection with the InlineCredentials parameter.
• Record the user name and transaction ID in IIS server logs.
• Use the NetBIOS name or UPN for IIS authentication.
• Configure NT Challenge/Response authentication.
• Implement an information card authentication scheme.
• Configure an FCC template for an information card authentication scheme.
• Control IIS 7.x module execution order.
• Use an IIS proxy user account.
• Enable anonymous user access.
• Disable Windows security context on an Agent for IIS.

Configure Agents for IIS to Obtain User Credentials Without Redirecting to an NTLM Credential Collector (NTC)

By default, CA SiteMinder® 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 SiteMinder® 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:

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 SiteMinder® Agents in your environment are configured to use NTC redirects, configure NT challenge/response authentication.

More information:

Configure Agents for IIS to Support 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.

Note: 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.

Note: 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 SiteMinder® 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 SiteMinder® transaction ID to the cs-uri-query field of the IIS server log. For URLs containing query strings, commas separate the query string, CA SiteMinder® 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.

Note: 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 SiteMinder® 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 SiteMinder® 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.

Note: 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 SiteMinder® 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.

Note: Set the NTCEXT only if you want to change this default behavior.

To make CA SiteMinder® 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:
   1. Map the .ntc file extension.
   2. Create and configure the virtual directory, and then verify that it requires the NT challenge and response credentials.
2. Configure the Windows authentication scheme for NT challenge/response authentication in the Administrative UI.
3. Specify an NTLM credential collector.
4. Configure policies for NT Challenge/Response authentication using the Administrative UI.

   Note: For more information, see the Policy Server Configuration Guide.

5. (Optional) Have your users configure the automatic logon feature of their Internet Explorer browser.

   The NT Challenge Response Authentication for IIS is configured.

More Information

Configure Agents for IIS to Obtain User Credentials Without Redirecting to an NTLM Credential Collector (NTC)

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 SiteMinder® 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 SiteMinder® Windows authentication scheme, click the Default Web Site icon.
   • If you do not want to protect the entire website, with the CA SiteMinder® 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.

   Note: 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

Note: 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.

Library

smauthntlm

More Information

MIME Types for Credential Collectors

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 SiteMinder® supports an Information Card Authentication Scheme (ICAS) that implements Windows CardSpace. Users who request access to protected resources can select an authentication card. CA SiteMinder® uses the information contained in the card to verify the identity of the user.

Implementing an ICAS requires configuration changes on the following CA SiteMinder® components:

• The server hosting the CA SiteMinder® Web Agent
• The CA SiteMinder® 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.

      Note: 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 SiteMinder® 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 SiteMinder® Web Agent includes a Forms Credential Collector (FCC) template that you can use to implement an ICAS in CA SiteMinder®.

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:

   Important! 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 SiteMinder® Agent for IIS

When you install and configure the CA SiteMinder® 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:

HKLM\SOFTWARE\Wow6432Node\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 SiteMinder® Agent for IIS. Use this setting to control when the CA SiteMinder® module executes.

Follow these steps:

1. Open the Windows Registry Editor on your IIS web server.
2. Expand the following keys:

   HKLM\SOFTWARE\Wow6432Node\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 SiteMinder® 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 SiteMinder® 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 SiteMinder® 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 SiteMinder® 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 SiteMinder® 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 SiteMinder®, 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 SiteMinder®. 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.

   Important! 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

Note: 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 SiteMinder® 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 SiteMinder® agent uses the Windows security context.
• Another CA SiteMinder® agent does not use the Windows security context.

This situation is shown in the following illustration:

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