Directory Server, Version 6.1

 

Appendix N. Audit format

The following is the format descriptions for server and admin daemon audits. (The format is the same for both the server and the admin daemon.)

 

Audit format for server and admin daemon audits

Following the header, any control information is audited.

Format of control information

  • controlType: OID

  • criticality: TRUE or FALSE

If the audit version is set to 1, no additional information is audited.

If the audit version is set to 2 or greater, then the following is TRUE:

  • If the control is a Proxy authorization control, then the following additional information is audited:

    • ProxyDN: Proxy Auth DN

  • If the control is a Group authorization control, and audit is configured to audit the groups sent on a Group authorization control, then the following additional information is audited:

    • Group: Group Name

    • Group: Group Name 2 (repeat for each group)

    • Normalized: TRUE or FALSE

  • If the control is an Audit control, and audit is configured to audit the additional information in the Audit control, then the following additional information is audited:

    • RequestID: request ID 1

    • RequestID: request ID 2 (repeat for each additional request ID)

    • ClientIP: client IP sent in the audit control

  • If the control is a Replication update ID control, and audit is configured to audit the Replication update ID control, then the following additional information is audited:

    • value: value sent in the control

As well as the previous control information, the following operation-specific data is audited:

  • Bind:

    • name: <bindDN string>

    • authenticationChoice: unknown, simple, krbv42LDAP, krbv42DSA, sasl

    • authenticationMechanism: CRAM-MD5

    • Admin Acct Status: Not Locked, Locked, or Lock Cleared

    • username: adminusername (for DIGEST-MD5 only)

    • mappedname: cn=root (for DIGEST-MD5 w/ authzid only)

    • authzId: u: username (for DIGEST-MD5 with authzid only)

  • Search:

    • base: o=ibm_us, c=us

    • scope: unknown, baseObject, singleLevel, or wholeSubtree

    • derefAliases: unknown, neverDerefAliases, derefInSearching, derefFindingBaseObj, or derefAlways

    • typesOnly: FALSE

    • filter: (&(cn=c*)(sn=a*))

    • attributes: cn, sn, title (this item is not present if there are no attributes)

  • Compare:

    • entry: cn=Joe Smith, o=ibm_us, c=us

    • attribute: cn
    Note:

    The attribute value is not written.

  • Add:

    • entry: cn=Joe Smith, o=ibm_us, c=us

    • attributes: cn, sn
    Note:

    The attribute value is not written.

  • Modify:

    • object: cn=Joe Smith, o=ibm_us, c=us

    • add: mail

    • delete: title

    • replace: telphonenumber (repeat for each operation/attribute pair)
    Modify types can be one of the following:

    • unknown

    • add

    • delete

    • replace

  • Delete:

    • entry: cn=Joe Smith, o=ibm_us, c=us

  • ModifyDN:

    • entry: cn=Joe Smith, ou=Austin, o=ibm_us, c=us

    • newrdn: Joe S. Smith

    • deleteoldrdn: true

    • newSuperior: ou=rochester (this item is not present if there is no newSuperior value)

  • Event Notification: Event Registration:

    • eventID: LDAP_change

    • base: o=ibm_us, c=us

    • scope: wholeSubtree

    • type: unknown, changeAdd, changeDelete, changeModify, or changeModDN

  • Event Notification: Unregistered Event:

    • ID: hostname.uuid

For all extended operations other than event notification, the OID is audited. Some extended operations also audit additional information.

Format of the OID

OID: OID

For more information about the auditing features for a specific extended operation, see "Appendix F. Object Identifiers (OIDs) for extended operations and controls" in IBM® Tivoli® Directory Server C-Client SDK Programming Reference Version 6.1.

 

Auditing server events

The following server events are audited if auditing is enabled:

  • Auditing started

  • Audited stopped

  • Audit configuration changed

  • Server started

  • Server stopped

Server events are audited in the following format: 

<Time>—<Message Text in local code page>

For example: 

2005-01-05-14:06:20.957-06:00--GLPSRV009I IBM Tivoli Directory (SSL), 
Version 6.0   Server started.

 

Notes

  • All DNs are audited in local code page.

  • If the SLAPD_AUDIT_ENCODE_DN is set to any value, the BindDN and Digest Bind DNs are encoded when written to the audit log. To decode the DNs, an administrator can perform a search against the server with the scope base, base NULL and a filter of ibm-auditdecodeddn= <value to decode>. For example: 
    idsldapsearch –D adminDN –w password –s base –b  " " ibm-auditdecodedn=encoded DN




[ Top of Page | Previous Page | Next Page | Contents | Index ]