I recently did an import of database from a sql server 2000 database to a sql server 2005 database. I've gone through and setup what I thought were the same login credentials and owner permissions that I had previously setup in my old database.
All of the code base I'm working has stored procedures listed simply by stored procedure name.
In order to make sure I have the proper logins created, I am logging into the SQL Server Management studio with the connection information my application is using (i.e. using the username "licensemgr" and it's associated password). I can see all the tables, stored procedures, etc... in my database when I log in with combination. When I try to run a stored procedure, Sql Server Management Studio uses the following syntax to execute it:
EXEC: #return_value = [licensemgr].[Stored_Procedure_Name]
and it executes without error.
If I try to remove the [licensemgr]. from before the [Stored_Procedure_Name], however I get the error "Cannot find stored procedure: Stored_Procedure_Name". This is the same error I get when running my application off this database. I changed one stored procedure call in my application to have "licensemgr." in front of the stored procedure name and that seemed to correct the problem, however, I don't want to do that for each and every stored procedure call in my application. I am therefore wondering what type of setup / permissions type issue I might be missing in my SQL Server instance so that even when I'm logged into the database as licensemgr, I cannot see the stored procedure which is in the schema "licensemgr".
In SQL server 2000 the [licensemgr] referred to the owner of the table. So when you are logged in as [licensemgr] you do not need the prefix.
In SQL Server 2005 this has been changed to the schema, therefore it must be specified. See:
http://msdn.microsoft.com/en-us/library/ms190387.aspx
EDIT
There are two things that you need to watch out for:
If the user is in the sysadmin role, he will always default to the dbo schema, therefore you need to prefix
If your user needs to run code that is in different schemas you will need to prefix
If none of the two above it should work by setting the default schema for the user
When you created your user, did you specify DEFAULT_SCHEMA?
CREATE USER ... WITH DEFAULT_SCHEMA = "licensemgr"
If not, you may need to use ALTER USER to fix this for your user in the new system.
Related
I am a developer for a hospital which uses software provided by a 3rd party vendor which hosts Sql Server for us. We have a local instance of Sql Server 2012 which has a linked server to their Sql Server instance. Within our instance of Sql Server we can see all of the Views and Tables that have been assigned to us but none of the stored procedures.
However, I have been given a Citrix connection which allows me to access Sql Server on their network. From here, I can create, alter and execute stored procedures in the [CUSTOMER] schema they created for this purposes (we can only execute procs in dbo, but not alter or create).
The vendor is now trying to give me access to execute stored procedures we created in [CUSTOMER] through our linked server. However, it's not working. They say they have given permission to my user as well as the user listed under the Security tab of Linked Server Properties in "Be made using this security context".
Properties for RPC and RPC Out are set to true.
No Sp's show up under the linked server node (no "programmability" node at all). And when I try to execute my proc like this: [remoteserver.ip.address].[remoteDbInstance].[Customer].[extr_myProc], I get the following error:
"Cannot find the object "extr_myProc" because it does not exist or you do not have permissions."
I suspect there's an issue on their side but our contact at the vendor says they've done everything. Is there something else I should be doing on my side though?
I suspect that there's more than one measure a vendor can take to lock down stored procs over a linked server and all their support staff did was to make sure [CUSTOMER] was executable for our users, but another setting is blocking it specifically for linked servers.
Is there something I can suggest to their support staff to look at for us that can hide stored procs from a user, but only over a linked server?
Thanks!
I have a stored procedure that I can execute in SSMS with a non domain SQL Server user.
This stored procedure selects data from tables in one database (DB1) truncates and selects into a table in DB2.
The user has datareader,datawriter and dbowner for both databases.
Problem:
When I execute the stored procedure via SS Agent with execute as the user I get the following error
The server principal [user] is not able to access the database [DB1]
under the current security context.
Actions taken So far:
I have tried to resolve this so far by:
Turning on db chaining for both databases
Deleted the user from DB1 and added again
Checked using EXEC sp_change_users_login #Action=’Report’ to see if user orphaned. As this is a database that is a restore of a live one. However I added the user after the restore. The user was not listed as orphaned
A possible workaround if you don't want to have the owner be sa is to have the user be a member of msdb and grant the the SQLAgentOperatorRole in msdb. See if that works.
But to be honest, either use sa or a dedicated service account with enough permissions. It's better if the job runs under that context.
I have a rather long stored procedure that I am using to generate a dataset for an SSRS report. While I can run the report in Visual Studio using SSDT and deploy it (SQL SErver 2012), running it via report manager isn't working. It's having a problem with the dataset using the stored procedure. If I try running the stored procedure using that login, I get:
'Msg 1088, Level 16, State 7, Procedure sp name, Line 237
Cannot find the object "table name" because it does not exist or you do not have permissions.'
In both cases, I'm running against our development database. The reporting services is NOT on the same machine as the data, and the SQL Server is not set up to work with Kerberos, so I'm running each report using credentials stored in SSRS.
All objects use the dbo schema owned by sa
the ssrs stored credential we use for reports is listed in SQL Server as having execute rights on the stored procedure (with no denys)-- we tend to not use roles.
Since the end of the stored procedure uses a dynamic query (I'm using pivot and the columns can change if new data items are added, hence use of dynamic query), I thought the ownership chain may have been broken. Therefore, I tried creating a certificate (rather than use execute as), associating it with a sql user & granting the user select rights on the above table, and signed the stored procedure with the certificate.
I checked the permissions on the cert user & it has select rights on the table. My understanding is that the permissions granted to the cert user will be added to the permissions of the user running the stored procedure. Yet I'm still getting the above error. I'm not sure why this isn't working...
The signature does show up & I have been re-signing whenever I change the stored proc. I get error if I try running the dynamic sql as the certificate user. As the user does exist and I am sysadmin, I guess that it cannot be impersonated Error is: Cannot execute as the database principal because the principal "Cert_Dynamic_User" does not exist, this type of principal cannot be impersonated, or you do not have permission.
I'm trying to allow a user to view SQL Server trace data from a .trc file without giving them ALTER TRACE permissions (SQL Server 2008 R2). So I've wrapped it up in a stored procedure, using my sysadmin account:
CREATE PROCEDURE test_trace
as
SELECT * FROM FN_TRACE_GETTABLE(N'C:\temp\trace1.trc', 1)
If I execute this stored procedure using my sysadmin account, it runs fine as expected. If I try to run this under the domain1\user1 account, it does not run giving an error of "You do not have permission to run 'FN_TRACE_GETTABLE'". This is again expected.
So now I want to let domain1\user1 run the stored procedure, so I change the stored procedure to execute under a sysadmin account:
CREATE PROCEDURE test_trace
WITH EXECUTE AS 'domain1\sysadmin1'
as
SELECT * FROM FN_TRACE_GETTABLE(N'C:\temp\trace1.trc', 1)
Now when I execute the stored procedure, I get "You do not have permission to run 'FN_TRACE_GETTABLE'" regardless of the account I execute it under! I was expecting to be able to execute it both under the domain1\user1 and domain1\sysadmin1 accounts.
Could anybody please help with what I've missed? My goal is to allow domain1\user1 to read the trace1.trc file without giving them ALTER TRACE permissions.
You need to use code signing to elevate privileges in a controlled manner. While in an EXECUTE AS procedure context you are sandboxed and cannot leverage a server level priviledge (such as trace related permissions), read Extending Database Impersonation by Using EXECUTE AS. Code signing is the proper solution to this problem as well. See a full example here.
According to the documentation you can only specify a (database) username in execute as for stored procedures. Still I think this should normally work, but please alter the SP with the sysadmin account and specify EXECUTE AS SELF instead of the user name.
If that still does not work, try giving the executing user read rights on the trace file, maybe the server ignores the execute as for the file access (which I would consider as a bug).
Copy&paste the path into a new explorer window and if it gives an error, there's your problem. Took me a while to figure out why SQL Server said the "sa" account didn't have permissions that it did have.
We have Silverlight application that is installed on IIS 6. This application use membership API on Microsoft SQL Server 2008 R2 for login. From time to time logged-in users stops can do any queries to the database, but it's not a connection problem, I think just select statements can't return any rows.
On login users start receiving a message 'The 'System.Web.Security.SqlMembershipProvider' requires a database schema compatible with schema version '1''. And this is because the first query to the server is execution of the procedure dbo.aspnet_CheckSchemaVersion, which check the schema version.
The query is executed but it's look like the select in the stored procedure can't return any rows. When I execute this procedure in the management studio it returns a correct value.
Please help!
Do all of your users have the rights to execute this stored procedure?
I believe that this procedure is run once on startup of the application domain (or possibly on first login). Depending on which user credentials are used for the connection, you may get this error.
This error may persist until the app domain is restarted.