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. Applications (such as Microsoft Exchange Server or SQL Server) need a user security context to provide security using Microsoft access control lists (ACLs) or other tools.

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

The 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, the product offers the following benefits:

• Two levels of security

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

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

  The product 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. The product combines this mechanism for credential collection with the Windows security context when permitting access to resources.
• The product 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 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.

The session store stores the encrypted credentials of a user and associates the user with a session ID. When a session is established between a client and an agent, the Windows user account is established and linked to the session. When the user session cache of the web agent is purged, the agent retrieves the credentials of the user from the session store. Retrieving the credentials lets the agent re–establish the session. The session store also stores the security context for propagation across single sign–on environments.

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 that is 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 expires, the credentials that are associated with the ID are invalidated. and the user must re‑authenticate.

The validation period, determines the frequency at which the agent revalidates a session. The validation period defines how long the agent keeps a session active using the information in its cache. After the validation period expires, the agent contacts the session store.

If the validation period is too small, the agent goes back to the session store frequently, affecting the speed at which the product processes requests. Set the validation value to a high number. When the number of active sessions is lower than the maximum user session cache value of the agent, the agent uses the cached information.

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

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 must 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.
• Users must have the privileges to log in locally to the web server. If there are multiple servers, users need the right to log in locally to all servers.
• Consider the following guidelines for accounts that start the World Wide Web Publishing Service:
  • System accounts need no additional configuration.
  • Domain accounts need the privileges of the associated user to act as part of the operating system.

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

  Agents cannot use certificates alone because the credentials of the user are not provided. Certificate authentication must be combined with basic or forms to collect the user credentials.

NTLM authentication schemes are not compatible with the Windows User Security Context for this product. Use NTLM for some resources on a web server and Windows User Security Context for different resources on the same web server. Resources that are accessed using NTLM must be in a different realm than the resources accessed through the Windows User Security Context mechanism.

More information:

Authentication Schemes

Active Directory and NetBIOS Names

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

For the product to support seamless Microsoft security context, NetBIOS names must match the DNS domain name as recommended by Microsoft.

When the DNS name of the Active Directory domain differs from its NetBIOS name, the user domain cannot be established. The web server cannot provide the security context when the product is configured to use an LDAP user directory.

Single Sign-on in Security Context

The product provides single-sign-on across all supported web servers while preserving the security context required for seamless Microsoft security context.

However, all realms must be persistent. Otherwise the users are challenged again when the product attempts to persist the security context.