Testimonials
What our customers say about Team Password Manager

The Log

Current Team Password Manager version: 13.166.291

Everything that happens in Team Password Manager is registered into an activity log. For example, each time a user logs in, views a password, copies a password to clipboard, moves a password, etc., creates an event that is stored in a log.

This document explains all you need to know about the log in Team Password Manager:

Where you can see the log

The log is visible from several screens in Team Password Manager:

  • The main log screen: it's accessible from the top menu "Log" option by users with IT or Admin roles only. It shows all the log entries and can be filtered and sorted by some fields: Main log screen Log filter
  • The "Log" tabs in the following objects: password, project, user and my account. Here only the log entries related to the object are shown. Not all users have access to the "Log" tab in all the objects, it depends on their role and permissions on the object. The log entries in the log tabs cannot be filtered, only sorted by some fields. Example of the log tab in a password: Log tab in a password

Log fields

The log has the following fields:

  • Date/time: the local date and time of the log event. See also the next section regarding the timezone.
  • IP Address: the IP address of the client computer that generates the log event. If your Team Password Manager installation is behind a reverse proxy, check this document to learn how to configure it to correctly detect the IP address: Reverse proxy configuration.
  • User: the user that generates the log event. The name of the user is the one the user has at the moment the event is generated. If no user can be detected, for instance, in external accesses to a password, no user is recorded.
  • Action: describes what happens in the log event. Example: "Copy password to clipboard" means that the user has clicked on the "Copy to password" button of the password. In the "Filter" in the main log screen you can filter any action individually, but there's a special one called "Password shown" that is used to filter four actions: "Show password", "Copy password to clipboard", "Show password (external), and "Copy password to clipboard (external)". This filter is provided as a quick way to check if the password datum was viewed.
  • Related Project/Password: if the action relates to a project or password, the project and password are recorded. Their names are the ones when the event happens. For instance, if you edit a password and change its name, you'll see two different names in the log for the same password: one before editing and one afterwards.
  • Additional data: any additional data that adds information to the event. For example: for the "View password data" action, the additional data is the selected tab (eg: tab=data, tab=security, etc.).
  • Origin: where the event originates. Currently these are the possible values: Web (the web interface), API and Extension (when connected directly, not when using the API).

Timezone

The date/time of a log event is important, so you need to make sure Team Password Manager correctly gets it from the server where it's installed. PHP, the system Team Password Manager runs on, has its own timezone. If PHP's timezone is different than the one in the server where it's installed, the date/time recorded will be incorrect. So, you need to make sure both timezones match. To do it:

  1. Check the timezone of the server where Team Password Manager is installed. In Ubuntu, for instance, you do it with this command:
    $ cat /etc/timezone
    Europe/London
  2. Check the timezone of PHP. The best way to do it is checking the date.timezone entry in phpinfo's output. For example: PHP date.timezone
  3. If both timezones are the same, you're done. If not, set the timezone in PHP to match the one in the server. Do it in the date.timezone entry in php.ini. Example: date.timezone = "Europe/London". Here you have all the available timezones in PHP: http://php.net/manual/en/timezones.php. Then restart the webserver or fpm for the setting to take effect and re-check it with phpinfo.

Log internals: the wmm_log table

Team Password Manager's log is stored in the database. Specifically, it's stored in the wmm_log table.

If you take a look at the structure of this table you'll see that it contains all the fields described in the Log fields section, and also the ids corresponding to the user, the project and the password. It also has and id field (auto-incremented), which is the primary key of the table and which uniquely identifies the log entries.

It's worth noting that:

  • The wmm_log table doesn't need supporting tables, so you can query it directly without joining it with other tables. This also makes it easy to export the log as it's only one table export.
  • The wmm_log table can easily contain lots of records, hundreds of thousands or millions. It's by far the largest table in Team Password Manager's database. Team Password Manager is able to handle this volume in the screens where the log is shown.

Send the log to a file/syslog for SIEM integration

Team Password Manager can output log events to a file or the system logger (syslog) in real-time. This is basically done to integrate the log with SIEM tools (https://en.wikipedia.org/wiki/Security_information_and_event_management). SIEM tools are used to analize security alerts in real-time, often in combination with other applications that a company uses.

To send the log to a file or syslog you need to use a parameter in config.php. This is also described in the "All the parameters in config.php" document, linked here: ADDITIONAL_LOG / ADDITIONAL_LOG_FILE.

Note that the log will be sent to a file or syslog from the moment these parameters are used in config.php. So, previous entries won't be sent.

Sending the log to syslog

define('ADDITIONAL_LOG', 'syslog');

When sending the log to syslog the facility used is user and the program name TeamPasswordManager.

In Ubuntu systems the syslog is found at /var/log/syslog. On Windows systems, syslog is emulated using the Event Log.

Sending the log to a file

define('ADDITIONAL_LOG', 'file');
define('ADDITIONAL_LOG_FILE', 'path to the log file');

Example:

define('ADDITIONAL_LOG', 'file');
define('ADDITIONAL_LOG_FILE', '/var/www/tpm.log');

Note that the web server has to be able to write that file, so you must give appropriate permissions to its folder.

In the last section you can find a list of all the log actions if you want to build a parser for these log files.

How to export the log

We don't provide any tool to export the log, but you can use any of the many tools MySQL has to export tables. Remember that the log is stored in the wmm_log table in the database. Also, since it doesn't need supporting tables, it's an easy one table export. You can use phpMyAdmin for this or, if you want to use mysqldump on the command line, here you have the command to export the log to a CSV file:

mysqldump -uUSERNAME -p -t -T/PATH/TO/FOLDER TPM_DATABASE wmm_log --fields-terminated-by=,

This command will generate the wmm_log.txt file in /PATH/TO/FOLDER. To run it you need to replace USERNAME, TPM_DATABASE and /PATH/TO/FOLDER with your values.

How to purge the log

Team Password Manager does not purge the log. If you want to do it, you need to do it "manually". The log is stored in the wmm_log table, so to clean it up you need to delete records from this table (and only from this table).

Our suggestion is that you use the id or date_time fields of the wmm_log table as a reference to delete old log entries because these two fields always increment. The id fields contains a number that uniquely identifies each log entry and that is automatically incremented.

For instance, this SQL command will delete log entries with id less than 100:

DELETE FROM wmm_log WHERE id<100

And this one, perhaps more useful, will delete log entries created before October 7, 2015:

DELETE FROM wmm_log WHERE date_time<'2015-10-07 00:00:00'

As always when manipulating the database directly, and specially in this case where you're deleting rows: 1) test the SQL commands on a test database and 2) do a backup before executing them.

List of log actions

You can download below a text file with the full list of the actions the log can generate:

Download list of log actions for v. 13.166.291 (log_actions_13.166.291.txt)

Download list of log actions for v. 12.162.284 (log_actions_12.162.284.txt)

Download list of log actions for v. 12.160.277 (log_actions_12.160.277.txt)

Download list of log actions for v. 12.154.276 (log_actions_12.154.276.txt)


Document changelog

Dec 19, 2024: List of log actions for v. 13.166.291
Jul 4, 2024: List of log actions for v. 12.162.284
Feb 2, 2024: List of log actions for v. 12.160.277
Feb 2, 2024: List of log actions for v. 12.154.276
Dec 13, 2021: Document created
Questions or Problems? Please contact our support department