LOGbinder Blog

***This blog post is still important but outdated. Please see this post for updated least privilege changes.***

A problem that might occur when using LOGbinder SP stems from the fact that SharePoint does not behave the same way through its web interface as through its API.

As a result, even though the account has been added correctly via Central Administration or the SharePoint site collection settings page, and has no problem when using the account in the SharePoint web interfaces, the privileges granted are not sufficient when third-party software uses the public SharePoint APIs, resulting in an ‘access denied’ error.

In this blog, we will provide a workaround for the problem.

SYMPTOMS:

Even though the LOGbinder user is definitely a farm administrator, you get an event from LOGbinder like this:

Unable to configure SharePoint export. Details: Cannot open database "WSS_Content" requested by the login. The login failed. Login failed for user 'SHAREPOINTSERVER\logbinderaccount'. SQL Database 'WSS_Content' on SQL Server instance 'SHAREPOINTSERVER\OfficeServers' not found. Additional error information from SQL Server is included below. Cannot open database "WSS_Content" requested by the login. The login failed. Login failed for user 'SHAREPOINTSERVER\logbinderaccount'.

CAUSE:

SharePoint behaves differently when accessing it via its web interface versus accessing it via standard Microsoft SharePoint API’s in third-party software. As a result, it might happen that you are able to perform certain operations through the SharePoint web interface, but when doing the same from a third-party application (such as LOGbinder SP) that is using only standard, published SharePoint API’s, the same operations performed by the same user do not work.

If this occurs, you will likely want to perform the following workaround, so please follow these steps:

1. Go to Central Administration and under “System Settings” click on “Manage servers in this farm”.

2. Make a note of the “Farm Information” at the top of the page, for example:

3. Using the server/instance specified above in the Farm Information, open SQL Server Management Studio.

4. Under the SharePoint_Config database (exact database may vary by installation), go to Security, then Users. Make sure that both the service account that LOGbinder SP is using, as well as the account to run LOGbinder SP Configuration (if not the same) have db_owner role set.

5. Repeat the previous step for the SharePoint_AdminContent database (exact database may vary by installation).

6. Note: If there are any other config databases for SharePoint and the problem still occurs, make sure you do this steps for those databases as well.

(Also see the additional note below.)

This should implement the workaround.

Additional note:

A similar issue may occur with administrator privileges to SharePoint site collections: even though the service account is listed as a site collection administrator in SharePoint’s user interface, you receive an error that the user is not a site collection administrator.

If this occurs, perform similar steps as described above, but to the WSS_Content database. In this case, you would need to add only the LOGbinder SP service account, since the account you use to run the LOGbinder GUI does not need site collection administrator privilege.

It has to be emphasized that we don’t consider the above steps to be a fix, just a workaround to this SharePoint problem, which affects not only LOGbinder, but many other applications too. See, for example this, this, or this article. Even Microsoft says that it can happen and that sometimes “you cannot open a database in the SharePoint Management console of SharePoint Foundation 2010 or SharePoint Server 2010 even though you are a farm administrator who has full administrator rights”, unless you are a member of the db_owner fixed database role for the database.

As a security company we strongly advocate the principles of least privilege, which we also apply in the design of our LOGbinder products. There is no reason why the LOGbinder service account should be granted any rights in SQL server, much less database owner. However, until Microsoft fixes this, the only way to get a third-party application work through SharePoint API is to implement the workaround outlined above.

While LOGbinder SP is processing events, it will perform actions that generate SharePoint events. What happens, though, if these same actions are performed maliciously by a SharePoint user? Will this compromise the integrity of the audit trail? No. LOGbinder SP can detect log tampering. How?

In order to distinguish between authorized and unauthorized changes, LOGbinder SP (version 3 and later), when processing these events, will indicate whether it performed the action itself, or the action might be unauthorized. A tamper warning will be generated in the following cases:

· Audit policy change: When processing event #11 “Site collection audit policy changed” or #12 “Audit policy changed,” LOGbinder will determine if the change overrides the settings in LOGbinder. If so, LOGbinder will reset the audit policy and generate a tamper warning (#60 “Possible tampering warning”).

· Audit logs deleted: When processing event #20 “SharePoint audit logs deleted,” LOGbinder will determine whether LOGbinder deleted the logs, and indicate it in an additional line added to this event. The line “Purge performed by LOGbinder” will show value “Yes” if LOGbinder performed the purge, and “No” otherwise. In the latter case, a tamper warning event (#60 “Possible tampering warning”) will be generated.
Note: If it cannot determined whether the logs were deleted by LOGbinder SP, the “Purge performed by LOGbinder” value will be set to “Indeterminate”. This typically occurs when processing backlog events, i.e. those produced before LOGbinder started processing the site collection.

By alerting on event #60 “Possible tampering warning”, malicious audit tampering attempts can be detected, so the audit trail is not compromised.

This whitepaper by Randy Franklin Smith, provides an overview of the 4 different logs in SharePoint and discusses their relative merits in terms of security value and how to integrate with your SIEM.

Click here to download it now.

LOGbinder SP can automatically purge audit entries from SharePoint after they have been processed by LOGbinder SP and forwarded to an event log or your SIEM/Log Management solution. This purging occurs on a daily basis, but a buffer is maintained, so only entries older than 24 hours are purged.
This is usually sufficient to satisfy security and compliance requirements through the audit logs stored in the organization’s SIEM or log management solution. However, in some rare instances, it might be necessary to leave the audit logs in SharePoint in order to be able to run audit reports from within the SharePoint environment. The problem is that these logs are no longer available in SharePoint, since LOGbinder SP purged them.
In this case, the LOGbinder SP automatic purging feature needs to be disabled through the Options dialog on the LOGbinder interface. Since it will not process events it has already processed, not purging the logs from SharePoint will not create duplicate events in your log management.

Figure 1: Disable purging under LOGbinder SP Options

To avoid the logs to accumulate in SharePoint, taking up valuable resources and potentially degrading the performance of the site collection, SharePoint can be set to trim the audit log. Under Site Settings / Site Collection Administration group / Site collection audit settings options are available to trim audit logs when they reach a certain age (specified in number of days) and optionally be stored in a document library.

Figure 2: Enable trimming in SharePoint audit settings

Applying these changes you can benefit from the managing your logs with your preferred SIEM/Log management solution through LOGbinder, while still taking advantage of having access to the audit logs from SharePoint.

LOGbinder SP is the only recognized solution for providing reliable audit information about the security events of SharePoint via HP ArcSight.

SharePoint generates several different logs ranging from true audit logs to diagnostic trace logs and usage analysis. This brief will identify what (if any) security intelligence can be learned from each log. It will then explain which logs are readily available to SIEMs, and which logs are not readily available.

Click here to download the whitepaper.

LOGbinder Blog

Workaround if LOGbinder SP is having SQL database issues

How does LOGbinder SP detect log tampering?

New Whitepaper by Randy Franklin Smith "Comparing SharePoint's 4 Audit Logs for Security and SIEM Integration"

You want to run audit reports in SharePoint but LOGbinder SP purges the audit log

New Whitepaper: SharePoint Audit Logging with HP ArcSight and LOGbinder SP