2
votes

I'm trying to confirm my findings on permissions.

In order for the SharePoint object model to be accessed from a console application or for that matter a WinForm application, the user running the application must have db_admin permission to the content database for the web application in question.

In order to use Microsoft.SharePoint.Administration (like calling SPFarm.Local.Solutions.Add) inside an ASP.NET application the following must be true:

  • The call must be wrapped with RunWithElevatedPrivileges like the following:

SPSecurity.RunWithElevatedPrivileges(delegate() { code to run } );

  • The user accessing the ASP.NET page must be part of the Farm Adminstrators Group (the page is running under _layouts)

  • The user in the identity of the App Pool for the web application in question must also be in the Farm Adminstrators Group

Does this information look correct?

4
Just for clarification: The WinForm/Console application is run ON the Sharepoint Server? Because the OM only works on a server in the Farm. - Michael Stum

4 Answers

2
votes

Yes but within the web service code you call the functional code using RunWithElevated Privileges this bypasses the identity you are running the web service as and instead uses the SPFarmAdmin user to execute the code.

Alternatively host the web service in an app pool which uses the same domain account as your central admin site, and allow anonymous access to the web service. This would be safe for internal use only and would mean that the web service always had elevated permissions.

2
votes

Edit: Contrary to Michael's comment I have assumed that this app is not going to be run from within the SP farm.

I would not recommend this approach at all as it is an unupported method of using the SharePoint OM.

You are much better off writing a web service that sits on the SP farm and uses the OM, and then access the web service mehods to perform your required functionality.

You could also look at the out of the box sharepoint web services.

RunWithElevatedPrivileges will not work in your scenario I dont think as it requires a base indetity to fall back on which in the case of code executing on the SP farm is the SP App Pool identity which is usually a farm admin account.

I am happy to be corrected on all of this, but certainly in my environment it would not be wise to invest in a non-standard and unsupported approach to a problem.

1
votes

Yes the web service will need proper access rights, but this is easier to control with a web service running locally.

However if as you say the apps are always running on the server then using RunWithElevatedPrivileges will solve any permissions issues as you are in effect running that code as an SPFarmAdmin (as long as the app pool identity is configured correctly).

Note: you could use this approach with either bespoke web services or client apps such as console applications or windows forms.

1
votes

Apologies hobbyman, I never saw you reply.

If you use RunWithElevatedPermissions then it doesn't matter which user the web service runs as, because you are effectivley impersonating a farm admin account.

You could additionally do your own impersonation within the web service and impersonate any user you wish.

Essentially if the web service is running within a given application pool then the web service will run under the indentity which the app pool runs as. Does this clarify things?