Enabling Auditing for Remote Sessions

All components of the Privileged Access Service log audit trail events for the activity on systems, domains, databases, applications, and accounts that you add to the service. If you also want to audit user session activity initiated from the Admin Portal on target systems, you can enable the auditing and monitoring services that are part of the Privileged Access Service enterprise offering.

To prepare for auditing, you must have at least one working audit installation running in your environment. If you don’t have an audit installation and want to create one, you can download the auditing and monitoring services for Privileged Access Service from the Customer Support Portal, then follow the instructions in the Auditing and Monitoring Administration to set up a working environment.

The audit installation must include the following core components:

• A management database to store installation information
• The audit store and audit store database to define the scope and store session activity
• At least two collectors to collect session activity and send it to the audit store database
• The Audit Manager console to manage installation components, audit roles, and permissions
• The Audit Analyzer console to view, query, and manage recorded activity

For information about creating the audit installation and configuring the core components of the installation, see the Auditing and Monitoring Administration.

If you are familiar with auditing using the auditing infrastructure, you might have an agent installed on some or all of your target systems. However, the agent is not required to audit session activity on the remote target computers you have added to the Privileged Access Service. Instead, you can use the Cloud Connector to send session activity directly to the collector without installing an agent or the auditing service on the target system. The only additional requirement to enable auditing using the connector is that the computer you are using for the connector must be within the scope of an audit store—that is, the computer must be included in the site, subnet, or IP address identified as the audit store. The session activity for all target systems will be sent to the audit store that includes the computer where the connector is installed.

For more information about defining the scope for an audit store, see the Auditing and Monitoring Administration or Creating the First Audit Store. If you're working with systems inside of a DMZ, be sure to read Auditing systems that are inside a DMZ.

Auditing Sessions on Target Systems

All of the administrative activity that takes place through the Privileged Access Service is audited and stored as events either locally or in the Privileged Access Service. In addition, if you have installed auditing services and have an audit installation established, the administrator’s activity on the target system during a secure shell or remote desktop session can also be collected and stored in an audit database for further review and analysis.

Capturing and Replaying Sessions

If you have an audit installation available and enable auditing, the connector captures all of the secure shell and remote desktop activity in the sessions you open from the administrative portal. The connector sends the recorded sessions to the collector service, which forwards the sessions to the audit store database. You can play back the recorded sessions using Audit Analyzer. You can also use Audit Analyzer to create queries and reports based on session activity and to review, update, or delete the sessions.

If you have multiple connectors, the connector used to record the session is selected randomly when you start the SSH or RDP session. If the connector with an active session stops running, the session is disconnected. If the connector is recording a remote desktop session when it stops, you can manually reconnect to the target system using a different connector to resume the session. However, the session segments are recorded in the audit store database as two separate audit sessions. The connector will spool audited session activity if it can’t connect to any collectors.

You must have the required Privileged Access Service components installed to audit the sessions you open from the Admin Portal. If you have an older version of Server Suite, you must upgrade before enabling auditing using the connector.

For more information about managing the audit installation, querying and reviewing session activity, and other auditing-specific topics, see the Auditing and Monitoring Administration.

Windows Sessions Recorded by a Connector

If you are already auditing session activity on Windows computers, you might notice a few differences between sessions recorded directly on a Windows computer that has an agent installed and the remote desktop sessions recorded by the Cloud Connector. For example, if a Windows session is recorded by the connector, you might notice the following differences:

• Windows sessions recorded by the connector do not include an indexed list of events.
• You cannot specify any agent configuration settings, such as the color depth to use or the offline data storage location.
• There is no role-based auditing or integration to skip auditing for some activity or to audit only privileged activity.

• Windows sessions recorded by the connector do not include any information about the DirectAuthorize desktop being used or about desktop changes.

  However, you can use the desktop label to determine the desktop used for different operations when replaying Windows sessions.

UNIX Sessions Recorded by a Connector

If you are already auditing session activity on UNIX computers, you might notice a differences between sessions recorded directly on a Linux or UNIX computer that has an agent installed and the remote shell sessions recorded by the Delinea Connector. For example, if a UNIX session is recorded by the connector, you might notice the following differences:

