If the bind attempt fails, then the connection reverts to an unauthenticated state. This behavior is dictated by LDAP specifications, and it is the appropriate behavior in most circumstances.

However, it might not be ideal for some applications, and especially those that support multiple concurrent users and use the PingDirectory server to authenticate those users. In such cases, connection pooling allows existing connections to be reused for multiple operations (and even operations that need to be processed under the authority of different users), which is much more efficient and resource-friendly than establishing a new connection for each request or maintaining a separate connection for each authenticated user. In such cases, performing a bind operation to verify a user’s identity might affect the application’s ability to reuse the connection for other purposes.

The most common way to address this in applications is to maintain two pools of connections. One that is used for only processing bind operations to verify user credentials, and a second that is used to process all other types of operations. However, the PingDirectory server offers an alternative that only requires the application to maintain a single pool: the retain identity request control. If this control is included in a bind request, then the server performs all of the usual processing for the bind operation, including identifying the user, verifying their credentials, and applying any necessary updates to their password policy state, but it does not affect the authentication state of the underlying connection. Regardless of whether the bind attempt succeeds or fails, the connection remains authenticated as the same account with the same authorization identity that it had before the bind was attempted.