LOGbinder Blog

Updates, Tips and News   RSS Feed  

Least Privilege Workaround for SQL DB Access

Sat, 08 Dec 2018 10:21:56 GMT
In the past we have explained how LOGbinder for SharePoint uses SQL privileges. We also informed you about the unfortunate workaround of giving dbo access to certain DB's in SQL in the sporadic cases when the SharePoint API interferes with access to the databases. 

This was never a "workaround" that we were really happy with.  Giving dbo access is not only like giving the bank the title to your home as collateral for the mortgage but also giving them a letter that says "Stop by anytime you want and while you're here feel free to repaint the walls and help yourself to the scotch in the pantry."

Thankfully, we have found a proper workaround that does not require dbo access.  There is a role on the SharePoint SQL DB's named "SPDataAccess".  We have found that giving the service account this role grants enough access for LOGbinder for SharePoint to function properly.  Again we would like to specify that this is not the standard configuration needed with LOGbinder for SharePoint.  This is only used in the rare situations when the SharePoint API is giving issues with DB access.  For most of our customers the permissions set within SharePoint itself for the service account is all that is needed. 

There are two ways to give the service account this role.  One is using the SharePoint Management Shell and the other is directly in SQL (in our example below using SSMS). 

Our preferred method is making the changes directly in SQL.  We noticed that when using the SP Management Shell an extra role is given.  We also noticed that this is not always the case as well.  Sometimes the extra role is given and sometimes it is not.  Why?  We don't know.  Maybe it's a hidden Microsoft feature.

Here is how to make the changes using SSMS.

1. In SSMS add your service account as a login.


2. Open the logins properties and locate the three databases that your SharePoint farm is using for the Admin Content, Configuartion and WSS Content databases..  In this instance we have SharePoint_AdminContent(GUID), SharePoint_Config2019 and WSS_Content(GUID). 


3. For each database map the SPDataAccess role to the login.  You will notice that for the WSS_Content db, after saving the role change SSMS also grants the PSDataAccess and the PSReportingSchemaAdmin role.  If you have more than one content db, then you will have to perform these steps on all applicable db's with the WSS_Content prefix.  For more information on how to set SPDataAccess on a large number of content databases, click here.


You can also perform the steps above with a simple cmdlet using the SharePoint Management Shell.  Run the following cmdlet:

Get-SPContentDatabase | Add-SPShellAdmin -UserName domain\ServiceAccount

So in our example below we ran "Get-SPContentDatabase | Add-SPShellAdmin -UserName lab\sp2019srvacct".  Notice that doing this grants an additional role on all three databases; the SharePoint_Shell_Access role. As security experts our recommendation is obviously whichever process results in the least privilege needed to get the job done which, in this case, is making the changes via SSMS.


What does the SPDataAccess role allow?  According to TechNet, the SP_DATA_ACCESS role will have the following permissions:

  • Grant EXECUTE or SELECT on all SharePoint stored procedures and functions
  • Grant SELECT on all SharePoint tables
  • Grant EXECUTE on User-defined type where schema is dbo
  • Grant INSERT on AllUserDataJunctions table
  • Grant UPDATE on Sites view
  • Grant UPDATE on UserData view
  • Grant UPDATE on AllUserData table
  • Grant INSERT and DELETE on NameValuePair tables
  • Grant create table permission
Reference:  TechNet

Exchange Cumulative Update breaks auditing

Wed, 01 Feb 2017 14:15:31 GMT
We have discovered earlier today that the latest Exchange cumulative updates released in December 2016 may be breaking Exchange auditing. We are currently testing the issue internally along with a few of our customers who have reported the same issue.  As of this time, installing the latest cumulative updates may break Exchange auditing which will break LOGbinder for Exchange.  Please visit our Knowledge Base for further details and steps to check if you are affected.

December 2016 LOGbinder Newsletter: New version of LOGbinder for SQL Server

Fri, 23 Dec 2016 10:48:01 GMT
In June 2016 Microsoft released SQL Server 2016 but due to a bug in their Exchange 2016 release, we wanted to make sure that we performed very extensive testing of this latest version of SQL Server and its new auditing features to make sure we didn’t discover any bugs there too.  We also performed very stringent testing of LOGbinder for SQL Server to make sure that our software continues to meet and exceed our internal standards.

With the release of SQL Server 2016 came not only many new features but also some new audit events. These include audit events related to committing and rollback of transactions, handling master keys, column encryption keys, database scoped credentials, as well as events related to external data sources (think, for example, Hadoop), external file formats and external resource pools.

LOGbinder for SQL Server 3.0 includes the ability to handle these new events as well as many other improvements. Here are some of the highlights:

  1. Support for SQL Server 2016
  2. New installer – Our new installer automates some of the prerequisites required during the installation process.  Installation time is now just a couple of minutes.
  3. Improved service resilience – We have improved on the delay that was reported by some customer when restarting/starting/stopping the service.
  4. Purge processed files - We have added a new option to purge SQL audit files that are no longer being used by SQL Server and have already been processed by LOGbinder.
  5. Enhanced application activity events - Information events written to the Windows Application log now include statistics including entries exported, elapsed processing time and events per second (EPS).

These are just a few of the improvements in this release of LOGbinder for SQL Server. For full details, check the release notes below.

Customers with current support and maintenance contracts can access the latest version at the link below.  To upgrade to the latest version just run the installer on top of the previous version.  No data or settings will be lost. Please note you will need to request a new license key for this version.  You can do so by clicking on File in the LOGbinder Control Panel, then License and send the license information to licensing@logbinder.com.

Related information

Thank you for your hard work in protecting sensitive information, and thank you for your support!


LOGbinder for Exchange 3.3.5 Released

