8

We have a 2 server farm running MOSS 2007 SP1. I am a member of the Administrators group on both servers.

I am also a member of the Farm Administrators group.

I needed to upgrade a few solutions, so naturally I started with the stsadm retractsolution command on the old solutions. No matter which solution I attempt to run the command, I get back 'Access Denied.'

The ULS Log file fortunately gives me a little more information:

System.Data.SqlClient.SqlException: Cannot open database "SharePoint_AdminContent" requested by the login. The login failed.  Login failed for user '***My Domain Login***'.

What seems strange here is the fact that SharePoint is attempting to connect with MY account using Windows Integrated Authentication instead of connecting with the configured Farm service account. Of course my account doesn't have access to the Admin Content database.

So the question is: Does my account need to be granted permissions to the Admin Content database in order to perform administration tasks? I sure hope not, so is something else terribly wrong?

Trent
  • 183
  • 1
  • 1
  • 5

2 Answers2

10

The short answer is "yes" for most activities you'll carry out via STSADM against SQL databases.

For the overwhelming majority of STSADM commands that execute against the SharePoint API directly (rather than scheduling tasks to carry out an action), the security context within which commands are executed is yours -- the signed-in user. As you've seen in the example you cited, your user account context is the one that will be used for the retraction. If you don't have the appropriate rights in SQL to carry out the operation it will fail (as you've seen).

This contrasts with most activities you'll carry out through the UI (that is, Central Admin). In the example you cited, retracting the solution via Central Admin would result in the command being executed within the context of the farm service account, as that account is the application pool identity for the Central Admin site. Result: the retraction would succeed even though you (personally) don't have permissions to the associated database.

If your environment is setup such that your account doesn't have admin-level access to the databases within the SharePoint farm, I would recommend carrying out as many activities as possible through the UI to avoid the type of security context issues you're encountering. You'll find you can do most of what you need to do that way. One notable exception that comes to mind, though, is adding a solution (STSADM -o addsolution) to the farm solution store -- no UI counterpart to the STSADM command exists.

Alternatively, you could do something similar to what MadlyAlive suggested (i.e., logging in with the farm service account) ... though local admin access for the farm service account is neither required nor recommended by Microsoft. You could also have your account granted the minimal set of permissions inside of SQL Server needed to carry out your operations.

For more discussion, see Microsoft's KB article at http://support.microsoft.com/kb/896148.

Rule of thumb recap: STSADM uses your account context, Central Admin uses the farm service account context.

I hope this helps!

Sean P. McDonough
  • 786
  • 4
  • 6
  • thanks for the good insight and information. Never thought much about the fact that stsadm runs in the context of the user. – Aaron Weiker Jun 27 '09 at 05:38
  • I also have the same problem when I attempt to retract the solution in the Central Admin UI. But this is really good info you shared. I will now start the lengthy bureacratic process of requesting the appropriate access to the SQL server. – Trent Jun 28 '09 at 15:39
  • I would still expect my account to get all these permissions when it's added to the "Farm Administrators" group. – vitule Dec 30 '09 at 17:39
  • Adding an account to the "Farm Administrators" group in SharePoint Central Admin has absolutely no effect on that account's rights in SQL Server. Becoming a farm admin gives you rights (within Central Admin) to initiate actions that are then taken *on your behalf* by farm/timer service account via delegation ... but it doesn't alter any permissions on the databases for the user account in SQL. Becoming a farm admin is a SharePoint permission change only -- not SQL Server. – Sean P. McDonough Jan 07 '10 at 14:08
0

This may be avoiding the core problem, but when trying to run a similar stsadm command 

stsadm -o preupgradecheck

I was receiving Access Denied as well. But running Command Prompt as Administrator enabled me to run it.

Jeff Dalley
  • 133
  • 1
  • 1
  • 7