1SLAPO-ACCESSLOG(5) File Formats Manual SLAPO-ACCESSLOG(5)
2
6 slapo-accesslog - Access Logging overlay
7
9 /etc/openldap/slapd.conf
10
12 The Access Logging overlay can be used to record all accesses to a
13 given backend database on another database. This allows all of the
14 activity on a given database to be reviewed using arbitrary LDAP
15 queries, instead of just logging to local flat text files. Configura‐
16 tion options are available for selecting a subset of operation types to
17 log, and to automatically prune older log records from the logging
18 database. Log records are stored with audit schema (see below) to
19 assure their readability whether viewed as LDIF or in raw form.
20
22 These slapd.conf options apply to the Access Logging overlay. They
23 should appear after the overlay directive.
24 logdb <suffix>
26 Specify the suffix of a database to be used for storing the log
27 records. The specified database must have already been config‐
28 ured in a prior section of the config file, and it must have a
29 rootDN configured. The access controls on the log database
30 should prevent general write access. The suffix entry of the log
31 database will be created automatically by this overlay. The log
32 entries will be generated as the immediate children of the suf‐
33 fix entry.
34 logops <operations>
36 Specify which types of operations to log. The valid operation
37 types are abandon, add, bind, compare, delete, extended, modify,
38 modrdn, search, and unbind. Aliases for common sets of opera‐
39 tions are also available:
40 writes add, delete, modify, modrdn
42 reads compare, search
44 session
46 abandon, bind, unbind
47 all all operations
49 logold <filter>
51 Specify a filter for matching against Deleted and Modified
52 entries. If the entry matches the filter, the old contents of
53 the entry will be logged along with the current request.
54 logpurge <age> <interval>
56 Specify the maximum age for log entries to be retained in the
57 database, and how often to scan the database for old entries.
58 Both the age and interval are specified as a time span in days,
59 hours, minutes, and seconds. The time format is [ddd+]hh:mm[:ss]
60 i.e., the days and seconds components are optional but hours and
61 minutes are required. Except for days, which can be up to 5 dig‐
62 its, each numeric field must be exactly two digits. For example
63 logpurge 2+00:00 1+00:00
64 would specify that the log database should be scanned every day
65 for old entries, and entries older than two days should be
66 deleted. When using a log database that supports ordered index‐
67 ing on generalizedTime attributes, specifying an eq index on the
68 reqStart attribute will greatly benefit the performance of the
69 purge operation.
70 logsuccess TRUE | FALSE
72 If set to TRUE then log records will only be generated for suc‐
73 cessful requests, i.e., requests that produce a result code of 0
74 (LDAP_SUCCESS). If FALSE, log records are generated for all
75 requests whether they succeed or not. The default is FALSE.
76
79 database bdb
80 suffix cn=log
81 ...
82 index reqStart eq
83 database bdb
85 suffix dc=example,dc=com
86 ...
87 overlay accesslog
88 logdb cn=log
89 logops writes reads
90 logold (objectclass=person)
91
94 The accesslog overlay utilizes the "audit" schema described herein.
95 This schema is specifically designed for accesslog auditing and is not
96 intended to be used otherwise. It is also noted that the schema
97 describe here is a work in progress, and hence subject to change with‐
98 out notice. The schema is loaded automatically by the overlay.
99 The schema includes a number of object classes and associated attribute
101 types as described below.
102 There is a basic auditObject class from which two additional classes,
104 auditReadObject and auditWriteObject are derived. Object classes for
105 each type of LDAP operation are further derived from these classes.
106 This object class hierarchy is designed to allow flexible yet efficient
107 searches of the log based on either a specific operation type's class,
108 or on more general classifications. The definition of the auditObject
109 class is as follows:
110 ( 1.3.6.1.4.1.4203.666.11.5.2.1
112 NAME 'auditObject'
113 DESC 'OpenLDAP request auditing'
114 SUP top STRUCTURAL
115 MUST ( reqStart $ reqType $ reqSession )
116 MAY ( reqDN $ reqAuthzID $ reqControls $ reqRespControls $
117 reqEnd $ reqResult $ reqMessage $ reqReferral ) )
118 Note that all of the OIDs used in the logging schema currently reside
120 under the OpenLDAP Experimental branch. It is anticipated that they
121 will migrate to a Standard branch in the future.
122 An overview of the attributes follows: reqStart and reqEnd provide the
124 start and end time of the operation, respectively. They use general‐
125 izedTime syntax. The reqStart attribute is also used as the RDN for
126 each log entry.
127 The reqType attribute is a simple string containing the type of opera‐
129 tion being logged, e.g. add, delete, search, etc. For extended opera‐
130 tions, the type also includes the OID of the extended operation, e.g.
131 extended(1.1.1.1)
132 The reqSession attribute is an implementation-specific identifier that
134 is common to all the operations associated with the same LDAP session.
135 Currently this is slapd's internal connection ID, stored in decimal.
136 The reqDN attribute is the distinguishedName of the target of the oper‐
138 ation. E.g., for a Bind request, this is the Bind DN. For an Add
139 request, this is the DN of the entry being added. For a Search request,
140 this is the base DN of the search.
141 The reqAuthzID attribute is the distinguishedName of the user that per‐
143 formed the operation. This will usually be the same name as was estab‐
144 lished at the start of a session by a Bind request (if any) but may be
145 altered in various circumstances.
146 The reqControls and reqRespControls attributes carry any controls sent
148 by the client on the request and returned by the server in the
149 response, respectively. The attribute values are just uninterpreted
150 octet strings.
151 The reqResult attribute is the numeric LDAP result code of the opera‐
153 tion, indicating either success or a particular LDAP error code. An
154 error code may be accompanied by a text error message which will be
155 recorded in the reqMessage attribute.
156 The reqReferral attribute carries any referrals that were returned with
158 the result of the request.
159 Operation-specific classes are defined with additional attributes to
161 carry all of the relevant parameters associated with the operation:
162 ( 1.3.6.1.4.1.4203.666.11.5.2.4
165 NAME 'auditAbandon'
166 DESC 'Abandon operation'
167 SUP auditObject STRUCTURAL
168 MUST reqId )
169 For the Abandon operation the reqId attribute contains the message ID
171 of the request that was abandoned.
172 ( 1.3.6.1.4.1.4203.666.11.5.2.5
175 NAME 'auditAdd'
176 DESC 'Add operation'
177 SUP auditWriteObject STRUCTURAL
178 MUST reqMod )
179 The Add class inherits from the auditWriteObject class. The Add and
181 Modify classes are very similar. The reqMod attribute carries all of
182 the attributes of the original entry being added. (Or in the case of a
183 Modify operation, all of the modifications being performed.) The values
184 are formatted as
185 attribute:<+|-|=|#> [ value]
186 Where '+' indicates an Add of a value, '-' for Delete, '=' for Replace,
187 and '#' for Increment. In an Add operation, all of the reqMod values
188 will have the '+' designator.
189 ( 1.3.6.1.4.1.4203.666.11.5.2.6
191 NAME 'auditBind'
192 DESC 'Bind operation'
193 SUP auditObject STRUCTURAL
194 MUST ( reqVersion $ reqMethod ) )
195 The Bind class includes the reqVersion attribute which contains the
197 LDAP protocol version specified in the Bind as well as the reqMethod
198 attribute which contains the Bind Method used in the Bind. This will be
199 the string SIMPLE for LDAP Simple Binds or SASL(<mech>) for SASL Binds.
200 Note that unless configured as a global overlay, only Simple Binds
201 using DNs that reside in the current database will be logged.
202 ( 1.3.6.1.4.1.4203.666.11.5.2.7
205 NAME 'auditCompare'
206 DESC 'Compare operation'
207 SUP auditObject STRUCTURAL
208 MUST reqAssertion )
209 For the Compare operation the reqAssertion attribute carries the
211 Attribute Value Assertion used in the compare request.
212 ( 1.3.6.1.4.1.4203.666.11.5.2.8
215 NAME 'auditDelete'
216 DESC 'Delete operation'
217 SUP auditWriteObject STRUCTURAL
218 MAY reqOld )
219 The Delete operation needs no further parameters. However, the reqOld
221 attribute may optionally be used to record the contents of the entry
222 prior to its deletion. The values are formatted as
223 attribute: value
224 The reqOld attribute is only populated if the entry being deleted
225 matches the configured logold filter.
226 ( 1.3.6.1.4.1.4203.666.11.5.2.9
229 NAME 'auditModify'
230 DESC 'Modify operation'
231 SUP auditWriteObject STRUCTURAL
232 MAY reqOld MUST reqMod )
233 The Modify operation contains a description of modifications in the
235 reqMod attribute, which was already described above in the Add opera‐
236 tion. It may optionally contain the previous contents of any modified
237 attributes in the reqOld attribute, using the same format as described
238 above for the Delete operation. The reqOld attribute is only populated
239 if the entry being modified matches the configured logold filter.
240 ( 1.3.6.1.4.1.4203.666.11.5.2.10
243 NAME 'auditModRDN'
244 DESC 'ModRDN operation'
245 SUP auditWriteObject STRUCTURAL
246 MUST ( reqNewRDN $ reqDeleteOldRDN )
247 MAY reqNewSuperior )
248 The ModRDN class uses the reqNewRDN attribute to carry the new RDN of
250 the request. The reqDeleteOldRDN attribute is a Boolean value showing
251 TRUE if the old RDN was deleted from the entry, or FALSE if the old RDN
252 was preserved. The reqNewSuperior attribute carries the DN of the new
253 parent entry if the request specified the new parent.
254 ( 1.3.6.1.4.1.4203.666.11.5.2.11
257 NAME 'auditSearch'
258 DESC 'Search operation'
259 SUP auditReadObject STRUCTURAL
260 MUST ( reqScope $ reqDerefAliases $ reqAttrsOnly )
261 MAY ( reqFilter $ reqAttr $ reqEntries $ reqSizeLimit $
262 reqTimeLimit ) )
263 For the Search class the reqScope attribute contains the scope of the
265 original search request, using the values specified for the LDAP URL
266 format. I.e. base, one, sub, or subord. The reqDerefAliases attribute
267 is one of never, finding, searching, or always, denoting how aliases
268 will be processed during the search. The reqAttrsOnly attribute is a
269 Boolean value showing TRUE if only attribute names were requested, or
270 FALSE if attributes and their values were requested. The reqFilter
271 attribute carries the filter used in the search request. The reqAttr
272 attribute lists the requested attributes if specific attributes were
273 requested. The reqEntries attribute is the integer count of how many
274 entries were returned by this search request. The reqSizeLimit and
275 reqTimeLimit attributes indicate what limits were requested on the
276 search operation.
277 ( 1.3.6.1.4.1.4203.666.11.5.2.12
280 NAME 'auditExtended'
281 DESC 'Extended operation'
282 SUP auditObject STRUCTURAL
283 MAY reqData )
284 The Extended class represents an LDAP Extended Operation. As noted
286 above, the actual OID of the operation is included in the reqType
287 attribute of the parent class. If any optional data was provided with
288 the request, it will be contained in the reqData attribute as an unin‐
289 terpreted octet string.
290
293 The Access Log implemented by this overlay may be used for a variety of
294 other tasks, e.g. as a ChangeLog for a replication mechanism, as well
295 as for security/audit logging purposes.
296
299 /etc/openldap/slapd.conf
300 default slapd configuration file
301
303 slapd.conf(5).
304
307 This module was written in 2005 by Howard Chu of Symas Corporation.
308OpenLDAP 2.3.34 2007/2/16 SLAPO-ACCESSLOG(5)