title: Audit logging for Oracle Internet Directory link: https://onemoretech.wordpress.com/2009/03/11/audit-logging-for-oracle-internet-directory/ author: lembobro description: post_id: 366 created: 2009/03/11 18:05:06 created_gmt: 2009/03/11 18:05:06 comment_status: open post_name: audit-logging-for-oracle-internet-directory status: publish post_type: post

Audit logging for Oracle Internet Directory

The usual caveats apply regarding always checking the latest documentation for the version (down to the last decimal place) you’re working with, in this case I’m using the Oracle Internet Directory Administrator’s Guide for Oracle Identity Management 10.1.4.0.1 (the latest patch level is 10.1.4.0.2, but this book in the documentation set is unchanged), Chapter 14, Logging, Auditing and Monitoring the Directory.

My low opinion of how Oracle has implemented logging in Oracle Internet Directory (OID) is well known. It is in fact an LDAP administrator’s nightmare. That said, if you’re in an Oracle shop you need to make the best you can of a bad situation.

While most purely LDAP protocol operations are consigned by Oracle to the debug logs (which when even at level 0 spit out an inordinate number of useless Java “messages”, you have to crank up full debugging to get standard LDAP stuff — like the actual search filter used in an LDAP query), security related matters are only available in the audit log. Audit logging is turned completely off by default. Once enabled it does not write anything to the filesystem. Instead it records everything in the backend database. Audit log data is accessed using the LDAP API by doing a search on the psuedo-rootdn “cn=auditlog”.

Your database administrators will not be happy. Even with careful tuning of garbage collection a busy directory service is going to use lots of tablespace to record all the normal things we’ve come to expect, like successful bind operations. Just tell them: “live with it”.

Not surprisingly, you can’t use the oidadmin gui configure Oracle’s audit logging to record successful bind. To do this you need to modify the orclauditlevel attribute at the DSE Root of your directory. The value you put in here is a decimal number, calculated by adding together the hex values in Table 14-6 corresponding to the particular item you want to audit. As concrete examples are also helpful, and mostly lacking in official documentation, here’s one from the real world:

Schema Add/Replace 0×0002

Schema Delete 0×0004

Access Violation 0×0010

DSE Modification 0×0020

ACL Modification 0×0080

User Password Mod 0×0100

Modify DN 0×1000

Successful Bind 0×2000

If you do the math, you wind up with a sum of 0×31B6 hex. That converts to 12726 in decimal.

To further clarify, if you had used the oidadmin gui to check off all the above except “successful bind” (the gui only has “bind”, which in Oracle’s perverse way of doing things actually means “unsuccessful bind”), you’d wind up with a decimal value of 4534 in orclauditlevel, which converts to 0×11B6 in hex, and just happens to be the sum of we had above — minus the 0×2000 for successful bind.

The above audit level is pretty much what I recommend as a minimum. That doesn’t mean you’ll actually want to implement it entirely. There’s a reason Oracle makes it so hard to audit successful binds: in addition to any user logons that happen through to OID, you’ve got lots of other things binding to the directory all the time. Like all those management daemons in the OAS infrastructure. And GRID (if you’ve deployed it). OSSO, Portal, & c.

(a typical environment without anyone logging in showed around 150 binds an hour)

Actual testing in close cooperation with your DBA team is strongly recommended.

Purging the audit log should happen automatically via the garbage collection task for this purpose that is enabled by default. Check the documentation for how to make the schedule more aggressive as needed. If you need to do a complete purge (like when deploying a new environment after testing), you can shutdown OID and use the bulkdelete command to remove the entire “cn=auditlog” basedn. When you start the server back up it should be recreated by the system.

Postscript:

Some more calculations (so I don’t have to do them again).

If you want to include (which I think you will)

Add 0×0200

Delete 0×0400

Modify 0×0800

in my original example above, you’d get 0×3FB6. Which translates to a 16310 decimal value for orclauditlevel.

Copyright 2004-2019 Phil Lembo