Sun Java System Directory Server Enterprise Edition 6.0 Reference

Client Identification

A client is identified in the access logs by its IP address and, optionally, by its bind DN. When a client establishes a connection to Directory Proxy Server, the following kind of message is logged in the Directory Proxy Server access log:

[timestamp] - CONNECT  - INFO  - conn=0 client=IP1:port1 server=IP2:port2 protocol=LDAP

Directory Proxy Server identifies this client connection as conn=0.

When Directory Proxy Server establishes a connection with a remote Directory Server, the following kind of message is logged in the Directory Proxy Server access log:

[timestamp] - SERVER_OP  - INFO  - Created connection for READ s_conn=server-1:1 client=IP2:port3 
 server=IP4:port4 protocol=LDAP main

Directory Proxy Server identifies this connection to the remote server as s_conn=server-1:1.

At the same time, the following kind of message is logged in the Directory Server access log:

[timestamp] conn=13 op=-1 msgId=-1 - fd=23 slot=23 LDAP connection from IP2:port3 to IP4

So, Directory Server identifies the connection as conn=13.

Tracking the connection in this way enables you to identify the full connection path from the client to Directory Server.

Directory Proxy Server does not wait for a client connection before it establishes a connection to a remote server. The Directory Proxy Server configuration specifies that certain connections are dedicated to bind operations, others to read operations, and others to write operations. When Directory Proxy Server starts up, it establishes all connections to the remote servers, according to this configuration.

When a connection has been established completely (from the client to Directory Server) the client can be identified by its DN.

Directory Server recognizes the client DN as one of the following:

A single connection can be used by multiple clients (though not simultaneously). To identify a client connection correctly in the access logs, Directory Proxy Server and Directory Server must be synchronized, that is, the server clock must be as close as possible. This will ensure that the timestamps in the access logs correspond. If the servers are not synchronized, you should synchronize them by using a time server, or evaluate the difference between the server clocks and search the access logs taking this difference into account.