Red-hat 8.1 Manual de usuario Pagina 164

  • Descarga
  • Añadir a mis manuales
  • Imprimir
  • Pagina
    / 292
  • Tabla de contenidos
  • MARCADORES
  • Valorado. / 5. Basado en revisión del cliente
Vista de pagina 163
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.
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 version=3
mech=DIGEST-MD5
[21/Apr/2009:11:39:55 -0700] conn=14 op=0 RESULT err=14 tag=97 nentries=0
etim e=0, S ASL bind in progress
In logging a SASL bind, the sasl method is followed by the LDAP 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 version=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
etim e=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 Cont ent 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.
Exa mple 5.2. Access Log Extract with Internal Acce ss Operations Le vel (Level 4 )
[12/Jul/2009:16:45:46 +0200] conn=Internal op=-1 SRCH
base="cn=\22dc=example,dc=com\22,cn=m apping tree,cn=config"scope=0
filter="objectclass=nsMappingTree"attrs="nsslapd-referral" options=persistent
[12/Jul/2009:16:45:46 +0200] conn=Internal op=-1 RESULT err=0 tag=48
nentries=1etime=0
[12/Jul/2009:16:45:46 +0200] conn=Internal op=-1 SRCH
base="cn=\22dc=example,dc=com\22,cn=m apping tree,cn=config"scope=0
filter="objectclass=nsMappingTree" attrs="nsslapd-state"
[12/Jul/2009:16:45:46 +0200] conn=Internal op=-1 RESULT err=0 tag=48
nentries=1etime=0
Access log level 4 enables logging for internal operations, which log search base, scope, filter, and
requested search attributes, in addition to the details of the search being performed.
In the following example, access logging level 768 is enabled (512 + 256), which logs access to entries
and referrals. In this extract, six entries and one referral are returned in response to the search request,
which is shown on the first line.
164 Chapter 5. Log File Reference
Vista de pagina 163
1 2 ... 159 160 161 162 163 164 165 166 167 168 169 ... 291 292

Comentarios a estos manuales

Sin comentarios