[Date Prev][Date Next]
LDAP Audit Logging
- To: OpenLDAP Devel <openldap-devel@OpenLDAP.org>
- Subject: LDAP Audit Logging
- From: Howard Chu <firstname.lastname@example.org>
- Date: Tue, 26 Oct 2004 04:57:12 -0700
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041002
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...)
must: requestDN, requestStart, requestEnd, requestType, sessionID,
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,
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
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
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
objectclass AuditModify - sup AuditObject
attribute modification -
( + | - | = ) attributeDescription $ value
objectclass AuditSearch - sup AuditObject
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
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support