Skip links

Accelerate SiteMinder Authentications

You can significantly enhance the performance of Symantec SiteMinder authentications for LDAP-based user directories. SiteMinder is an I/O bound product, meaning that constrained I/O performance has a significant impact on the performance of the product. As a result, network latency or disk I/O can reduce the throughput of the policy server. The server management tools available to most server administration groups can easily identify such issues, but proper configuration of the user directory object can result in a significant improvement in performance.

Many SiteMinder administrators create a highly available user directory configuration within the SiteMinder WAMUI using failover groups to ensure operational availability. This is a sound practice, but many administrators are unaware that SiteMinder performance can also be improved by defining user directory load balance groups that share the same IP multiple times.

How SiteMinder Uses LDAP Connections

SiteMinder maintains 3 ldap connections for each uniquely named directory instance in a user store object. Each connection has an unique role:

  • directory management
    • ensures the connection to the user store is still viable and determines when failover is required
  • search (authorizations)
    • performs user lookups policy evaluation
  • bind (authentications)
    • performs binds to validate the users credentials for authentications

For example, if your LDAP hostname is ldap1, the policy server will open three connections: ldap1Dir, ldap1Az, and ldap1Auth. The policy server is multithreaded, but the bottleneck for authentication in this case would be the ability to service the authentication requests. The policy server and web agents will cache authorization information, which allows for greater throughput for the policy and web servers, but authentication information is not cached and must be validated against the source each time.

Achieving Greater Performance

To overcome this constraint, multiple connections to the user store should be defined via hostname aliases. The LDAP library used in the product establishes a group of connections per named alias and as a result using the same hostname multiple times would not give the desired result.

In the following example, there are four load balanced groups each with a failover pair.

This configuration can leverage either DNS entries for the hostnames or a host file. The following is an example of using a host file.

10.0.1.1 ldap1A
10.0.1.1 ldap1B
10.0.1.1 ldap1C
10.0.1.1 ldap1D
10.0.1.2 ldap2A
10.0.1.2 ldap2B
10.0.1.2 ldap2C
10.0.1.2 ldap2D

More Lanes to service users.

This example only shows two servers, but this model can be expanded to support as many servers as necessary. In doing that, the only limit is the underlying storage for a user store object within the policy store. This is why we use short, non-domain qualified hostnames for the LDAP servers.

This change would provide a 300% increase in throughput for authentications. Although authorizations were not the topic of this post, the change would increase the throughput for authorizations as well. This could be useful in enhancing performance if your policy server is configured to use one of the non-default caching options.

Note: it is important to make sure both your policy server and downstream directory servers can support additional connections before implementing this change.

If you need assistance improving the performance of your SiteMinder infrastructure or deploying and hosting other enterprise security solutions, please consider contacting SIS.