[Date Prev][Date Next] [Chronological] [Thread] [Top]

LDAP Audit Logging

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