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

October 2016 LOGbinder Newsletter: New version of LOGbinder for SharePoint

Mon, 31 Oct 2016 14:05:41 GMT

One of our team members was recently reminiscing about a past IT career and how at their organization SharePoint was a document storage facility hosting timesheets, resumes and the weeks’ cafeteria menu.  Years later, SharePoint has become a widely-used workflow platform for critical business processes and a clearing house for sensitive unstructured data.

Over the years, as we have had more interactions with our customers and audience, we have become convinced that SharePoint security auditing is a requirement for the millions of SharePoint customers around the world.  It seems that on a monthly and weekly basis we are hearing reports of more information leaks and data thefts.  You need the ability to open up closed applications like SharePoint and Exchange and see who’s doing what.

In May 2016 Microsoft released SharePoint 2016 but due to a bug in their Exchange 2016 release, we wanted to make sure that we performed very extensive testing of SharePoint auditing to make sure we didn’t discover any bugs there too.  We also performed very stringent testing of LOGbinder for SharePoint to make sure that our software continues to meet and exceed our internal standards.

What is new in LOGbinder for SharePoint 2016?

  1. Support for SharePoint 2016 On-Premises
  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 – A few customers have reported to us that from time to time the LOGbinder service is stopped.  The detailed service logs showed that delays between SharePoint and the farms’ SQL Server were causing timeouts. These timeouts were being reported by SharePoint and were long enough to negatively impact the LOGbinder service.  Now the LOGbinder service will handle these interruptions with less impact.
  4. Weird username prefixes removal – Some customers were wondering why they are seeing weird characters prefixing usernames in the logs.  You can find more info about it here.  We have included an option to remove the claim type characters from the data.
  5. Site collection selection – Managing a handful of site collections is easy.  Some customers though have thousands and thousands of site collections being monitor.  Now you can use CTRL-A to select all site collections in the LOGbinder input.

These are just a few of the improvements in this release of LOGbinder for SharePoint.

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

·         Release notes

·         Download

·         Getting Started Guide

·         Support



LOGbinder for SharePoint Restricted Lookups Option

Wed, 06 Jul 2016 14:55:50 GMT

LOGbinder for SharePoint by default makes every effort to fully translate and enrich SharePoint audit events through so called "lookups" where-in LOGbinder makes extra queries to SharePoint to obtain this information.  But there is a cost/benefit relationship to be considered.  Some events in the native SharePoint audit log include fields that are of low or no value to end users at many organizations.  Each field in the native log, including these low or no value fields, requires a lookup by LOGbinder to resolve the native SharePoint data in to user friendly data.  

For example, below is a sample of LOGbinder for SharePoint event ID 13: 

Document checked in
Occurred: 6/25/2016 1:13:04 PM
Site: http://sp2010-sp
User: Administrator
Object
  URL: Shared Documents/FinancialData.xlsx
  Title: n/a
  Version: 1.0 

As you can see in the above event, the “Title” field returned from SharePoint is “n/a”.  This is obviously of no value to the end user.  Since SharePoint includes these low/no value fields, LOGbinder for SharePoint includes an option to intelligently restrict the number of lookups it processes resulting in increased performance of LOGbinder.  You can manage the amount of SharePoint lookups by opening the LOGbinder Control Panel selecting File and then Options.  The amount of lookups performed by LOGbinder can be customized by choosing a value under “Amount of SharePoint lookups.”  See figure 1 below.

 
Figure 1: Managing the amount of SharePoint lookups

The fields that are affected (with the exception of the “Restrict all lookups option”) are all child fields of the targeted object.  “URL” is the most important field included in the events and that field is always reported except on some permission change events and only if the “Exclude high/medium-cost” option is selected. 

Most organizations who need to speed up LOGbinder can safely use the “Exclude high-cost lookups” option without losing significant audit information.  Please note that the “Exclude high/medium-cost” option does adversely impact permission change events. 

We have created a document that explains outlines which fields are affected depending on which option is selected when managing the amount of SharePoint lookups.  You can find a link to the document on the LOGbinder for SharePoint resources page or by clicking here.


December 2014 LOGbinder Newsletter: QRadar fully supports Exchange, SharePoint and SQL Server audit; Tech resources for security analysts

Fri, 19 Dec 2014 20:59:06 GMT

So far, 2014 has been a great year for application security intelligence. All the major SIEM providers offered new or additional integrations for LOGbinder. Hundreds more organizations deployed LOGbinder for their SIEM and many of them received significant features and updates from prior versions. We're thrilled with the results and hope you are too!

We are very excited to let you know that IBM Security's QRadar product team produced DSM integrations with all 3 LOGbinder products. This brings Exchange, SharePoint and SQL Server security audit logs to the QRadar-based SOC. In addition to the Device Support Module (DSM) support, LOGbinder has also received LEEF certification. The implications are huge. Now QRadar customers can consume critical security audit logs from their enterprise applications with minimal setup and configuration. LOGbinder collects, translates and delivers the audit information via LEEF-certified output. QRadar consumes that information and allows analysts to easily prioritize and present critical security correlations where, when and to whom it matters most.

To get the IBM Security QRadar DSM Configuration for Exchange, SharePoint and SQL Server, click the following links:

Curious about what SIEM solutions have solid Exchange, SharePoint and SQL Server security audit capability? More news is coming next month, but the full list is AccelOps, AlertLogic, AlienVault, Blue Lance, EventTracker, GFI EventsManager, IBM Security QRadar, HP ArcSight, LogPoint, LogRhythm, McAfee ESM (formerly Nitro), RSA Security Analytics (formerly enVision), Solarwinds LEM and Splunk.

What's coming with LOGbinder EX

