Client connection policies can be used to control what a client can see or do at a very high level. You can use client connection policies to enforce a certain level of security that is not available through other mechanisms.

There are a number of common use cases for client connection policies:

  • Allow exceptions to requirement for secure connections based on a service account’s group membership
  • Limit the subtrees viewable or accessible to a client
    • Useful when storing both employee and customer data on the same server to logically isolate the branches from each other for most applications
  • Restrict access or disallow access to PingDirectory based on client IP address (for example, don’t allow adds/mod/writes from the Internet even if the account has ACIs granting those permissions)
  • Place restrictions on allowable search filters
  • Enforce limits on poorly behaving applications or applications that are yet to be vetted by the directory administrators
  • The calculation of expensive virtual attributes can be restricted so that they only occur over a specific connection policy

The client connection policy associated with a particular connection can change over time. The client connection policy will be determined:

  • When the connection is initially established
  • After any successful Bind operation
  • After a StartTLS request is received

Not a replacement for ACIs

Care should be taken not to rely too heavily on connection policies to enforce security that can be addressed at a lower level by ACIs or Privileges.

If you don’t want a particular user to have access to ou=Customers, for example, you could create a connection policy that prevents that user from seeing ou=Customers. However, ACIs should also be created to ensure that the user does not have access to those entries if a client connection policy mistake is made.


Creating new client connection policies can easily introduce issues in the client connection policy evaluation order and process a more permissive policy before the more restrictive policies.

Define unauthenticated/insecure policy

When clients connect to PingDirectory, the initial connection is almost always unauthenticated.

If you are deleting the default client connection policy (or modifying it), make sure that there is at least one client connection policy that allows for a connection to transition from an unauthenticated state to an authenticated state or to allow an unauthenticated connection to send a StartTLS control.

Set restrictive client connection criteria

The evaluation order defined for a client connection policy will determine which client connection policy a client receives if it meets the criteria for more than one client connection policy. This has the potential to create unexpected scenarios if a valid client connection state is not considered or tested during the design of the client connection criteria and client connection policies.

Best practice is to implement mutually exclusive client connection criteria where possible to reduce or eliminate reliance on the evaluation order index when a connection’s client connection policy is determined.