There is a database entry for LAST_SOAP_ACCESS (getLastSoapAccessTime) in ZIMBRA.MAILBOX - not ported to a LDAP value because that would be nuts. The 'last SOAP activity time' is the time in milliseconds of the last write operation on the mailbox by the mailbox's owner; this is maintained in the session and written at the time of the session's first write and the session's expiry.
Your /opt/zimbra/log/audit.log is continuous anyways so you can always check that. (I port to a nice log index program called
Splunk.)
Ok, so the zimbraLastLogonTimestampFrequency default is 7d to cutdown on ldap writes every time you auth... The value isn't new to 5.0.x, just now displayed in the admin console. The server will update the user's zimbraLastLogonTimestamp user attribute at most once every zimbraLastLogonTimestampFrequency.
It's your call - you can set it to values like: 1d, 1h, 1m, 1s, or 0 for disabled.
Quote:
|
zmprov mcf zimbraLastLogonTimestampFrequency 3d
|
Think of the pure volume of some systems, updating an attribute for a million+ active users all day long makes for a lot of writes and replication. Prompted implementation of:
Bug 18972 - provide way to completely disable zimbraLastLogonTimestamp (setting to 0).
For some, 7 days on zimbraLastLogonTimestampFrequency does seem a little high though given the average installation size and faster systems. To that end, someone had an bugzilla entry in to get the default changed from 7d > 3d but I don't know what happened to it. If you have the time/ability for a large scale performance test go for it
(Don't know what you're running at Stanford but btw
Bug 24012 - "Last logged in" not updating when using external LDAP was fixed for 5.0.3)