LOGbinder Blog

Updates, Tips and News   RSS Feed  

New Syslog Features in LOGbinder SP 4.0.5

Mon, 17 Mar 2014 11:06:43 GMT

We have a quick update to LOGbinder SP for all of you who are using Syslog to forward your SharePoint audit log to your favorite SIEM.

LOGbinder SP version 4.0.5 adds the following new features:

  • Alternate Output Data Folder: It is now possible to change the default data folder, which is also used for the output data. This is the folder where LOGbinder stores its outputs that are written in files, as well as the diagnostic files. Now you can store these in a different folder, or on a different hard drive, or even in shared folder on a different server. You will find this useful, if you need to separate software and data, or you have the requirement of using minimal disk space on the hard drive where your programs are installed.
  • Network locations for Syslog output: As a result of the above change, it is now possible to use network location for Syslog outputs, such as Syslog-Generic (File) and Syslog-CEF (File). These files, in turn, can be easily accessed by your SIEM.
  • Test button for Syslog output: A "Test" button is now available for Syslog outputs that sends a test Syslog message using the specified address/port. When setting up LOGbinder to output to a Syslog server for your SIEM to collect the logs, the most difficult part can be to ensure that firewalls and other settings don't block the traffic from LOGbinder to the Syslog server. The "Test" button will assist you in setting up and testing this connection.
  • Output file name clarification: The sample file name for the Syslog (File) outputs now correctly indicates that the date is included in the file name.

If you would like to take advantage of the above feature, please go ahead and download LOGbinder SP.


Dealing with large amount of audit backlog when first starting LOGbinder EX

Wed, 12 Feb 2014 17:38:19 GMT

If you have had auditing enabled on your Exchange server for a while when you install LOGbinder EX (and administrator audit logging is enabled by default), you might have large amount of audit data accumulated, depending on your audit retention period. (See AuditLogAgeLimit for mailboxes, and AdminAuditLogAgeLimit for the administrator audit log.)

When starting LOGbinder EX for the first time, LOGbinder will collect and process all audits existing in your Exchange system. If there is a large amount of audit logs, this can take up a considerable time and computational resources on your Exchange server. How can you find out how much audit data you have in your Exchange environment, and what can you do if you do not want to process large amount of backlogs?

Assessing size of audit data

The following Exchange PowerShell command displays the mailboxes with the 20 largest audit data size. It only queries the mailboxes that have auditing enabled.

Get-Mailbox -Filter {AuditEnabled -eq $true} | Get-MailboxFolderStatistics | where {$_.Name -eq "Audits"} | Sort-Object FolderSize -Descending | Select-Object Identity, ItemsInFolder, FolderSize -First 20

The following Exchange PowerShell command displays the size of the administrator audit log.

Get-Mailbox -Arbitration | Get-MailboxFolderStatistics | where {$_.Name -eq "AdminAuditLogs"} | Select-Object Name, ItemsInFolder, FolderSize

If you find that any of the above seems too large (for example, you have hundreds of megabytes of mailbox audit data in some mailboxes), then you might want to consider bypassing those past events, and start the audit log collection with LOGbinder EX from this point forward.

Omitting past audit logs

If you decide that you would like to omit the past audit logs and let LOGbinder EX start processing only new logs, please contact us at support@logbinder.com, so we can set up LOGbinder for you to start processing from a given time and date.

In the near future, a new feature will be included in a LOGbinder EX release that enables specifying the start time, just like it is already done in our other products: LOGbinder SP and LOGbinder SQL.


SQL Server Audit Support in Different Editions and Versions

Sat, 23 Nov 2013 14:02:05 GMT
SQL Server 2012 made SQL Server Audit partially available to all editions. Until SQL Server 2012, this true, native auditing feature (introduced in SQL Server 2008) was only available in Enterprise and Datacenter editions. Starting with SQL Server 2012,the server-level auditing portion of SQL Server Audit was made available to all editions, leaving only the more granular database-level auditing still exclusive to the Enterprise edition.

