Subject: [ldapext] Representing LDAP protocol in LDAP

From: Howard Chu <[email-masked]>
Date: Sun, 16 Oct 2005 14:28:51 -0700

I've attached an initial draft of the LDAP Logging schema we're using in 
  OpenLDAP 2.3. This is my first try writing with the XML tools, so I'd 
like to get comments early before submitting to the RFC Editor. The 
intended category is Informational; I'm not seeing that in the output 
even though I've specified it in the XML source. (Any tips on making it 
behave? Using xml2rfc from xml.resource.org...)

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

Network Working Group                                             H. Chu
Internet-Draft                                               Symas Corp.
Expires: April 19, 2006                                 October 16, 2005

                 A Schema for Logging the LDAP Protocol
                    draft-chu-ldap-logschema-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 19, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   In order to facilitate remote administration and auditing of LDAP
   server operation, it is desirable to provide the server's operational
   logs themselves as a searchable LDAP directory.  These logs may also
   be used as a persistent change log to support various replication
   mechanisms.  This document defines a schema that may be used to
   represent all of the requests that have been processed by an LDAP
   server.  It may be used by various applications for auditing, flight
   recorder, replication, and other purposes.

Chu                      Expires April 19, 2006                 [Page 1]

Internet-Draft               LDAP Log Schema                October 2005

Table of Contents

   1.          Introduction . . . . . . . . . . . . . . . . . . . . .  3
   2.          Conventions  . . . . . . . . . . . . . . . . . . . . .  4
   3.          Syntaxes . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1.        Control Syntax . . . . . . . . . . . . . . . . . . . .  5
   4.          Attribute Types  . . . . . . . . . . . . . . . . . . .  6
   4.1.        General Attribute Types  . . . . . . . . . . . . . . .  6
   4.2.        Request-specific Attribute Types . . . . . . . . . . .  6
   5.          Object Classes . . . . . . . . . . . . . . . . . . . .  9
   5.1.        Basic Audit Object Classes . . . . . . . . . . . . . .  9
   5.2.        Request-Specific Object Classes  . . . . . . . . . . .  9
   5.3.        Generic Container Class  . . . . . . . . . . . . . . . 10
   6.          Discussion of Schema . . . . . . . . . . . . . . . . . 11
   6.1.        AuditObject  . . . . . . . . . . . . . . . . . . . . . 11
   6.2.        AuditContainer . . . . . . . . . . . . . . . . . . . . 12
   6.3.        Request-Specific Discussion  . . . . . . . . . . . . . 12
   7.          Examples . . . . . . . . . . . . . . . . . . . . . . . 15
   8.          Security Considerations  . . . . . . . . . . . . . . . 16
   9.          Normative References . . . . . . . . . . . . . . . . . 16
   Appendix A. IANA Considerations  . . . . . . . . . . . . . . . . . 18
               Author's Address . . . . . . . . . . . . . . . . . . . 19
               Intellectual Property and Copyright Statements . . . . 20

Chu                      Expires April 19, 2006                 [Page 2]

Internet-Draft               LDAP Log Schema                October 2005

1.  Introduction

   In a widely distributed network with multiple LDAP servers, it is
   desirable to be able to audit and monitor the operation of each
   server remotely, using the same tools that are normally used to
   interact with the LDAP servers.  Using a standardized logging format
   in LDAP allows LDAP queries to be used to generate server usage
   statistics with little effort.  This document describes a set of
   object classes that can be used to represent any LDAP operation.  The
   object classes are intended to represent a complete record of all of
   the parameters of an operation.  The log not only allows clients to
   see what operations were executed on a given server, but also to
   easily regenerate and re-issue a sequence of operations to aid in
   testing situations.  The sequence of write operations recorded in the
   log can also be used by various replication mechanisms.

Chu                      Expires April 19, 2006                 [Page 3]

Internet-Draft               LDAP Log Schema                October 2005

2.  Conventions

   Imperative keywords defined in [RFC2119] are used in this document,
   and carry the meanings described there.

Chu                      Expires April 19, 2006                 [Page 4]

Internet-Draft               LDAP Log Schema                October 2005

3.  Syntaxes

