Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

KB-4018: DirectAudit Session logging (scp file stream content) can cause excessive DB usage

Auditing and Monitoring Service ,  

12 April,16 at 11:07 AM

Applies to: Centrify DirectAudit 3.1.1 only on all UNIX/Linux platforms
It is observed that Centrify DirectAudit AuditStore storage is increasing much faster than expected after installing and configuring the DirectAudit agent 3.1.1 on a machine that runs frequent or  large scp/rsync/sftp incoming file transfers.
Upon closer inspection, its noticed that the audited sessions with scp (secure copy) or rsync or sftp commands contain not just the audited commands and the resulting output but the entire data stream itself.  
There is a known issue with the Centrify DirectAudit agent 3.1.1 where the agent is unable to distinguish between scp, rsync, and sftp traffic and audits the entire data stream including the file data produced during rsync and scp sessions.  
This issue is fixed in Centrify Suite 2014, if an upgrade is not possible, there are three options to choose from.
Additional information can be obtained by following the referenced Knowledge Base articles.
The below steps need to be performed as root or sudo.
Option A: Using the dash.allinvoked parameter in /etc/centrifyda/centrifyda.conf
(See KB-4253: dash.allinvoked parameter for more details on what the parameter does.)
In /etc/centrifyda/centrifyda.conf, set the dash.allinvoked parameter to false and run dareload
  • This parameter is deprecated in DA 3.0.x in favor of NSS. It has to be manually set
  • Remote rsync/ssh/sftp/scp traffic will never be audited and this will result in smaller spool file size and smaller Audit database.
  • This workaround will not work for those who are using DirectAudit for command-level auditing.
    This means if specific commands need to be audited (as opposed to the default all login/shell invocation), the dash.allinvoked parameter needs to be set to true. 
    This is set to true by default and is hidden. Those using command-level auditing should refer to workaround B)  
Option B: Using the dash.user.skiplist: parameter in /etc/centrifyda/centrifyda.conf
By adding the audited users running scp or rsync to the skip list in the DirectAudit configuration file (/etc/centrifyda/centrifyda.conf), scp/sftp/rsync sessions are not audited based on the "logged in user". 
Note that this will mean that no session data will be audited at all for these users, and not just rsync or scp & rsync data. It will be all or nothing.
Option C: Set up a SQL job to periodically delete the scp session from the audited database
Please contact Centrify Support for additional information.
Option A: Those running into this issue can contact Centrify Support for a special build for the agent (for RHEL and Solaris platforms only) which completely resolves this issue.  
This one-off has to be installed using and choosing (R - re-install). 
In the fix, the agent will automatically filter out the full data stream from scp and rsync commands from the audit stream itself so it does not get sent to the collector / AuditStore.  
Option B: Upgrade Centrify DirectAudit components (agent, collector, database, console) to Centrify Suite 2014
On UNIX/Linux, Centrify's allows an agent upgrade with minimum downtime. 
On Windows, tools are available to upgrade components without having to uninstall or reboot.
Additional notes for cleaning already audited data generated by scp/sftp/rsync traffic: 
  1. Use AuditAnalyzer to identify the sessions with large amounts of data by opening them and the ones that have data streamed in them will show long strings of non-readable data indicative of a file transfer.
  2. Remove those sessions by right-clicking them and choosing "delete".
For more information  on performing a Database shrink on MSSQL see the link below: