idnits 2.17.1 draft-chu-ldap-logschema-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 812. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 802. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 3, 2006) is 6566 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'XORDERED' is defined on line 755, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2254 (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2255 (Obsoleted by RFC 4510, RFC 4516) ** Obsolete normative reference: RFC 3383 (Obsoleted by RFC 4520) == Outdated reference: A later version (-02) exists of draft-sermersheim-ldap-subordinate-scope-00 -- Possible downref: Normative reference to a draft: ref. 'SUBORD' -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- No information found for draft-chu-ldap-orderedvalues-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'XORDERED' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chu 3 Internet-Draft Symas Corp. 4 Expires: November 4, 2006 May 3, 2006 6 A Schema for Logging the LDAP Protocol 7 draft-chu-ldap-logschema-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 4, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 In order to facilitate remote administration and auditing of LDAP 41 server operation, it is desirable to provide the server's operational 42 logs themselves as a searchable LDAP directory. These logs may also 43 be used as a persistent change log to support various replication 44 mechanisms. This document defines a schema that may be used to 45 represent all of the requests that have been processed by an LDAP 46 server. It may be used by various applications for auditing, flight 47 recorder, replication, and other purposes. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions . . . . . . . . . . . . . . . . . . . . . 4 53 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Control Syntax . . . . . . . . . . . . . . . . . . . . 5 55 4. Attribute Types . . . . . . . . . . . . . . . . . . . 6 56 4.1. General Attribute Types . . . . . . . . . . . . . . . 6 57 4.2. Request-specific Attribute Types . . . . . . . . . . . 7 58 5. Object Classes . . . . . . . . . . . . . . . . . . . . 10 59 5.1. Basic Audit Object Classes . . . . . . . . . . . . . . 10 60 5.2. Request-Specific Object Classes . . . . . . . . . . . 10 61 5.3. Generic Container Class . . . . . . . . . . . . . . . 11 62 6. Discussion of Schema . . . . . . . . . . . . . . . . . 12 63 6.1. AuditObject . . . . . . . . . . . . . . . . . . . . . 12 64 6.2. AuditContainer . . . . . . . . . . . . . . . . . . . . 13 65 6.3. Request-Specific Discussion . . . . . . . . . . . . . 13 66 7. Examples . . . . . . . . . . . . . . . . . . . . . . . 16 67 7.1. Audit Trail . . . . . . . . . . . . . . . . . . . . . 16 68 7.2. Add request . . . . . . . . . . . . . . . . . . . . . 17 69 7.3. Modify request . . . . . . . . . . . . . . . . . . . . 17 70 7.4. Rename request . . . . . . . . . . . . . . . . . . . . 18 71 7.5. Delete request . . . . . . . . . . . . . . . . . . . . 18 72 7.6. Usage Notes . . . . . . . . . . . . . . . . . . . . . 19 73 8. Security Considerations . . . . . . . . . . . . . . . 20 74 9. Normative References . . . . . . . . . . . . . . . . . 20 75 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 22 76 Author's Address . . . . . . . . . . . . . . . . . . . 23 77 Intellectual Property and Copyright Statements . . . . 24 79 1. Introduction 81 In a widely distributed network with multiple LDAP servers, it is 82 desirable to be able to audit and monitor the operation of each 83 server remotely, using the same tools that are normally used to 84 interact with the LDAP servers. Using a standardized logging format 85 in LDAP allows LDAP queries to be used to generate server usage 86 statistics with little effort. This document describes a set of 87 object classes that can be used to represent any LDAP operation. The 88 object classes are intended to represent a complete record of all of 89 the parameters of an operation. The log not only allows clients to 90 see what operations were executed on a given server, but also to 91 easily regenerate and re-issue a sequence of operations to aid in 92 testing situations. The sequence of write operations recorded in the 93 log can also be used by various replication mechanisms. 95 2. Conventions 97 Imperative keywords defined in [RFC2119] are used in this document, 98 and carry the meanings described there. 100 3. Syntaxes 102 3.1. Control Syntax 104 A value of the Control syntax represents an LDAP Control as used by a 105 client or server. It consists of the numeric OID of the Control, the 106 Boolean criticality flag, and an optional OctetString containing the 107 Control value. The definition given here merely repeats the 108 definition of Controls in [RFC2251]. 110 The Abstract Syntax Notation One (ASN.1 [X680]) definition of this 111 syntax is as follows: 113 Control ::= SEQUENCE { 115 controlType LDAPOID, 116 criticality BOOLEAN DEFAULT FALSE, 117 controlValue OCTET STRING OPTIONAL } 119 The following is an LDAP syntax description [RFC2252] suitable for 120 publication in the subschema. 122 ( LOG_SCHEMA_SYN.1 DESC 'Control' ) 124 4. Attribute Types 126 4.1. General Attribute Types 128 These attributes are common to all of the LDAP request records. 130 ( LOG_SCHEMA_AT.1 NAME 'reqDN' 131 DESC 'Target DN of request' 132 EQUALITY distinguishedNameMatch 133 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 134 SINGLE-VALUE ) 136 ( LOG_SCHEMA_AT .2 NAME 'reqStart' 137 DESC 'Start time of request' 138 EQUALITY generalizedTimeMatch 139 ORDERING generalizedTimeOrderingMatch 140 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 141 SINGLE-VALUE ) 143 ( LOG_SCHEMA_AT .3 NAME 'reqEnd' 144 DESC 'End time of request' 145 EQUALITY generalizedTimeMatch 146 ORDERING generalizedTimeOrderingMatch 147 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 148 SINGLE-VALUE ) 150 ( LOG_SCHEMA_AT .4 NAME 'reqType' 151 DESC 'Type of request' 152 EQUALITY caseIgnoreMatch 153 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 154 SINGLE-VALUE ) 156 ( LOG_SCHEMA_AT .5 NAME 'reqSession' 157 DESC 'Session ID of request' 158 EQUALITY caseIgnoreMatch 159 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 160 SINGLE-VALUE ) 162 ( LOG_SCHEMA_AT .6 NAME 'reqAuthzID' 163 DESC 'Authorization ID of requestor' 164 EQUALITY distinguishedNameMatch 165 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 166 SINGLE-VALUE ) 168 ( LOG_SCHEMA_AT .7 NAME 'reqResult' 169 DESC 'Result code of request' 170 EQUALITY integerMatch 171 ORDERING integerOrderingMatch 172 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 173 SINGLE-VALUE ) 175 ( LOG_SCHEMA_AT .8 NAME 'reqMessage' 176 DESC 'Error text of request' 177 EQUALITY caseIgnoreMatch 178 SUBSTR caseIgnoreSubstringsMatch 179 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 180 SINGLE-VALUE ) 182 ( LOG_SCHEMA_AT .9 NAME 'reqReferral' 183 DESC 'Referrals returned for request' 184 SUP labeledURI ) 186 ( LOG_SCHEMA_AT .10 NAME 'reqControls' 187 DESC 'Request controls' 188 EQUALITY objectIdentifierFirstComponentMatch 189 SYNTAX LOG_SCHEMA_SYN.1 X-ORDERED 'VALUES' ) 191 ( LOG_SCHEMA_AT .11 NAME 'reqRespControls' 192 DESC 'Response controls of request' 193 EQUALITY objectIdentifierFirstComponentMatch 194 SYNTAX LOG_SCHEMA_SYN.1 X-ORDERED 'VALUES' ) 196 4.2. Request-specific Attribute Types 198 These attributes are specific to a single type of LDAP request. 200 ( LOG_SCHEMA_AT .12 NAME 'reqId' 201 DESC 'ID of Request to Abandon' 202 EQUALITY integerMatch 203 ORDERING integerOrderingMatch 204 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 205 SINGLE-VALUE ) 207 ( LOG_SCHEMA_AT .13 NAME 'reqVersion' 208 DESC 'Protocol version of Bind request' 209 EQUALITY integerMatch 210 ORDERING integerOrderingMatch 211 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 212 SINGLE-VALUE ) 214 ( LOG_SCHEMA_AT .14 NAME 'reqMethod' 215 DESC 'Bind method of request' 216 EQUALITY caseIgnoreMatch 217 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 218 SINGLE-VALUE ) 219 ( LOG_SCHEMA_AT .15 NAME 'reqAssertion' 220 DESC 'Compare Assertion of request' 221 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 222 SINGLE-VALUE ) 224 ( LOG_SCHEMA_AT .16 NAME 'reqMod' 225 DESC 'Modifications of request' 226 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 227 EQUALITY octetStringMatch 228 SUBSTR octetStringSubstringsMatch ) 230 ( LOG_SCHEMA_AT .17 NAME 'reqOld' 231 DESC 'Old values of entry before request completed' 232 EQUALITY octetStringMatch 233 SUBSTR octetStringSubstringsMatch 234 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 236 ( LOG_SCHEMA_AT .18 NAME 'reqNewRDN' 237 DESC 'New RDN of request' 238 EQUALITY distinguishedNameMatch 239 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 240 SINGLE-VALUE ) 242 ( LOG_SCHEMA_AT .19 NAME 'reqDeleteOldRDN' 243 DESC 'Delete old RDN' 244 EQUALITY booleanMatch 245 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 246 SINGLE-VALUE ) 248 ( LOG_SCHEMA_AT .20 NAME 'reqNewSuperior' 249 DESC 'New superior DN of request' 250 EQUALITY distinguishedNameMatch 251 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 252 SINGLE-VALUE ) 254 ( LOG_SCHEMA_AT .21 NAME 'reqScope' 255 DESC 'Scope of request' 256 EQUALITY caseIgnoreMatch 257 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 258 SINGLE-VALUE ) 260 ( LOG_SCHEMA_AT .22 NAME 'reqDerefAliases' 261 DESC 'Disposition of Aliases in request' 262 EQUALITY caseIgnoreMatch 263 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 264 SINGLE-VALUE ) 266 ( LOG_SCHEMA_AT .23 NAME 'reqAttrsOnly' 267 DESC 'Attributes and values of request' 268 EQUALITY booleanMatch 269 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 270 SINGLE-VALUE ) 272 ( LOG_SCHEMA_AT .24 NAME 'reqFilter' 273 DESC 'Filter of request' 274 EQUALITY caseIgnoreMatch 275 SUBSTR caseIgnoreSubstringsMatch 276 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 277 SINGLE-VALUE ) 279 ( LOG_SCHEMA_AT .25 NAME 'reqAttr' 280 DESC 'Attributes of request' 281 EQUALITY caseIgnoreMatch 282 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 284 ( LOG_SCHEMA_AT .26 NAME 'reqSizeLimit' 285 DESC 'Size limit of request' 286 EQUALITY integerMatch 287 ORDERING integerOrderingMatch 288 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 289 SINGLE-VALUE ) 291 ( LOG_SCHEMA_AT .27 NAME 'reqTimeLimit' 292 DESC 'Time limit of request' 293 EQUALITY integerMatch 294 ORDERING integerOrderingMatch 295 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 296 SINGLE-VALUE ) 298 ( LOG_SCHEMA_AT .28 NAME 'reqEntries' 299 DESC 'Number of entries returned' 300 EQUALITY integerMatch 301 ORDERING integerOrderingMatch 302 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 303 SINGLE-VALUE ) 305 ( LOG_SCHEMA_AT .29 NAME 'reqData' 306 DESC 'Data of extended request' 307 EQUALITY octetStringMatch 308 SUBSTR octetStringSubstringsMatch 309 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 310 SINGLE-VALUE ) 312 5. Object Classes 314 5.1. Basic Audit Object Classes 316 This is the basic class containing attributes common to all of the 317 LDAP requests. The following object classes all inherit from this 318 class. 320 ( LOG_SCHEMA_OC .1 NAME 'auditObject' DESC 'OpenLDAP request 321 auditing' SUP top STRUCTURAL MUST ( reqStart $ reqType $ reqSession ) 322 MAY ( reqDN $ reqAuthzID $ reqControls $ reqRespControls $ reqEnd $ 323 reqResult $ reqMessage $ reqReferral ) ) 325 These object classes are used to aggregate read operations and write 326 operations under common parent classes. 328 ( LOG_SCHEMA_OC .2 NAME 'auditReadObject' DESC 'OpenLDAP read request 329 record' SUP auditObject STRUCTURAL MUST reqDN ) 331 ( LOG_SCHEMA_OC .3 NAME 'auditWriteObject' DESC 'OpenLDAP write 332 request record' SUP auditObject STRUCTURAL MUST reqDN ) 334 5.2. Request-Specific Object Classes 336 Each LDAP Request has its own object class containing all of the 337 attributes needed to represent an instance of the request. 339 ( LOG_SCHEMA_OC .4 NAME 'auditAbandon' DESC 'Abandon operation' SUP 340 auditObject STRUCTURAL MUST reqId ) 342 ( LOG_SCHEMA_OC .5 NAME 'auditAdd' DESC 'Add operation' SUP 343 auditWriteObject STRUCTURAL MUST reqMod ) 345 ( LOG_SCHEMA_OC .6 NAME 'auditBind' DESC 'Bind operation' SUP 346 auditObject STRUCTURAL MUST ( reqDN $ reqMethod $ reqVersion ) ) 348 ( LOG_SCHEMA_OC .7 NAME 'auditCompare' DESC 'Compare operation' SUP 349 auditReadObject STRUCTURAL MUST reqAssertion ) 351 ( LOG_SCHEMA_OC .8 NAME 'auditDelete' DESC 'Delete operation' SUP 352 auditWriteObject STRUCTURAL MAY reqOld ) 354 ( LOG_SCHEMA_OC .9 NAME 'auditModify' DESC 'Modify operation' SUP 355 auditWriteObject STRUCTURAL MUST reqMod MAY reqOld ) 357 ( LOG_SCHEMA_OC .10 NAME 'auditModRDN' DESC 'ModRDN operation' SUP 358 auditWriteObject STRUCTURAL MUST ( reqNewRDN $ reqDeleteOldRDN ) MAY 359 ( reqNewSuperior $ reqOld ) ) 360 ( LOG_SCHEMA_OC .11 NAME 'auditSearch' DESC 'Search operation' SUP 361 auditReadObject STRUCTURAL MUST ( reqScope $ reqDerefAliases $ 362 reqAttrsonly ) MAY ( reqFilter $ reqAttr $ reqEntries $ reqSizeLimit 363 $ reqTimeLimit ) ) 365 ( LOG_SCHEMA_OC .12 NAME 'auditExtended' DESC 'Extended operation' 366 SUP auditObject STRUCTURAL MAY reqData ) 368 5.3. Generic Container Class 370 This object class may be used for the parent entry of the log 371 records. 373 ( LOG_SCHEMA_OC .0 NAME 'auditContainer' DESC 'AuditLog container' 374 SUP top STRUCTURAL MAY ( cn $ reqStart $ reqEnd ) ) 376 6. Discussion of Schema 378 6.1. AuditObject 380 1. reqDN: the distinguished name of the entry the request applies 381 to. In the case of a ModRDN request, the reqDN gives the DN of 382 the entry before it was modified. In the case of a Search 383 request, the reqDN is the base DN of the search. 384 Syntax: DN 386 2. reqStart: the time the request began on the server. 387 reqEnd: the time the request completed on the server. The 388 timestamps MUST have high enough resolution to ensure that the 389 reqStart values are unique. The values for reqEnd MUST also be 390 unique, although overlap of reqStart and reqEnd values is 391 allowed. Servers SHOULD use one of reqStart or reqEnd as the log 392 records' RDN. Either choice will allow records to be read in 393 ascending order, although the two alternatives may produce 394 different orders. In cases where the server clocks do not 395 provide sufficient resolution, a simple counter may be used in 396 the fractional seconds part to distinguish multiple events 397 occurring within the same second. 398 Syntax: GeneralizedTime 400 3. reqType: the type of request. One of: "abandon", "add", "bind", 401 "compare", "delete", "modify", "modrdn", "search", or 402 "extended{OID}". For Extended requests, the numeric 403 objectIdentifier of the request is included in the string. 404 Syntax: DirectoryString 406 4. reqSession: an implementation-defined value that is constant for 407 all operations occurring within a Bind/Unbind sequence. 408 Syntax: DirectoryString 410 5. reqAuthzID: the Authorization Identity used to perform the 411 request. This will usually be the same as the reqDN of the Bind 412 request with matching reqSession, but may be altered by various 413 Controls and other processing. 414 Syntax: DN 416 6. reqResult: the LDAP result code for a completed Request. This 417 value is omitted for Requests which have no defined result (e.g. 418 Abandon and Unbind) and also for Requests which were Abandoned or 419 otherwise did not run to completion. 420 Syntax: Integer 422 7. reqMessage: the textual error message accompanying the result, if 423 any. 425 Syntax: DirectoryString 427 8. reqReferral: any referrals that accompanied the result. They are 428 in the standard LDAP URI format [RFC2255]. 429 Syntax: DirectoryString 431 9. reqControls: the set of Request Controls accompanying a request. 432 reqRespControls: the set of Response Controls accompanying a 433 request result. Each value represents a single Control. Note 434 that since Controls are transmitted as an ordered Sequence, the 435 X-ORDERED 'VALUES' [XORDERED]schema extension is used here to 436 preserve their ordering. 437 Syntax: Control 439 6.2. AuditContainer 441 reqStart: the timestamp of the first (oldest) record in the log. 442 reqEnd: the timestamp of the last (newest) record in the log. 443 Syntax: GeneralizedTime 445 6.3. Request-Specific Discussion 447 6.3.1. Abandon 449 reqId: the ID of a request to Abandon. 450 Syntax: Integer 452 6.3.2. Bind 454 reqVersion: the protocol version of the request. 455 Syntax: Integer 457 reqMethod: the Bind method. Either "Simple" or "SASL/" 458 where "" is the specific SASL [RFC2222] mechanism 459 requested. 460 Syntax: DirectoryString 462 6.3.3. Compare 464 reqAssertion: the Attribute Value Assertion (AVA) of the request. 465 The AVA is encoded according to the rules in [RFC2254]. 466 Syntax: DirectoryString 468 6.3.4. Rename 470 reqNewRDN: the new RDN of the request. 471 Syntax: DN 472 reqDeletedOldRDN: the deleteOldRDN value of the request. 473 Syntax: Boolean 475 reqNewSuperior: the new Superior DN of the request. 476 Syntax: DN 478 6.3.5. Add and Modify 480 reqMod: The modifications of the request. The encoding is defined by 481 the following grammar, using the ABNF notation defined in [RFC0822]. 483 mod = attr ":" modop 485 attr = AttributeDescription from [RFC2251] 487 modop = add / delete / replace / increment 489 add = "+" sp value 491 delete = "-" [ sp value ] 493 replace = "=" [ sp value ] 495 increment = "#" sp value 497 sp = " " 499 value = AttributeValue from [RFC2251] 501 Note that Add requests will only use the add modop format. 502 Syntax: OctetString 504 reqOld: the previous values of a modified attribute. The encoding is 505 of the form attr ":" sp value, using the same definitions as for 506 reqMod above. 507 Syntax: OctetString 509 6.3.6. Delete 511 reqOld: the previous values of a deleted entry. The encoding is as 512 given above. 513 Syntax: OctetString 515 6.3.7. Search 517 reqScope: the scope of the Search request. The possible values are 518 as specified for the scope parameter in the LDAP URL format [RFC2255] 519 and [SUBORD]. Currently one of "base", "one", "sub", or "subord". 521 Syntax: DirectoryString 523 reqDerefAliases: the derefAliases parameter of the Search request. 524 One of "never", "searching", "finding", or "always". 525 Syntax: DirectoryString 527 reqAttrsOnly: the typesOnly parameter of the request. 528 Syntax: Boolean 530 reqFilter: the Search filter, encoded according to [RFC2254]. 531 Syntax: DirectoryString 533 reqSizeLimit: the size limit of the request. 534 reqTimeLimit: the time limit of the request. 535 Syntax: Integer 537 reqAttr: the specific attributes requested, if any. 538 Syntax: DirectoryString 540 reqEntries: the total number of entries returned for this request. 541 Syntax: Integer 543 6.3.8. Extended 545 reqData: the data accompanying the request, if any. 546 Syntax: OctetString 548 7. Examples 550 In the following examples the log records reside under the "cn=log" 551 entry and are named by their "reqStart" attribute. 553 7.1. Audit Trail 555 This is the set of log records produced for a session comprising a 556 Simple Bind request, a Search request, and an Unbind: 558 dn: reqStart=20051017081049.000000Z,cn=log 559 objectClass: auditBind 560 reqStart: 20051017081049.000000Z 561 reqEnd: 20051017081049.000001Z 562 reqType: bind 563 reqSession: 0 564 reqAuthzID: 565 reqDN: cn=manager,dc=example,dc=com 566 reqResult: 0 567 reqVersion: 3 568 reqMethod: SIMPLE 570 dn: reqStart=20051017081049.000002Z,cn=log 571 objectClass: auditSearch 572 reqStart: 20051017081049.000002Z 573 reqEnd: 20051017081049.000003Z 574 reqType: search 575 reqSession: 0 576 reqAuthzID: cn=Manager,dc=example,dc=com 577 reqDN: dc=example,dc=com 578 reqResult: 0 579 reqScope: one 580 reqDerefAliases: never 581 reqAttrsOnly: FALSE 582 reqFilter: (objectClass=*) 583 reqSizeLimit: -1 584 reqTimeLimit: -1 585 reqEntries: 3 587 dn: reqStart=20051017081049.000004Z,cn=log 588 objectClass: auditObject 589 reqStart: 20051017081049.000004Z 590 reqEnd: 20051017081049.000005Z 591 reqType: unbind 592 reqSession: 0 593 reqAuthzID: cn=Manager,dc=example,dc=com 595 7.2. Add request 597 This is a log record from adding an entry to the directory: 599 dn: reqStart=20051017083706.000001Z,cn=log 600 objectClass: auditAdd 601 structuralObjectClass: auditAdd 602 reqStart: 20051017083706.000001Z 603 reqEnd: 20051017083706.000002Z 604 reqType: add 605 reqSession: 4 606 reqAuthzID: cn=Manager,dc=example,dc=com 607 reqDN: ou=People,dc=example,dc=com 608 reqResult: 0 609 reqMod: objectClass:+ organizationalUnit 610 reqMod: ou:+ People 611 reqMod: description:+ A bunch of people will be here 612 reqMod: structuralObjectClass:+ organizationalUnit 613 reqMod: entryUUID:+ f16734aa-d334-1029-9290-cd8deceec6b0 614 reqMod: creatorsName:+ cn=Manager,dc=example,dc=com 615 reqMod: createTimestamp:+ 20051017083706Z 616 reqMod: entryCSN:+ 20051017083706Z#000000#00#000000 617 reqMod: modifiersName:+ cn=Manager,dc=example,dc=com 618 reqMod: modifyTimestamp:+ 20051017083706Z 620 Note that operational attributes written with the request are 621 included in the log record. All of the static data associated with 622 an entry will be exposed, allowing a replication client to get a full 623 copy of the entry. 625 7.3. Modify request 626 This is a log record from modifying an entry in the directory: 628 dn: reqStart=20051017083734.000010Z,cn=log 629 objectClass: auditModify 630 reqStart: 20051017083734.000010Z 631 reqEnd: 20051017083734.000011Z 632 reqType: modify 633 reqSession: 1 634 reqAuthzID: cn=Manager,dc=example,dc=com 635 reqDN: ou=People,dc=example,dc=com 636 reqResult: 0 637 reqMod: description:- 638 reqMod: entryCSN:= 20051017083734Z#000003#00#000000 639 reqMod: modifiersName:= cn=Manager,dc=example,dc=com 640 reqMod: modifyTimestamp:= 20051017083734Z 641 reqOld: description: A bunch of people will be here 643 In this example the entire "description" attribute is deleted from 644 the entry. Its original value is recorded in the "reqOld" attribute. 645 Preserving the data allows the logs to be replayed both forwards and 646 backwards. A client can run the log forward to bring a replica up to 647 date, or run it backwards to undo a series of unintended operations. 649 7.4. Rename request 651 This is a log record from renaming an entry in the directory: 653 dn: reqStart=20051017083734.000018Z,cn=log 654 objectClass: auditModRDN 655 reqStart: 20051017083734.000018Z 656 reqEnd: 20051017083734.000019Z 657 reqType: modrdn 658 reqSession: 1 659 reqAuthzID: cn=Manager,dc=example,dc=com 660 reqDN: ou=People,dc=example,dc=com 661 reqResult: 0 662 reqNewRDN: ou=Populi 663 reqDeleteOldRDN: TRUE 665 7.5. Delete request 666 This is a log record from deleting an entry in the directory: 668 dn: reqStart=20051017083734.000020Z,cn=log 669 objectClass: auditDelete 670 reqStart: 20051017083734.000020Z 671 reqEnd: 20051017083734.000021Z 672 reqType: delete 673 reqSession: 1 674 reqAuthzID: cn=Manager,dc=example,dc=com 675 reqDN: ou=Populi,dc=example,dc=com 676 reqResult: 0 677 reqOld: ou: Populi 678 reqOld: objectClass: organizationalUnit 679 reqOld: structuralObjectClass: organizationalUnit 680 reqOld: entryUUID: f16734aa-d334-1029-9290-cd8deceec6b0 681 reqOld: creatorsName: cn=Manager,dc=example,dc=com 682 reqOld: createTimestamp: 20051017083706Z 683 reqOld: entryCSN: 20051017083734Z#000007#00#000000 684 reqOld: modifiersName: cn=Manager,dc=example,dc=com 685 reqOld: modifyTimestamp: 20051017083734Z 687 7.6. Usage Notes 689 More information is accomodated in this specification than may be 690 needed in typical use. Servers MAY implement only subsets of the 691 attributes, or provide configuration mechanisms to reduce the range 692 of operations covered in the log. Replication clients working from a 693 full log can use a search filter with the terms 694 "(&(objectClass=AuditWriteObject)(reqResult=0))" to filter out 695 irrelevant records. The "reqOld" attribute will often contain 696 redundant information; having an option to omit it from the logs may 697 also be more suitable for some sites. 699 8. Security Considerations 701 Servers implementing this scheme SHOULD NOT allow the logs to be 702 generally readable. Extensive information about the existence and 703 content of data, as well as the usage patterns associated with the 704 data, will be present in the log and should only be made available to 705 trusted users. 707 The structure of the log does not prevent fine-grained access 708 controls from being used, although the rules will be necessarily 709 longer than they would be in the primary database. E.g., while a 710 single rule to deny access to the userPassword attribute would 711 suffice in the primary database, two rules would be needed in the log 712 - one to deny access to the reqOld attribute with values 713 userPassword:*, and one to deny access to the reqMod attribute with 714 values userPassword:*. 716 Servers implementing this scheme should not permit users to write 717 directly to the log container object or any entries contained within. 719 9. Normative References 721 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 722 text messages", STD 11, RFC 822, August 1982. 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, March 1997. 727 [RFC2222] Myers, J., "Simple Authentication and Security Layer 728 (SASL)", RFC 2222, October 1997. 730 [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory 731 Access Protocol (v3)", RFC 2251, December 1997. 733 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, 734 "Lightweight Directory Access Protocol (v3): Attribute 735 Syntax Definitions", RFC 2252, December 1997. 737 [RFC2254] Howes, T., "The String Representation of LDAP Search 738 Filters", RFC 2254, December 1997. 740 [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, 741 December 1997. 743 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 744 Considerations for the Lightweight Directory Access 745 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 747 [SUBORD] Sermersheim, J., "Subordinate Subtree Search Scope for 748 LDAP", a work in 749 progress draft-sermersheim-ldap-subordinate-scope-00.txt. 751 [X680] International Telecommunications Union, "Abstract Syntax 752 Notation One (ASN.1): Specification of basic notation", 753 ITU-T Recommendation X.680, July 2002. 755 [XORDERED] 756 Chu, H., "Ordered Values in LDAP", a work in 757 progress draft-chu-ldap-orderedvalues-xx.txt. 759 Appendix A. IANA Considerations 761 In accordance with [RFC3383] (what needs to be done here?) . 762 Currently we are using 763 OpenLDAP_Experimental = 1.3.6.1.4.1.4203.666 764 LOG_SCHEMA = OpenLDAP_Experimental.11.5 765 LOG_SCHEMA_AT = LOG_SCHEMA.1 766 LOG_SCHEMA_OC = LOG_SCHEMA.2 767 LOG_SCHEMA_SYN = LOG_SCHEMA.3 769 Author's Address 771 Howard Chu 772 Symas Corp. 773 18740 Oxnard Street, Suite 313A 774 Tarzana, California 91356 775 USA 777 Phone: +1 818 757-7087 778 Email: hyc@symas.com 780 Intellectual Property Statement 782 The IETF takes no position regarding the validity or scope of any 783 Intellectual Property Rights or other rights that might be claimed to 784 pertain to the implementation or use of the technology described in 785 this document or the extent to which any license under such rights 786 might or might not be available; nor does it represent that it has 787 made any independent effort to identify any such rights. Information 788 on the procedures with respect to rights in RFC documents can be 789 found in BCP 78 and BCP 79. 791 Copies of IPR disclosures made to the IETF Secretariat and any 792 assurances of licenses to be made available, or the result of an 793 attempt made to obtain a general license or permission for the use of 794 such proprietary rights by implementers or users of this 795 specification can be obtained from the IETF on-line IPR repository at 796 http://www.ietf.org/ipr. 798 The IETF invites any interested party to bring to its attention any 799 copyrights, patents or patent applications, or other proprietary 800 rights that may cover technology that may be required to implement 801 this standard. Please address the information to the IETF at 802 ietf-ipr@ietf.org. 804 Disclaimer of Validity 806 This document and the information contained herein are provided on an 807 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 808 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 809 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 810 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 811 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 812 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 814 Copyright Statement 816 Copyright (C) The Internet Society (2006). This document is subject 817 to the rights, licenses and restrictions contained in BCP 78, and 818 except as set forth therein, the authors retain all their rights. 820 Acknowledgment 822 Funding for the RFC Editor function is currently provided by the 823 Internet Society.