LOGbinder Blog

Updates, Tips and News   RSS Feed  

«  LOGbinder EX for Exchange... | How does LOGbinder SP det... »

Workaround if LOGbinder SP is having SQL database issues

Fri, 14 Dec 2012 18:45:22 GMT

***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.


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'.


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 sometimesyou 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.

Comments disabled

powered by Bloget™