Siteminder 6.x Policy Server to LDAP User Directory Connections.
Article ID: 54152
Updated On:
Products
Issue/Introduction
Description:
The following is a summary of the connection model used by the 6.x Policy Server when communicating to a typical LDAP User Directory.
Solution:
The Policy Server creates four connections to a given LDAP directory: management, bind, select and ping. Each connection is independent of the others. Note that the management connection is a legacy connection, and will normally time out and disconnect.
- The 'ping' thread runs periodically, and issues a command via its LDAP directory connection to test for connectivity.
- The 'bind' (or 'user') connection performs the authentication requests.
- The 'select' (or 'search') connection performs LDAP searches and other long running commands.
- The 'management' (or 'admin') connection is a legacy connection, that will normally idle out.
Please see the following table for usage details of each connection:
Table summarizes connections created by policy server to LDAP directories
| Connection | Purpose | When created | When released | Who creates |
| Ping | Check availability of servers | For each server in a fail-over group upon first request | When a network error is received on a ping request | Ping thread |
| User | User authentication | When either there is no user connection to a selected server from the current fail-over group or the current user connection had to be re-initialized | After being in a bad connection list for 10 minutes | Request thread |
| Search | Searches and updates | When either there is no user connection to a selected server from the current fail-over group or the current user connection had to be re-initialized | After being in a bad connection list for 10 minutes | Request thread |
| Referral ping | Check availability of referred servers | When a referral to a non-configured server is received. Note that there can not be both ping and referred ping connections | After being in a bad connection list for 10 minutes | Referral ping thread |
| Referred | Searches and updates | When a referral to a non-configured server is received. Note that there can not be both search and referred connections | After being in a bad connection list for 10 minutes | Request thread |
| The table below summarizes threads that are created during a user directory initialization | ||||
| Ping | Check for availability of the configured servers | For each serve in a fail-over group upon first request to the user directory | When policy server shuts down | Request thread |
| Referral ping | Check for availability of referred server | When first referral to a non-configured server is received. Only one referral ping thread is created per user directory instance | When policy server shuts down | Request thread |
Each connection performs actions depending on load, at different rates. If the connection has not performed an action before the LDAP idle timeout, the LDAP directory terminates the connection. The connections that most are frequently terminated by LDAP idle timeout are the 'select' connection and then the 'management' connection.
Due to the fact that the ping thread generally performs health check every six seconds it is typically not affected by the LDAP idle timeout.
When the Policy Server wishes to reconnect to LDAP after a termination, it begins with the primary LDAP directory server, and continues down the list of servers until it finds an available one.
Environment
Component: SMPLC
Feedback
