Implementation Guide › Architectural Considerations › Implementation Considerations › Operating Systems › Password Policy Considerations

Password Policy Considerations

If you plan to implement password policies in your enterprise, consider the following:

• SiteMinder needs read and write access to the user directory, including exclusive use of several attributes within that directory to store passwords and password–related information.
• Password policies can affect SiteMinder performance because of the additional user directory searches required to validate passwords. Password policies that are configured to search only part of a user directory, instead of the entire directory, can also affect performance.
• If your user directory has a native password policy, this policy must be:
  • Less–restrictive then the SiteMinder password policy or
  • Disabled

  Otherwise the native password policy accepts or reject passwords without notifying SiteMinder. Consequently, SiteMinder cannot manage those passwords.

• If you use password policies on multiple Policy Servers, the system times of all the servers must be synchronized to avoid disabling accounts or forcing password changes prematurely.

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

Identify Who Will Manage Your Web Agents

Web Agents connect to a Policy Server upon startup. The Policy Server contains an Agent Configuration Object (ACO), which directs the associated Web Agent to the location of its configuration parameters.

How your applications are deployed throughout your organization can help you determine the most efficient method of storing the configuration parameters for your SiteMinder Web Agents. Consider the following questions:

1. Are most of your web applications deployed on a large server farm with the same security requirements?
2. Are most of your web applications managed by a centralized person or group?
3. Are most of your web applications deployed on separate web servers with different security requirements?
4. Are most of your web applications managed by different personnel in different departments or physical locations?

If you answered yes to questions one or two in the previous list, try the following configuration method:

Central Configuration

Manages the parameters for one or more agents from an agent configuration object (ACO) that resides in the Policy Server. With a central agent configuration, you can update the parameter settings of several agents at once. Generally, each distinct web application uses a separate ACO, whose settings are shared among all the agents that protect the web application. For example, if you have five agents protecting one accounting application, you can create one ACO with the settings that you want for the application. All five agents would use the parameter settings from the same ACO.

For different applications, we recommend using separate agent configuration objects. For example, if you want to protect a human resources application with stricter security requirements, create a separate ACO for the human resources application.

When an agent starts, it reads the AllowLocalConfig parameter values of its associated ACO. When the value is set to no, then the agent uses the parameter settings from the ACO (except the agent log and trace file settings). Agent log files and trace files can always be controlled locally, regardless of ACO settings.

Note: We recommend using central agent configuration (wherever possible) because it simplifies agent configuration and maintenance.

If you answered yes to questions three or four in the previous list, try the following configuration method:

Local Configuration

Manages each Web Agent individually using a file installed on the web server itself. When a Web Agent starts, it reads the value of the AllowLocalConfig parameter of its associated Agent Configuration Object (ACO). If the value is set to yes, then the Web Agent uses the parameter settings from LocalConfig.conf file on the web server. The parameter settings from the LocalConfig.conf file override any settings stored in an ACO on the Policy Server.

Note: For more information about the location of the LocalConfig.conf file on your respective web server, see the Web Agent Configuration Guide.

The following questions can help you identify other situations where local agent configuration better serves the needs of your enterprise:

• Will your enterprise deploy some of your Web Agents on reverse proxy servers?

  For example, you want to protect your internal resources with a large group of Web Agents, while implementing reverse-proxy servers in a few locations. You can use local configuration to manage the reverse-proxy Web Agents.

• Do you want to allow local web server administrators to change some Web Agent configuration settings but not others?

  For example, your organization uses SiteMinder to manage and enforce security policies, but allows web server administrators in remote offices to customize their log on and log off pages. You can add individual parameters to the value of the AllowLocalConfig parameter of the ACO to allow the administrators to change only those settings for the customized pages but no others.

  Note: For more information, see the Web Agent Configuration Guide.

Central and Local Configurations Together

You can also use a combination of central and local configuration to meet your needs. For example, you can manage three similar web servers with central configuration, while managing the other two servers with local configuration. See the following illustration for an example:

Identify Data Centers

Multiple factors, which are discussed later, can influence how you decide to implement SiteMinder components across multiple data centers. Identifying the data centers and the purpose each is to serve in your SiteMinder environment prepares you to make informed decisions when determining how to implement SiteMinder components. Consider the following questions:

• How many data centers does your deployment include and where is each center located?
• If you have multiple data centers:
  • Will they all be active or are some only intended for disaster recover or backup?
  • Will each protected application reside in a single data center or across multiple centers?
  • Will you configure failover on the data center-level or across data centers?
  • What is the bandwidth and throughput between the data centers?

When gathering information about each data center, use a resource table similar to the following to organize your results:

More information:

Multiple Data Centers

Identify Resources to be Secured with Multiple Cookie Domains

Will the single-sign on environment in your enterprise extend across multiple cookie domains?

SiteMinder implements single sign-on across multiple cookie domains using a SiteMinder Web Agent configured as a cookie provider.

The cookie domain where the cookie provider Web Agent resides is named the cookie provider domain. All the other Web Agents from the other cookie domains within the single sign-on environment, point to one cookie provider.

The following illustration shows an example of an SSO environment using multiple cookie domains:

Note: For more information about cookie providers, see the Web Agent Configuration Guide.

Load-balancing for SSO between Cookie Provider Domains and Other Cookie Domains

Will the Agents in your single-sign on environment use load-balancing?

All agents in an SSO environment must refer to a single cookie provider domain. Add a load-balancer between the web servers in your cookie provider domain and the other cookie domains in your SSO environment. The following illustration shows an example:

The Web Agent in the example.org cookie domain points and the Web Agent in the example.com cookie domain both point to the same cookie provider domain of example.net. A load-balancer distributes the traffic evenly between all the web servers in the example.net cookie provider domain.