Previous Topic: User SessionsNext Topic: Agents and Agent Groups


Windows User Security Context

In a Windows network, a security context defines a user identity and authentication information. Web applications such as Microsoft Exchange Server or SQL Server need a user security context to provide native security in the form of Microsoft access control lists (ACLs) or other access control tools.

Note: In a Windows security context, the user store must be Active Directory (AD).

The SiteMinder Web Agent can provide a Windows user security context for accessing web resources on IIS Web Servers (Windows 2000 platforms). By establishing a user security context, the server can use this identity to enforce access control mechanisms.

By providing a Windows user security context, SiteMinder offers the following benefits:

How Persistent Sessions for User Security Contexts Are Maintained

For the web agent to provide a security context for specific resources, enable persistent sessions for all realms that include those resources. The session store maintains persistent sessions.

Note: For conceptual information about persistent sessions, see Persistent and Non–persistent Sessions. For instructions on enabling persistent sessions for realms protected by web agents, see Configure a Realm.

The session store, which resides on the same system as the Policy Server, stores the encrypted credentials of a user and associates the user with a session ID. When a SiteMinder session is established between a client and a web agent, the Windows user account is established and linked to the session. If the user session cache of the web agent becomes full and entries are purged, the agent can retrieve the credentials of the user from the session store and re–establish the session. The session store also stores the security context because this context must be propagated across a single sign–on environment.

How Sessions Are Revalidated

You can explicitly configure the web agent, working through the Policy Server, to contact the session store to revalidate a session. A session cookie stored in the browser of the user contains the session ID. The cookie uses the session ID to reacquire the credentials of the user from the session store.

Note: If the session cookie becomes invalid, the credentials associated with the ID also become invalid, and the user must reauthenticate.

A configurable value, validation period, determines the frequency at which the agent revalidates a session. The validation period defines how long the agent can keep a session active using the information in its cache before contacting the session store for updates.

If the validation period is too small, the agent goes back to the session store frequently, slowing down SiteMinder performance when processing requests. Therefore, you want to set the validation value to a high number. If the number of active sessions is lower than the maximum user session cache value of the agent, the agent uses the cached information instead of contacting the session store.

Note: If the session store is not operating, the validation period is infinite and the agent does not contact the session store.

For instructions on configuring the validation period, see Configure a Realm.

Windows User Security Context Requirements

Your IIS Web server environment must meet the following requirements to use the Windows security context feature:

Configuration Overview

Step

SiteMinder component

Supporting documentation

Designate a relational database as the session store.

Data tab of SiteMinder Policy Server Management Console

SiteMinder Policy Server Administration Guide

Enable the user directory containing the Windows users to run the security context.

Use Authenticated User's Security Context check box on the Directory Setup group box on the User Directory pane

User Directories

Associate one of the Supported Authentication Schemes with each realm

Resource group box of the Realm pane

 

Configure a Realm

Enable persistent sessions for each realm and set a high Validation Enabled Period

Session group box of the Realm pane

Configure a Realm

If your IIS Web server is not in a physically secure location, set insecureserver to YES

Agent Configuration Object or WebAgent.conf

SiteMinder Web Agent Configuration Guide

Supported Authentication Schemes

The following authentication schemes are supported:

The Web Agent cannot use certificates alone because the user’s credentials are not provided. Certificate authentication must be combined with basic or forms to collect the user credentials.

You may want to use the NTLM authentication scheme to provide access to resources in a particular realm, such as those on an intranet. CA does not support selecting the NTLM authentication scheme as part of the Windows User Security Context configuration described in this section. However, you can use NTLM for some resources on a Web server and the Windows User Security Context mechanism (with a supported authentication scheme) for different resources on the same Web server. In that case, the resources accessed using NTLM need to be in a different realm than the resources accessed through the Windows User Security Context mechanism described in this section.

More information:

Authentication Schemes

Active Directory and NetBIOS Names

Although Active Directory domains are named according to DNS naming standards, a NetBIOS name must still be defined when creating Active Directory domains.

For SiteMinder to support seamless Microsoft security context, NetBIOS names should be named the same as the DNS domain name as recommended by Microsoft.

When the Active Directory domain has a DNS name that is different from its NetBIOS name, the user domain cannot be established for the web server to provide the security context when SiteMinder is configured to use an LDAP user directory.

Single Sign-on in Security Context

SiteMinder will provide single-sign-on across all supported web servers while preserving the security context required for seamless Microsoft security context.

However, this requires that any realm that may cause the user to be authenticated (and establish the SiteMinder session) be configured as “Persistent”. If the user authenticates in a realm that is not persistent, the user will be challenged again when SiteMinder needs to persist the security context.