3.1.  Control Syntax

   A value of the Control syntax represents an LDAP Control as used by a
   client or server.  It consists of the numeric OID of the Control, the
   Boolean criticality flag, and an optional OctetString containing the
   Control value.  The definition given here merely repeats the
   definition of Controls in [RFC2251].

   The Abstract Syntax Notation One (ASN.1 [X680]) definition of this
   syntax is as follows:

      Control ::= SEQUENCE {

         controlType LDAPOID,

         criticality BOOLEAN DEFAULT FALSE,

         controlValue OCTET STRING OPTIONAL }

   The following is an LDAP syntax description [RFC2252] suitable for
   publication in the subschema.

   ( LOG_SCHEMA_SYN.1 DESC 'Control' )

Chu                      Expires April 19, 2006                 [Page 5]

Internet-Draft               LDAP Log Schema                October 2005

4.  Attribute Types

4.1.  General Attribute Types

   These attributes are common to all of the LDAP request records.

   ( LOG_SCHEMA_AT.1 NAME 'reqDN' DESC 'Target DN of request' EQUALITY
   distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-
   VALUE )

   ( LOG_SCHEMA_AT .2 NAME 'reqStart' DESC 'Start time of request'
   EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .3 NAME 'reqEnd' DESC 'End time of request' EQUALITY
   generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX
   1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .4 NAME 'reqType' DESC 'Type of request' EQUALITY
   caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .5 NAME 'reqSession' DESC 'Session ID of request'
   EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-
   VALUE )

   ( LOG_SCHEMA_AT .6 NAME 'reqResult' DESC 'Result code of request'
   EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-
   VALUE )

   ( LOG_SCHEMA_AT .7 NAME 'reqAuthzID' DESC 'Authorization ID of
   requestor' EQUALITY distinguishedNameMatch SYNTAX OMsDN SINGLE-VALUE
   )

   ( LOG_SCHEMA_AT .8 NAME 'reqControls' DESC 'Request controls'
   EQUALITY objectIdentifierFirstComponentMatch SYNTAX LOG_SCHEMA_SYN.1
   X-ORDERED 'VALUES' )

   ( LOG_SCHEMA_AT .9 NAME 'reqRespControls' DESC 'Response controls of
   request' EQUALITY objectIdentifierFirstComponentMatch SYNTAX
   LOG_SCHEMA_SYN.1 X-ORDERED 'VALUES' )

4.2.  Request-specific Attribute Types

   These attributes are specific to a single type of LDAP request.

   ( LOG_SCHEMA_AT .10 NAME 'reqMethod' DESC 'Bind method of request'
   EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-
   VALUE )

Chu                      Expires April 19, 2006                 [Page 6]

