HP-UX Directory Server 8.1 configuration, command, and file reference

targetop=NOTFOUND indicates the operation to be aborted was either an unknown operation
or already complete.
5.1.2.19 Message ID
The message ID, in this case msgid=2, is the LDAP operation identifier, as generated by the
LDAP SDK client. The message ID may have a different value from the operation number but
it iidentifies the same operation. The message ID is used with an ABANDON operation and tells
the user which client operation is being abandoned.
[21/Apr/2009:11:39:52 -0700] conn=12 op=2 ABANDON targetop=NOTFOUND msgid=2
NOTE:
The Directory Server operation number starts counting at 0, and, in the majority of LDAP
SDK/client implementations, the message ID number starts counting at 1, which explains why
the message ID is frequently equal to the Directory Server operation number plus 1.
5.1.2.20 SASL multi-stage bind logging
In Directory Server, logging for multi-stage binds is explicit. Each stage in the bind process is
logged. The error codes for these SASL connections are really return codes. In
Example 5-1 “Example access log”, the SASL bind is currently in progress so it has a return code
of err=14, meaning the connection is still open, and there is a corresponding progress statement,
SASL bind in progress.
[21/Apr/2009:11:39:55 -0700] conn=14 op=0 BIND dn="" method=sasl ver\
sion=3 mech=DIGEST-MD5
[21/Apr/2009:11:39:55 -0700] conn=14 op=0 RESULT err=14 tag=97 nentries=0
etime=0, SASL bind in progress
In logging a SASL bind, the sasl method is followed by the LDAP version number (see “Version
number”) and the SASL mechanism used, as shown below with the GSS-API mechanism.
[21/Apr/2009:12:57:14 -0700] conn=32 op=0 BIND dn="" method=sasl ver\
sion=3 mech=GSSAPI
NOTE:
The authenticated DN (the DN used for access control decisions) is now logged in the BIND
result line as opposed to the bind request line, as was previously the case:
[21/Apr/2009:11:39:55 -0700] conn=14 op=1 RESULT err=0 tag=97 nentries=0 etime=0
dn="uid=jdoe,dc=example,dc=com"
For SASL binds, the DN value displayed in the bind request line is not used by the server and,
as a consequence, is not relevant. However, given that the authenticated DN is the DN which,
for SASL binds, must be used for audit purposes, it is essential that this be clearly logged. Having
this authenticated DN logged in the bind result line avoids any confusion as to which DN is
which.
5.1.3 Access log content for additional access logging levels
This section presents the additional access logging levels available in the Directory Server access
log.
In Example 5-2 “Access log extract with internal access operations level (level 4)”, access logging
level 4, which logs internal operations, is enabled.
5.1 Access log reference 179