Exchange audit is increasingly critical to security analysts. This means the demands on LOGbinder EX have increased too. Our development team has responded with new features, now in our labs for testing, to help security analysts dial-in on the new pain-points and remove them. Now, directly from the LOGbinder interface, security analysts can configure mailbox audit policy and autofill the PowerShell and Exchange server URL fields. These changes offer more than merely convenience. These new features allow far better mailbox “on-boarding” (and whatever the opposite of that is). And it makes it easier for security analysts to do their job; no more slow dances or hat-in-hand sessions with the Exchange admin(s).

Quick reference guide to security audit resources

This year LOGbinder sponsored Ultimate Windows Security webinars that many of you attended. Thank you! These webinar recordings still pack a punch with great information. So you will have these links in once place, we list them below. (You can still get the recordings. They're free.)

LOGbinder's core competence is application security audit technology for SIEMs. Not blog writing. But every now and then we fuse the use-case and technical know-how into a blog post. There's some good stuff there:

Thank you for your support. We'll catch up next year.


November 2014 LOGbinder Newsletter: Windows Event Collection and your SIEM; 2 Tech Tips for security analysts

Mon, 24 Nov 2014 19:34:00 GMT

Is Windows Event Collection a problem for you? We hear (a lot) that organizations struggle with collecting Windows Events. It’s not that their SIEM struggles, but rather there is a gap in the technology to deliver Windows Event Collection (WEC) data from hundreds or thousands of machines to SIEM at sufficient speed.

We like to solve problems yet to be solved, and therefore would love to hear from you about your experience with WEC. Would it help you to have a LOGbinder for Windows that could deliver relevant security events to your SIEM? If so, what SIEM do you use?

This issue strikes at the very heart of our core belief that important security event information should be in the SIEM. We love SIEMs and we love solving the little problems so the SIEMs and their security analysts can pay attention to the big stuff.

What your SIEM doesn’t know about endpoints can kill you. If your SIEM (or your security analysts) don’t have the security event information from all those Windows machines in the organization in a timely manner – whether they are remotely connected or not – and if that’s a big problem for you, please tell us. If it’s not a problem, please tell us that, too, and also which SIEM you use. We’ll share that with our audience.

This brings us to another topic related to what SIEMs do (and don’t do).

It’s not your SIEM’s fault that it can’t consume audit logs from Exchange, SharePoint, SQL Server or even SAP via normal collection means. No SIEM can do this. Sometimes people forget that a SIEM’s job is to provide the analysis tools; it’s not the SIEM’s job to change hats and perform ad hoc coding to address all the different application audit log frameworks. For that, you need the insight and best effort from a subject matter expert focused on getting the information to a SIEM. Which is exactly where LOGbinder came from, the insight and effort of an application security subject matter expert.

Tech Tip: Manage the audit performance by tweaking the amount of excess information attached to the audit

One of the new features of LOGbinder SP 5.0 is the ability to dial-back internal processing to tweak audit performance.  LOGbinder SP allows the control of how many lookups it should perform in order to obtain additional information while translating raw audit events to easy-to-understand audit entries. Examples of this could be resolving a user ID to user name or an object GUID to the actual name of the object. We include recommendations to help guide you in our LOGbinder SP Getting Started Guide. See pages 8 and 9 for details.

It’s Renewal Time

For many of you, this month is the month to renew your support and maintenance contract. There are good reasons for doing so. For one thing you fix your support costs and get help immediately. For another, you have access to software updates at no additional cost. This year has seen major updates to LOGbinder software and we’re not done yet. We expect to release automatic mailbox audit policy management for Exchange from within the LOGbinder EX application! This is a huge advance, for not just LOGbinder EX but for Exchange Auditing in general, and customers who are current with their support and maintenance contract get it for no additional money.

Where to find information about LOGbinder events

Every month we answer about 150,000 questions about events. But where do you go if you have a specific question about an event reported by LOGbinder? Some of our SIEM Synergy partners have collaborated with us to provide a hyperlink within their application to take you directly to the relevant event ID page. So when you see an event you wish to research, clicking on the hyperlinked Event ID will take you directly to the details page on Ultimate Windows Security’s Online Encyclopedia.

But what if your SIEM doesn’t have a hyperlink to the right page? You can still get the information by browsing to UltimateWindowsSecurity.com and clicking on Security, then Encyclopedia. (https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/Default.aspx) Once there, select the source of the event (All Sources, Windows Audit, SharePoint Audit, SQL Server Audit or Exchange Audit). If you want to narrow the list use the drop-down box on the right, else browse the list of events and click on the appropriate one to get the full details. We list the events in numerical order, so they’re easy to find. (By the way, when you get a chance, send a note to your SIEM’s product manager to ask them to finish their integration so you can save yourself the trouble next time when you need the event information.)

If you still can’t find your answer there then click on the blue “Ask a question about this event” button and post your question in the Ultimate Windows Security forum.  LOGbinder is now sponsoring an Exchange, SQL and SharePoint forum there and you can expect a quick response from one of our technical engineers. 

Tech Tip: How to find the status of Exchange Server 2013 audit log requests

Exchange Server’s audit function is asynchronous. Which makes sense for Exchange but causes security analysts heartburn who have to “wait in faith”. The good news is that you can see the status of those audit requests via a PowerShell cmdlet, but the bad news is that only Exchange 2013 supports it. In Exchange 2013, you can retrieve a list of current audit log searches with the Get-AuditLogSearch cmdlet.

For more tips on application security intelligence, be sure to watch our blog updates at www.logbinder.com/Blog and sign up for the Real Training for Free™ webinars at Ultimate Windows Security’s web site.


previous | next

powered by Bloget™