Wed, 13 Jul 2016 18:15:30 GMT
We are happy to announce the release of the latest update to LOGbinder for Exchange.  The latest update, Version 3.3.5, introduces some improvements as well as a few bug fixes.  We know that some of our customers that utilize the LEEF Syslog output may have had a few issues with the format of the LEEF output.  This latest release fixes that issue.  We have also created a more robust installer for LOGbinder that automatically configures many of the prerequisites that previously had to be configured manually.  Click here to see a list of all of the latest enhancements and bug fixes.

In conjunction with this release, we have also added a new support section at LOGbinder.com that we will be keeping up-to-date with the latest news, bulletins and features of the entire suite of LOGbinder products.


The 24-hour Bug in Microsoft Exchange Mailbox Auditing

Mon, 14 Dec 2015 16:36:48 GMT

"This is the official LOGbinder page for tracking the Exchange  24-hour mailbox audit bug. You can keep up with everything my team knows and  is doing by checking this page often.” – Randy Franklin Smith



LOGbinder bulletin, December 14, 2015 -- While investigating a support case, LOGbinder discovered a non-obvious yet critical bug in Exchange audit logging that essentially delays your ability to detect non-owner mailbox access for 24 hours. The PowerShell cmdlets New-MailboxAuditLogSearch and Search-MailboxAuditLog produce audit search results that are unpredictable and inconsistent when auditing all mailboxes and the start date is less than 24 hours ago.

We have notified Microsoft about the problem and they have confirmed it as a bug but have told us that they have no timeline for a bug fix. The bug affects Exchange Server 2010, 2013 and 2016.

What is the risk?

The risk to you is that you may never know you have an Exchange Server data breach – despite performing regular audits.

This strikes to the very core of application security audit. Not only is a 24-hour audit delay 24 hours too long, audit integrity is absolutely critical to security intelligence operations.

Details about the Bug

We encourage you to watch an 8-minute clip of our recent Exchange mailbox audit webinar embedded below. In this clip we discuss specifics about the bug and how it could be affecting you.

Here are the highlights about the bug:

  • The bug returns unpredictable results when auditing all mailboxes: you may get no events at all when there are events, you may get only a few events, or you may get all matching events as you should. 
  • Unless you are looking for specific events repeatedly – or you audit your audit results – you will never notice the problem. 
  • The bug is not documented. We have reported this issue to Microsoft; they have confirmed it is a bug and said they have no solution timeline to share. Microsoft’s suggested workaround is to use a date range greater than 24 hours.

LOGbinder’s View on this Issue

The bug introduces a huge business, compliance and security impact. It is simply unacceptable to be unable to detect or respond to information theft for 24 hours. Security audits need to be available in seconds, not minutes! A delay brings compliance issues and prevents organizations from handling Edward Snowden-like information grabs before the culprit is out of reach.

We believe that you need to get audit results off the system (or application) where they are generated as fast as possible, without causing harm to the application or system while using least privilege.

What LOGbinder is Doing

Our development team is solving the problem. To ensure audit integrity we have released an update to our Exchange audit solution that all customers should download and begin using immediately. LOGbinder for Exchange 3.1 allows customers to choose whether they wish to perform audits in less than 24 hours, but defaults to the delay that we know will provide all the audit results requested. Click here to download: https://www.logbinder.com/Form/LBEXDownload

But LOGbinder for Exchange 3.1 is only the first phase of the ultimate solution. We are working with Microsoft and the Exchange Server community to raise awareness of the issue to get it to the top priority within Microsoft.

Exchange Server’s audit function is quite good. Leaving the bug aside, few applications make such an effort to audit events. Microsoft deserves a lot of credit (more than they usually get) for embedding both an admin and mailbox audit function in the application.

But if and until Microsoft does fix this bug we realize you need to protect your organization and fulfill compliance requirements.

Coming soon: Targeted, Synchronous Mailbox Audit Log Collection

Our new edition of LOGbinder for Exchange due Q1 2016 will continue to maintain audit log integrity using least-privilege and minimal impact, and deliver the admin audit as well as mailbox audit logs with a new robust and stable technology to provide audit logs for high-priority mailboxes in near real-time!

Like our current version, you can specify groups or OUs of executives or other sensitive mailboxes, and LOGbinder will use synchronous mailbox audit log searches on those groups and/or OUs. (To understand why “synchronous” is so significant, watch the full edition of our webinar Detect and monitor threats to your executive mailboxes with Exchange mailbox auditing. Non-targeted mailbox audit logs that should also be monitored for non-owner access will be returned in 24 hours (if and when Microsoft fixes the bug).

The benefit is that your targeted mailboxes will get to your SIEM in minutes if not seconds! Click here to get the beta of the newest edition of LOGbinder for Exchange when it becomes available.

What You Can Do

Stay up-to-date and get the latest innovations from LOGbinder.

If you are already a LOGbinder for Exchange customer, the first thing you should do is download the latest version. This will ensure you get all the audits you should be getting to the SIEM, even if they are delayed 24 hours. Some organizations have reported that they have no issues with the 24-hour delay.

Register for a beta of the coming new edition of LOGbinder for Exchange that will deliver targeted mailbox audit using synchronous search and real-time log delivery.

Open a support case with Microsoft to let them know this bug is a problem for you and send us the case ID. LOGbinder is taking a proactive approach with Microsoft and the Exchange Server community to help solve this problem and your participation will be of great value to the process.

Join the discussion at http://forum.ultimatewindowssecurity.com/Forum1608-1.aspx.

Bookmark this page and check it often to see what news and updates there have been. We will keep you up-to-date with everything we know and are doing by adding news items to the top of the page (content will be in reverse date-order top-to-bottom).


previous | next

powered by Bloget™