LDAP Audit Logging

[Howard Chu <hyc@symas.com>]

One of the features I've found useful for security/auditing purposes was 
an audit log that recorded all the activity on a server in another 
backend. We had an older implementation of this for OpenLDAP 2.0 but it 
seems that it's a bit too dusty to bring up to date by itself. So here 
are some notes on what I'm planning for OpenLDAP 2.2/2.3...

We all know about replog and changelogs, but they only record 
modifications on a server, and so are not suitable for security/auditing 
purposes. The current slapd StatsLog is pretty much in line with what 
would be suitable for audit, but it is not LDAP-accessible. Since I 
believe very much in "when all you have is a hammer everything looks 
like a nail" design philosophy, I believe everything about slapd must be 
accessible via LDAP. So I've been thinking about an "LDAP Audit Format" 
or "LDAP Transcript Schema" or somesuch.

(Forgive the braindead schema notation, this is just for basic context, 
not for a precise specification...)

objectclass AuditObject
  must: requestDN, requestStart, requestEnd, requestType, sessionID, 
requestResult
  may: requestAuthzID, requestMessage, requestControls, responseControls

attribute requestDN - the DN the operation applies to

attribute requestStart, requestEnd - generalizedTime reflecting when 
processing of an operation began and ended.

attribute requestType - Add, Bind, Compare, Delete, Modify, ModRdn, 
Search, Extended{OID}
describe the type of operation

sessionID - a server-defined value that is constant for all operations 
occurring within a Bind/Unbind sequence

requestResult - integer result of the operation

requestAuthzID - the ID of the user performing the operation - generally 
not required since it can be inferred by tracing the sessionID back to a 
preceding Bind

requestMessage - any error text associated with the operation result

requestControls, responseControls - binary multivalued attributes 
carrying one control per value


objectclass AuditBind - sup AuditObject
  must: BindMethod - Simple, or SASL/<method>
(targetDN is the BindDN)

objectclass AuditCompare - sup AuditObject
  must: CompareAssertion - AVA

objectclass AuditAdd - sup AuditObject
  must: AddEntry
 it would be nice if the entry itself could just be included inline, to 
keep the entire audit entry human-readable, but I suspect it would be 
more practical to store the LDIF or BER of the entry in a separate 
attribute. My original implementation added this stuff inline.

objectclass AuditDelete - sup AuditObject
 nothing special here - don't really need this class, do we...

objectclass AuditModRdn - sup AuditObject
 must: newRdn, deleteOldRdn
 may: newSuperior

objectclass AuditModify - sup AuditObject
 must: modification

attribute modification -
( + | - | = ) attributeDescription $ value


objectclass AuditSearch - sup AuditObject
 must: searchScope
 may: searchFilter, searchAttrs, searchEntries

I suppose sizeLimit and timeLimit should be there for completeness' 
sake, but I've never been too concerned with them myself.



Implementation in slapd will be via an overlay that generates audit 
records and writes them to a separate backend. This backend may just be 
back-ldif, storing things in flat text files and providing no indexing, 
or it could be any other backend. I have a habit of running "tail -f" on 
system log files; with persistent search an LDAP client could do this 
instead.

Comments, suggestions?

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support