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.
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 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 am looking for different ways to uniquely identify an application user in SQL Server 2008.
To give some back ground to the issue:
The ASP.NET 4 web application I work with uses an SQL Server 2008 database, there is one SQL Server login and DB User for all connections from the application to database.
We are developing a reporting solution using Crystal Reports where users can write and execute their own reports through the application. The crystal reports can only return data from Views. Each application user will have their own unique login to the server.
The View then uses SELECT SYSTEM_USER() to find the logged in user and restrict data returned from the view.
Is it bad practice to create a distinct login and DB user for each application user? This would mean > 1000 users per DB, across up to 80 databases (Creation of
each log in would be handled through T-SQL, not manually)
What other ways can the user be identified in the View in the DB?
We looked at altering the connection string to include the user id in the Workstation ID, we can use SELECT HOST_NAME() to get the ID, but this seems like abuse of the Workstation ID.
Any other suggestions about how the user can be uniquely identified would be appreciated.
Many thanks
Have you considered using Windows Authentication as apposed to SQL Authentication? That would at least reduce the number of logins & users that would need to be managed.
Y can use external database,file or other resource to store user access to any data when u use msql 2008.
http://msdn.microsoft.com/en-us/library/dd392015%28v=sql.100%29.aspx
That give y change to not mix data with audit elements for performance and security reasons.
Use profiler on your sql server and in profiler is information about ( aplication , user , and host ). So that kind of information y can easy get by audit or from custom trigger on certain database objects.
Your aplication can also have own user table and share the same connection string too all users or give users with windows auth type only public privilege. And use in stored procedures run as command ( run as another user in db).
So y can log any user and give them minimal rights.
Its my firs post here and I actually learning English lol.
There were two solutions that we came up with:
Before the Crystal report is executed, in .Net we can extract the SQL the report (and sub report) will generate, execute the SQL and put the results in a dataset and generate the report from the dataset. The advantage of this is that because we have the SQL, before the SQL executes, we can supply user information to the SQL server session that can be used to identify the user when the SQL is executing.
Have a limited number of SQL Server user logins which can be dynamically assigned to application users. We will have a table which will map the SQL Server Login to an application user just before they run a Crystal report. When they query has finished executing the Login is released. Obviously this means that at busy times we may run out of Logins, but more can be added depending on usage.
I've created a stored procedure in SQL Server that in turn is using a linked server to query two databases. The results are returned as expected in Query Analyzer, but when I try running the same stored procedure using a pass-through query in Access I get an authentication error.
Access has no problem quering either database when I use the passthrough and either DSN, it's only when I try to execute the stored procedure.
It almost seems like the DSN connection can't pass on the credentials to the linked server via the current DSN server.
The user is a member of domain admins, has full rights to both sql servers and I'm using Integrated Security on both DSNs.
Sounds like a classic double hop issue. The article Configuring Linked Servers for Delegation discusses how to work around this. But you'll note that one of the first requirements listed is:
The user Active Directory property, Account is sensitive and cannot be delegated, must not be selected.
which is almost certainly selected for the domain admin account (or at least, it should be in a well run domain)
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.