• UNIX sessions recorded by the connector do not include standard input (stdin).
• You cannot specify any agent configuration settings that you control using the centrifyda.conf file, such as password masking.
• There is no role-based auditing or integration to skip auditing for some activity or to audit only privileged activity.
• You cannot configure “per command” auditing.
• You cannot obfuscate any sensitive information that might be captured in a session.

Specifying the Audit Installation

After you have created an audit installation and verified you have a working environment, you can enable auditing and specify the installation name for the systems you manage in the Admin Portal.

To configure auditing settings:

1. In the Admin Portal, click Settings > Resources to display the settings available for Privileged Access Service.

2. Click DirectAudit.

3. Select Enable Auditing.

4. Type the name of the audit installation where you want to audit user activity on the systems you manage.

5. Optionally, click Add to map one or more connectors to a specific audit installation.

   If you have multiple audit installations—for example, to support multiple data centers— you might want to specify which connectors to use for each audit installation for network efficiency, high availability, and load balancing.

   After clicking Add:

   • Specify an audit installation name.
   • Select one or more connectors from the list of available connectors to receive and transfer audited activity.
   • Click Done.

6. Click Save to save the setting.

Adding Connectors to a Secure Installation

If you have configured auditing to run as a secure installation that only allows agents to connect to trusted collectors and collectors to only accept connections from trusted agents, you must add the connectors you are using to the list of trusted audited systems for the audit store. If the connectors are not identified as trusted systems, the sessions and audit trail events captured by the connector will not be accepted by the audit store database.

For information about configuring a secure installation and how to identify trusted systems, see the Auditing Administrator’s Guide.

Downloading the Audit Packages for the Cloud Clients

In order to enable full auditing on a system outside of Active Directory, please download and install the following audit packages, depending on your system:

Windows: After enrolling the system with the Cloud Client for Windows, download and install the Windows - Audit package. The audit package enables the system for auditing.

Linux: After enrolling the system with the Cloud Client for Linux, download the two additional audit packages appropriate for your Linux system. Install these Linux audit packages in the following order:

1. <Linux operating system> - OpenSSL
2. <Linux operating system> - Audit

For more information about configuring your audit installation to collect data from non-Active Directory systems, see Checklist for auditing systems outside of Active Directory.

Audit Commands Included with the Cloud Client for Windows Audit Package

If you install the audit package and enable auditing for a system that has the Cloud Client for Windows installed, you can use any of the following commands with the caudit.exe command line program to enable or disable auditing, display audit status, or change the log level. You must have local administrative rights to enable or disable auditing, change the log level, or prepare a diagnostics package.

Auditing Systems Outside of Active Directory

You can use gateway-based auditing for systems that are not in your Active Directory system. For the non-Active Directory systems that you need to audit, you have two ways to do so:

• (Option A) Install and enroll the Cloud Client on the systems you want audit.
• (Option B) Configure your non-Active Directory cloud connectors to point to your audit collectors (which are joined to Active Directory). Any systems connected to PAS by way of these cloud connectors will be audited.

For option A, the details of what you need to do are specified in Checklist for auditing systems outside of Active Directory.

For option B, follow just steps 1-6 in the Checklist for auditing systems outside of Active Directory, and then configure your non-Active Directory cloud connectors with the changes below.

To configure a non-Active Directory cloud connector to point to your Active Directory-joined audit collectors:

• Make the following registry key changes:

 Location – HKLM\\SOFTWARE\\Centrify\\Cloud
  Name – NGDACollectorsOverride
  Type – REG_MULTI_SZ
  Value – One or more collectors in FQDN:Port format. For example, DACOLLECTORHOST1.ACME.COM:5064.

Port 5064 is the default value; be sure to use the same port that your audit collectors use. You can open the Collector Control Panel to see which ports that the audit collectors are using.

You can make the registry key changes at the command line by running a command with the following syntax:

reg.exe add HKLM\\SOFTWARE\\Centrify\\Cloud /v NGDACollectorsOverride /t
REG_MULTI_SZ /d <one or more collector hosts in FQDN:Port format separated by
\\0\>

Here's an example:

reg.exe add HKLM\\SOFTWARE\\Centrify\\Cloud /v NGDACollectorsOverride /t
REG_MULTI_SZ /d DACOLLECTORHOST1.ACME.COM:5064\\0DACOLLECTORHOST2.ACME.COM:5064`