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