Logging is important for any device, but often considered critical for enterprise applications. One issue with configuring logging on enterprise applications is determining how to configure logging on enterprise applications. I would like to provide a reference guide to ease this pain point.
Notes
Every application should support logging. What you need to know for each application is:
- What logging is enabled by default?
- How can you change logging?
- Where do logs go?
These questions are critical when designing a syslog solution to ensure that the proper events are being collected for troubleshooting, root cause analysis, auditing, security, and compliance reasons.
You will notice in many cases below I do not give specific examples on how to configure logging on enterprise applications and instead provide some commentary as well as links on where to get more information. The reason for this is because how you configure logging on any device depends heavily on requirements. I would rather provide the resources then provide a solution that may or may not fit your needs. In addition, this post does not cover how to forward OS logs to a remote syslog target. I will also be covering this topic in a later post.
Microsoft
In terms of logging for Microsoft Windows and Microsoft products it is important to note several things:
- Windows does not natively support syslog
- Most Microsoft product event logs in Windows log to the Windows Event Viewer
- The Windows Event Viewer primarily contains events with a priority of warning or higher
- Several application in Windows (e.g. VMware) also log to specific log files and contain information separate from the Windows Event Viewer
Active Directory
Default Active Directory logging is typically sufficient. To enable additional Active Directory logging see:
Exchange
Logging for Exchange needs to be configured or else information will be missing. For more information on how to enable additional logging in Exchange see:
IIS
IIS logs to a particular directory on Windows. This directory would need to be monitored by a syslog agent in order to ensure all events were being forwarded. For more information on logging in IIS see:
SharePoint
Default SharePoint logging is typically sufficient. To enable additional SharePoint logging see:
SQL
SQL logs detailed errors to a particular directory on Windows. This directory would need to be monitored by a syslog agent in order to ensure all events were being forwarded. For more information on logging in SQL see:
Oracle
Auditing is disabled by default. Several auditing outputs are supported. For syslog support, the AUDIT_TRIAL should be set to OS, which allows a syslog agent to collect and forward the events to a remote syslog target. To configure the AUDIT_TRIAL, you can run a command like:
ALTER SYSTEM SET audit_trail=OS SCOPE=SPFILE;
In addition to setting the AUDIT_TRIAL, several other parameters needs to be considered. This includes what events should be auditing. For example:
AUDIT INSERT, UPDATE, DELETE ON sys.aud$ BY ACCESS;
Also you can specify the AUDIT_FILE_DEST and the AUDIT_SYSLOG_LEVEL. Finally, be sure to check out Fine Grained Auditing (FGA) if you need that functionality.
For more detailed information on configuring auditing in Oracle please see:
SAP
SAP have a lot of different components that are capable of logging in different ways. For more information see:
© 2013, Steve Flanders. All rights reserved.
