Restricting server access based on client IP address
Two methods are available to limit client access to the PingDirectory server.
Connection Handlers
You can limit the IP addresses using the LDAP or LDAPS connection handlers. The connection handlers provide an allowed-client
property and a denied-client
property. The allowed-client
property specifies the set of allowable address masks that can establish connections to the handler. The denied-client
property specifies the set of address masks that are not allowed to establish connections to the handler.
Client Connection Policies
For a more fine-grained approach, restrict access by configuring a new client connection policy. Then, create a new connection criteria and associate it with the connection policy. A connection criteria defines sets of criteria for grouping and describing client connections based on a number of properties, including the protocol, client address, connection security, and authentication state for the connection. Each client connection policy can be associated with zero or more connection criteria. Server components can use connection criteria to indicate which connections to process and what kind of processing to perform, such as to select connections and operations for filtered logging or to classify connections for network groups.
Restricting server access using the connection handlers
Use dsconfig
to set the allowed-client
property for the LDAP connection handler.
Steps
-
Set the
allowed-client
property for the LDAP connection handler usingdsconfig
. -
Specify the address mask for the range of allowable IP addresses that can establish connections to the PingDirectory server.
-
To configure the server using the
dsconfig
tool on the local host, specify the loopback address to 127.0.0.1.Example:
$ bin/dsconfig set-connection-handler-prop \ --handler-name "LDAP Connection Handler" \ --set "allowed-client:10.6.1.*" \ --set allowed-client:127.0.0.1
Restricting server access using client connection policies
A client-established connection to the PingDirectory server is associated with a client connection policy. Use client connection policies to restrict the kinds of requests that the client can issue and impose resource limits for that connection.
Steps
-
Create a simple connection criteria.
Example:
The following example uses the
dsconfig
tool in non-interactive mode. It allows only the PingDirectory server’s IP address and loopback to have access.$ bin/dsconfig set-connection-criteria-prop \ --criteria-name allowed-ip-addrs \ --add included-client-address:10.6.1.80 \ --add included-client-address:127.0.0.1
-
Assign the criteria to the client connection policy.
Example:
$ bin/dsconfig set-client-connection-policy-prop \ --policy-name new-policy \ --set connection-criteria:allowed-ip-addrs
Result:
After you have run the command, access is denied to remote IP addresses. The PingDirectory server does not require a restart.
-
Add a remote IP range to the criteria.
For the following example, add
10.6.1.*
.Example:
$ bin/dsconfig set-connection-criteria-prop \ --criteria-name allowed-ip-addrs \ --add "included-client-address:10.6.1.*"
Result:
Access from any remote servers is allowed. The PingDirectory server does not require a restart.
-
To restore default behavior, remove the criteria from the connection policy.
Example:
Include the LDAP or LDAPS connection parameters, such as host name, port, bindDN, bindPassword, with the
dsconfig
command.Example:
$ bin/dsconfig set-client-connection-policy-prop \ --policy-name new-policy --remove connection-criteria:allowed-ip-addrs
Result:
The PingDirectory server does not require a restart.
Automatically authenticating clients that have a secure communication channel
The PingDirectory server provides the option to automatically authenticate clients that have a secure communication channel, either SSL or StartTLS, and to present their own certificate.
About this task
By default, this option is disabled. When enabled, the net effect is as if the client issued a SASL EXTERNAL bind request on that connection.
This option is ignored if the client connection is already authenticated, such as when using StartTLS, but the client had already performed a bind before the StartTLS request. If the bind attempt fails, the connection remains unauthenticated but usable. If the client subsequently sends a bind request on the connection, it’s processed as normal, and any automatic authentication is destroyed. |
Steps
-
Run the following
dsconfig
command.Example:
$ bin/dsconfig set-connection-handler-prop \ --handler-name "LDAPS Connection Handler" \ --set "auto-authenticate-using-client-certificate:true"