Internet-Draft               LDAP Log Schema                October 2005

   ( LOG_SCHEMA_AT .11 NAME 'reqAssertion' DESC 'Compare Assertion of
   request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .12 NAME 'reqNewRDN' DESC 'New RDN of request'
   EQUALITY distinguishedNameMatch SYNTAX OMsDN SINGLE-VALUE )

   ( LOG_SCHEMA_AT .13 NAME 'reqNewSuperior' DESC 'New superior DN of
   request' EQUALITY distinguishedNameMatch SYNTAX OMsDN SINGLE-VALUE )

   ( LOG_SCHEMA_AT .14 NAME 'reqDeleteOldRDN' DESC 'Delete old RDN'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .15 NAME 'reqMod' DESC 'Modifications of request'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch SUBSTR
   caseIgnoreSubstringsMatch )

   ( LOG_SCHEMA_AT .16 NAME 'reqScope' DESC 'Scope of request' SYNTAX
   1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .17 NAME 'reqFilter' DESC 'Filter of request' SYNTAX
   1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .18 NAME 'reqAttr' DESC 'Attributes of request'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   ( LOG_SCHEMA_AT .19 NAME 'reqEntries' DESC 'Number of entries
   returned' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .20 NAME 'reqSizeLimit' DESC 'Size limit of request'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .21 NAME 'reqTimeLimit' DESC 'Time limit of request'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .22 NAME 'reqAttrsOnly' DESC 'Attributes and values
   of request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .23 NAME 'reqData' DESC 'Data of extended request'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .24 NAME 'reqId' DESC 'ID of Request to Abandon'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .25 NAME 'reqMessage' DESC 'Error text of request'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

   ( LOG_SCHEMA_AT .26 NAME 'reqVersion' DESC 'Protocol version of Bind
   request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

Chu                      Expires April 19, 2006                 [Page 7]

Internet-Draft               LDAP Log Schema                October 2005

   ( LOG_SCHEMA_AT .27 NAME 'reqDerefAliases' DESC 'Disposition of
   Aliases in request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
   )

   ( LOG_SCHEMA_AT .28 NAME 'reqReferral' DESC 'Referrals returned for
   request' SUP labeledURI )

   ( LOG_SCHEMA_AT .29 NAME 'reqOld' DESC 'Old values of entry before
   request completed' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Chu                      Expires April 19, 2006                 [Page 8]

Internet-Draft               LDAP Log Schema                October 2005

5.  Object Classes

5.1.  Basic Audit Object Classes

   This is the basic class containing attributes common to all of the
   LDAP requests.  The following object classes all inherit from this
   class.

   ( LOG_SCHEMA_OC .1 NAME 'auditObject' DESC 'OpenLDAP request
   auditing' SUP top STRUCTURAL MUST ( reqStart $ reqType $ reqSession )
   MAY ( reqDN $ reqAuthzID $ reqControls $ reqRespControls $ reqEnd $
   reqResult $ reqMessage $ reqReferral ) )

   These object classes are used to aggregate read operations and write
   operations under common parent classes.

   ( LOG_SCHEMA_OC .2 NAME 'auditReadObject' DESC 'OpenLDAP read request
   record' SUP auditObject STRUCTURAL )

   ( LOG_SCHEMA_OC .3 NAME 'auditWriteObject' DESC 'OpenLDAP write
   request record' SUP auditObject STRUCTURAL )

5.2.  Request-Specific Object Classes

   Each LDAP Request has its own object class containing all of the
   attributes needed to represent an instance of the request.

   ( LOG_SCHEMA_OC .4 NAME 'auditAbandon' DESC 'Abandon operation' SUP
   auditObject STRUCTURAL MUST reqId )

   ( LOG_SCHEMA_OC .5 NAME 'auditAdd' DESC 'Add operation' SUP
   auditWriteObject STRUCTURAL MUST reqDN $ reqMod )

   ( LOG_SCHEMA_OC .6 NAME 'auditBind' DESC 'Bind operation' SUP
   auditObject STRUCTURAL MUST reqDN $ reqMethod $ reqVersion )

   ( LOG_SCHEMA_OC .7 NAME 'auditCompare' DESC 'Compare operation' SUP
   auditReadObject STRUCTURAL MUST reqDN $ reqAssertion )

   ( LOG_SCHEMA_OC .8 NAME 'auditModify' DESC 'Modify operation' SUP
   auditWriteObject STRUCTURAL MUST reqDN $ reqMod $ reqOld )

   ( LOG_SCHEMA_OC .9 NAME 'auditModDN' DESC 'ModDN operation' SUP
   auditWriteObject STRUCTURAL MUST ( reqDN $ reqNewRDN $
   reqDeleteOldRDN ) MAY reqNewSuperior )

   ( LOG_SCHEMA_OC .10 NAME 'auditSearch' DESC 'Search operation' SUP
   auditReadObject STRUCTURAL MUST ( reqDN $ reqScope $ reqAttrsonly )

Chu                      Expires April 19, 2006                 [Page 9]

Internet-Draft               LDAP Log Schema                October 2005

   MAY ( reqFilter $ reqAttr $ reqEntries $ reqSizeLimit $ reqTimeLimit
   ) )

   ( LOG_SCHEMA_OC .11 NAME 'auditExtended' DESC 'Extended operation'
   SUP auditObject STRUCTURAL MAY reqData )

   ( LOG_SCHEMA_OC .12 NAME 'auditDelete' DESC 'Delete operation' SUP
   auditWriteObject STRUCTURAL MAY reqOld )

5.3.  Generic Container Class

   This object class may be used for the parent entry of the log
   records.

   ( LOG_SCHEMA_OC .0 NAME 'auditContainer' DESC 'AuditLog container'
   SUP top STRUCTURAL MAY ( cn $ reqStart $ reqEnd ) )

Chu                      Expires April 19, 2006                [Page 10]

Internet-Draft               LDAP Log Schema                October 2005

6.  Discussion of Schema

6.1.  AuditObject

   1.  reqDN: the distinguished name of the entry the request applies
       to.  In the case of a ModDN request, the reqDN gives the DN of
       the entry before it was modified.  In the case of a Search
       request, the reqDN is the base DN of the search.
       Syntax: DN

   2.  reqStart: the time the request began on the server.
       reqEnd: the time the request completed on the server.  The
       timestamps MUST have high enough resolution to ensure that the
       reqStart values are unique.  The values for reqEnd MUST also be
       unique, although overlap of reqStart and reqEnd values is
       allowed.  Servers SHOULD use one of reqStart or reqEnd as the log
       records' RDN.  Either choice will allow records to be read in
       ascending order, although the two alternatives may produce
       different orders.  In cases where the server clocks do not
       provide sufficient resolution, a simple counter may be used in
       the fractional seconds part to distinguish multiple events
       occurring within the same second.
       Syntax: GeneralizedTime

   3.  reqType: the type of request.  One of: "abandon", "add", "bind",
       "compare", "delete", "modify", "moddn", "search", or
       "extended{OID}".  For Extended requests, the numeric
       objectIdentifier of the request is included in the string.
       Syntax: DirectoryString

   4.  reqSession: an implementation-defined value that is constant for
       all operations occurring within a Bind/Unbind sequence.
       Syntax: DirectoryString

   5.  reqResult: the LDAP result code for a completed Request.  This
       value is omitted for Requests which have no defined result (e.g.
       Abandon and Unbind) and also for Requests which were Abandoned or
       otherwise did not run to completion.
       Syntax: Integer

   6.  reqMessage: the textual error message accompanying the result, if
       any.
       Syntax: DirectoryString

   7.  reqReferral: any referrals that accompanied the result.  They are
       in the standard LDAP URI format [RFC2255].
       Syntax: DirectoryString

Chu                      Expires April 19, 2006                [Page 11]

Internet-Draft               LDAP Log Schema                October 2005

   8.  reqAuthzID: the Authorization Identity used to perform the
       request.  This will usually be the same as the reqDN of the Bind
       request with matching reqSession, but may be altered by various
       Controls and other processing.
       Syntax: DN

   9.  reqControls: the set of Request Controls accompanying a request.
       reqRespControls: the set of Response Controls accompanying a
       request result.  Each value represents a single Control.  Note
       that since Controls are transmitted as an ordered Sequence, the
       X-ORDERED 'VALUES' [XORDERED]schema extension is used here to
       preserve their ordering.
       Syntax: Control

6.2.  AuditContainer

   reqStart: the timestamp of the first (oldest) record in the log.
   reqEnd: the timestamp of the last (newest) record in the log.
   Syntax: GeneralizedTime

6.3.  Request-Specific Discussion

6.3.1.  Abandon

   reqId: the ID of a request to Abandon.
   Syntax: Integer

6.3.2.  Bind

   reqMethod: the Bind method.  Either "Simple" or "SASL/<mechanism>"
   where "<mechanism>" is the specific SASL mechanism requested.
   Syntax: DirectoryString

   reqVersion: the protocol version of the request.
   Syntax: Integer

6.3.3.  Compare

   reqAssertion: the Attribute Value Assertion (AVA) of the request.
   The AVA is encoded according to the rules in [RFC2254].
   Syntax: DirectoryString

6.3.4.  ModDN

   reqNewRDN: the new RDN of the request.
   Syntax: DN

   reqNewSuperior: the new Superior DN of the request.

Chu                      Expires April 19, 2006                [Page 12]

Internet-Draft               LDAP Log Schema                October 2005

   Syntax: DN

   reqDeletedOldRDN: the deleteOldRDN value of the request.
   Syntax: Boolean

6.3.5.  Add and Modify

   reqMod: The modifications of the request.  The encoding is defined by
   the following grammar, using the ABNF notation defined in [RFC0822].

      mod = attr ":" modop

      attr = AttributeDescription from [RFC2251]

      modop = add / delete / replace / increment

      add = "+" sp value

      delete = "-" [ sp value ]

      replace = "=" [ sp value ]

      increment = "#" sp value

      sp = " "

      value = AttributeValue from [RFC2251]

   Note that Add requests will only use the add modop format.
   Syntax: DirectoryString

   reqOld: the previous values of a modified attribute.  The encoding is
   of the form attr ":" sp value, using the same definitions as for
   reqMod above.
   Syntax: DirectoryString

6.3.6.  Delete

   reqOld: the previous values of a deleted entry.  The encoding is as
   given above.
   Syntax: DirectoryString

6.3.7.  Search

   reqScope: the scope of the Search request.  One of "base", "one",
   "subtree", or "subordinate".
   Syntax: DirectoryString

Chu                      Expires April 19, 2006                [Page 13]

Internet-Draft               LDAP Log Schema                October 2005

   reqDerefAliases: the derefAliases parameter of the Search request.
   One of "never", "searching", "finding", or "always".
   Syntax: DirectoryString

   reqSizeLimit: the size limit of the request.
   reqTimeLimit: the time limit of the request.
   Syntax: Integer

   reqAttrsOnly: the typesOnly parameter of the request.
   Syntax: Boolean

   reqFilter: the Search filter, encoded according to [RFC2254].
   Syntax: DirectoryString

   reqAttr: the specific attributes requested, if any.
   Syntax: DirectoryString

   reqEntries: the total number of entries returned for this request.
   Syntax: Integer

6.3.8.  Extended

   reqData: the data accompanying the request, if any.
   Syntax: OctetString

Chu                      Expires April 19, 2006                [Page 14]

Internet-Draft               LDAP Log Schema                October 2005

7.  Examples

   To be filled in later...

Chu                      Expires April 19, 2006                [Page 15]

Internet-Draft               LDAP Log Schema                October 2005

8.  Security Considerations

   Servers implementing this scheme SHOULD NOT allow the logs to be
   generally readable.  Extensive information about the existence and
   content of data, as well as the usage patterns associated with the
   data, will be present in the log and should only be made available to
   trusted users.

   The structure of the log does not prevent fine-grained access
   controls from being used, although the rules will be necessarily
   longer than they would be in the primary database.  E.g., while a
   single rule to deny access to the userPassword attribute would
   suffice in the primary database, two rules would be needed in the log
   - one to deny access to the reqOld attribute with values
   userPassword:*, and one to deny access to the reqMod attribute with
   values userPassword:*.

   Servers implementing this scheme should disallow write access to the
   log container object and all entries contained within.

9.  Normative References

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2251]  Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
              Access Protocol (v3)", RFC 2251, December 1997.

   [RFC2252]  Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
              "Lightweight Directory Access Protocol (v3): Attribute
              Syntax Definitions", RFC 2252, December 1997.

   [RFC2254]  Howes, T., "The String Representation of LDAP Search
              Filters", RFC 2254, December 1997.

   [RFC2255]  Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
              December 1997.

   [RFC3383]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
              Considerations for the Lightweight Directory Access
              Protocol (LDAP)", BCP 64, RFC 3383, September 2002.

   [X680]     International Telecommunications Union, "Abstract Syntax
              Notation One (ASN.1): Specification of basic notation",
              ITU-T Recommendation X.680, July 2002.

Chu                      Expires April 19, 2006                [Page 16]

Internet-Draft               LDAP Log Schema                October 2005

   [XORDERED]
              Chu, H., "Ordered Values in LDAP", a work in
              progress draft-chu-ldap-orderedvalues-xx.txt.

Chu                      Expires April 19, 2006                [Page 17]

Internet-Draft               LDAP Log Schema                October 2005

Appendix A.  IANA Considerations

   In accordance with [RFC3383] (what needs to be done here?) .
   Currently we are using
   OpenLDAP_Experimental = 1.3.6.1.4.1.4203.666
   LOG_SCHEMA = OpenLDAP_Experimental.11.5
   LOG_SCHEMA_AT = LOG_SCHEMA.1
   LOG_SCHEMA_OC = LOG_SCHEMA.2
   LOG_SCHEMA_SYN = LOG_SCHEMA.3

Chu                      Expires April 19, 2006                [Page 18]

Internet-Draft               LDAP Log Schema                October 2005

Author's Address

   Howard Chu
   Symas Corp.
   18740 Oxnard Street, Suite 313A
   Tarzana, California  91356
   USA

   Phone: +1 818 757-7087
   Email: [email-masked]

Chu                      Expires April 19, 2006                [Page 19]

Internet-Draft               LDAP Log Schema                October 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Chu                      Expires April 19, 2006                [Page 20]

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Howard Chu <[email-masked]>
Date: Mon, 17 Oct 2005 03:44:27 -0700

> behave? Using xml2rfc from xml.resource.org...)

The XML source as well as the text and HTML output are temporarily 
available here: http://24.126.120.178/~hyc/. The corresponding 
implementation is in the current OpenLDAP CVS.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

---

From: "Steve Trottier" <[email-masked]>
Date: Tue, 18 Oct 2005 09:55:09 -0600

Howard,

This seem well thought out and obviously an improvement (at least for
auditing purposes) to the older changelog mechanism in use by several
other directories.

Is there a standard way to discover if this LDAP Logging mechanism is
in use in a particular directory? I.e, will there be an entry in the
rootDSE indicating the DN of the auditContainer in use? Or would a
potential consumer of this information search the directory looking for
entries that have the objectclass of interest?

Also, is this feature on by default in OpenLDAP 2.3? Is its use
configurable?

Thanks,

Steve Trottier
Sr. Software Engineer
Novell, Inc.   http://www.novell.com/

>>> Howard Chu <[email-masked]> 10/16/2005 3:28:51 pm >>>
I've attached an initial draft of the LDAP Logging schema we're using
in 
  OpenLDAP 2.3. This is my first try writing with the XML tools, so I'd

---

From: Howard Chu <[email-masked]>
Date: Tue, 18 Oct 2005 09:30:15 -0700

> Howard,

Hi Steve,

> entries that have the objectclass of interest?

Good questions. There is currently no formal mechanism to advertise the 
availability of this feature. I realize that's a hole here.

My preference would be to provide an operational attribute for the root 
entry of a naming context that gives the DN of the container. 
Alternatively it could be a collective attribute returned for all 
entries under the naming context. Since we can configure multiple 
databases in the server, and each database could be logging to different 
destinations, just listing the DN of a container in the rootDSE doesn't 
provide enough information. (I.e., you need to know which log goes with 
which subtree / naming context.)
> Also, is this feature on by default in OpenLDAP 2.3? Is its use

The feature is not on by default, it's implemented in a separate overlay 
module. There are a few simple options to configure it, e.g. you can 
configure it to log only a subset of operation types. You can view the 
current manpage for the overlay here
http://24.126.120.178/~hyc/man/man5/slapo-accesslog.5

By the way, the XORDERED draft that this document references is now also 
available. http://24.126.120.178/~hyc/draft-chu-ldap-xordered-xx.txt

---

From: "Steve Trottier" <[email-masked]>
Date: Tue, 18 Oct 2005 17:07:42 -0600

Thank you for those answers. Regarding where to put the operational
attribute with the DN of the audit container, I think either (or both)
would work. The preferred method would depend on what a client's purpose
would be in reading the audit information. If you wanted to see all
accesses or writes to a particular entry in the directory, then your
second suggestion of the attribute being available on all entries under
a naming context would be helpful because you could read the value of
the container directly from the entry of interest. If, however, your
purpose in reading the audit information was to replicate or synchronize
directory data, then you would probably just want a quick way to find
which container or containers you should poll for updates. Searching the
rootDSE for naming contexts and then the naming contexts for their audit
containers would work well in that case. Interestingly, these two
methods are very similar to the current methods of finding a
subschemasubentry, which makes sense.

>>> Howard Chu <[email-masked]> 10/18/2005 10:30:15 am >>>
... There is currently no formal mechanism to advertise the 
availability of this feature. I realize that's a hole here.

databases in the server, and each database could be logging to
different 

> Also, is this feature on by default in OpenLDAP 2.3? Is its use

The feature is not on by default, it's implemented in a separate
overlay 
module. There are a few simple options to configure it, e.g. you can 
configure it to log only a subset of operation types. You can view the

By the way, the XORDERED draft that this document references is now
also 
available. http://24.126.120.178/~hyc/draft-chu-ldap-xordered-xx.txt