This article will be used to enable/disable Arculix Device Trust logs.
All significant events in Device Trust are collected at runtime and can be sent to 2 different destinations for archiving:
- Text files on the workstation: This destination is controlled by “Enable/Disable file logging” option on the admin panel. When enabled, all generated events will go into 2 different text files on the workstation. “AccepttoCP.log” for the authentication plugin logs, and “atagent.log” for the agent logs. These files are controlled by Device Trust. No rotation or retention features are available for this option. They are easy to find, read and send to support in case of reporting issues.
- Central operating system log storage: This destination is controlled by the “Enable/Disable system logging” option on the admin panel. Both Windows and macOS have central log aggregation subsystems that can be utilized by 3rd party applications to store their logs and events. The operating system has complete control over how and where it stores these events and whether they are also sent to another log processing system for further processing or archiving. Both operating systems have built-in viewers and management interfaces that can be used to inspect the entries. You can use this option If you need flexible and advanced log retention and rotation policies and/or forwarding logs to external SIEM systems for further processing. Depending on the subsystem configurations, it might not be trivial to find, filter and export the logs.
In general, we recommend keeping the “Enable/Disable file logging” option enabled, as the logs contain critical information that can help track down and troubleshoot potential issues. This options is enabled by default.
The “Enable/Disable system logging” option, however, is disabled by default and can be enabled if you have any of the use cases mentioned in the 2nd bullet point above.
Below are FAQs related to the above topic:-
- Do the “enable system logging”, and “enable file logging” options apply to both organization and user level?Yes, they both can be set per organization and also overridden. For organization basis, it can be done by a user who is an Organization Admin. For user level, it will be done by email@example.com .
- In “Enable system logging” do you get the same exact logging information in the syslog (macOS) and Event Log (Windows) as you get in the Device Trust file logging?Yes, logged events are identical regardless of the destination.
- What are some of the reasons to enable logging other than for debugging an issue?The primary use case is to help with troubleshooting. In case of using central logging, you can choose to forward the logs to external systems for post processing.
- Why have two separate logging systems (both system logging and file logging)?They serve different purposes and corporate polices might enforce using one vs the other. Please see above for more information.
- Can both be enabled at the same time?Yes
- If so, why would you want both to be enabled?You rarely need to enable both of them, usually one would suffice (File logging).
- When would you use one vs the other?We recommend you keep the “File logging” enabled at all times and only enable “System logging” when you have specific requirements, see above for examples of such use cases.
- Should they be enabled by default at the organization level? Yes, “File logging” should be enabled for all workstations unless there are very specific reasons not to.
- What are the drawbacks of keeping them on by default?None, unless you have very extreme storage restrictions on workstations. Even long running installation won't exceed a few megabytes in size.
- Can logging be enabled by the user, or it has to be enabled by the admin?No, it needs to be enabled by the administrators.
- Is there a performance issue when offline events logging is enabled?No, performance and storage overhead in both approaches are negligible. Fast occurring log entries are also coalesced into single entries to avoid polluting the logs.
If there are any queries, feel free to reach out to us at firstname.lastname@example.org.
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.