SQL Server Audit is based on actions and action groups. The audit can contain server-level audit specification and database-level audit specifications:
  • Server-level auditing consists of server-level audit action groups, which include server operations, such as security operations involving logins, roles and permissions, logon and logoff operations, database backup and restore,manipulation of certain database-, server-, and schema objects.
  • Database-level auditing is auditing at the database scope, and it is set on each database individually. This feature is not available in all editions of SQL Server, only in Enterprise editions. Database-level auditing utilizes database-level audit action groups, and database-level audit actions.
    • The database-level audit action groups cover some similar areas as the server-level audit groups, if applicable, but at the database level.
    • Additionally to auditing action groups,database-level auditing also enables auditing certain individual actions, such as SELECT, INSERT, UPDATE, DELETE, EXECUTE, RECEIVE, and REFERENCES. These database-level audit actions can be restricted to a specific database, an object (such as table, view, stored procedure), or a schema.
Here is a summary of the SQL Server Audit support in the different editions:

 Edition  SQL Server 2008 and 2008 R2  SQL Server 2012
 Enterprise
Server- and database-level Server- and database-level
 Evaluation Server- and database-level Server- and database-level
 Developer Server- and database-level Server- and database-level
 Datacenter Server- and database-level N/A
 Business Intelligence  None  Server-level
 Standard  None  Server-level
 Web  None  Server-level
 Express  None  Server-level

So where does LOGbinder SQL fit into the SQL audit equation? LOGbinder SQL can be installed on any Windows server running SQL Server 2008 or later regardless of the edition, including Express. It does not need to be installed on Enterprise edition. The requirement is that the SQL Server that is being audited is:

  1. Set to produce audit events.
  2. Set to output these audit events to a location accessible to LOGbinder SQL.
The audit file can then be accessed and processed by LOGbinder SQL and made available for your SIEM / log management solution.

To summarize, audit logs could move the following way:


LOGbinder SP use of SQL Privileges

Thu, 10 Oct 2013 09:33:13 GMT

Issue

In the blog on www.logbinder.com (Workaround if LOGbinder SP is having SQL database issues), a suggested workaround for insufficient privileges to SharePoint’s SQL databases is to add the LOGbinder service account as a database administrator (DBO). The question arises: How does LOGbinder SP use these elevated privileges?

Access to SharePoint databases

First, it must be understood that LOGbinder SP does not access SharePoint’s SQL databases directly. All access to SharePoint data is through the SharePoint Server Object Model (see http://msdn.microsoft.com/en-us/library/jj164060.aspx). LOGbinder SP does not execute any Transact-SQL commands directly, nor does LOGbinder SP access the SQL database directly to adjust database structure, privileges, and so forth.

The workaround suggested in the above blog is recommended based on troubleshooting in our labs, to address what apparently is a defect in the SharePoint Server Object Model. LOGbinder SP does not then use these elevated privileges to perform other activity.

LOGbinder SP’s use of SharePoint data

Even though LOGbinder SP accesses SharePoint through its object model, a secondary question may be: What activity does LOGbinder SP perform in SharePoint? LOGbinder SP’s main activity is to read SharePoint audit logs, as well as to read metadata about SharePoint site collection, lists, libraries, users, groups, and similar entities.

Through the SharePoint Server Object Model, LOGbinder SP does make some changes to SharePoint (the customer specifies these changes in the LOGbinder Control Panel). The changes LOGbinder SP will make to SharePoint include: adding/removing site collection administrators, adjusting audit policy settings for a site collection, adjusting the audit log trimming setting for a site collection, and deleting audit log records. (The documentation for LOGbinder SP contains details on these actions.) So, other than purging old log data and setting audit policy according to configuration settings by the administrator, there is nothing that LOGbinder does that modifies or could corrupt SharePoint content or the SQL database.


Audit Myth Busters: SharePoint, SQL Server, Exchange

Wed, 02 Oct 2013 08:58:56 GMT

previous | next

powered by Bloget™