I have a dotnet core application running on azure. There are several pages interact with the db and those render fine and without error; however there is one page which executes a stored procedure in the db, which is failing.
After some initial troubleshooting I noticed the error being thrown is "Exception: System.Data.SqlClient.SqlException: Login failed for user username"
Using sql server management studio, I used the application connection string - along with the username and password for username - to connect to the azure db and was able to execute the stored procedure without error - So I'm not sure why I'm getting this problem.
Observations:
Can view pages which fetch data from the database via plain EFcore
code
Page which runs stored procedure fails - "An error occured while processing your request" - This was found to be "Exception:
System.Data.SqlClient.SqlException: Login failed for username"
Can connect to the remote azure DB using sql server management studio and execute the stored procedure using the user account
username
Works fine in development with a local SQL server database (of
course)
Configuring my local dev environment to use the remote Azure DB (connecting with username) throws the same error at the same page
Based on this it seems the problem lies with configuration of the remote DB. Given that username can execute the stored procedure through SSMS -this should mean that it has the right permissions to execute that stored procedure.
Any ideas on what I should check next or how I can go about resolving this will be GREATLY appreciated.
I have a stored procedure that runs a simple select query against a linked server, which runs fine in the query editor. I need this procedure to run every 5 seconds, and have successfully followed the excellent post from Remus Rusanu re calling a stored procedure to run every n seconds and have his sample procedure running fine.
However, when attempting to run my stored procedure containing the linked server query, it fails with an error
Access to the remote server is denied because the current security context is not trusted
I am using "execute as owner" for activation. The remote (linked) server uses Windows Authentication Mode, and is in the same domain. The Windows account I use to logon to the local SQL Server also has rights on the remote server. I don't understand why the stored procedure works in the query editor and not when called via activation.
What am I missing here?
With the Windows 2003 end-of-life data looming next month, I am migrating a legacy application to Windows 2008. This has all gone surprisingly smoothly with the exception of our connection to Indexing Services.
We have two servers, a DB server running SQL 2008 and a Web server. Our web application allows users to search a document store. Here's the process:
User types in query to web application
Web application sends a query to the database server
The query references the web application as a linked database server and loads the retrieved paths into a temporary table
The database server joins those paths against another table in the SQL server
The database server sends the results back to the web application
The web application shows the results to the user.
The web application logs in via SQL authentication to the DB server to perform the query, but it fails with this error:
An error occurred while preparing the query "SELECT PATH FROM "10.0.1.89".MyCatalog..SCOPE('DEEP TRAVERSAL OF "C:\Documents"') WHERE (FREETEXT(Contents, 'introduction')) OR (FREETEXT(FileName, 'introduction'))" for execution against OLE DB provider "MSIDXS" for linked server "Filesystem".
The same error is displayed when I attempt to execute the query when logged in as this user on the DB server through SSMS, but with some extra information:
OLE DB provider "MSIDXS" for linked server "Filesystem" returned message "Invalid catalog name 'MYCATALOG'. SQLSTATE=42000 ".
Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "MSIDXS" for linked server "Filesystem" reported an error.
Access denied.
Msg 7321, Level 16, State 2, Line 1
An error occurred while preparing the query "SELECT PATH FROM "10.0.1.89".MyCatalog..SCOPE('DEEP TRAVERSAL OF "C:\Documents"') WHERE (FREETEXT(Contents, 'introduction')) OR (FREETEXT(FileName, 'introduction'))" for execution against OLE DB provider "MSIDXS" for linked server "Filesystem".
However, when I log in to SSMS with my Windows Authentication account, I am able to perform the same query and it returns result. My username and password must be the same as an account on the web server - if I change my password on the web server, an error is thrown, but not the same one:
OLE DB provider "MSIDXS" for linked server "Filesystem" returned message "Unspecified error".
OLE DB provider "MSIDXS" for linked server "Filesystem" returned message "Invalid catalog name 'MYCATALOG'. SQLSTATE=42000 ".
Msg 7321, Level 16, State 2, Line 1
An error occurred while preparing the query "SELECT PATH FROM "10.0.1.89".MyCatalog..SCOPE('DEEP TRAVERSAL OF "C:\Documents"') WHERE (FREETEXT(Contents, 'introduction')) OR (FREETEXT(FileName, 'introduction'))" for execution against OLE DB provider "MSIDXS" for linked server "Filesystem".
I created the linked server with this query, which appears to match the configuration of the legacy system:
EXEC sp_addlinkedserver FileSystem, 'Index Server', 'MSIDXS', 'Web';
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname = N'FileSystem', #locallogin = NULL, #useself = N'False', #rmtuser = N'CatalogUser', #rmtpassword = N'xxx';
I created a user on the web server with the name CatalogUser, and I set its password to be the same as the query above.
When I connect with Windows authentication however, this information seems to be ignored and my Windows authentication data is used instead. If I change the password to anything, the query still succeeds.
I have tried enabling CatalogUser to log on as a service account, and this has had no effect.
The two machines are not on a domain, but neither are the two Windows 2003 machines, and that works totally fine.
I must have missed something from the set-up between the two. Unfortunately, these machines were set up long before people started keeping documentation for stuff like this, so I'm not sure what the missing step is.
There isn't very much information about this issue on the internet, presumably due to the age of the software, so at the very least we can start to build a knowledge base here. I wonder if more people are having issues with this software now the end of life is on the horizon.
I have now resolved this issue. I didn't know this, but when you run a program under NT AUTHORITY\LOCAL SYSTEM, it will authenticate over the network as an anonymous user.
To resolve this, I created a new SqlServer user on both the web server and the DB server with the same password. I then configured my SQL Server instance to run under this new user, and it started authenticating correctly.
It seems that any security information entered for the MSIDXS backend is just ignored, although perhaps it wouldn't be if you were joined to a domain. All other documentation I read suggested that was the only way to do this, but it wasn't the case in the original setup and it isn't the case here.
I've a SQL Server Agent Job set up and this job calls a query. When I run the query in SQL Server Management Studio, it works just fine. But when I call it automatically through the job, it gives the following error.
Access to the remote server is denied because the current security
context is not trusted
Please help me out
If this is calling a linked server, this worked for me in a similar situation:
Give ownership of the job to the linked server user (the one that you are using to connect to other server).
In the job, inside each step, go to "Advanced" tab and verify that the "Run as user" field is blank.
If the Stored Procedure the Job Runs is using "Execute as Owner", you may also get that error. Depending on how your permissions are set up, removing the "execute as owner" will resolve this issue.
I am migrating a classic ASP web app to new servers. The database back end is migrating from SQL Server 2000 to SQL Server 2008, and the app is moving from Win2000 x86 to Win2003R2 x64. I am getting the above error on every single stored procedure call within the application.
I have verified:
Yes, the SQL user is set up, using correct username and password
Yes, the SQL user has execute permissions on the stored procedures in the database
Yes, I have updated the TypeLib references to the new UUID
Yes, I have logged into the database via SSMS with the SQL user id and it can see and execute the stored procedures just fine in SSMS, but not from the web app.
Yes, the SQL user has the database set as its default database.
The most frustrating thing is it works fine on the DEV server, but not on the production server. I have gone through every IIS setting 5 or 6 times and the web app is set up precisely the same in both environments. The only difference is the database server name in the connection string (DEV vs prod)
EDIT: I have also tried pointing the prod web box at the dev database server and get the same error so I'm fairly sure the issue isn't on the database side.
Are you sure that you are really connected to the instance and database you think you are (in the App)? It only takes the wrong DB in the connection string to override the default database for the user.
Can you execute some inline SQL on the connection like:
SELECT ##SERVERNAME AS SERVERNAME
,DB_NAME() AS [DB_NAME]
,CURRENT_USER AS [CURRENT_USER]
It might be the schema. Have you set the default schema of your user in the database you are using?