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"
Related
I'm unable to start user profile synchronization service on sharepoint 2013 on premise.When I start the the service,under service account name and password section,account name shown as (NT AUTHORITY\NETWORK SERVICE) and unable to change the value.How to resolve this problem?
This might be the issue due to "Forefront Identity Manager" stopped. To start this service please follow below steps:
Go to Central Administration. Click on "Manage services on server" under "System Settings".
Now you can see the configured service list. Go to User Profile service and start it.
When it start, check in services "Forefront Identity Manager". It will be started.
But you can't change User Profile Manage account once its configured. you need to delete it and create it once again. Please see below links for reference:
MSDN link - User profile create
setup user profile service
I opened Sharepoint 2010 Central Admin and as per normal, was prompted for my login details. As I did not know the details, I closed after a few guesses/changing the default account.
A few hours later, remembering the password, I try again but get a 503 Service Unavailable.
I check the app pools in IIS7 and see that the SharePoint Central Administration v4 app pool is off. I turn it on, close IIS7, but it turns off again. Its settings look good to me:
Enable 32-bit applications Off
Start Automatically True
Enabled True
However, the application event log tells me that the account I was using to access Central Admin, and used by this app pool, has now expired (it's a local account so I did not know this will happen). This also impacts all other services such as SQL Server etc. How can I change the account of the app pool, but also change all of the other service accounts?
The credentials used for the account [name] expired on 1/9/2010 1:33:39 PM, and need to be updated. If they are not updated, the system may stop working. The account is used by the following:
Farm Account
Microsoft SharePoint Foundation User Code Service
User Profile Synchronization Service
Web Analytics Data Processing Service
Security Token Service Application
Application Discovery and Load Balancer Service Application]
I assume updatefarmcredentials will fix this. I tried the following:
stsadm.exe -o updatefarmcredentials -username sysaccountname -password pwvaluehere -local
This results in a "command line error". What is the proper syntax?
You can also just change the current System Account password in AD or Computer Management, and mark it to not expire.
When it comes to the stsadm command, it is userlogin not username, unless that changed in 2010. (Source)
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.
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?
Is it possible to create a user with permissions of both a local administrator and NETWORK SERVICE?
I've got a Sharepoint timer job which runs stsadm for which it needs local administrator permissions. On the other hand temer jobs are also used by other services which need NETWORK SERVICE permissions and those to sets of permissions only overlap, so I need a user with the "sum" of the permissions to run OWSTIMER under.
(I know that most of the operations you can perform with stsadm sharepoint administration API can be used, by in my case it is the operation which moves a site collection between content databases for which there seems to be no API equivalent).
I recommend always using domain accounts - SharePoint works best on servers connected to an Active Directory server. For production environments a best practice is using a least privilege account. I always create the following domain account dedicated to SharePoint services:
DOM\spservice
You do not need to grant any special privileges to this account as SharePoint will automatically do this for you when you specify the account during setup.
I can't help you with the user permissions (Lars hit the important points), but I wanted to share some information that may be of use.
You mentioned that you're trying to move site collections between content databases and haven't found an API the can be leveraged. Have you looked into SharePoint's Content Deployment API (also know as the PRIME API) to see if it can assist? The types of which I'm speaking are located in the Microsoft.SharePoint.Deployment namespace, and they provide you with mechanisms to export (via SPExport) site collections as CAB files and then import them (via SPImport).
SharePoint leverages types in this namespace for its own content deployment paths and jobs (in MOSS); it's also the API that is leveraged by the STSADM.EXE executable for export (STSADM.EXE -o export) and complementary import operations. For that matter, it's also used by SharePoint Designer for it's site "backup" and "restore" operations.
For an example of how this API can be leveraged, check out the SharePoint Content Deployment Wizard tool on CodePlex (http://www.codeplex.com/SPDeploymentWizard).
I hope this gives you a potential alternative to shelling out to a command line in your timer job!