Policy Server Guides › Policy Server Configuration Guide › User Sessions › Windows User Security Context

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:

• Two levels of security

  You can protect web resources using all of SiteMinder’s capabilities with the additional benefit of working with Microsoft security tools to protect applications.

• The Web Agent can communicate with various web browsers and still provide a Windows security context.

  SiteMinder can work with any browser that supports HTTP 1.x requests, HTTP cookies, and where appropriate SSL/TLS

• The Agent can collect user credentials over SSL connections, then allow subsequent requests over non-SSL connections. SiteMinder combines this mechanism for credential collection with the Windows security context when permitting access to Web resources.
• SiteMinder can implement single sign-on using forms-based authentication, and can pass on a user identity to back-office applications.

  Microsoft does not provide general-purpose forms credential collection.

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:

• All IIS servers have to be trusted in the domain in which the user is authenticating. You can establish trust relationships among servers that provide distributed services for groups of users. To set up trust relationships, see Microsoft server documentation.
• Users must have the privileges to log on locally to the Web server. If there are multiple servers, users need the right to log on locally to all servers.

  To enable a user to log on locally, configure this feature through the IIS Administrative Tools. See Microsoft documentation for instructions.

• If you are using a specific domain account and not the system account when starting the World Wide Web Publishing Service, you must set the user’s account privileges to act as part of the operating system for the domain account running the service. This feature is configured through the Administrative Tools. See Microsoft documentation for detailed instructions.

Configuration Overview

Supported Authentication Schemes

The following authentication schemes are supported:

• Basic Authentication Schemes
• Basic Over SSL Authentication Schemes
• HTML Forms Authentication Schemes
• X.509 Client Certificate and Basic Authentication Schemes
• X.509 Client Certificate and HTML Forms Authentication Schemes

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.