Centrify DirectAudit 1.3.0 Release Notes (C) 2006-2011 Centrify Corporation. This software is protected by international copyright laws. All Rights Reserved. Table of Contents 1. About This Release 2. New Features 2.1 New Features in DirectAudit 1.3.0 2.2 New Features in DirectAudit 1.1.2 2.3 New Features in DirectAudit 1.1.0 2.4 New Features in DirectAudit 1.0.3 2.5 New Features in DirectAudit 1.0.2 3. Bugs Fixed 4. Known Issues 5. Additional Information and Support 1. About This Release Centrify (R) DirectAudit TM helps you comply with regulatory requirements through detailed auditing and logging of user activity on your UNIX and Linux systems. With DirectAudit you can also perform immediate, in-depth troubleshooting by replaying user activity that may have contributed to system failures, and spot suspicious activity through real-time monitoring of current user sessions. These release notes contain information that updates information available in the Administrator's Guide as well as known issues with this release. Centrify DirectControl (R) is a prequisite for DirectAudit. The minimum version of DirectControl supported by this version of DirectAudit is 4.1.2. 2. New Features 2.1 New features in DirectAudit 1.3.0 * New dash.loginrecord parameter in /etc/centrifyda/centrifyda.conf When set to true, this parameter enables "who -m" and "who am I" to operate correctly. However, setting this parameter also has the side effect that a regular "who" to list all users logged into the system will list users twice. With this parameter set to false (the default behavior), "who" reports the user list correctly, but "who am I" doesn't work properly on an audited shell. * Auditing can be enabled for all shells during installation From Centrify Suite 2011, install.sh will offer to start auditing for all-shells during installation. There is a corresponding parameter ("DA_ENABLE") in centrify-suite.cfg for use in unattended installation and a new option, --enable-da, for use on the install.sh command line. * Agent support has been added for the following operating systems: - CentOS 4.5, 4.6, 4.7. 4.8, 5.1, 5.2, 5.3, 5.4, 5.4, 5.5 (32- and 64-bit) - Fedora 14 (32- and 64-bit) - IBM AIX 7.1 - OpenSuSE 11.3, 11.4 (32- and 64-bit) - Red Hat Enterprise Linux 4.9, 5.6 (32- and 64-bit) - Scientific Linux 4.6, 4.7, 4.8, 5.1, 5.2, 5.3, 5.4, 5.5, 6.0 (32- and 64-bit) - Ubuntu Server 10.04 LTS, 10.10 (32- and 64-bit) - VMware ESX 4.1 2.2 New features in DirectAudit 1.1.2 * New default port for the DirectAudit Collector service is 5063 as registered with the IANA. * Console support has been added for Windows 2008 and Windows 7. * Supports SQL Server 2008 databases. * Supports FIPS 140 license keys. * New dash.force.audit parameter allows auditing of non-terminal sessions. dash.force.audit is a list of binaries that must be audited. Note that they are the .daudit names for example: dash.force.audit: /usr/share/centrifydc/bin/ssh.daudit * New option '--force-da-global' added to install.sh so that the user can force DirectAudit to be installed only in a Solaris global zone. * Agent support has been added for the following operating systems: - OpenSuSE 11.1 and 11.2 (32 and 64 bit) - RHEL 4.8 (32 and 64 bit) - RHEL 5.0, 5.1, 5.2, 5.3, 5.4 (32 and 64 bit) - Fedora Core 10, 11, 12 (32 and 64 bit) - Novell SLES 11 (32 and 64 bit) - VMWare ESX 4 / VIMA 4 - Debian 5 (32 and 64 bit) - Ubuntu 9.10 (32 and 64 bit) - Ubuntu 9.04 (32 and 64 bit) - Ubuntu 8.10 (32 and 64 bit) - Ubuntu 8.04 (32 and 64 bit) 2.3 New features in DirectAudit 1.1.0 * Support for 1-way forest trust environments * Only login shells audited by default. Controllable via centrifyda.conf parameter. * Support is added for the following operating systems: - Ubuntu 6.06 (32 and 64 bit) - Ubuntu 7.04 (32 and 64 bit) - Ubuntu 7.10 (32 and 64 bit) 2.4 New features in DirectAudit 1.0.3 * None, this is a maintenance release. 2.5 New features in DirectAudit 1.0.2 * The DirectAudit agents are now compatible with DirectControl version 4.0.0. * Support is added for the following operating systems: - Debian 4 (32 and 64 bit) - OpenSuSE 10.1 (64 bit) - OpenSuSE 10.2 (32 and 64 bit) - Fedora Core 5 (32 and 64 bit) 3. Bugs Fixed This release features the following updates: * Any modifications made to /etc/centrifyda/centrifyda.conf after install were lost when DirectAudit was upgraded. Now custom changes are preserved on upgrade. * The DirectAudit session player now correctly handles non-US date formats. Previously the session player would fail when selecting a comment from the Indexed Command List if non-US date formats were used. * The shell session in which DirectAudit is installed will now exit correctly without having to stop and start the DirectAudit daemon. * Improved the speed of Dacontrol all-shells operations compared to previous releases. * Fixed a UNIX-side spool file corruption issue when dad terminates unexpectedly. * Root login through a GUI interface with SELinux enforcing is now supported. Previously this was only supported with SELinux in permissive mode or when SELinux was disabled. * Pseudo-shells, (nologin, passwd, true and false) are no longer removed from /etc/shells when DirectAudit is installed. * The timeouts have been increased from 30 minutes to 10 hours for session archive and recovery operations as timeouts were being experienced by customers when sessions were >1GB in size. * Extensive DirectAudit documentation update based on customer feedback, including an all-new chapter in the Administration Guide with guidelines on footprint and requirements for implementing DirectAudit. 4. Known Issues The following sections describe common known issues or limitations associated with Centrify DirectAudit. * Disable auditing and stop dad daemon before upgrading If you are upgrading from a previous release of DirectAudit, you should temporarily disable auditing and stop the dad daemon via the dastop command. Use ps to ensure that dad is indeed stopped. Run the upgrade from a shell that is not audited (note that disabling auditing doesn't affect existing audited shells), and ensure that any audited shells that still exist are inactive. The recommended way to do this is to disable auditing (via dacontrol), reboot, run dastop, then upgrade. If you are using all-shells auditing mode, the corresponding dacontrol commands are: dacontrol -d -a to stop auditing dacontrol -e -a to re-enable it If you are using per-user auditing then you should use: dacontrol -d -p to stop auditing dacontrol -e -p to re-enable it * Ensure spool file is empty before upgrading Before upgrading to DirectAudit 1.3.0 or later, you should ensure that any existing spool files are empty as, after upgrade, an existing spool file will be ignored. * First start of dad will take some time after an upgrade if large spool files exist. The *first* time dad is run after an upgrade it iterates through the unix spool files that existed before the upgrade. If the existing spool file is very large (e.g. 1GB), this iteration may take 30 minutes or more, during which time dad will appear to be inactive as far as dainfo and audited shells are concerned, but the dad process (as seen by ps) exists and will use a high amount of CPU time. Subsequent starts of dad will not take as long. * Cannot browse for SQL Server 2008 instance in DirectAudit Manager When browsing for an existing SQL Server instance in the Create Database Wizard in the DirectAudit Manager, only SQL Server 2005 instances will be shown. To open an existing SQL Server 2008 instance, you should type the name of the instance rather than browsing for it. * Installing DirectAudit on 64-bit Windows With 64-bit editions of Microsoft Windows, only the quick install option is supported for installing SQL Server Express. The effect of this is that this release of DirectAudit will support only the SQL Server Express 64-bit edition installed by the DirectAudit installer on a 64-bit Windows computer. * DirectAudit on 64-bit Windows 2008 DirectAudit console and collector are not supported on 64-bit versions of Windows 2008 Server or on Windows 2008 R2. * DirectAudit not supported in WPARs DirectAudit is not supported running in an AIX 6 or 7 Workload Partition (WPAR) in this release. * Shells in /sbin are not audited. Shells under the /sbin directory are not audited. These are typically shells used during system boot. * Only interactive shells are audited By default, DirectAudit audits interactive login shells only. The reason for this is to eliminate the creation of a large number of empty sessions. When a user launches a script from an un-audited shell, DirectAudit interprets the script as a new shell and creates a new, empty session. When auditing is restricted to login shells, DirectAudit does not create these new empty sessions. However, you can configure DirectAudit to begin auditing whenever an audit-enabled shell is invoked from a terminal session, not only when it is invoked from a login shell. To configure DirectAudit to begin auditing whenever an audit-enabled shell is invoked: 1) On the audited machine, open the DirectAudit configuration file /etc/centrifyda/centrifyda.conf with a text editor. 2) Add the following option, and a similar comment to the file: # configure DirectAudit to audit anytime dash is run dash.allinvoked: true Note: Although it is not explicitly in the configuration file, dash.allinvoked: false is the default option. If you want to change back to auditing login shells only, you can specify this option in the configuration file, or simply delete dash.allinvoked: true from the configuration file. * Repair fails after install package is deleted The repair installation feature will not work once the install package (msi) has been deleted. If you attempt to repair the installation after deleting the install package you will need to reinstall, as an attempt to repair will damage the installed package. * Collector cannot connect to SQL Server 2008 SQL server 2008 needs to be configured with a service account rather than a machine account. If the user configures a service account with no domain administrator priviledge, SQL server fails to update the SPN correctly. Kerberos authentication will not work if the SPN is not set correctly on the SQL server service account. The Centrify DirectAudit Database Creation Wizard will check if the selected SQL server instance has the SPN set correctly on its service account. If not, a warning message is prompted, but it will not fix the SPN automatically. The user can run the checkspn.vbs script provided in the DirectAudit Manager installation package to both diagnose and correct the problem. * Installation of SQL Server Express can take a long time When you are installing the DirectAudit Auditor or Management Console applications, some install types include the installation of Microsoft SQL Server Express. In some cases, installation of SQL Server Express can take 10-15 minutes, during which time there is no feedback on the screen. Do not terminate the installation at this point as this is normal behavior. * Unexpected error when using structured query and grouping When using a structured query, and grouping the results by a particular object type, an unexpected error exception is generated when the query is run. To work around this, do not group the results of a structured query. * Auditing cannot be performed if number of machines exceeds license DirectAudit licensing limits the number of machines that can be audited to the number for which DirectAudit has been licensed. Any machines in excess of this number should not be able to be audited, although all others will be audited correctly. However, if the number of audited machines exceeds the number of licenses then no machines can be audited until the session for the machine that caused the number of licensed to be exceeded is removed. * Cannot audit init during startup The init command used during the boot process may not be audited using per command auditing; attempting to do so will result in a system that does not reboot properly. The init command is properly audited when run from an audited shell. * Installation problems when SQL Server is already installed This pertains to the Quick Install method only. When installing DirectAudit on a machine that already has SQL Server installed, you may receive a message indicating that the SQL Native Client package cannot be found. Centrify recommends that you do not install DirectAudit onto a machine that already has SQL Server installed, however if you do need to install on a machine with SQL Server installed, you should remove the existing SQL Native Client package before installing DirectAudit. Note If Microsoft SQL Server is already installed — either the standard or express version — do not use the Quick Install option, which will attempt to install Microsoft SQL Server 2005 Express on top of the existing SQL Server installation. Rather use one of the other options, Server, Workstation, or Custom. * Installer always installs a new database instance This pertains to the Quick Install method only. The installer currently fails to recognize an existing DirectAudit database instance. This issue may be avoided by using the DirectAudit setup.exe program to perform any uninstall operation, ensuring that the database instance is removed, so that if DirectAudit is installed again, there will be no existing database instance. Note If Microsoft SQL Server is already installed — either the standard or express version — do not use the Quick Install option, which will attempt to install Microsoft SQL Server 2005 Express on top of the existing SQL Server installation. Rather use one of the other options, Server, Workstation, or Custom. * Repair installation removes SQL Server instance DirectAudit setup.exe includes a repair installation feature. However, if DirectAudit setup.exe was used to install SQL Server, running a repair installation will uninstall SQL Server from the machine. In this case, rather than running a repair installation, perform an uninstall followed by an install. * Collector configuration allows multiple database selection In the Collector configuration program it is possible to select multiple databases, however only the first selected database is used. Centrify recommends you only choose a single database to avoid confusion. * Collector log-on account must be a local system account In this version of DirectAudit, the "log-on as" account in the collector property page in the services application should be a local system account. Active Directory accounts are not supported. * Collector will not automatically startup Occasionally the Collector will not start up, despite the service being set to start up automatically. When this happens, the collector will correctly start up when started manually. * Uninstalling collector does not remove it from console list When a collector is uninstalled it is not removed from the list of collectors on the management console. To remove it from the management console list it must be deleted manually by clicking on the uninstalled collector and choosing the delete option. * Using Run As... to start DirectAudit applications This release of DirectAudit does not support starting the auditor or management console using Run As... * Auditing users in a remote forest In the auditor console, the username displayed for users in a remote forest appears as a local user name on the DirectAudit audited machine. * Session Command List has been changed to Indexed Command List The Session Command List has been renamed to "Indexed Command List" to help clarify that the dialog provides a partial list of commands executed during the session to ease replaying a session mid-stream. The "command" attribute in the Structured Search query criteria has been removed. Use the "Session output" attribute instead. All existing queries that referenced the "command" attribute are automatically converted to "Session output" during the upgrade process. * Use of add/remove columns The use of the add/remove columns feature for query folders is not supported in this release. * Replay window does not adjust size automatically If the width of the data in the replay window is greater than the size of the replay window, the window does not automatically adjust to show all the data. In this case you need to adjust the size of the replay window manually. * "Too many table names in query" exception A session filter may be defined by clicking on a particular session and choosing "Suppress similar sessions". If many session filters have been defined, and the sessions each contain many commands, it is possible to receive the above exception when Refresh is chosen at the Query node. If you receive this exception, try reducing the number of session filters, or using sessions with fewer commands as the model for sessions to suppress. * Auditing with --per-user shell option When enabling auditing with the --per-user shell option, some limitations apply: - Inability to login via telnet or other /bin/login related method. If this occurs, try moving the shell to a shorter path as it may be caused by the length of the pathname to the shell. - Debian's /bin/dash is skipped. - Indirect links are not enabled automatically. - Restricted shells like ksh will always run in "restricted" mode. * Command output shown in command list window Occasionally, information output by the audited computer is shown in the command list window along with the list of commands typed by a user. This extra information may be ignored. * Filtering on zone names In the console it is possible to filter output based on one or more zone name matches. However, in this release filtering on only one zone name at a time is supported. * Archiving sessions When archiving sessions in the Manager Console, a new name should always be chosen for the archive file as appending to an existing archive file is not supported in this release. * Removing deleted users from the authorized users list Authorized users should be deleted from DirectAudit before they are deleted from Active Directory as they cannot be removed via the Manager Console after they have been deleted from Active Directory. If a user is deleted from Active Directory before they are deleted from the authorized users list, then you should use the SQL Server Management Studio to remove the user from the DirectAudit database directly. Navigate to: root node -> security -> logins and remove logins. Then navigate to: root node -> Databases -> -> Security -> Users and remove the deleted users. * KDE Konsole Super User mode not supported The kdesu graphical su is not supported with DirectAudit in this release. To use KDE and superuser mode you should use su instead. From the KDE menu, select System Tools > Terminal Program Super User Mode and set the program to System Tools/Terminal. This will launch the regular (non-superuser) terminal. To enter superuser mode use su from the terminal prompt. * Unable to start a GUI session if the user's shell is a symlink to csh If a user's shell has been configured to a per-user auditing shell that points to csh (e.g. /bin/dash_bin_csh), and auditing has been disabled, the user will not be able to login via GUI. Available workarounds: (1) don't use per-user shell auditing, or (2) if using per-user shell auditing, and the user's shell is 'csh', and auditing has been disabled, reconfigure users' shells to refer to the real csh shell, not the symlink. (3) use another shell. * Keyword search in the session player will fail if the keyword spans two lines. * SQL Server 2005 full text search categorizes certain words as noise words by default and ignores them for searches. Some are common Unix commands for example, like, which, do, while. Full list is below: Users can change the noise word list by modifying this file (for US English): C:\Program Files\Microsoft SQL Server\ MSSQL.1\MSSQL\FTData\noiseENU.txt about, 1, after, 2, all, also, 3, an, 4, and, 5, another, 6, any, 7, are, 8, as, 9, at, 0, be, $, because, been, before, being, between, both, but, by, came, can, come, could, did, do, does, each, else, for, from, get, got, has, had, he, have, her, here, him, himself, his, how, if, in, into, is, it, its, just, like, make, many, me, might, more, most, much, must, my, never, no, now, of, on, only, or, other, our, out, over, re, said, same, see, should, since, so, some, still, such, take, than, that, the, their, them, then, there, these, they, this, those, through, to, too, under, up, use, very, want, was, way, we, well, were, what, when, where, which, while, who, will, with, would, you, your, A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z * Search behavior in the session player If the term you are searching for in the session player is on the same line as user input, you will have to hit the 'Search' button multiple times to continue searching in the session. * Fast session player output will cause search targets to scroll off the screen. In cases where the original terminal output is fast and scrolling occurs some search targets may scroll off the screen so fast that the user will not see it. The session player will find the search target packet and pause. As the content has already scrolled off the screen, the user may not realize why the session player stopped without showing any highlighted search items. * Collector throughput may be degraded during restore of large archives. * Slow response for first search after SQL server has been idle. Periodically SQL Server Full Text Search (FTS) will go out to verify the signature of the DLL/binaries used by the service. This will cause a search delay for the first search performed after SQL server has been idle for some time. * Zmodem applications may fail. Invocations of zmodem applications such as sz, rz, and kermit, within or via an audited shell may fail. * Replay of sessions generated from an Emacs shell will be incorrect. When a unix session is started from within Emacs, the session player will display the output incorrectly with a stair-step effect. * Missing session header will cause an incorrect session start time to be displayed. If the session header is missing or lost the session start time will be incorrectly shown as 12/31/1752. This occurs if part of the session was not correctly written to the database. This can happen if the local spool file is deleted or the zone is configured to send audit data to another database while an active session is being audited. * The DA collector service may throw an exception during uninstall. The DirectAudit collector service may throw an exception during the uninstall process. The recommended procedure is to stop the collector service, wait for the service to stop, and then uninstall. * 'who -m' and 'who am i' will not return any info When DirectAudit is enabled 'who -m' and 'who am i' will not return any info. A workaround is to use who --lookup. * Collector event error after migrating to a new domain. The collector may report: Centrify DirectAudit internal error in the Windows event log after migrating to a new domain. Reason: System.Runtime.InteropServices.COMException (0x80072020): An operations error occurred. This error can be safely ignored. This is because old sessions may still exist on the unix client spool file, these sessions will continue to despool after joining and will contain data from the previous domain. The collector tries to resolve the SID, if it cannot it logs the error. * Modifying or deleting the 'dbo' is not allowed" The user that created the DirectAudit database is also the database owner (dbo) in SQL Server. This user is shown in the DirectAudit Manager / Authorized Users node and cannot be modified or deleted. * The Windows Installer 3.1 redistributable package does not work on 64-bit systems and will fail silently. For 64-bit system, users need to download the installer separately. See the section "Download the installer for 64-bit versions of Windows Server 2003 or 64-bit versions of Windows XP" in the following MSDN KB. http://support.microsoft.com/kb/893803 For the most up to date list of known issues, please refer to the Knowledge Base article in the Centrify Support Portal, KB-1896 for the latest known issues with DirectAudit 1.3.0. 5. Additional Information and Support In addition to the documentation provided with this package, you can find the answers to common questions and information about any general or platform-specific known limitations as well as tips and suggestions from the Centrify Knowledge Base. You can also contact Centrify Support directly with your questions through the Centrify Web site, by email, or by telephone. To contact Centrify Support or to get help with installing or using this version of Centrify DirectAudit, send email to support@centrify.com or call 1-408-542-7500, option 2. For information about purchasing or evaluating Centrify products, send email to info@centrify.com.