If yes, please give an example.
UPDATE:
I have a PowerShell script that iterates through all site collections within selected Web application and changes the siteCollection.Audit.AuditFlags property. It works fine on my development machine, but the siteCollection.Audit.Update() command fails with Access is denied error on the production server, even though I am trying to run it as a user who is a farm administrator.
Yes, it can.
[Microsoft.SharePoint.SPSecurity]::RunWithElevatedPrivileges({
$site = get-spsite "http://localhost/nonfarmadminsitecollection";
});
Be careful with that. Since you are impersonating the process account, you lose information about the user in the audit trails.
RunWithElevatedPrivs uses the application pool user on regular web apps, not farm admin. If the elevation happens on central administration, then it's a farm admin account. I assume you are doing this on regular webapps, so launch powershell as the app pool acount.
Run powershell as an administrator or as your webapp application pool user.
Related
I've setup a special user account for MSDeploy connections. The user is a member of the local Administrators group.
MSDeploy fails with ERROR_USER_UNAUTHORIZED when I use this account and yet it works fine with my own account, which is also an administrator, via a domain group.
In the IIS Management settings, this new website is not listed and so my account doesn't receive its rights via config, I believe its implicit via my admin rights. So why doesn't the dedicated account work?
What I'm learning, from day after day and $1000s worth of consultancy time, is that MSDeploy is another Microsoft over-complicated anti-pattern, we should stick to RoboCopy and not cave in to 'right way' BS.
Have you checked event log for MsDeploy? It could contain possible answer :).
I assume you are using Windows 2008 Server, not Windows 2012 Server?
Try specifying explicitly the authType=Basic token for the -dest parameter (or /A:Basic command line switch in case of .cmd deploy script). Though the documentation claims that WMSvc method uses by default basic authentication I've recently found this is not (always) true.
I've moved my codebase to a new directory and need to grant the IIS account read/write privileges on a few folders to allow access by the ASP.Net runtime. I believe NETWORKSERVICE is no longer used for this purpose (as mentioned in this earlier question:
ASP.Net which user account running Web Service on IIS 7?) but, try as I might I can't seem to be able to add the IISAppPool/IIS Worker Process the article links to.
I've found a MyDomain/IIS_WPG account but this isn't the one that is listed in Task Manager for the w3wp process. Can someone help?
UPDATE:
Even odder - the Application Pool for the website in question uses the LocalSystem identity which I thought would be able to access pretty much the entire machine. Is there something incorrect about my basic machine/Windows setup?
I'm going to reset IIS through a batch file. Using iisreset utility, as the batch file will be used by others who may log in the domain without the administrator account of the target server. How can I make the batch script running with proper permission? Thanks in advance!
And I also don't want to prompt the user to type in username/password as the batch file will be called by other programs.
Problem 1: Resetting remotely from batch. I prefer sc.exe
Example
sc \\webserver stop w3svc
sc \\webserver start w3svc
SC is not as heavy as IISRESET. Actually, I prefer to use WMI to recycle application pools, but that is tricky to do through batch
Problem 2: Allow users who are not Administrators on the target server to reset IIS.
You are either going to have to grant these users (or their group) permissions to control the services or store credentials somewhere. To grant the minimum permissions, see this KB -- a lot of work.
If you don't grant those executing the batch permission to restart services, see Rusell's answer -- create a WCF service.
You could create a windows service (using .net WCF for example) that executes this command. Then the service can run using credentials with administrator access.
Your other programs can call this service remotely.
"iisreset computername" will reset the IIS server if they have admin rights on computername. While I'm not sure how to change the user account in a batch file, this could be a security issue as batch files (as I'm sure you are aware) are stored in plain text.
PS. This would probably be better on ServerFault
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?
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.
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.
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.
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?
What user context do SharePoint timer jobs run under? The farm account?
I'm going to be accessing some external resources (network share) via the timer job, so I need to know which SharePoint service account to grant permissions.
Yes, in all documents in Technet, it's "SharePoint farm account".
In fact, it's the user which run the OWSTimer job.
The windows identity will be as described above, i.e. the identity of the OWSTimer service. In accessing SharePoint resources, however, a SPTimerJob will use the SPUser identity of SharePoint\System. You can check this by creating a timer job to modify a list item - the "modified by" user friendly name will be "System Account" not the domain\user windows identity of the OWSTimer service.
I believe so.
According to this blog post, http://meenrajan.blogspot.com/2008/08/sharepoint-timer-job.html you can check the identity of what's running it by doing the following:
"you may go to the Task Manager, and find the w3wp.exe process that is running and see what account it has been using to figure out what was the account used to run the job.update(). Otherwise, you can also, do a SQL Trace on your Sharepoint Configuration Database and find the account used"