How To: Enable or Disable Arculix Device Trust Logging

Version Affected: Arculix

 

Overview

Device Trust collects all significant runtime events and can send them to either or both of two destinations for archiving: local text files on the workstation, or the operating system's central log storage. This article explains how to enable or disable each logging destination and answers frequently asked questions about Device Trust logging.

Logging Destinations

The two logging destinations serve different purposes:

• Text files on the workstation: controlled by the Enable/Disable file logging option. When enabled, Device Trust writes events to two text files: AccepttoCP.log for the authentication plugin, and atagent.log for the agent. No rotation or retention is applied to these files, but they are easy to find, read, and send to Support when reporting an issue.
• Central operating system log storage: controlled by the Enable/Disable system logging option. Both Windows and macOS have built-in log aggregation subsystems that third-party applications can use, with their own viewers and management interfaces, and their own rules for how (and whether) events are retained or forwarded to another system such as an external SIEM. Depending on how the subsystem is configured, it may not be trivial to find, filter, and export the logged events.

Enabling or Disabling Each Destination

• To capture logs locally, enable Enable/Disable file logging in the Arculix Admin Dashboard. This option is enabled by default and can be set at the organization level (by an Organization Admin) or overridden at the user level by support@secureauth.com.
• To forward logs to the operating system's central log storage instead (or in addition), enable Enable/Disable system logging. This option is disabled by default and follows the same organization-level / user-level override rules as file logging.

SecureAuth recommends keeping file logging enabled at all times, since it contains critical information for troubleshooting. Only enable system logging in addition if you have a specific requirement, such as forwarding to an external SIEM or needing more advanced retention and rotation policies than file logging provides.

Frequently Asked Questions

• Do the “enable system logging” and “enable file logging” options apply to both the organization and user level? Yes. Both can be set at the organization level by an Organization Admin, and both can be overridden at the user level by support@secureauth.com.
• When system logging is enabled, is the same information logged to the syslog (macOS) or Event Log (Windows) as to the Device Trust file logs? Yes. The logged events are identical regardless of destination.
• What are some reasons to enable logging other than debugging an issue? The primary use case is troubleshooting, but system logging also lets you forward events to an external system for post-processing.
• Why are there two separate logging systems? They serve different purposes, and corporate policy may require one over the other.
  • Both can be enabled at the same time.
  • You rarely need both enabled together — file logging alone is usually sufficient.
• When should I use one versus the other? Keep file logging enabled at all times, and only enable system logging when you have one of the specific requirements described above.
• Should file logging be enabled by default at the organization level? Yes. File logging should be enabled for all workstations unless there is a specific reason not to.
• What are the drawbacks of keeping both enabled by default? None, unless the workstation has extreme storage restrictions — even long-running installations rarely exceed a few megabytes of log data.
• Can logging be enabled by the end user, or does it require an administrator? It must be enabled by an administrator; end users cannot enable it themselves.
• Is there a performance impact when offline event logging is enabled? No. The performance and storage overhead of both approaches is negligible, and fast-occurring log entries are coalesced into single entries to avoid flooding the logs.

If you have any further questions, reach out to support@secureauth.com.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.