SQLServerAgent Security Context Does Not Have Server Autorestart Privileges
Oct 21, 1999
SQL Server in on a ‘member’ server in my company domain (We took the ‘stand-alone’ option when installing NT on this server).
I have set up an NT domain account for SQL ServerAgent ‘Service startup account’ which is a different account than the NT domain account listed in the SQL Server Properties, Security tab, ‘Startup service account’.
I log on to this server with the login in the latter.
Replication is working OK, but my application log keeps filling up with the message “SQLServerAgent security context does not have server autorestart privileges”.
We have a sqlserver 7 on windows nt 4. We'd just change a startup account for sqlserver agent to a not domain admin for security reason. The startup account for sqlserver service is still domain admin. We are now getting the following error every 5 second in our application event log.
"SQLServeragent security context does not have server-autorestart privileges"
Is there a way to get rid of this error without putting a domain admin as a startup account for sqlserver agent?
I recently installed SQL Server 2005 and setup a database for one of the systems that I support as a DBA. After installation and the system, which has remote developers, was tested successfully, our security group performed a security scan on the SQL server. The scan revealed a few potential vulnerabilities. Below are the questionable items that the scan identified within the Windows User Rights Assignment. I believe the SQL Server installation assigns these system privileges to the SQLServer and SQLServerAgent accounts by default. I'd like to know how many, if any of these privileges, are necessary.
1) SQLServer and SQLServerAgent accounts have "Bypass Traverse Setting" privilege within Windows User Rights Assignment
2) SQLServer and SQLServerAgent accounts have "Log on as Batch Job" privilege within Windows User Rights Assignment. I realize I need this to schedule SQL Server jobs which run batch jobs and such, but any other reason to keep this privilege.
3) SQLServer and SQLServerAgent accounts have "Memory Quota" privilege within Windows User Rights Assignment
4) SQLServer and SQLServerAgent accounts have "Replace Process Token" privilege within Windows User Rights Assignment
Any guidance on this would be greatly appreciated.
I am experiencing a head-scratcher of a problem when trying to use a Linked Server connection to query a remote SQL Server database from our SAP R/3 system. We have had this working just fine for some time, but after migrating to new hardware and upgrading OS, DBMS, and R/3, now we are running into problems.
The target database is a named instance on SQL Server 2000 SP3, Windows 2000 Server. The original source R/3 system was also on SQL Server 2000 (SP4), Windows 2000 Server. I had been using a Linked Server defined via SQL Enterprise Manager (actually defined when the source was on SQL Server 7), which called an alias defined with the Client Network Utility that pointed to the remote named instance. This alias and Linked Server worked great for several years.
Now we have migrated our R/3 system onto new hardware, running Windows Server 2003 SP1 and SQL Server 2005 SP1. I redefined the Linked Server on the new SQL 2005 installation, this time avoiding the alias and referencing the remote named instance directly, and it tests out just fine using queries from SQL Management Studio. It also tests fine with OSQL called from the R/3 server console, both when logged on as the application service account with a trusted connection, and with a SQL login as the schema owner. From outside of the application, I cannot make it fail. It works perfectly.
That all changes when I try to use the Linked Server within an SAP custom program (ABAP), however. The program crashes with a database interface error. The database error code is 15274, and the error text is "Access to the remote server is denied because the current security context is not trusted."
I have set the "trustworthy" property on the R/3 database, I have ensured the service account is a member of the sysadmin SQL role, I've even made it a member of the local Administrators group on both source and target servers, and I've done the same with the SQL Server service account (it uses a domain account). I have configured the Distributed Transaction Coordinator on the source (Win2003) system per Microsoft KB 839279 (this fixed problems with remote queries coming the other way from the SQL2000 system), and I've upgraded the system stored procedures on the target (SQL2000) system according to MS KB 906954. I also tried making the schema user a member of the sysadmin role, but that was disastrous, resulting in an instant R/3 crash (don't try this in production!), so I set it back the way it was (default).
What's really strange is no matter how I try this from outside the R/3 system, it works perfectly, but from within R/3 it does not. A search of SAP Notes, SDN forums, SAPFANS, Microsoft's KnowledgeBase, and MSDN Forums has not yielded quite the same problem (although that did lead me to learning about the "trustworthy" database property).
Any insight someone could offer on this thorny problem would be most appreciated.
From my desktop in Management Studio (MS) I can connect to server A and run a query like, select top 1 * from serverB.mydatabase.dbo.mytable, and all seems to be working. If I leave and come back after a few minutes it no longer works and I get this error: Msg 18452, Level 14, State 1, Line 1
Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.
If I remote connect to server B and run the query it works and when I try it from my desktop MS it starts working again. Any ideas on why this is happening?
SQL2005 on winserver 2003. I have a view in Xdb that accesses tables in 2 different databases (Xdb and Ydb) on the same server. I have mixed mode security. I have a SQL user (XYuser) that has read access to all tables and views on both databases, yet when I try to access the view using a C# windows application I get the following error:
The server principal "XYuser" is not able to access the database "Ydb" under the current security context
This same scenario works under SQL 2000. I looked through the postings and tried to set TRUSTWORTHY ON on both databases but that didn't help. I can access any other views or tables on the SQL 2005 server, just not the one that joins the tables cross databases. Any help is much appreciated... john
I am unable to run a stored procedure that accesses a linked Oracle database as a dataset for a deployed report in Reporting Services. I receive the following error:
An error has occurred during report processing.
Query execution failed for data set 'spName'.
Access to the remote server is denied because the current security context is not trusted.
A few facts ...
The report previews fine in Microsoft Visual Studio 2005 Version 8.0.50727.762 (SP.050727-7600) report designer with VS being installed on my local machine and a shared data source referencing Server1 The deployed report on Server2 produces the error The stored procedure code is similar to the following:
SELECT x.FieldName as OracleField
,y.FieldName as SSfield
FROM OracleLinkedServer..DatabaseName.TableName x
LEFT JOIN Server1.dbo.TableName y
The deployed report runs fine when the stored procedure code is changed as follows. This indicates to me that the problem is truly an Oracle connection issue;
SELECT 'ABC' as OracleField
,y.FieldName as SSfield
FROM Server1.dbo.TableName y
The Oracle database is a linked database on both SQL Server1 and on SQL Server2 database engines. (I don't see where in Server2 Reporting Services I can specify additional server connections.) I've tried to trick Mr. Reporting Services on Server2 by creating a @L_TempTable in my stored procedure, inserting the data into it, then selecting from a SQL Server1.dbo.TableName LEFT JOIN @l_TempTable, but Server2 still knows I'm trying to get out to Oracle and rewards me with the error. I can effectively run the Server1 stored procedure script on Server2 through MSSMS -- it's just the deployed report that references the stored procedure that doesn't work The data source properties of the deployed report are as follows:
Select -- A Custom Datasource
Connection Type: Microsoft SQL Server
Connectoin String: Data Source=Server1;Initial Catalog=DatabaseName
Select -- Credentials stored securly in the report server
Username: UserName
Password: Password
Check -- Use as Windows credentials when connecting the the data source
Check -- Impersonate the authenticated user ...
(Please do not get sidetracked on the 'A Customer Datasource' selection above. I'd rather be using a shared data source, but right now, this is just the way it is.)
Anyone's expertise would be greatly appreciated. We have a great data warehouse but sometimes you just have to go back to the Oracle ERP and slug it out. What do I need to do to get a deployed report to effectively read from a stored procedure that references an Oracle table?
In SQL 2005, from a stored procedure in a local database I am attempting to execute a remote stored procedure in another database on another server. I am getting the error referred to in the Subject when the local stored procedure tries to execute the remote stored procedure. A couple of comments:
The remote database is set up as a linked server in the local database. As part of the linked server definition I selected the 'be made using this security context', and provided a local user name and password. The remote database is set to Trustworthy. I have tried every combination of WITH Execute As on the remote stored procedure but nothing works. I can query against the remote database successfully within Management Studio. I can even execute the remote stored procedure successfully from within M.S., but not from within my local stored procedure when it is run.
I am unable to run a stored procedure that accesses a linked Oracle database as a dataset for a deployed report in Reporting Services. I receive the following error:
An error has occurred during report processing.
Query execution failed for data set 'spName'.
Access to the remote server is denied because the current security context is not trusted.
A few facts ...
The report previews fine in Microsoft Visual Studio 2005 Version 8.0.50727.762 (SP.050727-7600) report designer with VS being installed on my local machine and a shared data source referencing Server1 The deployed report on Server2 produces the error The stored procedure code is similar to the following:
SELECT x.FieldName as OracleField
,y.FieldName as SSfield
FROM OracleLinkedServer..DatabaseName.TableName x
LEFT JOIN Server1.dbo.TableName y
The deployed report runs fine when the stored procedure code is changed as follows. This indicates to me that the problem is truly an Oracle connection issue;
SELECT 'ABC' as OracleField
,y.FieldName as SSfield
FROM Server1.dbo.TableName y
The Oracle database is a linked database on both SQL Server1 and on SQL Server2 database engines. (I don't see where in Server2 Reporting Services I can specify additional server connections.) I've tried to trick Mr. Reporting Services on Server2 by creating a @L_TempTable in my stored procedure, inserting the data into it, then selecting from a SQL Server1.dbo.TableName LEFT JOIN @l_TempTable, but Server2 still knows I'm trying to get out to Oracle and rewards me with the error. I can effectively run the Server1 stored procedure script on Server2 through MSSMS -- it's just the deployed report that references the stored procedure that doesn't work The data source properties of the deployed report are as follows:
Select -- A Custom Datasource
Connection Type: Microsoft SQL Server
Connectoin String: Data Source=Server1;Initial Catalog=DatabaseName
Select -- Credentials stored securly in the report server
Username: UserName
Password: Password
Check -- Use as Windows credentials when connecting the the data source
Check -- Impersonate the authenticated user ...
(Please do not get sidetracked on the 'A Customer Datasource' selection above. I'd rather be using a shared data source, but right now, this is just the way it is.)
Anyone's expertise would be greatly appreciated. We have a great data warehouse but sometimes you just have to go back to the Oracle ERP and slug it out. What do I need to do to get a deployed report to effectively read from a stored procedure that references an Oracle table?
We've got 3 SQL Servers all SQL Server 2012. We have a Master server and 2 production servers (let's call them A and B). The Master has linked servers defined for both A and B in an identical way.
A and B both have the same databases and each has a Stored Proc that gets called by the Master server. An SQL Agent job executes the stored proc on both A and B. It works fine against A but not B.
If we execute the stored proc in a query window under our windows account (domainowner) it works, if we use SetUser to pretend to be the SQL Server Agent account (let's call it domainagent) A works and B doesn't.
Executing against B returns the error "Access to the remote server is denied because the current security context is not trusted."
domainagent is a sysadmin on both Server A and B.
Trustworthy is set to ON in both the Master Server Database it's executing from and the remote databases on both A and B.
All 3 databases have the same owner (let's call it domainowner).
I am sorry for posting this question here. The only reason I am doing so is because Remus answered a question similar to this late last year, but I couldn't get access to the whole thread.
In SQL 2005, from a stored procedure in a local database I am attempting to execute a remote stored procedure in another database on another server. I am getting the error referred to in the Subject when the local stored procedure tries to execute the remote stored procedure. A couple of comments:
a.. The remote database is set up as a linked server in the local database. As part of the linked server definition I selected the 'be made using this security context', and provided a local user name and password. b.. The remote database is set to Trustworthy. c.. I have tried every combination of WITH Execute As on the remote stored procedure but nothing works. d.. I can query against the remote database successfully within Management Studio. I can even execute the remote stored procedure successfully from within M.S., but not from within my local stored procedure when it is run.
I have a stored procedure servicing a queue (sql 2005). The stored procedure updates some data in a different server and database. If the queue contains messages and I execute manually the stored procedure, I don't have any problem at all. However, if I set the queue to use the same stored procedure, it gives me the following error:
Error 15274: Access to the remote server is denied because the current security context is not trusted.
A client has received the results of a security scan suggesting that Execute privileges granted to the certificate ##MS_AgentSigningCertificate## on the master database are a security hole which needs to be fixed. I'm unsure of the affect do doing this. We have a very vanilla sql server database, we don't use certificates, we just connect via jdbc to the db and do OLTP work. Are there basic functions associated with ##MS_AgentSigningCertificate## that will fail if I revoke privileges? We only need to be able to log on to a user database and do DML and basic backup and recovery.
I'm currently creating a database that will only allow data operations through stored procedures, ie users will not be able to directly modify tables. I'd like to use an Insert trigger which will run in response to a stored procedure that inserts records. The trigger will check business logic and additionally modify records in a couple of other tables. Given that I've disallowed direct access to the tables, will it run or will the security set-up prohibit that?Thanks in advance for any answers.
I'm building a SQL function from C++ and compile my assembly with /clrafe. After that I create the assembly with SAFE permission sets and create the function, both in SQL. But the server don't accept load or execute the function because of permission error. It says:
Code Snippet
"An error occurred in the Microsoft .NET Framework while trying to load assembly id 65561. The server may be running out of resources, or the assembly may not be trusted with PERMISSIONSET = EXTERNALACCESS or UNSAFE. Run the query again, or check documentation to see how to solve the assembly trust issues."
Does the terminology coince with the technology, or is it diffrent "safety" conditions we are speaking about? One for the SQL permission set, and another safety for CLR type-safe assemblies?
Anyway, after playing around a bit, and following the tricks from this thread. I managed to load and execute the function, but only in UNSAFE permission (unrestricted mode?)
---8<----
My second question is can I use unrestricted mode for assembly compiled with /clr (mixed CLR)?
I'm asking, because I have some C source code that I want to reuse, and for this I can't be type-safe and therefore need to compile only with /clr (mixed CLR).
Should I go back to the plain C API in SQL 2000 to implement such function in SQL 2005, and ignore all new things in c++/CLR/.NET?
If you have any points to C++ sample code, then please forward this to me.
some time back i had problem with sending the service broker messages on remote machine,
I had some security issues and they were resolved by the help of Remusu.
since the ip of the remote machine was changed in between so i just re-executed the same scrips which used to successfully send messages on the remote machine.(I just updated the IP in the route )
To my surprise same script did not work now where as no change have been made.
I am doing the following:
1.Created the certificate and end point on the sender side. back up the certificate in a file and copied to the other machine. same step was repeated for receiving side as well.
2.both the side i created the certificates using the back up files from other sidend proper authorization
3.Then I created the database,route,messagetypes,contract,queues,services etc both the side.
4. then i setup dialog security(ie.created the dialog security certificates both the sides and back up them). Later I copied these back up files to each other, create some dialog user and create certificate using authorization to these remote dialog users created.
5.I also created remote service binding on both the sides and granted send permission to the remote dialog user.
When i send the message from sender to the receiver, and run the profiler, I see that on the sending side none of the broker event gives any error.
In the recever side I get the followng Event: Broker:Message Undeliverable
This message could not be delivered because the security context could not be retrieved. Error 11229.
I m surprised that the same script was run in the same order,Why was it running before and not now.
I also checked the End points using telnet and they seem to be fine. Also the firewall was "Off" on both the machines i.e. there was no change in system state also.
The objective is to programmatically create an IIS virtual directory from within a stored proc. I already have a proxy account configured using the sp_xp_cmdshell_proxy_account proc. The SQL server is a member server to a domain and the proxy account is a member of Domain Admins (per iisvdir.vbs requirement). When I login to the server as the proxy account and run the dos command in a window it executes just fine. However, the above SQL statements result in the following in server management studio:
"You cannot run this command because you are not an administrator on the server you are trying to configure."
If the xp_cmdshell runs under the proxy account, and the proxy account has been verified to be able to login and run the script independently, what gives?
Edit: Just to make sure the proxy account was setup properly, I used the following cmd
select @cmd='set'
and it's results set shows
USERNAME=sqladmin
which is indeed the name of the proxy/windows account that I can run the dos script under when logged into windows...
I have a service broker setup between 2 remote server. The message send does get sent to the target, but I am having a problem where the end conversation message from the target is failing. I did a trace on both the target and the source server. here's what I found
On the Target Server:
on Broker: Message undeliverable --- This message could not be delivered because it is a duplicate
On the Source Server
on Broker: Message undeliverable --- This message could not be delivered because the security context could not be retrieved,
I do not understand why the message is delivered, but the end conversation message is not getting thru. On the Target transmission_queue. I have millions of messages like this
I need to allow only a specific group of users to use a linked server. Rather than granting each user access in the linked server I create and give access to a local SQL login "link_user" and then grant the group impersonate to "link_user". The folllowing statements then work fine:
EXECUTE AS LOGIN = 'link_user'
SELECT * FROM OPENQUERY(linked_server, 'SELECT * FROM ...)
But when I use the exact same statements in a stored procedure I get the folllowing error:
Msg 7416, Level 16, State 1, Procedure linktest2, Line 5
Access to the remote server is denied because no login-mapping exists.
I need to be able to work with the result set which is why I use OPENQUERY rather than EXECUTE... AS... AT which works fine also in stored procedures!?
Is there another workaround then to create all users in the linked server security?
I have 2 databases one for datawarehouse and one for reporting.
I created a view in the reporting database joining several tables from datawahourse. The view is meant for a users who uses powerpivot. It will contain a few million of rows.
I set up a role in the reporting database. I assigned select rights to that role on the view.
When the user wants to access the view, he can see the view but a select gives
The server principal "pp_user" is not able to access the database "datawarehouse" under the current security context.
How can I fix this ? I don't want to give the user select rights on tables in the datawarehouse.
I have a login that is mapped to a Windows sysadmin account. I used it to login to Sql Server 2005. I then created a database called Freedom. I then added a Windows login and user called FreedomAdmin, with Freedom set as the default database. When I login in to Windows using FreedomAdmin and then try to login in to Sql Server 2005, I get the following error:
The server principal "FREEDOM1FreedomAdmin" is unable to access the database "master" under the current security context.
If the default database for FreedomAdmin is Freedom (and it is - I checked from my sysadmin login account), why can't I login. Must I give FreedomAdmin permissions to master?
"Could not impersonate the client during assembly file operation."
The CLR function is invoked from Service Broker internal activation stored procedure.
"SELECT user_name()" returns dbo just before CREATE ASSEMBLY execution.
SqlContext.WindowsIdentity.Name is "NT AUTHORITYSYSTEM" as the Data Engine runs with the LocalSystem account.
How do I create a the necessary security context for "CREATE ASSEMBLY" to succeed ?
Service Broker Queue activation with EXECUTE AS = "SELF", "OWNER", domain account or dbo, all result in the above error. The Service Broker assembly having the internal activation stored procedure is registered "unsafe".
How do you set column privileges in the SQL Server 7.0’s Enterprise Manager. It was so easy in 6.5’s but now it seems that the only way to do it is through the stored procedure.
I am still fairly new to Sql Server 2008 R2 (express) , but am enjoying exploring it.
I have several databases up and running and now a large number of users in each.
But I notice whenever I write a stored procedure I have to go in and add each user to give them permission to exec it. When the user numbers are low its not a problem but I now have over 20 users on 1 database and its becoming tiresome.
I have heard of Active Directory on Windows Server but my database is installed on windows xp professional PC. Its running well and we don't have a budget to change it.
I've been searching the internet to see if there is some way I can create a group within sql server give the group all the necessary permissions/ privileges and then add the users to that group thereafter...
Can any of you tell me how to create a login in SQL Server 6.5 with System Administrator privileges, like we can do with SQL 7 or SQL 2000 ? I don't want to use the sa login.
I need a hand here, referring to this knowledge base on Microsoft (http://support.microsoft.com/default.aspx?scid=kb;en-us;Q283811) i applied this knowledge base, and it worked, the MSSQL and SQLSERVERAGENT have run under local non admin account.
But after i installed SP1, MSSQL service is ok, but SQLSERVERAGENT wont run. The warning message is : "Some service run and then stop if they have no work to do."
Is there any way i can install SP1 but in the same time run SQLSERVERAGENT under local non admin account?
Hello, I have an XP box with SQL 2k working without any problems. I am trying to install SQL 2005 CTP April on the same machine. Installation goes fine, but when I try to connect, I am getting an error "Can not Create SSPI Context". Why am getting this error ? DOes the machine needs to be on a domain to get connected? If yes, is there a work around? Can I use mixed mode? WhereHow do I specify password for sa?
Our end users is getting below error, when they try to connect to our database:
"Cannot generate SSPI Context."
That is Windows based application and we have done everything like restart our DB Server , reinstall exe in users system, but still issue is same.The issue has occured from when DB Server has restarted and at the same time few users are connected. before that it was working fine. we could not find what is issue.
My goal is to write a DR plan where i am restoring all user databases onto a diffrent server in a event of hardware failure. I was trying to figure out a way to extract DDL of user accounts and their permissions on all user databases so i can simplify my DR documentation.  This is the plan I came up with...to restore all system and user dbs on a different Physical SQLServer.
1. build named instance $PROD
2. restore master database
   - startup sqlserver in single user mode -m or DAC sqlcmd -S ServerName -U sa -P<xxx> –A    net stop MSSQLSERVER$PROD    net start MSSQLSERVER$PROD -m    - restore database master from disk e:master.bak with replace;    3. start sqlserver normally
4. stop SQLServer agent
5. restore msdb
-restore database msdb disk e:msdb.bak with replace;
